Jump to content
  • Advertisement
Sign in to follow this  
klette

Design Issues: Making systems know about eachother (engine)

This topic is 4562 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

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?

Share this post


Link to post
Share on other sites
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;
}
}

Share this post


Link to post
Share on other sites
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/.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
Got Dependency Injection working on all systems just now :) Works great. Thanks again everybody ;)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

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!