Sign in to follow this  
alejandro

Game Architecture/Design Pattern?

Recommended Posts

Hello,

 

I want to know if there are any game architectures that are recommended, well, actually I don't know if I can call them architectures or design patterns.

 

Basically what I want to know is how do you structure your games at a logical for example I tend to the following.

 

I create an object named GameMaster, this object controls the game (enemies, ambient, etc) and knows the state of everything in the game, the control is done through Managers, for example EnemieManager, AmbientManager, etc. This managers don't communicate directly, the communication has to go throught the GameMaster.

 

In a more plactical way say we have the following:

 

class GameMaster
{
	Player player;
	EnemyManager enemyManager;
	GameStatus status;

	void update()
	{
		if(enemyManager.enemies == 0)
		{
			status = GameStatus.EndGame;
		}

		if(status == GameStatus.EndGame)
		{
			player.stopInteraction();
		}
	}

	void draw()
	{
		drawString(status);
	}
}

 

Sure, the managers can also have control of a few elements... what I see in some friends code is more like...

 

class Player
{
	GameStatus status;

	void update()
	{
		if(status == GameStatus.EndGame)
		{
			player.stopInteraction();
		}
	}
        
        void draw()
        {
                drawString(status);
        }
}

class EnemiesManager
{
	Player player;
	int enemies; 

	void update()
	{
		if(enemies == 0)
		{
			player.status = GameStatus.EndGame;
		}
	}
}

So my doubt are, what is better? what is worse? are there any architecture/patterns for structuring the objects in the videogames?.

 

I follow the GameMaster pattern because it's easier to me to structure things like this, but maybe this is not the best pattern...

 

 

Any literature on the topic is appreaciated wub.png

Edited by Alejandro

Share this post


Link to post
Share on other sites

I think what you have is pretty good.  However, instead of making your update check specific information about how many enemies there are, I would recommend creating a statically available boolean called shutDown = false;  (or an enum for GameState)  Then what ever might decide to shut off your game can just call the variable change for it.  Your update method won't check each area for reasons to shut down then.  Instead it just checks the one value.

 

But the key issue, is performance vs maintainability.  Your engine, 3D rendering, timing handlers, etc... should be performance based.  I.e. forgo easier to maintenance architectures for architectures that employ speed.  This for instance might be to use arrays instead of dynamic lists, pointers (bark bark) instead of copies and static references instead of lookups.  The layers of code that manage logic such as AI, level details, and mob generations would be best in a more manage able code approach.  I.e. highly structured code, preferring clearly named abstraction over direct but vague variable references.  Also larger separations of object code, to help organize data, instead of compressing more code purpose into one location.  Also preferring Dynammic easy to use lists, instead of additional code required for locked array sizes.

 

I see no problem in having a split in your architectures layout, as long as it is easy to distinguish where one stops and the other begins.  If your using an existing engine, like XNA, Unity, DirectX even, then you'll probably want all your code to be a logic oriented architecture (more maintainable)

 

That being said, I typically create an interface called "IModifier" (having .Modify()) and another called and "IPaintable". (having .Paint(View/Paint Object reference))

Then my main class will have a List<IModifier> Modifiers.  My update method does any generic things it needs to, like initializing the mouse coordinate variable, or keyboard variables, but then just calls ForEach(IModifier mod in Modifiers) mod.Modify();

And of course having a second loop that removes any objects marked for removal  (either another static list, or a flag on each game object to mark them for deletion)

 

I'll usualyl wrap that code up into a layer to manage its own cleanup.

 

The IModifable/IPaintable interfaces are a form of an Object Based Decorator Pattern.  Which I've found highly useful.  I typically create different Lists for managing different sets of objects, like playershots, enemy shots, enemies, stars, etc...  Then each object also gets a List inside for all its modifiers.  Modifiers would include things like friction, reactToMoustMovement, Gravity, TakeImpactFromEnemyShots, TakeImpactFromPlayerShots, etc...   Anytime I create an object, I simply create a generic GameOBject, set the image and position, and other variables, then apply a bunch of decorators to do what ever things it needs to.  Makes for something inredibly easy to manage.  

 

 

I'll also say that I'm sure there are many architectures that can work, I think the key is learning which to apply for your case that won't damage your performance.  Don't look for one perfect architecture.  Look for options, and figure out in what circumstances each work.  

 

I recommend looking through this to start out: Wikipedia's Software Design Pattern's List (the list is a page or two down, and broken apart a bit)

Share this post


Link to post
Share on other sites

I "found" another way to look at variables: instead of imagining them as container, I think of them as things that change how my functions behave.

 

