Three-Frame Walkabouts?

[eaagvark]

What's the best way to give heroes three frames of walkabouts (like in FF6)?

Obviously a hero's picture has to be changed in order to add the extra frame, but if I want to be in complete control of how/when the picture changes, how do I stop the default frame toggling from interfering? Am I right in assuming that the standard 'walk hero' command would be useless for this? I'd basically have to use several instances of the 'put hero' command?

For moving one tile, something like:

put hero 5 pixels to the right
wait
change hero picture (to one putting its right foot forward)
put hero another 5 pixels to the right
wait
put hero another 5 pixels to the right
wait
change hero picture (to the original stationary one)
put hero another 5 pixels to the right
wait

And then a slightly different one for every other step that uses the 'left foot forward' picture?

I guess that's pretty doable, but I thought there might be a simpler way.

This would also require suspending the player from the beginning of the game, I think... so I'd also have to write scripts to replace the standard "escape opens the menu" and "spacebar activates an NPC in front of you" inputs? I think I know how to do all of that, but I just wanted to check if it's the best way.

[Bob the Hamster]

I think there is a demo script for 3-fram walking somewhere on the gamelist.

Personally, I would attach a sprite slice to the walkabout slice. I would hide the normal walkabout sprite, and do all the animation on the manually attached sprite slice.

That way I get total control over the animation frames, but I don't have to do anything at all regarding the positioning or movement of the walkabout on the map.

EDIT: Oh, here is the example script: http://rpg.hamsterrepublic.com/ohrrpgce ... me_walking

[kylekrack]

I'm doing this for my next game. I hate 2-frame walkabouts. I was never quite sure what the best way would be, however.

Also, to expand on that, you'll want to either set the hero sprite's visibility off or just assign it a sprite that has nothing drawn. Then when the game starts you load a walkabout sprite and parent it to the hero sprite (which is now invisible). In the game's main loop, or in a keypress handler, you have the script check if the hero is walking or if a directional key was pressed, then check the direction and either set the sprite's frame accordingly or replace the walkabout sprite (because you will need 12 frames, which will take up more than one spriteset).

If you do this with a while loop, you will likely need to use timers to activate the animations, but if you prefer to use wait commands, an on keypress script should be able to use waits and not be interrupted.

EDIT: I assume this would work just as effectively if you used hero sprites instead of walkabouts, no? I feel like that would be an easier alternative to the walktall scripts I've seen.

EDIT EDIT: Well the example script here finally loaded for me. That makes more sense than what I said.

[eaagvark]

Hmmm... I haven't played around with slices yet (since they weren't a thing the last time I used the OHRRPGCE), but maybe they would make things easier.

It sounds like there are a few ways to do this, which is good to know. And those example scripts are cool - I didn't notice them before.

Actually, it's mostly the up-down walkabout animations that are annoying to me (since stationary NPCs/heroes often look like they are standing on one foot), so another idea I had (which would definitely work for the game I'm planning) would be to simply not have any vertical movement in the game (e.g. like Valkyrie Profile) - and the up/down graphics would just be standing animations, in case characters ever needed to face those directions.

Thanks for your help!

[kylekrack]

That's totally viable as well. And if you're checking out slices, look at the slice collection editor, it makes organization much easier.

[TMC]

Note that the script on the wiki still uses a two-ticks-per-frame animation. It fact it doesn't change the frame at all, it just loops the spriteset between two adjacent ones to create a longer animation.

If you don't like heroes standing on one foot while still, have a look at http://rpg.hamsterrepublic.com/ohrrpgce ... ding_still

[kylekrack]

Note that the script on the wiki still uses a two-ticks-per-frame animation. It fact it doesn't change the frame at all, it just loops the spriteset between two adjacent ones to create a longer animation.

If you don't like heroes standing on one foot while still, have a look at http://rpg.hamsterrepublic.com/ohrrpgce ... ding_still

Can't you just check if the velocity is 0 at the end of each tick?

[TMC]

Scripts run at the beginning of a tick, before hero movement, not the end of the tick.

As you say, you could instead check "hero is moving" but it tells you what the situation was for the previous tick. That one tick delay creates noticeable glitchiness.

[kylekrack]

Oh crap. Pixel based movement is going to be harder than I thought.

[TMC]

Actually, it's not really a problem if you script your own movement. It's a serious problem only when you want to use builtin movement and you have something that depends on that (like extra animation frames), because you don't know what movement is about to occur (though the "hero will move" script tries to predict it).