14 replies to this topic

[ultramailman]

Hello, I want to ask something about state machines.
In the game I am making, I have a struct game_obj that represents game objects, like bricks, trees, people, etc. These objects will either be controlled by the user input, or by AI. These objects will be able to move around as well.
right now i have something like this:

enum state{
	 /* brain states. if the state is STATE_PLAYER, do input handling instead of AI thinking.*/
	 STATE_PLAYER,
	 STATE_WARRIOR,
	 STATE_SNEAKY,
	 STATE_MAGE,
	 STATE_ATTACK,
	 STATE_RETREAT,
	 /* physical states*/
	 STATE_MOVE,
	 STATE_IDLE,
	 /* total number of states*/
	 STATE_LAST
};


struct game_obj{
	 int posx;
	 int posy;
	 float direction;
	 enum state brain_state;
	 enum state physical_state;
};
typedef void (* state_action)(struct game_obj * gobj);
state_action action_map[STATE_LAST];
void player_action(struct game_obj * gobj)
{
	 /* if pressing up, set direction to 90*/
}
void mage_action(struct game_obj * gobj)
{
	 /* do magey thinking and actions*/
}
void move_action(struct game_obj * gobj)
{
	 /* modify posx and posy according to direction*/
}
/*....*/

In this arrangement, I have two states. brain_states is for the AI, or the user if the state is STATE_PLAYER. physical_states are for movement. At first I tried to use only one state to do all of this, but couldn't do it and ended up seperating the mind and body into two states. Are two states enough, or too many? Is there a way to use only one state?

[rip-off]

Are two states enough, or too many?

Is it too many? Yes, if something is superfluous? Is it enough? No, until the requirements are met.

Is there a way to use only one state?

Separate the "controller" logic from the "model".

Example:

struct game_obj{
         int posx;
         int posy;
         float direction;
};

struct human_player {
    enum human_state state;
    struct game_obj *object; // Alternatively, a handle
};

struct computer_player {
    enum brain_state state;
    struct game_obj *object;
};

[Lauris Kaplinski]

In this arrangement, I have two states. brain_states is for the AI, or the user if the state is STATE_PLAYER. physical_states are for movement. At first I tried to use only one state to do all of this, but couldn't do it and ended up seperating the mind and body into two states. Are two states enough, or too many? Is there a way to use only one state?

It is impossible to say whether two states is enough without knowing more about your game logic. But you eventually will find out it yourself if you write the code ;-)

As rip-off told - I strongly suggest separating controllers and models into separate structs.

struct Mind;
struct GameObject {
	int posx;
	int posy;
	float direction;
    int physical_state; /* Idle/moving... */
	struct Mind *mind;
};

struct Mind {
	int type; /* Player/AI/... */
	int state; /* Attacking, retreating... */
	struct GameObject *object;
};

Two-way link between mind and body allows you to go easily in both directions - from mind (for example planning) to movement and from body (for example collision hit) to mind.

[ultramailman]

Are two states enough, or too many?

Is it too many? Yes, if something is superfluous? Is it enough? No, until the requirements are met.

Is there a way to use only one state?

Separate the "controller" logic from the "model".

Example:

struct game_obj{
		 int posx;
		 int posy;
		 float direction;
};

struct human_player {
	enum human_state state;
	struct game_obj *object; // Alternatively, a handle
};

struct computer_player {
	enum brain_state state;
	struct game_obj *object;
};

In this arrangement, I have two states. brain_states is for the AI, or the user if the state is STATE_PLAYER. physical_states are for movement. At first I tried to use only one state to do all of this, but couldn't do it and ended up seperating the mind and body into two states. Are two states enough, or too many? Is there a way to use only one state?

It is impossible to say whether two states is enough without knowing more about your game logic. But you eventually will find out it yourself if you write the code ;-)

As rip-off told - I strongly suggest separating controllers and models into separate structs.

struct Mind;
struct GameObject {
	int posx;
	int posy;
	float direction;
	int physical_state; /* Idle/moving... */
	struct Mind *mind;
};

struct Mind {
	int type; /* Player/AI/... */
	int state; /* Attacking, retreating... */
	struct GameObject *object;
};

Two-way link between mind and body allows you to go easily in both directions - from mind (for example planning) to movement and from body (for example collision hit) to mind.

Interesting. Seeing as both of you suggest seperating them, I'd like to know if this is common practice/pattern. Also, what are the advantages of seperating them like this?

[rip-off]

The Model, View, Controller pattern (or MVC) is common in general, and is often applied to games. The advantages are separation of concerns - each structure and its associated functions can concentrate on the task at hand. Googling for "MVC advantages" gives lots of promising results.

[ultramailman]