So instead of focusing on making variables accessible, think of them as evil/good things that can influence behavior of your code.

Think of function arguments as a scope for something to happen. Think of different arguments as another scope for something else to happen.

Think of a class as an environment which changes how ALL functions in it behave.

 

I found that thinking this way helps to keep number of available variables for my code to minimum, because I start thinking more about the reasons I am introducing yet another field for class. Do all functions inside REALLY need to know about it? Maybe passing it as parameter when actually needed is just cleaner.

 

The main principle one should follow is separation of concerns. Think of controller/view/model - separating concerns of getting data, displaying data, and data itself.

However, design patterns are just ways to organize the code and communicate this organization. Never try to fit something into a design pattern, that often does not work by the book :). Most likely it needs adjustments for your project.

Share this post


Link to post
Share on other sites

Thank you very mucho for all your comments, I liked the idea on Performance vs Maintainability, also because a lot of the code I do is also read by other team members so it's important to have maintanable code

 

I'll take a look at the Game Engine book

 

Until know there's no clear best one, it appears as everyone has different approaches, that's what I am searching, how people create the architecture of the code.

 

Does anyone has an example on how MVC pattern will work in a videogame? particulary on Unity blink.png

Share this post


Link to post
Share on other sites

Thank you very mucho for all your comments, I liked the idea on Performance vs Maintainability, also because a lot of the code I do is also read by other team members so it's important to have maintanable code

 

I'll take a look at the Game Engine book

 

Until know there's no clear best one, it appears as everyone has different approaches, that's what I am searching, how people create the architecture of the code.

 

Does anyone has an example on how MVC pattern will work in a videogame? particulary on Unity blink.png

 

No idea about unity, but:

- You can think about your game state Update function as Controller.

- You can think of your Draw as View.

- You can think of your game objects as Model.

 

The main point here is to never Draw from Controller or Model, never Update game state from View, keeping game-state related things only in Model.

Separation of Concerns.

Edited by Nercury

Share this post


Link to post
Share on other sites

You can think about your game state Update function as Controller.

 

Update functions, and components in general in most cases.  

 

 

Does anyone has an example on how MVC pattern will work in a videogame? particulary on Unity

 

The MVC pattern is good for games, but I tend to find a stronger blur between Model and Controller.  Separating the code is good, and I'll do that in most things I do, but I'm not going to let MVC stand as a permanent requirement, when sometimes it just makes more sense to have some data and logic floating intermingled for performance needs.  I.e. if you keep the MVC model, would typically require an impact controller to loop through all the game objects for collisions with particular objects.  But then you also have Momentum controllers, AI controllers, gravity controllers, etc...  Each one needing to loop through your gameobject list to make changes.  Or, you could blur the Model-Controller, and add an update function to the game object that takes care of all the same logic, but this structure requires only one loop through the game objects.  

 

MVC is good, but games some times need more efficiency.  

 

(I should include that I certainly think MVC is possible in game development, and that it can be done elegantly in many situations.  For a web app or forms app, I will typically impliment MVC, MVVM or a similar model.  For games, while while still defaulting to MVC, I just don't lock myself to it.  I don't step away from it without good reason either)

Edited by Dan Violet Sagmiller

Share this post


Link to post
Share on other sites

- You can think about your game state Update function as Controller.
- You can think of your Draw as View.
- You can think of your game objects as Model.

 

I agree, but maybe with a little twist:

- The Controller handles all input from keyboard, mouse, timers and OS signals.

- The Model knows about the game state and all objects in it. It is not real-time. It has input functions called by the Controller that will trig actions and update the time.

- The View asks the Model about its state, and draws it accordingly. The View will also take orders from the Controller, e.g. toggling between first person and third person or showing/disabling a chat window.

Share this post


Link to post
Share on other sites

The Controller handles all input from keyboard, mouse, timers and OS signals.

 

Typically the controller is also the place for handling all logic.  If you look at the MVC Wiki page, it shows the Controller as manipulating the model.

 

 

The Model knows about the game state and all objects in it. It is not real-time. It has input functions called by the Controller that will trig actions and update the time.

 

'real-time' has to do with the total time it takes for something to get back to the user in a way that they don't perceive a lag between their interactions and what they see, including all model changes.  I can't think of a game where the MVC as a whole is not in real time, unless your talking about a save/load button, or the start of a level.  But typically once going, the model/controller/view all act as one real-time responsive unit.

 

The View asks the Model about its state, and draws it accordingly.  The View will also take orders from the Controller, e.g. toggling between first person and third person or showing/disabling a chat window.

 

