I''m working on an isometric rpg. I got the map working (scrolling smootly etc..) and now I''m ready to implement character movement & animation (for the pc''s and npc''s) I want to move the selected character (pc) by pointing & clicking somewhere at the map with the mouse and then the character should walk/move to the iso-cell which was clicked on, but how to make it appear/look like if the character is moving? simply moving it from one iso-cell to another iso-cell every frame will make the character move much too fast and unrealist. So my idea was to make it move from one cell to the next cell using several frames so that it moves smaller steps switching images every frame to make the character appears to walk/drive/etc..., but I think if I do it like this the response of the character will be slower ''cause it needs x frames to move from 1 cell to another and it can''t stop halfway...I think(''cause where would it be then), so is my idea any good or is there a better way to do it? and if I would decide to make the character move by keyboard or joystick (i.e. pressing left makes it move left etc..) then my idea won''t work very well at all I think, ''cause the response of the character will be slow/delayed how would I do it then? any help, ideas would be appreciated very much Christiaan.

Okay I'm no expert.

What I would do is have each frame displayed for several cycles. Say your tile(cell) is 16 by 16 pixels. So you move 16 pixels to get to the next cell, some-how keep track of how many pixels your have travled so far, then display frames accordlinly.

Well, it's like this... You display first frame in animation sequence for 5 cycles, then move, display second animation frame, move, untill you are in the next cell...I'm not sure it would work, like I said I'm no expert.

Just my $0.02

Oh yeah, you could make your function display 30 frames per second. Which I thin would make your animation look realistic.

OR (just poped into my mind) each frame would travel so many pixels...for example first 2 frame travel 1 tile, 3rd and and 4th frame travel the next...start over...

$0.000002





Edited by - CodePlayEatSleep on May 8, 2000 3:44:11 AM

Hi Christiaan,

I would suggest using a timer as performance of PCs may vary, so the frame rate can hardly be the same for two PCs. Place all the movement controls in some fixed numbers of functions, and everytime the time event fires, do updates on the player movements by calling these functions.

Method of CodePlayEatSleep is a good idea as well, just that it doesn''t work for slower machines. You can have your display function called 30 times a second, but on a slower PC, player will appear to move very slow. Not VERY slow, but it does slow down a bit. (Because the frame rate goes down)

Frame rate does change, but time never change. Once the timer of your game is set, it fires at a fixed rate, same on any PCs. Window''s timer event is a good way of doing that.

I''m working on a similar project, and this is actually one of my current tasks. Go figure. :-) The co-ordinate system I''m using is actually pixel-precise, rather than cell-based. This allows for very fine control of where every object is placed, especially for things. Yeah, it adds to the size of things, since all the location numbers need to be 32-bit values (except Z, which I used 16-bit signed integers for).

That said, I''m not going to suggest you rip apart what you''ve written and start over. Try this instead.

You could use a ''degree'' system not dissimilar to what is used in our "real world" geography. Earth is divided into a big 360x360 grid along lines of latitude and longitude. Of course, that''s nowhere near precise enough, so we have fractional ''degrees'' to give us a more accurate point. Using a similar system, you could provide for pixel-perfect locationing of any given object by saying: "Okay, this is at (45''4",31''0"), so I offset the rendering by four pixels on the X axis from the top-left corner of (45,31)." So, let''s say your cells are 16x16 (using CodePlayEatSleep''s example)... moving along the X axis, you would travel from (45''0") to (45''15") before reaching (46''0").

That said, when you want to move an object (a person, in your case) from point A to point B, you can use that pixel-precision to your advantage, and be able to move different characters/monsters at different rates. Prepare for some floating-point calculations as you get into determining trajectory and speed; you will need the ability to say, "okay, this guy moves (2''5") in the space of one second" (or for the sake of our example, 37 pixels). So how do you know how many pixels in X and Y to move every frame? You need to determine how many milliseconds go by for each frame of rendering, and essentially think of it like this:

Frame n:
"Okay, it''s been 40ms since I last checked this character''s movement. Given that the character will move 37 pixels in 1000ms, I know that it takes 27.027ms to move 1 pixel. We''ve definately moved one pixel, and I''m (40-27.027 =) 12.973ms on my way towards the next pixel. I''ll remember that for next time."

Frame n+1:
"Allrighty then, it''s been 47ms since the last frame. I know it takes 27.027ms to move one pixel, and I know we''re also 12.093ms into the next pixel-step... so let''s add this(12.973+47 =) 59.973 then subtract 27.027 from that until we''re under 27.027 (59.973-27.027 =32.946) (32.946-27.027 =5.919). I''ve moved two pixels towards our destination, and I''m 5.919ms on my way towards the next step."


