1

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 ?

gsimard
  • 643
  • 8
  • 24
  • 1
    Why didn't composition work? – Viktor Klang May 11 '13 at 13:13
  • You mean creating an actor as a field of JmeActor instead of mixing with Actor ? How would you setup the receive function for this actor to have access to private fields of JmeActor ? This is probably trivial to you but right now I'm unclear about this. – gsimard May 11 '13 at 13:40
  • No, I meant having JMEActor extend Actor but having a field with a SimpleApplication in it. And then the actor takes messages and invokes methods on the SimpleApplication. – Viktor Klang May 11 '13 at 16:01

1 Answers1

1

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.

Roland Kuhn
  • 15,412
  • 2
  • 36
  • 45
  • Indeed the very point of mixing with Actor was to avoid exposing protected fields through public methods, not only because it is such a chore, but also because encapsulation would break unless great care is taken. – gsimard May 11 '13 at 14:30
  • 1
    Encapsulation is perfect within an actor, no matter what the access modifiers say, since no other code can call methods or access fields of an actor other than by sending messages. Inheritance on the other hand leaves you no choice wrt. the life-cycle of the actor/application, and great care must be taken that the SimpleApplication is not exposed to other threads, which would break the actor model. I think my answer boils down to “jME is badly designed because it forces inheritance”. – Roland Kuhn May 11 '13 at 17:53