Hi community,

I have finally decided to start my first big game (2D RPG with everything like quests and so on). So I need a good way to structure my code, not to end in a chaos like in some of my other projects. So I googled a bit and found different patterns for object handling like Observer, Mediator or event queue. So I wanted to ask you guys if someone has experience with different patterns and can tell me which to use, why to use and mybe an example when to use. Sry for my english, I am from Austria.

Have a nice day :D

... So I need a good way to structure my code, not to end in a chaos like in some of my other projects.

Software patterns do not help you in structuring your code. They are just typical approaches to recurring problems. You can implement patterns and still produce chaos.

The correct way is to plan what and how you will implement. Analyze what you desire in the end, then make architectural decisions on that, then look at the demands coming of, and then, perhaps, patterns may come into play. Otherwise you try to solve problems without knowing to have them, so to say.

... and can tell me which [pattern] to use ...

... and mybe an example when to use.

Thanks for your reply, which showed me that I have to think more about structure and upcoming problems, than I thought. I´m often impatient and always start programming before I have a solid structure to build upon, which leads to the chaotic code. So I´m going to think things over. I have already some ideas when I can use patterns. I thought of a Command pattern for player input and contolling enemies with an AI controller. That would let me easily attach the player actions(attack, ...) to Keys or MouseButtons. So would that be a good way to start? And I also have some ideas where to use the observer pattern(Achievment system, SoundManager, ...). But one problem I actually have,is that I want an easy way to add interaction between the player and world objects like treasures, enemies, traps, NPC´s and so on. I thought of an event pipeline(for example the player fires an event before he moves and objects like the collision layer or doors would react to that and would prevent the player from moving). So what would be a good approach to solve that "communication" problem. I thought of using the Observer pattern here as well, but I am not sure about that.

Thanks for your help anyway :D

... I thought of a Command pattern for player input and contolling enemies with an AI controller. That would let me easily attach the player actions(attack, ...) to Keys or MouseButtons. ...

The Command pattern, if you mean exactly those of the Gang of Four, is overkill in this case. It is fine to abstract input (in the case of the player character) and to "objectize" any character action, and the Command pattern goes in that direction. However, other features of the pattern are not so good in this case. You usually don't need a history of past commands (no undo, and usually no playback). You will not queue up commands, waiting for the previous ones to complete (because players will claim that your game is not responsive). You will not perform the actual action in some virtual Command::perform().

On the other hand, if you understand Command as a lightweight instruction for interpretation by e.g. the animation sub-system or whatever, then it's okay.

... But one problem I actually have,is that I want an easy way to add interaction between the player and world objects like treasures, enemies, traps, NPC´s and so on. I thought of an event pipeline(for example the player fires an event before he moves and objects like the collision layer or doors would react to that and would prevent the player from moving). So what would be a good approach to solve that "communication" problem. I thought of using the Observer pattern here as well, but I am not sure about that.

This is a real problem per se. You have to notice that the observer pattern introduces some kind of local view onto the world state. What I mean is that a single event happening in the world is seen by the observer at the moment it is generated, but it does not foresee all the other events that happen at the same simulated time but at a later runtime due to sequential processing. So the observer reacts on a world state that is incomplete!

Look at the structure of a game loop and notice that it is build with a well-defined order of sub-system processing. Introducing observers often will break this well-defined order (for example the animation sub-system moves the character and the collision sub-system moves it back).

This is one of the examples where the problem analysis need to take into account the big picture. Observers are fine for desktop application where the entire UI is just reacting on events, but a game is (usually) a self running simulation.

In short: I would not introduce observers especially wherever sub-system boundaries are crossed, and I would think twice for observers in general.

Just my 2 Cent, of course ;)

Ok, so what would be a good approach to decouple all the different parts of a game(Physics, Collision, Events), so that there´s no code of collision detection in the player class itself, or to decouple the achievment system from parts like physics(for example I want an achievment "Fall 100 metres") then I would use observer to let the achievment system

listen to the physics part. Till now I always used Lists of Gameobjects for exampe. So when I shot a bullet I added it to an ShotManager and Updated it in there. Same with collisions, I had a collision manager which had references to the player, shotmanager and then checked tif they collide. But I don´t want that ugly coupling anymore. I want a flexible architecture to work with, so that I can easily expand the game.

There is a interesting way to handle this problem, but I don´t know if it´s too slow or not manageable(the first answer): http://stackoverflow.com/questions/11323413/handling-interaction-between-objects

I also read about putting everything in a class and let an entity have a list of behaviours(like movingPart, physicsPart), but I don´t have experience with that kind of architecture so I want to learn it first before I try my luck in a game.

So what approach would you choose?

Glass_Knife nice anecdote :D

One thing to keep in mind is to keep classes small enough and short. May be hard to follow, but typically large classes may be a sign of a code bloat and that they may have too many responsibilities.

Cheers!

Yeah that has been my problem so far, but my last project was better in that point. Still I have to find another way of handling the objects in a growing project.

Any approaches? How manage you guys your game objects?

Anyone?