Overview
This blog post is going to cover how I like to organize code in an event driven manner. Is any one way of organizing game logic better than another, probably not. But what helps you find, modify, add, and debug your game logic a little easier is always a good goal to have.
When I say event driven code, I mean trying to generate an event when something happens in the game and not worrying about what happens because of that event. It then becomes the responsibility of the event sheet(s) listening for that event to perform an action. That may sound a little confusing, but just imagine you tap on the main game screen. It just issues an event called screen touched with a message of the x and y coordinates. A player event sheet might listen for that message and cause a jump to be initiated. Another event sheet might listen for the same event and play a jumping sound. What this allows you to do is to add, in the future, more event sheets that might listen for that event without disturbing the original event sheet that generated the initial event.
I'm sure that cleared everything up :), but you will find examples included with this blog post that will hopefully make it a little clearer and I will highlight some important points about this type of organization technique.
It should also be noted that it is possible to mimic some of this functionality just using functions, but where the real power comes in is that you can have one event trigger many actions without the sender knowing anything about who is listening for the event, except for including event sheets of course.
Requirements
- Install the Event trigger plugin https://www.construct.net/wf/make-games/addons/143/event-trigger
- Download Traditional example: https://drive.google.com/open?id=1qnplsPH6GBFokWs_MUoxmqpyHmueENQb
- Download Events example: https://drive.google.com/open?id=19WqsGIbzqG2lSWDwbXc1iijiobjGc-au
Example
Both examples do the same thing, but using a slightly different approach. It is a simple game that allows you to tap on the screen, play a sound, launch a missile to where was tapped, destroy the missile at that point, play a sound, decrease the missiles left, move the player and barrier towards the bottom of the screen, and show a message that the game is over when the player reaches the bottom.
Traditional approach
- Create a events sheets for the major functional components
- Implement functions in each event sheet related to the different items
- Implement all the calls in the main layout's event sheet
You can see in the main game layout that it calls different functions in different event sheets to carry out the functionality. If you needed to add something new the touch item you would have to call a new function from the main game event sheet.
Event Approahs
This time we'll look at the main game layout event sheet first to see how it's different.
- Uses the same event sheets as the traditional example
- The main game layout event sheet only generates an event that something happened.
- Other event sheets listen for the event, could be many that are listening
- The main layout can also listen for an event that is generated from somewhere else in the game.
So with this example it becomes easier for me to locate logic related to the player because it's all together. It also becomes easier for me to add new functionality tied to an existing event without having to modify the layout event sheet where the event is generated.
Messages
Messages that can be passed with an event can contain any number of items. So just use the plus on the screen to add additional items.
Wrap up
I didn't want to get into a lot of detail in the post directly. But this approach has helped me tremendously in my game which is about 80% done. As the number of layout events get more and more, this helps me stay a little more organized. Please look at the two projects included and just let me know if you have any questions. Is this approach for everyone, definitely not. But if it can help one person, I'm satisfied.