The Model, View, Controller pattern (or MVC) is common in general, and is often applied to games. The advantages are separation of concerns - each structure and its associated functions can concentrate on the task at hand. Googling for "MVC advantages" gives lots of promising results.

Thanks, I've never heard of this term. This sounds similar to the component pattern I read about here. Are they the same thing with different names?

[rip-off]

I haven't used components myself, but my understanding is that they are more fine grained than MVC. The goal is similar, to reduce the amount of code that cares about a particular responsibility or concern. It may be possible to do both.

Note that both MVC and components are design decisions that make sense for games at a certain scale. An important engineering decision is whether your game is complex enough to require such an architecture. Again, I may be incorrect but from reading I sense that components only make sense for "bigger" games, while personally I've found MVC is good for intermediate sized games.

[BrentChua]

This is my own interpretation but i'll share my thoughts on MVC and Component design pattern.

You can think of MVC as a sub-set of the Component object model. MVC can be broken down into three main components:

Model - Data Component
View - Rendering Component
Controller - User/AI Input Component

MVC was made to try to explicitly separate the data, visual, and modifiers. While Components is more of a way to try to group specific functions. Some examples of a component would be:

Transform Component - Manages linear transforms
Camera Component - Handles all the camera specific functionalities
Text Renderer - Handles all text renderings
Model Renderer - Stores all the needed data buffers such as vertex buffers, index buffers, shaders, materials, textures AND handles the rendering of these data.

Notice that some of these components such as the Model Renderer not only store the data but also handles the rendering(view) and manipulation (animation - controller) of its data. But you can also make it such that inside the Model Renderer Component it breaks it into an MVC for storing, rendering, and manipulating data.

Just as what rip-off said, it depends on how complex your game is. But if you're also writing code to be reused later in your future projects, it might be better to do both.

To give you a better idea, the engine i'm currently developing uses something similar to MVC for the high-level application level functions and a component object model for my Actors(GameObjects).

My high-level application is composed of three main systems; The application, logic, and view layer.

Application layer - Manages all the low-level system data such as file system, renderer, process manager, input devices, and other OS specific systems.
Logic - Handles my game logic specific code. How do game objects react, all the rules in my game, etc2x.
View - Basically my rendering layer.

Inside my logic it manages all my actors and each of my actors contains components required to do their specific behaviors. A very simple scene example would be:

Actor1 - Contains Camera Component
Actor2 - Contains Model Renderer Component

Actor1's camera component is responsible for setting up all the requirements for rendering such as the view, project, camera culling. Actor2's model renderer component uses the info provided by Actor1's camera component to fully render the model.

Finally my renderer doesn't have to worry anything and just presents the rendered image to the screen.

LOL! I didn't mean to have this long explanation. But i hope this helps you understand more about MVC, and the Components design pattern a bit.

Edited by BrentChua, 19 October 2012 - 11:28 AM.

[ultramailman]

An important engineering decision is whether your game is complex enough to require such an architecture. Again, I may be incorrect but from reading I sense that components only make sense for "bigger" games, while personally I've found MVC is good for intermediate sized games.

Yes, I do try not to impose a pattern into the game. Recently though, it feels like making a game turned into making a game engine. I constantly find myself trying to make the game "modular" and "easily extensible", and all those nice things. On the art side, all I have is a sprite sheet for blue bricks :\

This is my own interpretation but i'll share my thoughts on MVC and Component design pattern.
.....
..........
...............
LOL! I didn't mean to have this long explanation. But i hope this helps you understand more about MVC, and the Components design pattern a bit.

After reading about MVC and your explanation, I realized the game I am making already uses it, if I am not mistaken. It has three main modules:

video (view) - functions to render things. actually just a wrapper of SDL
event (controller) - it's called event, but it's really just input handling. it's a wrapper of SDL as well
world (model) - has a list all the loaded game objects

As for using MVC with game objects, should the three parts be strongly seperated, or loosely seperated, and allow the any of the parts to easily reach the other two parts?

strong seperation:

struct game_obj{
	 struct model model;
	 struct controller controller;
	 struct view view;
};
void render(struct view *);
void control(struct controller *);
void update(struct model *);

or weak seperation, where one can obtain the other two parts by typecasting the pointer:

struct game_obj{
	 struct controller{
	 	 struct model{
	 	 	 struct view{
	 	 	 };
	 	 };
	 };
};
void render(struct view *);
void control(struct controller *);
void update(struct model *);

I realize this is no longer just about state machines, but I hope it's still fine to ask it in the same thread.

[BrentChua]

Hi ultramailman,

Sorry for the delayed response. Had a bit of a... "complication in life" last week. But if you still want my help the first code sample more resembles to your requirement than the second one. I'm not sure if your second option is fairly common in c programming but it seems it would look ugly scattered everywhere in your code. The second one more resembles an inheritance than a composition of MVC. Let me know if you need further clarification.

