Skip to content

EventSystem[2].Tutorial(XMLExplanation)

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 a basis for understanding what the code is actually doing (I hope!), the next part we need to discuss is the data driven aspects of the Event System.  In other words, I am going to walk you through the xml file in the game and explain what each part does so that you can modify/add/delete/ whatever you want to customize the Events in your game.  Please keep in mind, however, that this was dev’ed to work with the DarkWynter HUD so, if you want to use this code as is with your own HUD, you will need to add in some functionality, especially for the  HUDEvent and DialogueEvent.  Otherwise, you will need to change the events to match your HUD.

If you open your EventSettings.xml file, you will see there are four entries in the file; a HUDEvent, a DialogueEvent, an AIEvent, and a LevelChangeEvent.  You will also note that there are four common elements in the XML for all - typeID, node, coins, and sanity.  The typeID is the name of the Event class that you want to use so they need to match the name of the class, even if you make a new class.  The rest of the common elements are the trigger for the event in question.  This is what the CurrentGameConditions checks to see if it matches the event – the rest of the data is what the event does.

So, we are going to go over the DialogueEvent first.  DialogueEvent is a very specialized piece of code that works directly with our DarkWynter engine HUD to allow us to draw actual game dialogue on the HUD, run it for a preset amount of time, and then remove it from the HUD when finished.

 

DialogueEvent has four parts that are unique to the Event - speaker, message, texturePath, and time.

speaker (string)– This is the person speaking the message.  Since our game’s Dialogue was all text based and we wanted to at least have the ability to show other people talking, we added in a name variable for the message so that our players would see who was speaking to them.

message (string) -  This is the actual message that will be printed on the screen.  Please note, because this is in XML, if you want to do special characters or insert new line characters, you will have to use the XML syntax. 

Some of the more common ones include…

<

less than

>

greater than

&

&

ampersand 

'

apostrophe

"

quotation mark




\r\n

New line

 

For a better explanation, refer to http://www.w3schools.com/Xml/xml_syntax.asp. 

texturePath (string)-  The texture path is the location of the image.  Please note that you do not have to specify the entire path as the game takes care of that for you.  All that you need to provide is the location of the texture in the Content directory, in this case, the texture is in Content/textures.

time (int)-  This is the time that you want the dialogue to be displayed on the screen.  Note that it takes an int and that the time is in milliseconds (1000 milliseconds = 1 second).

Next, we are going to cover the HUDEvent.  Also a specialized piece of code, the HUDEvent allows us to run other images on the HUD that are not timer based.

 

 

HUDEvent has five distinct parts that are unique to the Event - name, texture, texX, texY, and draw.   

 

name (string)   The name of the HUDEvent is what allows us to use the same Event to change different pieces of the HUD.  If you look in the FireEvent() method of the  HUDEvent, you will see there is an if statement that checks which name we are using and fires the code depending on the name.  Seeing as how we show a mini map and also a stack as separate images on the HUD, this allows us to reuse code with just a simple switch to know which one we are changing.

 

texture (string) The texture path is the location of the image.  Please note that you do not have to specify the entire path as the game takes care of that for you.  All that you need to provide is the location of the texture in the Content directory, in this case, the texture is in Content/textures.

 

texX (int) – The X coordinate (position) of the image to be drawn on the HUD.

 

texY (int) – The Y coordinate (position) of the image to be drawn on the HUD.

 

draw (bool) – This is what you use to control whether or not you want to display the image on the HUD (so you can flip images on and off at will).  

 

 

Next, we are going to cover the AIEvent.  In the case of our game, the AIEvent was designed to work with some of our customized AI code in which we have a method called goToDestination(Vector3 position) .  As you might guess from the name, the method tells the AI to go (in a straight line) to the position that we pass in.

 

 

AIEvent has five distinct parts that are unique to the Event - ID, drawable, destX, destY, and destZ.   

 

ID (int)   The numeric ID of the AI that controls this event.  Okay, so that is a little confusing, even to me.  So, let’s pretend like you have 5 AI in your game and they are numbered 0-4.  This allows you to associate the event with, in this case, AI[0] and the event will only work on AI[0].

 

drawable (bool) – Another piece of customization – we use this to determine whether or not to draw the AI’s position when in level editing mode.  However, you can change or ignore this at will as it will not affect your code one way or another currently.

 

destX (int) – The X coordinate (position) for the AI.

 

destY (int) – The Y coordinate (position) for the AI.

 

destZ (int) – The Y coordinate (position) for the AI.

 

Obviously, if you are going to use this particular event as it is currently designed, you will have to add your own code to your AI classes that control how the AI walks when given a vector destination.  However, this can also be modified to spawn new AI upon reaching a trigger point in your game (triggered based off collision or time), give the AI a health bonus, or whatever else that you need have the code to do.

 

 

Our final event is the LevelChangeEvent, which was designed to send a signal to the engine either swap the game to the next level or to write out the game logs and end the game.  This can also be used to kill the event list, wipe your graphics from memory, whatever you need it to do.  Notice, there is only one part to the LevelChangeEvent that is unique and that is the nextLevel.

 

nextLevel(int) –Tells the game which level to load next.  Can also be used (by negating the number, or however you want to do it) to end the game.

Post a Comment

You must be logged in to post a comment.