game state question

I'm bored and was wondering about this so I guess I'll ask. Its ok if asking makes me appear like an idiot, I'm used to it.

Lets say I have a game similar to RC Pro Am for NES. When a car is moving around the track normally:
car_state = 'moving'
when the car hits a tile with arrows on it (a turbo):
car_state = 'using_turbo'
While in the turbo state, the car moves fast but gradually lowers speed over time until it enters the normal 'moving' state again.

So the question that I'm AXING you is... right when you hit that turbo, some things need to happen ONLY ONE time. For example a wav sound 'beeeeooooww' needs to play just ONCE, and the car speed needs to be set to highest just once. Obviously there is a problem if this wav sound plays on EVERY iteration of the 'using_turbo' state when you only want it to happen once.
Is this solution I thought of the 'correct' one?: make a 3rd transition state called something like:
car_state = 'transitioning_to_turbo'
Maybe tie a counter that only counts one time to it so it will play the sound and set speed to max only once, then when the count == 0 switch to the 'using_turbo' state where it speed-=1 every frame until slow enough to enter the normal 'moving' state. ¿Bien?

You can do it in many ways, for instance you could do it without turbo states at all.

Example: When normally moving your movement speed is capped. When you go to turbo you simply put a large boost to speed. As long as your speed is above the capped limit, you reduce it every tick. Also when you hit the turbo platform, you check if the player speed is under "speed limit to turbo", in which case the turbo is applied.

const int MAX_SPEED = 100;
const int TURBO_CAP = 150;

void Tick(){
  if(speed < MAX_SPEED){
    //Normal acceleration
    speed++;
  } else if(speed > MAX_SPEED){
    //If we're above max speed (turbo) -> decelerate
    speed--;
  }
}

void DoIApplyTurbo(){
  if(speed < TURBO_CAP){
    speed += 100;
    PlayVROOOOOM();
  }
}

I'd have it so that the activation of turbo makes the noise and boosts the speed, and then the using_turbo state is for the period of slowing down. When in using_turbo, you can't activate turbo, thus avoiding the problem of having the sound and/or action repeated.

If you don't want to use an FSM, then Jodwin's method is also perfectly valid... and probably the one I'd be more likely to use myself as well.

make sure it doesn't activate for every tic the car is on the speed booster :D

magicsofa said:

make sure it doesn't activate for every tic the car is on the speed booster :D

Lol Doom chainsaw? :-p

magicsofa said:

make sure it doesn't activate for every tic the car is on the speed booster :D

Urrr, that's exactly the reason the thread was posted in the first place.

Phobus said:

I'd have it so that the activation of turbo makes the noise and boosts the speed, and then the using_turbo state is for the period of slowing down. When in using_turbo, you can't activate turbo, thus avoiding the problem of having the sound and/or action repeated.

If you don't want to use an FSM, then Jodwin's method is also perfectly valid... and probably the one I'd be more likely to use myself as well.

My brain sucks at figuring out proper code structure, but now that you wrote that, the solution seems obvious to me now, thanks. (just make the 'once only' stuff happen at the same time as the state change, rather than inside the loop of the state... doi!) My main goal is to learn about states, so maybe a car turbo is a bad example to apply states to, but thanks for that example too, jodwin.

Even a number is like a state as far as I can tell. n=7. Now n is in the 'state' of 7.. I guess that's obvious because 'using_turbo' and 'moving' could just be renamed as 0 and 1 respectively.

I've been thinking of states as a way to turn code blocks on or off sort of. So if you press A, and mario is in the swimming state, he'll swim up and not do any of the jumping code blocks etc.

But you think state is very important in many games? Take street fighter. You think its coded like 'if guile is in jumping_high_kick state and blanka is in fast_rolling_ball state, and they collide, then...' etc (which would be tons of conditions due to all the possible combinations)? I bought a few books but am only 1/10th through the first one.

gggmork said:

But you think state is very important in many games? Take street fighter. You think its coded like 'if guile is in jumping_high_kick state and blanka is in fast_rolling_ball state, and they collide, then...' etc (which would be tons of conditions due to all the possible combinations)? I bought a few books but am only 1/10th through the first one.

