Jump to content
  • Advertisement
Sign in to follow this  
Xperience

Managers, which pattern should I use

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

Hi,

I'm learning Direct3D now, but I don't know how I should write managers(Input manager, texture manager etc.).
I created some small games, but in this games I had input manager and texture manager in one big root class, and pass them to function which want to use them, but this is a bad or not? Is some pattern which should I use?

Share this post


Link to post
Share on other sites
Advertisement

Singleton pattern is the most commonly used for managers.

Just careful to not put managers as singleton that don't need to be.

 

One day you will want to add multiplayer, or split screen, to your game. And all those singleton will haunt you.

Some things, like Texture manager, should definitely be in a singleton. It's sharing textures across all part of the engine.

 

But input manager, maybe not. If you add a second controller for player 2, you might want him to handle his own input separately, and you will want a second instance of input manager.

 

What I do in my games generally, is create a global singleton, where I put all those managers in.

Globals::getInstance()->textureManager()->getTexture("baby.png");

Globals::getInstance()->inputManagers[PlayerId]->isButtonDown('A');

 

Not the best practice, but accessing things easily from everywhere is nice too. Also I cant keep all my other managers singleton-free.

Edited by Daivuk

Share this post


Link to post
Share on other sites

...

 

Globals::getInstance()->textureManager()->getTexture("baby.png");

Globals::getInstance()->inputManagers[PlayerId]->isButtonDown('A');

 

Not the best practice, but accessing things easily from everywhere is nice too. Also I cant keep all my other managers singleton-free.

 

That is just ugly. It reminds of me of the OGRE engine and how much i hated its managers. Like said before, there is nothing wrong with passing pointers or localizing functionality.  

Share this post


Link to post
Share on other sites

In my humble opinion the term "manager" should immediately ring an alarm bell when it comes to designing your application. I'm not saying that you should never write classes which completely manage some system, but they have a tendency to turn into god classes pretty quick and that's something you want to avoid at all costs.

 

Cornstalks made a really good point on which systems to implement to handle your texture resources. A system which handles the loading of resources shouldn't be bothered with maintaining a resource's lifecycle or vice-versa. It just bloats the system and will turn it into an unmanageable wreck.

 

The same thing goes for input. You can receive input from many different devices, do you really want to put all of the logic behind receiving that input into one system? Will systems which require input (eg. character controllers) all have to depend on this one bloated system? That's just not a flexible design.

Share this post


Link to post
Share on other sites

I know that a lot of people reject to 'managers', but I don't immediately reject the notion, provided that the 'manager' does not violate other design principals. It should not be a god class, and it shouldn't be a singleton unless it's 'managing' a resource which would cause conflicts in the case of multiple instances. For example, a 'texture manager' could be called a 'texture cache', and there's no reason to artificially force it to have a single instance. You may want a single cache for textures that are used everywhere, and a second cache for textures that are only used in the current level, etc.

 

That is to say, I agree with Cornstalks. 'Manager' just isn't the right name for what you want.

 

As for input, Radikalizm points out that you can have all sorts of different input devices, but in this case I think a 'manager' is okay for exactly that reason: your game can only support the device types that you code support for, and it needs a system in place to 'manage' which devices are active/connected, etc. That system can function as a means of allowing easy access to your input device interfaces, but it shouldn't implement those interfaces. I have no problem with something like

 

spacePressed = inputMgr->keyboard.isKeyDown(KBKEY_SPACE);

if(inputMgr->getNumberOfJoypads() > 0) {

  stickX = inputMgr->joypad[0].getLeftStickX();

}

mouseDX = inputMgr->mouse.getDeltaX();

 

The 'manager' would only do the work of enumerating the connected devices and containing the objects that allow interaction with those devices. By virtue of simplicity it avoids being restrictive. There may be a better name for it, but none comes to mind.

 

Anyway, that's my take on it. I'm interested in hearing feedback.

Edited by Khatharr

Share this post


Link to post
Share on other sites


As for input, Radikalizm points out that you can have all sorts of different input devices, but in this case I think a 'manager' is okay for exactly that reason: your game can only support the device types that you code support for, and it needs a system in place to 'manage' which devices are active/connected, etc. That system can function as a means of allowing easy access to your input device interfaces, but it shouldn't implement those interfaces. I have no problem with something like

 

I mostly follow the mindset that there will probably be some devices which I'll want to implement later on in my game's development lifecycle without having to bloat existing systems. Some devices also require you to use an existing SDK with some of their own manager objects which need to be alive during the time you want to use the device (like the Oculus Rift for example), so that's more of a reason to maintain the code driving a certain input device separated from other devices. 

 

Hiding all of your device info behind an input manager also hides which input devices a certain other input requiring class need, which can become a real mess when you want to change something in your input manager class.

Share this post


Link to post
Share on other sites

 


As for input, Radikalizm points out that you can have all sorts of different input devices, but in this case I think a 'manager' is okay for exactly that reason: your game can only support the device types that you code support for, and it needs a system in place to 'manage' which devices are active/connected, etc. That system can function as a means of allowing easy access to your input device interfaces, but it shouldn't implement those interfaces. I have no problem with something like

 

I mostly follow the mindset that there will probably be some devices which I'll want to implement later on in my game's development lifecycle without having to bloat existing systems. Some devices also require you to use an existing SDK with some of their own manager objects which need to be alive during the time you want to use the device (like the Oculus Rift for example), so that's more of a reason to maintain the code driving a certain input device separated from other devices. 

 

Hiding all of your device info behind an input manager also hides which input devices a certain other input requiring class need, which can become a real mess when you want to change something in your input manager class.

 

But you should hide all of you input devices behind an interface anyway otherwise you are going to add special code paths for certain device which lead to even worse design. Implement against and interface not an implementation, and behind that interface all kinds of nasty can go on but your game code doesn't need to know about this and that is exactly what an input system is supposed to do.

 

I agree with the idea that as soon as you try to create a manager object you need to rethink that part of your code to see whether this is a system or cache type situation but the example you use just doesn't work. In that case implementing against an interface will save you from a lot of trouble in the rest of the code base.

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!