Behaviours, components and states.
Behaviours, components and states.
Hello,
I am coding this simplified platformer thing with Mario jumping up and down in a tiled map same size as my screen. The map is made of tiles. Only two types, air and ground. You can go through air but not through ground. Simple enough..
Now, my issue is that, no matter what game I make, it always ends up being a f*** mess in no time. This is due to 2 reasons I believe: 1) I am not very intelligent 2) I don't know how to program games.
People that know how to program games know how to
1) use classes properly, with shallow inheritance + composition combos such as HAS A / IS A. I think I know this
2) simplify complexity by using techniques that are common among all languages such as: state machines and object-component systems.
Now my question is: What is the difference between a state and a behaviour/component? In my game I give my guy an array of behaviours so that there can be multiple behaviours assigned to a particular entity (in this case, the guy) at the same time. These are: 1) fall and 2) collide. Meaning that my guy is always under the constant pull of gravity and is also always checking for collisions.
Now what about jumping? My game turned accidentally into a bloody FlappyBird clone due to the ability of the player to jump even at mid-air. I want the player to be able to jump only when colliding (or when on the floor). HOW TO ACHIEVE THIS IN A CLEAN WAY?
Should I add a state machine with states? and would that merge well with my behaviours? Can you have both? My behaviours are just things that you call the .execute() method of, in a particular class (in my example: the player) so the player.update() calls .execute() of each behaviour. NOW, how are states different? at the end of the day they are still things that you call the .execute() method of.
**********************************
**************SUMMARY*************
**********************************
Could any of the pros here, post a pseudo-code example of a typical Player() class with states AND components OR something completely different that I don't know about that makes the logic neat, easy to understand and fun to code. e.g. addBehaviour functions, basic variables to keep track of position, etc etc
Thank you for reading and sorry for the rant.
I am coding this simplified platformer thing with Mario jumping up and down in a tiled map same size as my screen. The map is made of tiles. Only two types, air and ground. You can go through air but not through ground. Simple enough..
Now, my issue is that, no matter what game I make, it always ends up being a f*** mess in no time. This is due to 2 reasons I believe: 1) I am not very intelligent 2) I don't know how to program games.
People that know how to program games know how to
1) use classes properly, with shallow inheritance + composition combos such as HAS A / IS A. I think I know this
2) simplify complexity by using techniques that are common among all languages such as: state machines and object-component systems.
Now my question is: What is the difference between a state and a behaviour/component? In my game I give my guy an array of behaviours so that there can be multiple behaviours assigned to a particular entity (in this case, the guy) at the same time. These are: 1) fall and 2) collide. Meaning that my guy is always under the constant pull of gravity and is also always checking for collisions.
Now what about jumping? My game turned accidentally into a bloody FlappyBird clone due to the ability of the player to jump even at mid-air. I want the player to be able to jump only when colliding (or when on the floor). HOW TO ACHIEVE THIS IN A CLEAN WAY?
Should I add a state machine with states? and would that merge well with my behaviours? Can you have both? My behaviours are just things that you call the .execute() method of, in a particular class (in my example: the player) so the player.update() calls .execute() of each behaviour. NOW, how are states different? at the end of the day they are still things that you call the .execute() method of.
**********************************
**************SUMMARY*************
**********************************
Could any of the pros here, post a pseudo-code example of a typical Player() class with states AND components OR something completely different that I don't know about that makes the logic neat, easy to understand and fun to code. e.g. addBehaviour functions, basic variables to keep track of position, etc etc
Thank you for reading and sorry for the rant.
-
- Posts: 52
- Joined: March 10th, 2015, 7:51 pm
- Location: Romania
- Contact:
Re: Behaviours, components and states.
A state machine would be the best thing to do. Another thing would be creating different states as bool variables (this would help you mess the code up more if you want additional states)
If you want anything more concrete ask
If you want anything more concrete ask
“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.”
– Martin Golding
– Martin Golding
-
- Posts: 4373
- Joined: February 28th, 2013, 3:23 am
- Location: Oklahoma, United States
Re: Behaviours, components and states.
I think you should watch Intermediate lessons 10+ I think. Chili covers this exact thing actually.
A state is a player moving left, right, jumping or standing idle, etc. There can also be alive and dead for example. When the player dies, there are specific things that happen. Their state changes to dead, the number of lives is decreased and the players position is reset to the beginning of the level or the most recent checkpoint. Then the players lifestate is changed to Alive and then their actionstate is changed to idle. When the player presses the left button the players actionstate is changed to MovingLeft or Left. Now while the players state is MovingLeft, subtract some number from players X position.
Basically, a state machine will once per period, say once per frame, check for something to change causing a state change, like the left button being pressed. While in that state, it only runs that code that pertains to that state. Once the state is changed only that code in that state is ran, but will only be changed once per period.
A state is a player moving left, right, jumping or standing idle, etc. There can also be alive and dead for example. When the player dies, there are specific things that happen. Their state changes to dead, the number of lives is decreased and the players position is reset to the beginning of the level or the most recent checkpoint. Then the players lifestate is changed to Alive and then their actionstate is changed to idle. When the player presses the left button the players actionstate is changed to MovingLeft or Left. Now while the players state is MovingLeft, subtract some number from players X position.
Basically, a state machine will once per period, say once per frame, check for something to change causing a state change, like the left button being pressed. While in that state, it only runs that code that pertains to that state. Once the state is changed only that code in that state is ran, but will only be changed once per period.
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com
Re: Behaviours, components and states.
Thanks guys, I have already watched those videos but I don't really get it. Chili's state machine is too complex. Could anyone write on here the backbone of a very simple state machine, for Player with lets say.. 3 states. Idle walk and jump?
Sorry for asking and asking but I am very confused as to what to actually write
Sorry for asking and asking but I am very confused as to what to actually write
Re: Behaviours, components and states.
NOw getting what Chili was on about
http://gameprogrammingpatterns.com/state.html
edit: but now I don't know whether jump, walk and idle are states or behaviours. And what should be a behaviour and what a state
http://gameprogrammingpatterns.com/state.html
edit: but now I don't know whether jump, walk and idle are states or behaviours. And what should be a behaviour and what a state
-
- Posts: 4373
- Joined: February 28th, 2013, 3:23 am
- Location: Oklahoma, United States
Re: Behaviours, components and states.
Really, do you need to differentiate between the two. The player will behave a specific way for the state the program is in.
Would take a bit of time to write a state machine that encompasses all what you would need to know really. You already have 3 states you want to know about.
This is the simplest way I could write it. There are other ways such as making each state a different class so that player.state would have a Do function that would specifically do what you asked it to do as opposed to using another set of if statements in the DoState function, like chili did.
You can have state machines for all parts of your program. For instance, game states or screen states would control which screen you are showing, title screen, game over screen, menu, actual game play screen. Your player would have the left, right and jump states. Your enemies could have the left, right, jump and shooting state or whatever.
You would define behavior, what the object does, while in that particular state. Say you have multiple sets of idle animations you want to choose from. You could have your state as idle, and then have the program choose which set of sprites to animate. I think it will be like a state inside of a state, a sub state.
Would take a bit of time to write a state machine that encompasses all what you would need to know really. You already have 3 states you want to know about.
Code: Select all
void UpdateState(KeyboardClient &kbd)
{
if(kbd.KeyIsDown(VK_LEFT))
{
player.state = left;
}
else if(kbd.KeyIsDown(VK_RIGHT))
{
player.state = right;
}
else if(kbd.KeyIsDown(VK_SPACE))
{
player.state = jump;
}
else
{
player.state = idle;
}
}
void Player::DoState()
{
if(state == left)
{
x -= 1.5f;
}
else if(state == right)
{
x += 1.5f;
}
else if(state == jump)
{
y += 2.0f;
}
}
You can have state machines for all parts of your program. For instance, game states or screen states would control which screen you are showing, title screen, game over screen, menu, actual game play screen. Your player would have the left, right and jump states. Your enemies could have the left, right, jump and shooting state or whatever.
You would define behavior, what the object does, while in that particular state. Say you have multiple sets of idle animations you want to choose from. You could have your state as idle, and then have the program choose which set of sprites to animate. I think it will be like a state inside of a state, a sub state.
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com
Re: Behaviours, components and states.
Code: Select all
Really, do you need to differentiate between the two.
I think object/component model is different from states and state machines. So I am trying to implement both in my game. How to do that though? that is the question
Thanks for the help on the state machine though! I made a massive switch statement and it works pretty well. Now, not sure hot to implement collisions (don't know whether it's a state thing or a behaviour thing.. ..confused)
Re: Behaviours, components and states.
The behavior would be the map handling collision. The state would be standing/walking/running(however you set states up).
The state handles the behaviors.
The state handles the behaviors.
Computer too slow? Consider running a VM on your toaster.
-
- Posts: 4373
- Joined: February 28th, 2013, 3:23 am
- Location: Oklahoma, United States
Re: Behaviours, components and states.
Clodi wrote:
I think object/component model is different from states and state machines.
object/component model sounds more like a programming paradigm of Object oriented programming. Thing is, you can use object oriented programming to make state objects, as chili does in his state machine.
As far as collision goes...just have a function or so that can detect and handle the collisions.
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com
Re: Behaviours, components and states.
The component model is the idea of, instead of having a deep inheritance structure, perhaps with multiple inheritance, having a container class (like an 'Agent' class) that has pointers to components which handle different domains (like 'Physics', 'Graphics', 'AI', 'Dialogue', etc.) The components have shallow and broad inheritance, and by mixing and matching different components you can get good code reuse without tangled inheritance relationships.
Chili