game-editor.com

Hi.

How do I make it so that a character walks, say, 32 pixels only (basically, from middle of tile to middle of next tile, even if the key is depressed immediately, or pressed for a long time?

And how do I slow the speed of walking down, but still retain the same distance?

In other words, I want the character walk fairly slowly from only from the middle of one tile to the middle of the next one and only count "key pressed" when arriving in the middle of the next tile.

Much appreciated!

One idea I thought of for that is to set up so thatn the key down events change the animation. You'd need to make separate diagonal animations.
On key up, change to the stopped animation, but use the wait for frame command to do it only when the animation finishes. Make the animation be long enough to cover one tile distance. On draw actor, use a switch to move the actor according to the animindex.
The other thing would be on animation finish, if the key is no longer pressed, change to the stopped animation. You could also use this to check if the space in that direction is occupied, so you don't have problems with bumping into walls.

On key up, change to the stopped animation, but use the wait for frame command to do it only when the animation finishes. Make the animation be long enough to cover one tile distance. On draw actor, use a switch to move the actor according to the animindex.

Uhm... Could you explain in detail? Use a switch where, how? What's animindex?

What does the wait for frame command do?

To use a switch:

Code: Select all

switch(integer)
{
    case 0:
    code here;
    break;
 
    case 1:
    case 2:
    code here;
    case 3:
    more code here;
    break;

    default:
    code here;
    break;
}

more here:http://www.imada.sdu.dk/~svalle/courses/dm14-2005/mirror/c/subsection3_8_2.html#SECTION0008200000000000000
animindex is a variable that shows which animation is on the actor:http://game-editor.com/docs/script_reference.htm#animindex
If you use wait for frame instead of immedeate action, you can delay the action untill a certain frame of a certain animation.
I will try and make a quick demo.

Could you possibly write me a sample script? Because I still don't get where I should put the switch statement, what to check with it, and what "wait for frame" will do to the animation in this particular case - and why do I need diagonal animation?


I've only had GE for 2 days.


By the way, which tiles are easier to use in the long run in terms of calculations - (I wanna do something for the GP2X) - 32 x 30 tiles (which fit the screen perfectly) or 32 x 32 Tiles, where 2 pixels are always chopped off, but which have equal heigh and length? Because I've been thinking about a "strategy mode", where I'll have to somehow calculate a grid. No idea how to go about that one. Hm.


By the way, while on subject, can you make animated tiles?

Thanks. Sorry about the diarrhea of questions.

First, I'd say square tiles are better, but it depends on how you are using it. Currently, you cannot have animated tiles, but you can have separate clones. I've made a simple demo, but due to server problems I can't upload it yet. Using the method I am using, You need animations if you want to be able to walk diagonally, but it would be hard to set up right, without using diagonal keys, so I have it so you only walk in four directions.

First, I'd say square tiles are better, but it depends on how you are using it.

In the "walk around" mode, I just walk from tile to tile. They might look odd if they get cut off, especially if the view is centered on the player. Or even odder if I have "zelda-style" screenshifting. I'll give it a whirl if I can set up the whole grid-walking thing.


Another mode I was playing with was a "strategy mode", where a player gets movement points (and so do the enemies). Player moves, again, on tiles. One tile = one step. So, I'll have to find a way to calculate each move, then do something like

Code: Select all


void Move()
{

  CheckIfSpaceThatYouMoveToIsUnoccupied();

  if (PlayerMoves > 0)
         PlayerMoves --;
         Move();

  else if (PlayerMoves == 0)
   {
      PreviouslyDefinedFunctionToEndTurn();
   }
}

That's pretty easy, but I'll have to have the AI calculate its steps and distance toward the player as well. So, I need some kind of grid counting system. A matrix or something? Any ideas?

I'll also need some kind of checking system, for obstacles or enemies, because otherwise I'll move through them. That's why I asked if the height of the tiles should be the same as width - would that make calculations easier?

Currently, you cannot have animated tiles, but you can have separate clones.

Yea, I noticed, that's why I asked. It's a real pain to clone tiles as actors. And animated water just looks good.

I've made a simple demo, but due to server problems I can't upload it yet. Using the method I am using, You need animations if you want to be able to walk diagonally, but it would be hard to set up right, without using diagonal keys, so I have it so you only walk in four directions.

Diagonal seems too much of a hassle anyway.

Please?

I want to make some tiles, and I'd rather know.

And I need at least an idea for calculating grid stuff.

Another mode I was playing with was a "strategy mode", where a player gets movement points (and so do the enemies). Player moves, again, on tiles. One tile = one step.

With the way I'm doing it, this will be easy, just decrease a count variable in the appropriate place, and if it is zero, end the turn.

That's pretty easy, but I'll have to have the AI calculate its steps and distance toward the player as well. So, I need some kind of grid counting system.

That shouldn't be too hard, basically you need to know where the enemy needs to walk to, and then it's not too hard to make him walk in tiles. The tricky part would be finding a path-finding algorithm to make him navigate around obstacles.

I'll also need some kind of checking system, for obstacles or enemies, because otherwise I'll move through them.

The way I'm doing it, I use the CollisionFree function to check the point you are trying to move too. This means that any actor that obstructs the square that has collision state enabled will stop you.

Can you possibly post a demo?

savefile is having server problems, so I uploaded it to yourfilelink: http://www.yourfilelink.com/get.php?fid=163260
I have tried to put comments in it, to make it more clear, but if you have questions, feel free to ask.

Thanks. I'll have a look at it tonight. (8 PM here in Sydney).

Cool code, I love how the KeyDown just changes the animation, and the drawactor moves based on that.

Some things I don't understand:

1) Why, in the first switch of DrawActor, you only move x+=2 instead of 32?

2) Furthermore, I don't understand the whole afin variable and how the animation finished thing fits in and works.

Not sure if the animation finished variable called afin, but I think it is. Why is it incremented, what's it used for? Does it have to do with frames of the animation?

An explanation of that would be really good.

It only moves two in draw actor, to get a slow walk. It means that each frame whith the correct animation, you will move two pixels, and with two pixels each frame, the animation finishes at about thirty-two pixels.

The case3 on the switch with afin I originally had in animation finish, but it happened a bit too early, so I made a variable to delay it. When the animation finishes, it sets afin to one. In the draw actor, if afin is one or two, it increases it by one. If it is three, it does the check to stop the animation.

It only moves two in draw actor, to get a slow walk. It means that each frame whith the correct animation, you will move two pixels, and with two pixels each frame, the animation finishes at about thirty-two pixels.

The case3 on the switch with afin I originally had in animation finish, but it happened a bit too early, so I made a variable to delay it. When the animation finishes, it sets afin to one. In the draw actor, if afin is one or two, it increases it by one. If it is three, it does the check to stop the animation.

lemme see if I get this:

The user pressed a key. GE catches it and changes animation accordingly to walking, previously checking for collisiong (walls).

The action then goes into DrawActor, where the animation is displayed as "wait for frame", each frame advancing the player 2 pixels in a given direction, the number of frames & pixels ending up at 32 pixels.

- Don't the walking animations have 8 frames though? That would be 16 pixels.

So, this goes on until the animation is finished, at which point afin is set to 1. The whole purpose of the afin variable is to give it a second or two after the animation finishes to sync things.


The second switch checks whether a key is depressed, or whether we're facing a wall. If not, the animation goes on again, if yes, it's set to stop.


I'm not sure whether the second switch is executed every time we advance 2 pixels per frame?