Spot well written games

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 :slight_smile:

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.

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 :slight_smile:

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

Ah well, that will indeed bugger it right up.

Cas :slight_smile:

This thread has interestingly resurrected ten months after it’s death. Thank’s for your answers.