Day #5, Sunday, June 27th.

Here’s the rough concept for timed events I already mentioned in my last posting. It’s working for now, but I’ll do some more tweaks to abstract this even further and make it more flexible.

Keep reading below if you’re interested in today’s progress. Comments are welcome! In case you missed it, also don’t forget to read the reports on my steps in Android game development: Steps 1-3 and Step 4.

The diagram shows how timed events integrate into the component system. There’s one dedicated component TimedEventHandlerComponent which allows attaching a list of events which itself contain a timestamp, denoting the time in the game when the event is to be executed. For level creation, I create an invisible GameObject for the active level, currently consisting only of the TimedEventHandlerComponent and a bunch of TimedSpawnEvents. These contain the name of the object to spawn and it’s starting position and velocity. Once an event is executed, it makes use of the GameObjectFactory to create the object to spawn and the GameObjectManager to add it into the object lifecycle.

First, let’s look at the advantages of the status quo. One great thing is that you not only can spawn any game object any time you want, but also can make up events which temporarily disable player controls, display texts or dialogs, make the player move in a predefined way,… As intended, such time-based stuff is great for level and cutscene design where the order of events is predefined.

But that’s just the first step. Binding an event to a certain time is only one way to trigger an event. An event could also be executed due to the player hitting a certain hotspot, the player reaching a critical energy level, one evening finishing in a chain of events, etc.
So instead I’ll separate triggers and events in one of my next iterations. But first, I’ll proceed to collision testing and response.