[ultramailman]

Hi ultramailman,

Sorry for the delayed response. Had a bit of a... "complication in life" last week. But if you still want my help the first code sample more resembles to your requirement than the second one. I'm not sure if your second option is fairly common in c programming but it seems it would look ugly scattered everywhere in your code. The second one more resembles an inheritance than a composition of MVC. Let me know if you need further clarification.

Hello Brent,

The second code segment is just a dirty way to access the other parts, no inheritence was intended.
Better example to replace the mess that was the previous example:

struct model{
	 struct controller * c
	 struct view * v;
};
struct controller{
	 struct model * m;
	 struct view * v;
};
struct view{
	 struct model * m;
	 struct controller * c;
};

Here, I can easily access the model from the view, or the controller from the model, etc. Should easy communication like this be allowed in MVC, or is it better design to not allow them know about each other at all? Thanks

[BrentChua]

Strictly speaking, no. You would ask yourself how do these systems communicate if none of them know of each other. The (hidden) solution for this to make this work is to actually build another layer that manages the communication between these systems. This is where the event system/manager comes in. The event system is pretty much just a messenger that sends messages to the particular addressee. Or sends the message to those who are only interested in that particular type of message. This way, your model, view and controller doesn't have to know about any of them. They just care about sending all their information to the event system and the event system takes care of sending these info to the other systems interested.

Searching "event system" in google would return three or four links about this subject.

You can check out my simple implementation of an event system here:
http://pulsetec.code...ew/15801#463060
http://pulsetec.code...ew/15801#463062

btw, a more appropriate name for this system is called a listener/dispatcher design pattern.

This is just my suggestion but it might be better for you to use components instead of trying to follow MVC for your game objects. I don't know about the others but from my experience MVC is more used/implemented in defining their high-level applications. Unity for example might use something similar to MVC for the editor and main game systems but their GameObject uses a component object model.

Edited by BrentChua, 27 October 2012 - 12:26 AM.

[ultramailman]

Strictly speaking, no. You would ask yourself how do these systems communicate if none of them know of each other. The (hidden) solution for this to make this work is to actually build another layer that manages the communication between these systems. This is where the event system/manager comes in. The event system is pretty much just a messenger that sends messages to the particular addressee. Or sends the message to those who are only interested in that particular type of message. This way, your model, view and controller doesn't have to know about any of them. They just care about sending all their information to the event system and the event system takes care of sending these info to the other systems interested.

Searching "event system" in google would return three or four links about this subject.

You can check out my simple implementation of an event system here:
http://pulsetec.code...ew/15801#463060
http://pulsetec.code...ew/15801#463062

btw, a more appropriate name for this system is called a listener/dispatcher design pattern.

This is just my suggestion but it might be better for you to use components instead of trying to follow MVC for your game objects. I don't know about the others but from my experience MVC is more used/implemented in defining their high-level applications. Unity for example might use something similar to MVC for the editor and main game systems but their GameObject uses a component object model.

Whew, that what a big project you have there! The names event and listener reminds me of Java, where ActionListener's (something like that) were installed into swing buttons. I assume thats the type of event system you mean?

Anyways, I am using SDL, do you think the SDL events are similar enough that I can cook up some wrapper functions around it to emulate the event system you are talking about?

As for whether to use MVC or component, I still haven't decided yet. I think It will be become clear to me which one to use later on, as I make the game. Maybe I will even end up not using any patterns or paradigms.

[BrentChua]

Right. A general rule of thumb is that only apply a particular design pattern where you see fit. Don't try or force a particular pattern to a problem that wasn't designed to fix that problem. Design patterns normally emerge after implementing the same behavior a hundred times. Then you realize and say: "hey... these part of code more or less do the same thing.I can generalize this part of code and make it like this to make it flexible." And a design pattern is born.

I'm not very much familiar with Java and SDL but i would assume it is so. Only the system is limited to specific actions defined by the system/application. I could be totally wrong though, try to check the documentation if SDL has a way of registering new custom event types.

If you have your own event system, it would be easier to create, attach, and dispatch built-in and game specific events. Though the learning curve may be a bit too steep for you at this moment, i encourage you to learn and try to build one your own nonetheless. You'll be amazed to learn and discover new techniques and tricks after that. Just always remember there's no such thing as a perfect solution/implementation. The first system you'll make may not be as efficient, powerful, and flexible as a commercial grade one, but the experience you'll gain is invaluable and will be used the next time you re-create the system or design and implement a relatively similar one. I rewrote my manager totally from scratch about 7 times i think. I rewrote my Virtual File system at least three times. And each version was about almost two thousand lines of code.

[ultramailman]

So far I've only used it for keyboard input handling, but I remember it also provides the ability to define custom events. Thanks for the advice! Very motivating.