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\$

1 Answer 1

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\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .