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:

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?

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 ;-)

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 ;-)

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.

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?

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.

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.

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.

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 SDLevent (controller) - it's called event, but it's really just input handling. it's a wrapper of SDL as wellworld (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?

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.

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:

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

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.

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.

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.

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.

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.