(Hopefully that makes sense. ;-) )


As for animation of the walk sequence, you want to do a similar sort of ''cross-frame counter'' like I''ve described. Let''s say you want 5 frames of walking animation per second (200ms per). Each frame, measure the amount of time since the last "check", and if you cross over the 200ms mark, set the frame you''re going to render to the next frame in your animation sequence. (If more than 200ms has elapsed, then you would actually skip animation frames altogether -- if you''re going less than 5 frames per second, though, there are other issues to address... but at least your characters will still be moving at the speed you want them to :-)


As for determing how far to move in the X and Y axes when you move "one pixel". You need a relative angle (ie. "for every 1 pixel I move +X, I move 0.4 +Y"). Determine this by measuring the X delta over the Y delta (in other words, the difference between your current X/Y, and the one you''re moving to). If you don''t want to get into floating-point positional locations right now, that''s cool. You can just move straight on straight- and 45-degree angles towards your destination X/Y.

Whew. Okay, that''s enough typing for me for now. :-) Hopefully some of this will be of use. Write me at daltorak@elvensoftware.com if you want to discuss the subject further, I''d be happy to hear from you.

Warren.

When working with real-time, you dont want large tiles like the ones turn-based games use (you dont want large tiles the size of the character), instead, use very small tiles, where a character or monster is several tiles wide, its also easier then to have very large monster, so that not all characters/monsters are confined in size to a single tile.

But the way I would actually do it is to not use tiles at all, but make it pixel based. I did this once where I made some bouncing balls inside a pool table. Just think of it as the creatures can be anywhere, and they can have speed. Creature A walks at a rate of 7 pixels/second and Creature B walks at a rate of 12 pixels/second. Then you need to create a timing system and update the movement of your creatures based on how much time has been passed.

Say for example, your getting only 20 frames per second, and its time to update your movement. Creature A is located at pixel (1000,1000) and he is moving left at a rate of 7 pixels per second, so now his new position would be
x_position -= 7 * (1/20);
which = 999.65 Keep the values in decimal form (double), but you when you plot it, store it in a new value that is an int.
x_position_temp (int) = x_position (double)
so the int value would = 999
so the creature will apear on pixel 999 on the screen.

Possibility

If you do it with pixels, rather than tiles, how do you do pathfinding, AI, etc.?

Just a thought...

Trajar

Well, maybe I don''t know what I''m talking about, but if the screen is scrolling then can''t you just make the player stand still in the middle and have the screen scroll behind it? NPCs, of course, would be a differt story. So, it probably would be better to be able to have pixel accurate coordinates

First of all thanks to everyone for helping me!!!

read alot about the pixel based system, but got the idea that it''s not right for me, ''cause I think if I would use a pixel based instead of an cell based engine I can''t use tile graphics anymore, and instead I would have to use a big bitmap for my background (terrain etc..) and my drawing skills aren''t too impressive (that would be an understatement)
I''m making a game based either AD&D Ravenloft (TSR) or Battletech (FASA) and since both games are original tabl top games they are turn-based (aren''t all games technically) and both are cell based.
so I think pixel based is not for me at the moment. Does anyone know impressive ways to do character movement in an iso-based game, or know how the professionals do it?
anyway thabks again for all the replies so far has been helpful and giving me new inspritation

chris

You can easily use tile based graphics with a pixel based movement system. A "tiled" map and PC,NPC,etc which uses a pixelbased system.
I made a "run, jump n'' shoot" type of game once using that method. The maths for calculating which tile that corresponds to the players(or any other objects) pixelbased x,y is very straightforward...

In actual reality, you want to use a combo of both.

Unit positions and movement will be based on pixels, but buildings, trees, map objects ect... will be confined to a tile grid. This is evident in such games such as C & C, if you notice in that game, the building placements are confined to a gride which you can see when finding a spot to lay down your new building.

Also, each unit will in escence create its own little tile where the unit is standing, or I beleive its called a bounding-box. You can read more about this else where, but what it basically is, is that the unit is basically represent by a box, if 2 boxes cannot overlap each other ect... if one unit shoots a bomb, and it lands inside of another units box, than that unit is hit by it, or if the bomb has a radius effect, then it too will create a box, and if the box from the bomb overlaps the box of a unit, then that unit is hit by the bomb.

But in general, if you are making a Real Time game, you have to make almost per pixel movement, or make such small tiles that it seems nearly per pixel, like a tile size no larger then 5 x 5 pixels.

Possibility