WulfKat

 

Prototype By: Andrew Hicks and Katelyn Doran (Wicked Fly Games)
Engineering By: Amanda Chaffin, Andrew Hicks, and Jason Hardman
Code Review By: Jason Hardman and Amanda Chaffin
DLL and Docs By: Amanda Chaffin and Jason Hardman

Summary:

The Event System project is an example (and dev’ed code) of data driven events that run at a pre determined time after a pre determined condition has been met. Okay, so what the hell does that mean, anyway? It means that you can quickly and easily add RPG elements to your game (dialogue, HUD changes, and programmatic cutscenes) with minimal code changes needed. The way the Event System works is through events that run off triggers. You set the trigger, meet the trigger conditions, and the event that matches those conditions will fire.

Download:

The zip files for the EventSystem

The Demo project: Requires XNA, Visual Studios, and DirectX SDK to run

Installation: All instructions are written with the assumption that you have downloaded the zip files for the EventSystem.

So, now that you have the EventSystem installed into your game and you are not receiving any errors (i.e. you set the xml file to copy always, you included all the images, etc), I bet you are wondering what in the world you are supposed to do now. I mean, it still just shows a blue screen, right? Well, before we can get into how to make it work, we need to go over how it actually works (trust me on this one - the theory is totally important for understanding how to make it work later). In this part of the explanation, which will be in two parts, we will discuss what the code does that makes all this work.

 

 

 

 

 

 

 

 

 

 

 

 

 

In the EventSystem folder, there are two classes – GameEventHandler.cs and GameEvent.cs. There is also a folder called EventTypes which holds four classes – AIEvent.cs, DialogueEvent.cs, HUDEvent.cs, and LevelChangeEvent.cs. The first class that we are going to discuss is the GameEventHandler.cs.

The first thing that you should notice upon opening the GameEventHandler (GEH) is that it is a public static class with a public static list of type GameEvent and a public static GameEvent called CurrentGameConditions. The GameEvent list, as you might guess, contains all of the GameEvent of the current level (or the entire game, that part is up to you).

The most important concept, the CurrentGameConditions (CGC), is the global and current condition of the game, in other words, it holds the state of the game triggers as you play it. At its most basic, the CGC is a collection of triggers, in this case we are using two ints (triggerNode and triggerCoins) but this is completely expandable to be based on health conditions of the player or the AI, elapsed game time, etc. You will notice in the GameEventHandler class, we create the CGC as a new GameEvent without passing in any parameters (there are two constructors in GameEvent – one for the CGC and one for the rest of the events which takes an XML node). Basically, that constructor sets up the CGC as a game Event with the four preset triggers.

/// <summary>

/// CurrentGameConditions Constructor

/// </summary>

public GameEvent()

{

 _trigger_ID = -1;

_lastNodeVisited = 0;

_triggerCoins = -1;

_triggerSanity = -1;

}

There are four methods in the GameEventHandler class – LoadEventsXml, UpdateEvents, isEventTriggered, and killEventList.

LoadEventsXml (please note that you have to pass in content to run this part) goes through the level xml file that you specify when you call it (remember, it was GameEventHandler.LoadEventsXml(this, “_xml\\EventSettings.xml”); in your main class. If you open your _xml\\EventSettings.xml file, you will see the following that there are four events in the xml file…

DialogueEvent, HUDEvent, AIEvent, and LevelChangeEvent

 

Now, we aren’t going to go over how the xml file works yet, that is the next part of the tutorial but I am going to tell you what the code does in the LoadEventsXml method with the assumption that you all know how to read a file from XML and use the data in your games. (If not, just leave the code alone). So, for each EventSettings in the file (note: there is only one), create a new XML node node, then for each node in node, find the speficied node by the typeID (aka the name of the class). If the typeID matches one of the four events, create the event and add it to the list.

 

 

UpdateEvents – if the CGC is changes, the set method that changes the CGC parameter will call UpdateEvents in the GameEventHandler. UpdateEvents spins the GameEvents List and calls isEventTriggered on each event in the list. The isEventTriggered method takes the event’s trigger conditions and matches them against the CGC, if there isnt a match, we get another event from the list. If we get a match, we call the event’s FireEvent() method and remove the event from the list. Each event has it’s own FireEvent method (this is what you want to change if you want to add functionality to the Events).

 

 

The final method in the GameEventHandler is the killEventList and this simply drops the eventList and resets it to nothing.

 

 

The GameEvent class the parent class that all GameEvents inheirit from. It holds the triggers for the CGC and calls update in the GameEventHandler when the triggers in the CGC change. This also holds the portions that all the events share – the typeID, the triggers, and a bool of whether or not the event is triggered.

 

 

The GameEvents themselves have three parts - variables and accessors, the constructor, and the FireEvent method. The variables are all set by the XML node passed into the class inside the constructor. The FireEvent method, called when the CGC matches the Event’s triggers, will do whatever you have coded the game to do.  The FireEvent method in each of the Game Events is where you have to write your own code - our code will not work in your game - and we cannot write this code in a way that is modular…it’s just impossible.