Reconciling external events with the game loop

Question

Is there any way I can program (in Java or Python, but open to other solutions) some game logic based on events, timed and sent by player input, without dealing with it inside the game loop, by having a game state that has a number of scripts listening for events, and those scripts can themselves fire events that change the game states and by consequence the scripts listening for events? An example bellow

class BombScript {

    private GameObject bombReference;

    void bombDefused() {
        // change the script listening for events
        bombReference.destroy();
    }

    void bombExplode() {
        // launch some events, change the script listening for events
        stopListeningForEvent("bombDefused");
        bombReference.destroy();
        sendEvent("bombExplode", bombReference);
    }

    void bombPlanted() {
        // if somehow the server receives a defuse command
        onEvent("bombDefused").execute(bombDefused);

        // else, if 6 seconds pass without an "bombDefused" event
        onTimeout(6).execute(bombExplode); 
    }
}

I'm having trouble imagining a concrete implementation for that, specifically the timed based "if/else"

Answer 1

The way I've handled this in arc in the past - particularly for the JS version where you can't possibly avoid having to handle external events of various sorts - is to use a service that specifically acts as a proxy to the world outside the game loop. These services listen on the relevant event dispatcher(s) and stack up incoming events, which are popped off at the earliest opportunity by the controller class(es) (the main actors of the game loop in arc and can access any service) and handled thereby. You could handle one or more such events in a single game loop frame.

Using services neatly keeps this code away from your main game logic which - as you rightly indicate - shouldn't be polluted by external event loops.

One thing I will say about this is that if receiving game state from a server or peer, you will want those events to represent deltas, not absolute state since it becomes that much harder to update your local data model if you have to compare the last and current state objects (i.e. the events) just in order to determine what has changed... caused me some initial headaches.

This was tested in production for a client's real-time app, so I imagine it would work fine for you.

Answer 2

I'm not sure if you are asking about the implementation or the usage of an event based system, so I'll touch on both.

The implementation of event systems can be complex, and varies greatly depending on the language, but it is generally doable. The link above to the (excellent) Game Programming Patterns' article on the Event Queue is one hint to an implementation. The Observer (Delegate) pattern is also related; instead of binding to events passed by a mediator object, you bind directly to events fired by your objects.

After you have some building blocks, the game logic part is just that - logic. In your specific time-based example, here's what I'd do:

1. Create a Timer class. It fires a single event: TimerExpired, when some given interval of time has elapsed after the timer is started.
2. Create a Timer object in the BombScript class. In bombPlanted, initialize the timer with a time of 6 seconds and bind bombExplode to its TimerExpired event.
3. In bombExplode, unbind from the bombDefused event (since that can't occur anymore) and explode the bomb. Additionally, reset the timer, but don't start it again.
4. In bombDefused, unbind from the timer's TimerExpired event and reset the timer. Now, the timer won't fire.

---

I can see one big problem with dropping the game loop: things won't be able to happen without events firing. This is important for things like physics and AI, which must act independently of player input. Of course, you could just make a timer that fires every 60th of a second to update those systems - but that's basically just re-implementing the game loop. Barring those issues, I think it is possible (although, perhaps, difficult) to implement the server the way you are planning.