About the use of static in the component manager

[Sandoval]

Hey Mike, or whoever is reading this.

First off, thanks a lot for your tutorials. It has helped me a great deal in setting up a nice framework for developing small games. I've followed a number of your tutorials on the XNA 3D engine, and love what you're doing, but I have one concern that I'd like to hear your opinion about: your component manager uses static dictionaries for all the (types of) components. At first this seemed like a very good choice to me, but as I progressed through your tutorials I realized that basically anything is hooked into the component interface - from engine 'parts' such as the effect manager, to effects and drawable objects themselves.

This of course makes it very easy to access whatever you need, for example when setting shader parameters it makes life a lot easier. But I've always learned that 'static' should only be used when a particular member/method of a class does not really belong to a specific instance of that class (like having an 'object' class and a static method 'GetTotalObjectCount()' that uses a static member 'totalObjectCount'). Also, because pretty much everything is a 'component', you allow global access to every object used in the game/engine. For reasons you probably know better than me, I believe this is considered bad practise.

I do not want to criticize your design, I was just wondering how you feel about the above, and what made you choose this particular way of doing things. You seem to know what you're doing very well otherwise, so I imagine this was a conscious decision as well. I hope you can ease my mind on this

Kind regards,
Hans aka Sandoval

[mikeschuld]

I do agree that static variables or functions are quite often regarded as bad practice (coming from the whole "globals" thing that many new programmers use for EVERYTHING), but in this case, I feel it allows for the correct use of the static property (it wouldn't exist if it was always bad after all) and will make a lot of things quite a bit easier to deal with in later tutorials.

Much of my reasoning behind using static instead of a simple private member is so that the Game class can have a member for the DrawableGameComponent methods to be easily called like everything else in the engine (which from looking through the framework quite a lot is sort of how Microsoft expects things to be put together) while still being able to add objects and other items from the "Demo" or other classes that are made that only have a reference to the engine .dll.

Another reason I chose to make them static members is to ensure that no matter what, there would only be one copy of each collection possible even if for some reason there were ever more than one component manager in someone's specific engine implementation.

I am of course always open to suggestions, and if you see better ways to go about some of this, feel free to post it here in the forums and I will definitely take interest in what you have to say. The engine has gone through many (5 now I think) iterations of almost complete rewrites, so it is definitely not impossible that another may happen in the future.

[Sandoval]

Thanks for your fast reply,

I do agree that the use of the static property seems very well fit in this case. That was also my first impression, my worries were more in the fact that pretty much everything is treated as a component. I personally lost sight a bit of the dependencies between components, and got a bit confused you treat engine modules and scene entities the same.

Personally I am making a distinction between 'components' and 'entities' in the way I'm designing things for myself now. My framework has a 'kernel' that features components much like your componentmanager does: static dictionaries (I never before realized dictionary lookups are O(1) complexity, was wondering why you didn't seem worried about putting everything in one container) holding components, using the interfaces like you designed them, but instead of having an access method like GetComponent, I give each component an interface it inherits from, and gave the kernel a GetService<IService>() function. This way I feel I am abstracting a bit, since modules only communicate using these interfaces. Anyone using the framework in a project could for example replace the renderer just by inheriting from the IRenderService interface I supply, and when another component requests for a render service, it will just get whatever's there, not worrying about the details of implementation.

Each component registers it's services to the kernel in the component's constructor, and requests any services it depends upon in the Initialize() routine. This way it is clear to see dependencies between components, and it makes the whole thing a bit more pluggable in my opinion.

I seperated all 'entities' (pretty much everything that isn't a module of the engine), and decided not to make those lists static. Instead I have an EntityManager module, which is also a service, that allows access to the entity dictionaries. In practise the differences with your approach are small, in fact you could probably argue everything is still globally accessible with a bit more work, but I feel it's a bit more modular. Also, I have a feeling that having multiple entity dictionaries might become useful at some point (for example when switching levels), but multiple component dictionaries are not likely, as you mentioned.

In one thing you are definetly correct, your design will make any future tutorials a lot easier. I think your approach serves very well for explanatory purposes, and was personally wondering how viable it would be in 'serious' projects. I do see what you mean when you say Microsoft seems to expect this kind of design, but since I use Winforms a lot I tend to not plug into the Game class too much. The ability to be able to add objects and such into the engine from inside a project using the dll is indeed important, the way that works in your design reminded me a lot of a commercial engine I had the luck of working with for a little while.

Well anyway, thanks for clearing some things up for me. I am learning a lot from your tutorials, not just about engine design but also about neat stuff in C# in general.