4
\$\begingroup\$

Often "singletons" are problematic for testing, so with my next game I'm trying my best to avoid them. But there is bunch of data (configuration or game state information) that different parts of my game require to function. So far I've used events (publish/subscribe) to pass around for example keyboard/touch actions.

Is it a bad idea to try to do the same with configuration/game state? So for example user changes some configuration parameter and instead of all those that need it doing something like ConfigurationSingleton.getParam("someparam") my event handler would call all those interested in param changes with SomeSubscriber.paramChanged("someparam", "new value").

How do you usually make available this kind of "global state/configuration" data in games?

\$\endgroup\$
4
\$\begingroup\$

Whether you need a publish/subscribe pattern or not depends on when your data changes. If it does so during the lifetime of the interested objects, and if those objects need to know (and react) immediately, then publish/subscribe certainly is the right thing to do.

If you do not need immediate notification, just store a direct or indirect reference to the configuration/gamestate in the objects that need those information and let them ask for the values whenever they need them - configuration.getParam("someparam"). While at first sight this adds an additional dependency to the objects, it does not. The locally stored reference is not more of a dependency than the global singleton, and whether you have to "connect" the objects with a link to their "environment" (i.e. some object that directly or indirectly can get the information about gamestates, configuration etc.) during construction or with some publisher does not make a big difference either.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.