What is an Event Driven Object?

Welcome back to the engineering corner of SV Rewards! Today I wanted to dive into some of the cool details that are allowing us to continue a pretty intense development effort efficiently without everyone knowing how to code. Enter the Event Driven Object system.

What is an Event Driven Object?

An EDO is basically a set of scripts that are designed to provide powerful plug-and-play options for interactive areas of the screen in Unity. When we need Ace to move, speak, use items, etc, etc, these EDO scripts take the helm and do what we tell them to, when we tell them to do it.

“Details, man!?”, you might ask feverishly …

The skeletal structure for EDOs is as follows: Event Driven Objects contain different Triggers. Triggers can be anything like a mouse-click, mouse-drag or collision event. These Triggers fire off Sequences. Sequences are a group of instructional Operations and Conditions. Once triggered, the Sequences will check whether or not the Operations assigned to them should fire off as a result of user actions and the logical Conditions being met. Once the Sequence confirms the Conditions are met, it proceeds to handle all of our event Operations in the order we specified.

Huh?

The long and short of that paragraph (for the non-technical or lost-at-this-point) is that we have a system in place that allows our designers and non-coders to graphically add simple logic checking and game functionality. The functionality is broken up into modular pieces, so the process is similar to stringing pearls together.

For example, the logic and associated functionality for picking up an item might look like the following: The current Character is Ace? The current Interaction is Hand? Start Sequence of Operations-> Walk to “Thinger” -> Play Animation “PickUpThinger” -> Add Inventory “Thinger” -> Add Points “3” -> End Sequence of Operations

This is an over-simplification, of course, and a “Thinger” is not actually in the game (that I know of … yet), but an abstract idea for some item in-game. I can’t give away the real stuff! That might get me trouble with the management …

Why is this important?

Creating our core game functionality in a way that is modular (broken up into manageable pieces, and not crammed into one file or object) allows me to make sure that each piece of the game that is added can be tested individually and adding another piece to the puzzle doesn’t jeopardize large chunks of the game’s code. It also allows me to present the designers and other developers with a more simple way to make adjustments without the need for opening up and editing code. It also promotes code reuse, which ensures that we only have one version of the truth (the relevant code, all in one spot and only in one spot) for easy editing and testing.

The lowest level of technical I’m comfortable going on this particular topic without actually giving out code:

The EDO script is a container for a bunch of other scripts. In the programming world, to make things modular it is customary to create an Interface (sort of like a code contract) that other scripts will inherit and are contractually obligated to conform to as far as implementing functionality. For example, the event Operation scripts are based on an Interface that requires each and every Operation script to implement a set of functions (like “RunOperation()”, which is the entire purpose of Operations and there’s no reason to have an Operation script without it.)  Doing things this way has allowed us to implement and test many similar pieces quickly and keep it all well-organized.

These EDO scripts are fed into a controller that handles the data (Sequences, Operations, etc) and uses the contractual functionality to produce the results that ultimately drive most of the interaction in the game.

Wrapping Up

That’s a very high-level view of the heart of the functionality that’s been developed for SpaceVenture. Going into much detail beyond is not something I’m allowed to do, however I can give plenty of examples that are not directly pulled from SpaceVenture’s code base, and will try to provide lower technical details on other topics Unity-related (and SV-relevant) if anyone is interested in my doing so. Just leave your feedback below and let me know what you want more or less of.