Spot well written games

[cylab]

There is no need for all the high-level classes to hold a reference to each other, they all access each other trough the ApplicationContext.

But it doesn't hurt. IMHO Singletons are a solution to a nonexisting problem and only a quick hack to avoid refactoring of your class instantiations.

[Orangy Tang]

There is no need for all the high-level classes to hold a reference to each other, they all access each other trough the ApplicationContext.

Except now every subsystem has a dependancy on the ApplicationContext, and ApplicationContext depends on UpdateContext, RenderContext, etc.. Your dependancies are badly messed up and the whole thing devolves into a big mess of spaghetti.

You can make it slightly more sane by having ApplicationContext hold a bunch of interfaces, but you're still encoraging heavy module cross-talk instead of having a better engineered modules with proper dependancies.

[VeaR]

But it doesn't hurt. IMHO Singletons are a solution to a nonexisting problem and only a quick hack to avoid refactoring of your class instantiations.

It does hurt. If i have the InputSystem reference stored in 20 places, i cannot switch it to a different implementation at runtime. And cross-references among classes leads to clutter. Its much more cleaner to have a single class which holds the reference to all the subsystems in one place. And its a better API too. One look on the ApplicationContext class, and its easy to find the accessor for the subsystem needed. With static singletons, there is InputSystem.getInstance(), SoundSystem.getInstance(), etc and you just wonder what else there may be. With cross references, all the classes are cluttered with setInputSystem(), setSoundSystem() and the like methods. When using contexts, the classes can take from the context what they need themselves.

@Orangy
I think you imagine differently those contexts. UpdateContext and RenderContext are not subsystems those are like the HttpRequest class in servlets, those are passed to handler methods, to do some job on them.

Games published by our own members! Check 'em out!

[cylab]

When using contexts, the classes can take from the context what they need themselves.

...and effectively hide their dependencies, so you never know what a class may need without either running it or analysing it's source.

With cross references, all the classes are cluttered with setInputSystem(), setSoundSystem() and the like methods.

No, you would require them in a constructor (except you use setter based DI). Also I talk about subsystem/component wireing here, not deeply buried implementation classes. Those should get their subsystem reference in a suitable update callback like "updateSound(SoundSystem ss)" or something. You rarely need to access a subsystem out of thin air, so don't design an api/spi in a way that encourages it.

[princec]

See, you've spent all this time wanking around arguing over singletons instead of writing games!

Cas

[SwampChicken]

^^^ I LOL'ed

[cylab]

See, you've spent all this time wanking around arguing over singletons instead of writing games!

May be, but I think this is the place to wank over design principles Other than that, I only post here when waiting for a build to finish

If i have the InputSystem reference stored in 20 places, i cannot switch it to a different implementation at runtime.

Nothing stops anyone from storing a singleton reference or a reference retrieved from a AppContext, so you gained nothing regarding runtime switching of subsystem implementations. If you want to do that, you need to define a subsystem interface and only hand out proxies delegating to the real implementation. This can be done with any discussed approach.

[VeaR]

Nothing stops anyone from storing a singleton reference or a reference retrieved from a AppContext, so you gained nothing regarding runtime switching of subsystem implementations. If you want to do that, you need to define a subsystem interface and only hand out proxies delegating to the real implementation. This can be done with any discussed approach.

The programmer can do whatever he wants anyway, especially if its an open-source library.

If you have time to read over it, you can see the context system used in my code:

http://code.google.com/p/vlengine/source/browse/#svn/trunk/vle_cleanup/src/com/vlengine

There are things in need of fixing and redesign, but i consider the AppContext a good thing. There are lots of C game engines around, and most of them do have a central object, most of them just call it "Engine" instead of "AppContext".

[cylab]

If it works, it's good. Theres a saying I know from my wife: "Everything that works is good. And good is better than perfect."

I guess it's her way to explain the "New Jersey style", even if she has nothing to do with software engineering.

I have no problem with someone using static environments or singletons, if it works for them. It's just, that there are problems with this approach, which can be overcome by using other design principles, but chances are, that you never encounter this problems in your projects' scope and context.

If I would design an engine from scratch, which I am not doing (currently ), I would use an approach based on constructor declared dependencies using Pico as IoC container and DI engine. But hey, I am a J2EE developer, so I might tainted 

[ewjordan]

See, you've spent all this time wanking around arguing over singletons instead of writing games!

Cas

Damn straight - if you're the one writing your code and only you or a small team have to interoperate, there's no point in worrying too much about the philosophical (or even practical) problems with globals, statics, singletons, etc.  If you eff up, you can always change stuff after the fact without breaking other people's code.

This is a freedom that most "good code" advice assumes you don't have, because a) these books tend to be written by people dealing with far more substantial and publicly-used codebases (Bloch (for instance) is a master, but let's be honest, nobody here is writing code for the audience that he's writing for), and b) the books are generally aimed at people doing enterprise work where the ability to add or alter functionality without changing existing code is crucial.

For game designers these things shouldn't matter very much at all (unless you're writing a general library), because codebases should almost always be independent per-game and don't need to be publicly exposed.  You probably don't need a singleton because you can just decide for yourself that you're just going to create one of the offending object, but on the other hand you don't need to avoid the pattern if it feels like the best way to go, because you can deal with the ways that it sucks by holding yourself to a similar mental contract.

You'd probably be shocked to see the internal state of many games that you know and love.  What's important is not how it's written, it's how it plays and how long it took to write - nobody's maintaining these things after they're released, you've got to get it right the first time (well, unless you're dealing with something massive like an MMO, but that's venturing into EE-level scope, so it's a different ballgame).  If you can cut corners and stay within spec, by all means do it.  All the Flash game developers do, and to be frank, I suspect they're putting out a lot more content per-developer than we are!

Games published by our own members! Check 'em out!

[princec]

Actually you'd be surprised just how much maintenance goes into games after release! I still release regular patches to Ultratron, released 3 years ago. The problem is that all my games use the same 90% code from a couple of libraries (LWJGL, SPGL, and my gamelet framework) and every time I write a new game I fix things in the libs, change stuff, add new things, etc.

Having said that - never tripped over a problem with either statics or singletons before.

Many of these "code stability" design concepts arise from the fact that in very large teams working on rather spread out (enterprise) projects, the left and right hands frequently don't know what each other are doing. When everybody's aware of what they're up to, stuff gets done faster with less complexity by using the simplest methods possible.

Cas

[brackeen]

You'll want to avoid singletons when multiple apps can run in the same VM instance. I had a problem once where an applet game would break if you opened two copies in a browser, because InputSystem.getInstance() would only return the instance of the newest game.

That said, it's easy to fix by storing the App Context in a thread-local variable, since each game has it's own animation thread.

Luckily this is less an issue in 6u10, where you can just specify seperate_jvm and be done with it.

[princec]

Aye as it happens I've been wondering about that specific scenario since I'm turning my games into applets. I don't use singletons much but I do use statics a lot. As I understood it though each applet should be using its own classloader?

Cas

[brackeen]

Aye as it happens I've been wondering about that specific scenario since I'm turning my games into applets. I don't use singletons much but I do use statics a lot. As I understood it though each applet should be using its own classloader?

Cas

There's also the "classloader_cache" attribute, but as far as I can tell, it's also a 6u10-only attribute. Normally the classloader is the same if the archive and codebase is the same:
http://java.sun.com/javase/6/webnotes/6u10/plugin2/index.html#CLASSLOADER_CACHE

[princec]

Ah well, that will indeed bugger it right up.

Cas