Fighting games use hitboxes. Basically each frame of animation has lots of different hitbox areas attached to them like "this part damages the enemy" and "this part takes damage". Then during each tick the game checks if the players' hitboxes collide and acts accordingly. It's a (mostly) data driven design and the code needs to know nothing what particular state the characters are in (unless there's an actual hit, in which case characters in mid-air get bounced back while characters on ground do not).

I'll be honest, states are at best used for simple AI rather than anything else IMO. Things like actions, collisions and movement are things I'd all leave down to spur-of-the-moment code.

A good example of states is DECORATE, actually. When a monster is idle it's playing a simple animation and calling a code pointer to the look behaviour. When it's walking it's actually again doing an animation and calling a code pointer to the chase behaviour.

To use your example, Street Fighter is probably only state-based in that it says when the player is in the air or not, and possibly whether or not it's blocking. I can't be certain though, as I've never worked on a fighting game myself.

"Fighting games use hitboxes. Basically each frame of animation has lots of different hitbox areas attached to them like "this part damages the enemy" and "this part takes damage"."

My guess is 'damaging' hitboxes can have varying degrees of power or something? Because a dragon punch can collide with a high kick, but the dragon punch usually wins. Actually I noticed something weird in street fighter. If both players are ken and both do a dragon punch at eachother at exactly the same time, neither will be hurt. If ken A does a dragon punch then ken B does a dragon punch, I'm pretty sure ken B will win and only A will get hit, so in addition to damaging hitboxes, timing also seems to play a role. Its subtle little shit like that that always seems impossible to code for me.

"I'll be honest, states are at best used for simple AI rather than anything else IMO. "

I guess AI implies the behavior of a non-player-controlled character, like a megaman boss or something that changes from 'hanging on ceiling' to 'rolling around on floor' or whatever. Mario is completely player controlled, so doesn't need AI I guess, but 'swimming' vs. 'standing on ground' states would be useful anyway (like 'in air'/'blocking'/'on ground' seem to be states for street fighter characters even though they're player controlled?

I probably just need to read more programming books. I was hoping states would be a key to let me finally wrap my mind around building somewhat complex interesting games but I guess not now.

gggmork said:

I guess AI implies the behavior of a non-player-controlled character, like a megaman boss or something that changes from 'hanging on ceiling' to 'rolling around on floor' or whatever. Mario is completely player controlled, so doesn't need AI I guess, but 'swimming' vs. 'standing on ground' states would be useful anyway (like 'in air'/'blocking'/'on ground' seem to be states for street fighter characters even though they're player controlled?

You can have the player set into a state, certainly. If you've played Metroid Prime, then two obvious state distinctions would be when the player is using the Morph Ball and when they're running around as an FPS.

The thing with all this is that there never is one "right" answer. Many problems can be solved in a variety of ways, each with their own merits and limitations.

Labeled states like "mario_running" or "robot_shooting" aren't necessarily the most common way to represent it, but in some form or another there is always a ton of mutable state in the way modern games tend to be programmed

Fighters usually handle hitboxes by having at least 3 different kinds; collision box that does nothing but prevent characters overlapping, hittable boxes and various forms of attacking boxes (physical hits, grab boxes, projectiles etc. may each be separate types that behave differently); if one of player 1's hittable boxes overlaps one of player 2's attacking boxes onscreen then player 1 recoils and takes damage (or goes into a grabbed state or whatever) and vice versa. In general most games have no concept of hitboxes beating each other out based on set strengths (save basic stuff like "you can't reflect a super projectile"), it's based entirely on the shape/positioning of the boxes and where they are/are not in each frame of an attack; Street Fighter dragon punches for example have the "weird behavior" you described because they're usually invincible early in the move which is implemented by giving the move attacking boxes but no hittable boxes on the frames until you want it to start being vulnerable.

Jodwin said:

Urrr, that's exactly the reason the thread was posted in the first place.

Oh yeah. I'm not really sure how I missed that. I'm gonna go drink some hard cider now.

Infinite Ammunition said:

stuff

It's very interesting to learn that one of my favorite games is based on that simple elegant system. It's too bad many classic games have secrets locked in proprietary code and its hard to google their inner workings too. Do you have some sort of book recommendation or website that helped you learn this type of stuff?
What about punchout on nes. It's quasi-3d perspective means there's no 'colliding' hitboxes, pixel by pixel, per se, so my guess is each frame of the enemy's punch is given a depth value and if that depth value number 'collides' with (equals) the depth value number of the player's head, then he gets hit.

gggmork said:

What about punchout on nes. It's quasi-3d perspective means there's no 'colliding' hitboxes, pixel by pixel, per se, so my guess is each frame of the enemy's punch is given a depth value and if that depth value number 'collides' with (equals) the depth value number of the player's head, then he gets hit.

Punchout could as well use states or something similar, it doesn't need any kind of collision checks as there's no real movement.