How to implement acync event-driven game loop based on actors and messages?

Game Mechanics
#1

Hi folks!

I decided to switch from regular OOP style of programming to modern reactive functional programming style.
Also wanted to use actors model. It just an experiment for me.
As actors model implementation is chosen Akka. Fortunately it’s simple and well-done tool which will be the hear of my architecture. I hope.
I use well designed PlayN framework for 2D rendering.

I want to implement full event-driven circle. All system will consist of independent components and messages. Nothing else.
I’ve already switched all playN input to actors. It’s was easy, maybe no needed step. but… let is be.

And now problem not in Akka or playN or Java…
Problem in approach. I didn’t see good solutions for next problem.

How to implement acync event-driven game loop based on actors and immutable messages?

At that moment I only one idea:

  1. Create actor which will handle game loop. Like it is done in playn.core.Game class, method onFrame(). It will receive onFrame messages for re-draw screen.
  2. Create actor for handling Update messages. It will receive Update messages which contain game objects (what data structure?) handle them and return data back
  3. Create actor for handling Render messages. It will receive Render messages which contain game objects render them (maybe will return data back if it needs).
  4. Game loop logic will work like that: I have some data structure with all game entities (maybe a lot of them or all will be actors).
    I send this structure via immutable message to Update actor. It handle them in async way, collect already handled and send result back to GameLoop actor.
    GameLoop actor calculate timing and maybe decide to update game once again if needed.
    When Update actor returns ‘updateFinished’ message, GameLoop actor send message (the same data structure?) with renderable game objects to Render actor.
    Render actor as graphics monopolist render all entities via playn.core.Surface object, in the end it send ‘renderFinished’ message to GameLoop actor to notify it.
    GameLoop receive message form Render actor, maybe do something if needed.
    Also GameLoop actor can decided to send render message immediately while handling ‘onFrame’ message if update doesn’t required.
    The GameLoop actor will work like controller in MVC world.
    Please, look at the next pseudo code.

Pseudo code:


ReceiveBuilder
  .match(OnFrameMessage, m -> {
    if (isUpdateRequired) {
          updateMessage = createUpdateMessage();
          updateActor.send(updateMessage, self());
        } else {
          renderMessage = createRenderMessage();
            self().send(renderMessage, self());
        }   })
  .match(UpdateFinishedMessage, m -> {
    renderMessage = createRenderMessage();
        self().send(renderMessage, self());
  })
  .match(RenderFinishedMessage, m -> {
    // do something.
  })
  .build();

It’s unfinished idea. I have no experience with event-driven approach in general and async logic in particular.
Akka says: “or a given pair of actors, messages sent directly from the first to the second will not be received out-of-order.”
It means messages will guaranteed be in this order: onFrame -> Update -> Render in this case with three actors.

Questions for now:

  1. What do you thing about this? Any underwater stones?
  2. Possible other solutions for event driven game loop?
  3. Do I really need standard game loop? Any other approaches?
  4. Which immutable data structure is better for sending and receiving game objects between these actors (unmodifiable java.util.Collection)?
  5. How to divide update logic inside UpdateActor for increasing handling time?

Thanks!