Jump to content
  • Advertisement
Sign in to follow this  
flammable

Design patterns

This topic is 2951 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey, I got 2 questions regarding design pattern related to game programming.

All of my previous projects we're a complete mess (the programming part) but they we're quite small so it was manageble (but it was absolutely no joy to work with). Now I'm planning to make a more complicated game and I want to keep it manageable. I found a power-point about the design of game which was quite good but because there was no speech I think I missed some points.

1) My first question is about a queue design: According to the power-point it is better to let all the game entities communicate with each other through a Queue. something like:

Bad:
Player < ---- > Enemy (and a lot more of entities like: bullets, pick ups etc)

Good:
Player <---> Queue <----> Enemy


Well indeed the queue design looks nicer but I don't understand how it should be implemented. What does the player "say" to the queue and what does the queue "say" to the enemy (for example)?

2) The second question is about the model view controller pattern. I understand (mostly) how it works but how is it used in a game context?
A PlayerModel keeps the position of the player, a PlayerView draws a model at that position and a PlayerController changes the positon when the user pushes a key? But what if the game logic needs the model of the player to determine if the player is visible for an enemy? (I now realise that my question makes clear I don't understand how the MVC pattern works)

3) Can you think of some open-source projects I can take a look at to get a idea of how these things are done?

Thanks in advance.

ps: I know this post has a "Write games not engines" factor.

Share this post


Link to post
Share on other sites
Advertisement
Quote:

Now I'm planning to make a more complicated game and I want to keep it manageable.

Define "complicated game". Are we talking Doom N + 1 here or perhaps your first foray into 3D?

Quote:

1) My first question is about a queue design: According to the power-point it is better to let all the game entities communicate with each other through a Queue. something like:

Not strictly necessary. Message systems strive to decouple the sender and receiver classes. This means that an object can broadcast "I hit you" to a neighbour, or "I exploded" to objects nearby. It doesn't care about the specific types involved. For this to work your game must have a way of uniquely addressing the objects, for example a pointer to the Model might suffice.

However, at some stage you do care about the types, or at least some property of the type. If a Bullet hits an object with Health Points, some logic somewhere needs to know to react to this type combination.
Quote:

2) The second question is about the model view controller pattern. I understand (mostly) how it works but how is it used in a game context?
A PlayerModel keeps the position of the player, a PlayerView draws a model at that position and a PlayerController changes the positon when the user pushes a key? But what if the game logic needs the model of the player to determine if the player is visible for an enemy? (I now realise that my question makes clear I don't understand how the MVC pattern works)

That is fine. By game logic I assume you are talking about some EnemyController. This class might query the game for visible Player instances in its locality, it will get back a list of PlayerModels.

MVC is about decoupling the simulation from the input and output. In a traditional "monolithic" game object class these are all lumped in together. If your classes are in any way complex you can end up with very long code. Breaking them into the three
Quote:

3) Can you think of some open-source projects I can take a look at to get a idea of how these things are done?

No, I can't. Good open source games tend to be one-man, small scale efforts. The ones I know of (and have glanced at the code) generally have relatively neat procedural designs. The ones that go for "complex design" are usually unfinished, and their designs therefore remains unproven.



Don't be too focused on design patterns. The "write games not engines" is as much about bottom-up versus top-down design as it is about anything else. Only implement MVC if the alternative becomes too complex. Only implement a message queue if you find your game objects becoming too coupled. The more you design up-front the more you will have to change the code to work with the "real" game, doubly so when you lack experience.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!