Your right about the view asking the model for the state, but typically the toggling between 1st/3rd Person Perspectives would also be stored as model data.  You should see the controller as the implementer of change, not as a constant updater of things that aren't changing.  I.e. something happens and the controller will change the state, view state being included in the model.

Share this post


Link to post
Share on other sites

Typically the controller is also the place for handling all logic.

The concept "all logic" is quite wide. So I must state I disagree with your statement, as much of the game logic goes into the model. This statement does not help anyone how to implement a MVC pattern.

 

I can't think of a game where the MVC as a whole is not in real time

 

As a whole, usually, yes. But, I would argue that the Model isn't real-time. The View will need to know about FPS, and have the responsibility of making sure the player get feed back in real time. And the Controller definitely has real time requirements, even for turned based games (laggy mouse responses can kill any game).

 

The model will need to know about time, that is usually the case. Especially if it manages physical modelling. But it is enough to have an input function to the Model where it is told the current time, or the delta time since last call. For example, it will be possible to slow a game to slow motion by simply giving a down scaled time to the Model. The Model doesn't need to know that the game is currently in slow motion mode. Thus, the Model should not be concerned about real-time requirements. And the Model should usually not have to care about the CPU power.

 

Of course, there are complications depending on what type of game it is. The model must not use too much CPU, or the View and Controller may no longer fulfill the requirements. Some games, like chess, may have a complicated relation to time. That is, the model is allowed to use a limited real time to find the next move. But even in that case, I would delegate the real-time responsibility to outside of the Model.

 

typically the toggling between 1st/3rd Person Perspectives would also be stored as model data.

I disagree again. This is a typical example where the Model should not be involved. However, the Model will need to support the View with information needed to show data in both 1:st person and 3:rd person, but the Model shall not know, or care, whether the game is currently in any of these specific modes. There are always exceptions, of course.

Share this post


Link to post
Share on other sites

I think it's worth to mention the component based architecture which is quite attractive.

Basically it says that your main classes are containers of components and components are behaviors or features (like "Render", "Collide", "Controllable").

It's a way to avoid the duplication problem of the inheritance and big base classes.

 

However even if it solves the problem of the inheritance, it brings new problem (as the communication between components) but at least your code is more independent and intuitive.

 

A very nice article:

http://gameprogrammingpatterns.com/component.html

 

and also:

 

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy

 

http://en.wikipedia.org/wiki/Composition_over_inheritance

 

Also please note that there are many different ways to implement this solution but the idea stays the same : you create some components which represent behaviors or features and you create your final object by assembling the components you need.

Edited by Rakilonn

Share this post


Link to post
Share on other sites
Your "managers" and GameMaster appear to be a rather arbitrary partitioning of game state, which can only cause needless and burdensome complications (for example, storing the GameStatus in two or more places and checking it redundantly).
 
Classes like EnemiesManager are inappropriate because using objects makes little sense:
  • There can be only one: no need to isolate different instances. On the other hand, game entities, like the individual enemies, could be objects (other sensible options exist).
  • There are no alternative implementations of a common interface; you are simply ripping out of GameMaster a part of the game logic that deals with enemies. Meaningful interfaces with (at least potentially) different implementation often include the "brains" of game entities (AI, user input and replay systems could control the exact same unit) or rendering (once you know what you need to draw, you can draw it in different ways).

Share this post


Link to post
Share on other sites

You're all doing it wrong.

 

 

 

Design patterns and architectures are [i]descriptions[/i] of how problems [i]can be[/i] solved. They emphatically [b]are not[/b] [i]prescriptions[/i] of how to solve those problems in all future cases.

 

As soon as you start thinking of "the" design for some software, you have failed as a designer, architect, and engineer. There is no "the one right design" - ever. Even after you are done with your code, there is only "how I did it" versus "many other ways it could have been done."

 

 

Do not fall into the trap of exclusively and blindly using design habits, principles, patterns, guidelines, suggestions, recommendations, or anything else. Do not reach for some off-the-shelf solution to every design problem.

 

 

Use your brain and think about how [b]best[/b] to solve the unique problem you are currently facing. Otherwise, you're not doing your job. Being lazy with your solutions will bite you eventually. Resist the urge to get stuck in a design rut.

 

 

 

In short: your question is broken. Un-ask it.

Share this post


Link to post
Share on other sites

To be fair, I think "how do you structure your games" is a reasonable question, as is "are there any architecture/patterns for structuring the objects", because patterns would help describe the structure. I don't think it's true that overall game structure is a unique problem that needs every individual to work out independently how to solve it.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this