Design Issues: Making systems know about eachother (engine)

Started by
25 comments, last by Bob Janova 17 years, 11 months ago
I know this is a pretty frequent question, but id like to know how you design your code, so that the different systems of your engine know about eachother. My current system: Core |-->Rendererer |-->ResourceHandler |-->Sound etc.. As you can see, the core can access everything neatly, but whats the best way of making the subsystems talk to eachother. One option is to make the core a singleton and fetch its instance and go from there. Is this the kind of situation that a singleton might be useful? Seems to be a lot of different opinions about them.. Any thoughts?
Advertisement
You could try using Dependency Injection. Basically pass the object reference as a parameter to one of the other objects for it to be used.

class DisplayManager {    private SoundManager soundManager = null;    ...    public void setSoundManager(const SoundManager &sm) {        this->soundManager = sm;    }}
In my engine, I have all the core components as static classes (SpriteRenderer, SoundManager, GameTimer, KeyboardInput, etc). They are not encapsulated by a Core. I've tested a bunch of different small-scale engine designs, and I think this works well.

For instance (the engine is a sprite based 2D C#/MDX engine btw) the rendering is handled by each renderable object itself.

So the the Ship class has a method like this
  public void Render()  {      // ...      SpriteRenderer.AddSprite(shipSprite);  }

and the Background class something like
  public void Render()  {      // ...      SpriteRenderer.AddSprite(backgroundSprite1);      SpriteRenderer.AddSprite(backgroundSprite2);  }

I.e. all classes can access the renderer, and tell the renderer which sprites to render.

It works the same for sound and input, these are static classes, so every class has access to these everywhere. Note that it is only the core classes that are static, all other gameobjects are instanciated.

I know some people dislikes having objects static and therefore global, but for game engine components I think it makes sense.

The regular updating (i.e. update input and render all added sprites etc), is handled by so called tasks. So I have a task that regularly updates input and regularly renders the scene etc. This idea is from superpigs Enguinity series (Part III) and it works great.

Btw, I listened to a keynote by Tim Sweeny at Epic Games recorded at the GDC 2006, where he told about the Unreal Engine 3.0 and its architecture. It's really intresting, you can find it at http://www.gdcradio.net/.
[s]--------------------------------------------------------[/s]chromecode.com - software with source code
Have you considered message passing? Have all the modules accept an enumerated message type with two integer values (which you can use as pointers or whatever).
Thanks for the fast response :)

Im going to try the dependency injection method first, as I kinda liked the concept.

This message passing, how does that really work? Do you have any articles or some other docs on that method?
Got Dependency Injection working on all systems just now :) Works great. Thanks again everybody ;)
Quote:Original post by klette
This message passing, how does that really work? Do you have any articles or some other docs on that method?


I'm sure I could find an article quickly, but I know it was covered well in Game Programming Gems 4.
Quote:Original post by Ravuya
I'm sure I could find an article quickly, but I know it was covered well in Game Programming Gems 4.


I found this one. Do you know of a bettter resource explaining it? I'm very interested as this is what I'm currently dealing with.
Quote:Original post by Enselic
It works the same for sound and input, these are static classes, so every class has access to these everywhere. Note that it is only the core classes that are static, all other gameobjects are instanciated.

I know some people dislikes having objects static and therefore global, but for game engine components I think it makes sense.


I do things the same way. Peoples' hatred of global variables is a bit harsh... you just have to know when to use them. If you have an object that is used everywhere in the program, will be created when the program starts, and lasts until the program ends, then static/global objects are the most straightforward/flexible/readable way to do it.

Check out my new game Smash and Dash at:

http://www.smashanddashgame.com/

Quote:Original post by tstrimp
Quote:Original post by Ravuya
I'm sure I could find an article quickly, but I know it was covered well in Game Programming Gems 4.


I found this one. Do you know of a bettter resource explaining it? I'm very interested as this is what I'm currently dealing with.


This page is always my first stop when constructing a complex system. I'm away from my home machines so I can't find other pages on it, but I'm sure others exist.

This topic is closed to new replies.

Advertisement