Behaviours, components and states.

The Partridge Family were neither partridges nor a family. Discuss.
Clodi
Posts: 175
Joined: November 18th, 2012, 7:47 pm

Behaviours, components and states.

Post by Clodi » August 2nd, 2015, 12:50 am

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. :D

superstar1998
Posts: 52
Joined: March 10th, 2015, 7:51 pm
Location: Romania
Contact:

Re: Behaviours, components and states.

Post by superstar1998 » August 2nd, 2015, 1:17 am

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 :)
“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.”

– Martin Golding

albinopapa
Posts: 4373
Joined: February 28th, 2013, 3:23 am
Location: Oklahoma, United States

Re: Behaviours, components and states.

Post by albinopapa » August 2nd, 2015, 8:48 am

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.
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

Clodi
Posts: 175
Joined: November 18th, 2012, 7:47 pm

Re: Behaviours, components and states.

Post by Clodi » August 2nd, 2015, 3:48 pm

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

Clodi
Posts: 175
Joined: November 18th, 2012, 7:47 pm

Re: Behaviours, components and states.

Post by Clodi » August 2nd, 2015, 8:45 pm

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

albinopapa
Posts: 4373
Joined: February 28th, 2013, 3:23 am
Location: Oklahoma, United States

Re: Behaviours, components and states.

Post by albinopapa » August 2nd, 2015, 9:50 pm

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.

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;
     }
}
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.
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

Clodi
Posts: 175
Joined: November 18th, 2012, 7:47 pm

Re: Behaviours, components and states.

Post by Clodi » August 4th, 2015, 12:17 am

Code: Select all

Really, do you need to differentiate between the two. 
Yes! :D

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 :shock:

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)

cameron
Posts: 794
Joined: June 26th, 2012, 5:38 pm
Location: USA

Re: Behaviours, components and states.

Post by cameron » August 4th, 2015, 12:23 am

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.
Computer too slow? Consider running a VM on your toaster.

albinopapa
Posts: 4373
Joined: February 28th, 2013, 3:23 am
Location: Oklahoma, United States

Re: Behaviours, components and states.

Post by albinopapa » August 4th, 2015, 3:33 am

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

User avatar
chili
Site Admin
Posts: 3948
Joined: December 31st, 2011, 4:53 pm
Location: Japan
Contact:

Re: Behaviours, components and states.

Post by chili » August 4th, 2015, 4:10 am

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

Post Reply