Question

I am using the Akka framework together with jMonkeyEngine (jME3) for my little scala/java game. By adapting some Akka dispatcher magic I managed to run a dedicated actor in the same thread as jME3's main loop thread. For the actor to have access to the protected variables of class SimpleApplication which one should extend to create a game with jME3, I figured it would be neat to create a class which would inherit class SimpleApplication and mix in trait Actor. Something like this:

JmeActor extends SimpleApplication with Actor

The problem is that both SimpleApplication and Actor have a context variable which clash together. For the time being, I have renamed SimpleApplication's context variable to jmeContext and recompiled jME3. The result works pretty well, but the very design seems broken to me, since any further release of jME3 (or Akka even) will require that I go over this refactoring manually once again. It may even be possible, although perhaps unlikely, that SimpleApplication is modified further by the development team making this clash avoidance technique much harder.

Can anyone see a simple solution to this ?

Was it helpful?

Solution

My intuition suggests that entwining an Actor instance this closely with such a rich class as a game engine’s “main” class might not be a good design choice. I’d recommend subclassing SimpleApplication such that all functionality you need is exposed by public methods and then just keep a reference to that within your actor; my guess is that you want to be able to influence the game engine by sending messages to the actor, which is thus enabled.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top