Test post
Checking out permissions and things, please ignore.
Pages
Categories
-
RSS Links
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.
EventSystem[1].Tutorial(CodeTheory)
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.
Figure 1: EventSystem Flow Control
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.
EventSystem[0].Tutorial(InstallationInstructions)
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, programatic cutscenes) with minimul 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.
1. Copy the folder event system into your main project folder (see Figure 1 for example). |
 Figure 1: Event System Added to a New Project |
2. If you open the files, you should see 6 classes and one folder (Figure 2). |
 Figure 2: The Six Event System Classes |
3. Copy the _xml/EventSettings.xml file into the root of your project (Figure 3). |
 Figure 3: Inclusion of the XML File |
4. Set the EventSettings.xml file properties to “copy always” (Figure 4). |
 Figure 4: EventSettings.xml set to Copy Always |
5. Drag the textures folder into your content folder (Figure 5). |
 Figure 5: Adding in the EventSystem Content |
6. Open your main game class (EventSystemMain in this case). |
|
7. Add using DarkWynter.EventSystem; into your using statements (Figure 6). |
 Figure 6: Using Statement |
8. In LoadContent(), add the line
|
 Figure 7: Event System Code |
9. You should now be able to compile the game.
But wait, there is nothing there, right? That is because we haven’t told you what to do next!
HUD Tutorial
Prototype By: Priyesh Dixit (ScreenObject) and Hunter Hale (HUD)
Engineering By: Amanda Chaffin
Code Review By: Jason Hardman
DLL and Docs By: Amanda Chaffin and Jason Hardman
Engineering By: Amanda Chaffin
Code Review By: Jason Hardman
DLL and Docs By: Amanda Chaffin and Jason Hardman
Summary:
The HUD DLL is an extensible heads up display for XNA platform games that can be used for any type of single player game. Self contained, users merely add the DLL, a couple of references, some method calls and the HUD appears on the screen, ready to go. Of course, you will still need to change the graphics, the text, and build in math for things like the health bar but this system is easily integrated into any XNA game of any type.
Download:
The zip files for the HUD
The Demo project: Requires XNA, Visual Studios, and DirectX SDK to run
Part the First: Download and Installation
Part the Second: Getting the HUD to work in a new project.
Part the Third: XML ImageDisplay Explanation
Part the Fourth: Image Positioning
Part the Fifth: imageReference, what?
Part the Sixth: Text Display Explanation
HUD Tutorial Part the Sixth: TextDisplay Explanation
Prototype By:
Priyesh Dixit (ScreenObject) and Hunter Hale (HUD)Engineering By: Amanda Chaffin
Code Review By: Jason Hardman
DLL and Docs By: Amanda Chaffin and Jason Hardman
Summary:
The HUD DLL is an extensible heads up display for XNA platform games that can be used for any type of single player game. Self contained, users merely add the DLL, a couple of references, some method calls and the HUD appears on the screen, ready to go. Of course, you will still need to change the graphics, the text, and build in math for things like the health bar but this system is easily integrated into any XNA game of any type.
Download:
The zip files for the HUD
The Demo project: Requires XNA, Visual Studios, and DirectX SDK to run
If you open your XML file that you downloaded and scroll down below the ImageDisplays, you will see a bunch of TextDisplays that look like this…
<TextDisplay nameID =“text1“ text =“quad upper center“ posX =“0“ posY=“15“
quadrant=“null” colorR =“250“ colorG =“100“ colorB =“250“ colorA =“255“
toDraw =“true” imageReference =“null“ operation=“add“ offsetX =“25“ offsetY=“7“/>
If you notice, most of the attribute tags are the same in the TextDisplays as they are in the ImageDisplays. The functionality of those tags is the exact same functionality that the ImageDisplays have so there please refer to the ImageDisplays section if you need a better explanation. There are a couple that were not in the ImageDisplays…
If you notice, most of the attribute tags are the same in the TextDisplays as they are in the ImageDisplays. The functionality of those tags is the exact same functionality that the ImageDisplays have so there please refer to the ImageDisplays section if you need a better explanation. There are a couple that were not in the ImageDisplays…
text – The text that you want displayed on the screen.
operation – The type of operation that you want performed on the TextDisplay using a the Vector2 offset if the imageReference does not equal null. There are four operations…
· add
· subtract
· multiply
· divide
offsetX – The X coordinate of the offset Vector.
offsetY – The Y coordinate of the offset Vector.
So, if you want to change the text, all you need to do is type in the text field what you want to say.
If, once you have drawn the item on the screen, you wish to change the location using the imageReference, you can choose to just add based on the image’s position. Finally, you then can use the offsets to make minute adjustments to insure that your text is positioned correctly.
Now, I will walk you through how to add a game timer to your project that displays on your HUD.
First of all, you need to create an image for the timer box if you wish. Your XML tag for the timer box will look something like this…
<ImageDisplay nameID =“Timer“ texturePath =“ArtAssets/HUDTextures/Time“
posX =“15” posY =“415“ quadrant =“UC“ colorR =“255“ colorG =“255“
colorB =“255“ colorA =“255“ toDraw =“true” imageReference =“null“
imageAttribute =“width“ modifier =“0“/>
As you can see, the image is being loaded into the “UC” (Upper Center) quadrant so the actual position values are irrelevent (but the numbers are there).
Make sure that you add the image to your project in the HUDTextures folder inside the ArtAssets folder inside Content (Note: you can put this wherever you need to, just make sure that your file path in the XML matches the location of the item in question).
Your XML value, if you want to center the timer, will look something like this…
<TextDisplay nameID =“TimerText“ text =“00:00“ posX =“0“ posY=“15“
quadrant=“null” colorR =“250“ colorG =“0“ colorB =“0“
colorA=“255“ toDraw =“true” imageReference =“Timer“
operation =“add“ offsetX =“25“ offsetY=“7“/>
As you can see, the text is not being loaded off the quadrant system but, because we are pulling the location from the Timer image, we do not need to actually try to position the image on the HUD in the XML…but, repeat after me, we cannot leave the values blank.
If you have done everything right, you will have something like Figure: 11…
Figure 11: Timer
But, how do we make the time change?
Go to your human class (or whatever has an update loop) and add a timer of some sort…I use System.Diagnostics.Stopwatch for all my timing needs. Start your stopwatch in your LoadContent method. You will also need to get the index of the Timer from the TextDisplays list so build the same for loop that you did for the ImageDisplays in your LoadContent and store the int in the class.
Once you have the relevant information, you can then add the timing code – make sure that you do this in your Update method. Here is my timing code, based off System.Diagnostics.Stopwatch, so if you use something else, your mileage may vary…
// Update the Game Time
int seconds = ((int)gameTimer.Elapsed.TotalSeconds) % 60;
int minutes = ((int)gameTimer.Elapsed.TotalSeconds) / 60;
string formatedSeconds = seconds.ToString();
if (seconds < 10)
{
formatedSeconds = “0″ + seconds.ToString();
}
string timing = minutes.ToString() + “:” + formatedSeconds;
hud.textDisplays[timerIndex].text = timing;
That’s it! And that is how the HUD works…
Next, dialogue!
HUD Tutorial Part the Fifth: imageReference, what?
Prototype By: Priyesh Dixit (ScreenObject) and Hunter Hale (HUD)
Engineering By: Amanda Chaffin
Code Review By: Jason Hardman
DLL and Docs By: Amanda Chaffin and Jason Hardman
Engineering By: Amanda Chaffin
Code Review By: Jason Hardman
DLL and Docs By: Amanda Chaffin and Jason Hardman
Summary:
The HUD DLL is an extensible heads up display for XNA platform games that can be used for any type of single player game. Self contained, users merely add the DLL, a couple of references, some method calls and the HUD appears on the screen, ready to go. Of course, you will still need to change the graphics, the text, and build in math for things like the health bar but this system is easily integrated into any XNA game of any type.
Download:
The zip files for the HUD
The Demo project: Requires XNA, Visual Studios, and DirectX SDK to run
imageReference:
Remember the nameID attribute that I told you to use a unique name for? Well, there was a very valid reason for that, beyond what I harped on earlier. You use the nameID attribute in the imageReference attribute to denote what image you wish to refer to.
For example, let’s say that I want to draw the dude image in the top left hand corner and then draw the health bar to the right of the the dude icon. My XML file will then look like this…
<ImageDisplay nameID =“DudeHealthBar“ texturePath=“ArtAssets/HUDTextures/healthBar“ posX =“215“
posY =“315“ quadrant =“UL“ colorR =“255“ colorG =“255“ colorB =“255“ colorA =“255“
toDraw =“true“ imageReference =“Dude“ imageAttribute =“width“ modifier =“15“/>
<ImageDisplay nameID =“Dude“ texturePath=“ArtAssets/HUDTextures/character“ posX =“215”
posY =“315“ quadrant =“UL“ colorR =“255” colorG =“255“ colorB =“255“ colorA =“255”
toDraw =“true“ imageReference =“null” imageAttribute =“null“ modifier =“0“/>
When you run the game, providing that you have added the health bar image into your game, you will see something like Figure 10.
Figure10: Character Icon and Health Bar
Options for the imageReference include ANY image that you have PREVIOUSLY added in the XML file. Please note the PREVIOUSLY notation – you cannot base an image’s location off an image that had NOT been loaded yet, ergo, the image that you want to reference must be entered before the one that is going to reference it (XML reads top to bottom).
Options for the imageAttribute include “width“, “height“, or “both“. The tags tell the HUD to go to the referenced image and find the image attributes of width, height, or both. The system then adds that number to the second image’s starting position, in a sense, scooting (hey, it’s a technical term now) it over where you want it to display.
The final option in the image display is the modifier option. This is a simple int that you can use to scoot the images into more precise locations. As it is an addition function, if you wish to make it a subtraction, just use a negative number.
So why did we do the whole imageReference routine instead of just setting the image height and width as an XML tag? Well, hardcoding numbers is bad and hardcoding those numbers means that, if you scale your HUD, the images will not rescale their height and width. It is better to just allow XNA to discover the image attributes for you and use those so as to avoid all kinds of silly mistakes that enter into programs with hardcoded numbers.
But, aren’t you going to show us how to make the health bar subtract depending on how healthy the player is? Um, no. Ok, well, I will show you how to set it up. You need to have an image of a full health bar and an empty health bar. In your human class (you do have one, yes?), you need to add the using statement as explained in the installation instructions.
Now, the HUD stores all of the ImageDisplays in a publically accessible list (Game1.hud.imageDisplays) so that you can check the list for the index of the image that you want. After you have added the using statement, you now need to find the index of the image that you are wanting, in this case, the index of both the full and empty health bars. To do this, I suggest that you make two int in your human class to permanently store the image’s list index (it beats having to spin the list every time you hit the update loop). After you have done that, you need to look for the images, I do this in LoadContent(), and the code for that is something akin to this…
for (int x = 0; x < Game1.hud.imageDisplays.Count; x++)
{
if (Game1.hud.imageDisplays[x].name == “DudeHealthBar”)
{
healthBar = x;
}
}
So now I know where the image is in the list (remember, you have to do this for any image or text that you want to modify), I can access the actual item in the list and tell it to change. The code for that is something like this (your math may be different)…
// Update the health bar
Game1.hud.imageDisplays[healthBar].Source = new Rectangle(0, 0,
Game1.hud.imageDisplays[healthBar].width,
(int)((( this.health * Game1.hud.imageDisplays[healthBar].height / 80))));
So now that you know how to put images on the HUD, move them around to the desired location, and even, hopefully, have your health bar working, we need to move onto the text portion of the HUD…Part the Sixth!
HUD Tutorial Part the Fourth: Image Positioning
Prototype By: Priyesh Dixit (ScreenObject) and Hunter Hale (HUD)
Engineering By: Amanda Chaffin
Code Review By: Jason Hardman
DLL and Docs By: Amanda Chaffin and Jason Hardman
Summary:
The HUD DLL is an extensible heads up display for XNA platform games that can be used for any type of single player game. Self contained, users merely add the DLL, a couple of references, some method calls and the HUD appears on the screen, ready to go. Of course, you will still need to change the graphics, the text, and build in math for things like the health bar but this system is easily integrated into any XNA game of any type.
Download:
The zip files for the HUD
The Demo project: Requires XNA, Visual Studios, and DirectX SDK to run
Image Positioning:
Like I said last time, I am going to assume that you know how to name your images and load them into your game. Therefore, we are going to start how you set up the position of the HUD image on the screen using the DarkWynter HUD system. Essentially, you have two options as far as the image position goes; hardcoding the images or using the quadrant system.
Hardcoding Images (More Expert Use)
If you wish, you can hardcode the image positions to show at a specific location in your game. To do this, simply change the posX and posY to be the location that you want to use and make sure that the quadrant’s value is set to null (quadrant=“null“). Remember that you cannot leave any value either blank, or take it out of the XML as you will cause the HUD to break. Remember, also, that the top left corner is (0,0). After you have hardcoded the image position, remember, too that you can change the base location by using the image reference tags, which we will discuss shortly. If you hardcode all of your image positions, you can also call hud.Resize() to correct the images to the proper viewport in the game.
Quadrant System
The quadrant system works by dividing the viewport space into 9 different quadrants: UL (upper left), ML (middle left), BL (bottom left), UC (upper center), MC (middle center), BC (bottom center), UR (upper right), MR (middle right), and BR (bottom right). Each quadrant knows where it is supposed to draw the images and you can also change the base location by using the imageReference tags. Note: The quadrant system is the DEFAULT system for the HUD so, if you do NOT set the quadrant=“null“ in the XML tag, you will be using the quadrant system. For a more indepth explanation of the quadrant system, please refer to Figure 9.
Figure 9: The Quadrant System
As you can see, each of the quadrants has the math already pre-configured for you so that you just need to use the actual attribute tags for the XML file listed in green in the introductory paragraph above. Also, notice the order that the tags are in (Y, X)…what can I say, I’m dyslexic. If you look in your HUD.xml file that you downloaded and installed into your project (if you have been following along), you can see that every image and text display are using the quadrant system and not the hardcoding. You will also note, however, that each image and text display has numbers in the posX and posY tags. If you leave out the numbers (it’s stored as an int in the code, so whatever you want as long as it is an int), you will crash the program.
And the monkeys will be sad.
Ok, so now that you have how you can load images to either a hardcoded or quadrant position, what happens if you want to load two images in the same quadrant? Or what if you want to hardcode an image position and then base your second image next to the one that you just loaded?
That is what the imageReference was designed to answer and what we will discuss in Part the Fifth.
HUD Tutorial Part the Third: XML ImageDisplay Explanation
Prototype By: Priyesh Dixit (ScreenObject) and Hunter Hale (HUD)
Engineering By: Amanda Chaffin
Code Review By: Jason Hardman
DLL and Docs By: Amanda Chaffin and Jason Hardman
Engineering By: Amanda Chaffin
Code Review By: Jason Hardman
DLL and Docs By: Amanda Chaffin and Jason Hardman
Summary:
The HUD DLL is an extensible heads up display for XNA platform games that can be used for any type of single player game. Self contained, users merely add the DLL, a couple of references, some method calls and the HUD appears on the screen, ready to go. Of course, you will still need to change the graphics, the text, and build in math for things like the health bar but this system is easily integrated into any XNA game of any type.
Download:
The zip files for the HUD
The Demo project: Requires XNA, Visual Studios, and DirectX SDK to run
How to Use the HUD:
So this is all very well and good, you say as you stare at the HUD that is both useless and somewhat pretty, but how do I replace your images with my images? And how do I make it work for things like a timer and a health bar?
Don’t worry, young samurai, it is very easy to do and I will explain all to you.
The first thing that you need to know is that the entire HUD, including positions and types of displays, are loaded in the HUD.xml file. In other words, if you want to change the HUD, you need to change the HUD.xml file.
XML Images Explanation:
Now, if you go into your HUD.xml file, you will see a bunch of ImageDisplays that look like this…
<ImageDisplay nameID =“Dude“ texturePath
“ArtAssets/HUDTextures/character“ posX =“215“
posY =“315“ quadrant =“null“ colorR =“255“ colorG =“255“ colorB =“255“ colorA =“255“ toDraw =“true“ imageReference =“null“ imageAttribute =“null“ modifier =“0“/>
ImageDisplays are, simply, the textures that you want to display on your HUD. If you have gotten your HUD integrated at this point, you will notice that there are 9 of the character images (see Figure #8) in your game, scattered in different locations and in different colors. All of those images are loaded via the XML file and you can change, add, and delete anything in the XML file at will.
Figure 8: Character Icon
Wait! But first, we must explain how to do it and what all the parts are from the XML configuration…
ImageDisplay – The name of the Node, also the type of display to be added to the HUD.
nameID – The name attribute of the image.
Note: This name is here for your convenience so that you can find the HUD image that you want to change so each nameID should be a unique but readily identifiable name.
For example, emptyHealthBar is a good name but image35324rqw, in a word, sucks. From the name image35324rqw, the next coder in line has less than no idea which image that actually is just by looking at the name and has to go track down the actual image to figure out which one it is, unless they know your naming conventions. Now, that may not seem like a big deal but, trust me, it is a very big deal. One that actually gets more monumentous the later in the evening it is and the less caffine there is at the programmer’s disposal.
texturePath – The actual location of the image, with the name of the image minus the file extension, in the project.
posX – The X coordinate of the position.
posY – The Y coordinate of the position.
quadrant – The quadrant that you want the image drawn into.
colorR – The red channel of the desired color.
colorG – The green channel of the desired color.
colorB – The blue channel of the desired color.
colorA – The alpha channel of the desired color.
toDraw – A boolean that tells the HUD to draw the image or not.
imageReference – The image that you wish to refer to (see why names are soooo important now, yes?) for the drawing location of your new image. Can be self referencing also.
imageAttribute – The attribute (height, width, or both) of the referenced image that you need for your drawing location of your new image.
modifier – An int that you can use to offset your images from one another. This one does an add operation but, if you use negative numbers, you can also get it to subtract.
Oh, my god, that’s so complicated, right? No, not really. Deving it was a little complicated but that’s all been done for you so now you get the easy part – changing the XML to show what you want it to show.
I am going to assume that you know how to name your images and load them into your game. Therefore, we are going to start how you set up the position of the HUD image on the screen using the DarkWynter HUD system. Essentially, you have two options as far as the image position goes; hardcoding the images or using the quadrant system. We will do this in part the fourth.
HUD Tutorial Part the Second: Getting the HUD to work in a new project
Prototype By: Priyesh Dixit (ScreenObject) and Hunter Hale (HUD)
Engineering By: Amanda Chaffin
Code Review By: Jason Hardman
DLL and Docs By: Amanda Chaffin and Jason Hardman
Engineering By: Amanda Chaffin
Code Review By: Jason Hardman
DLL and Docs By: Amanda Chaffin and Jason Hardman
Summary:
The HUD DLL is an extensible heads up display for XNA platform games that can be used for any type of single player game. Self contained, users merely add the DLL, a couple of references, some method calls and the HUD appears on the screen, ready to go. Of course, you will still need to change the graphics, the text, and build in math for things like the health bar but this system is easily integrated into any XNA game of any type.
Download:
The zip files for the HUD
The Demo project: Requires XNA, Visual Studios, and DirectX SDK to run
All instructions that follow will be based on your use of the game1.cs class (which is renamed to HUDDemo in my images. The first thing that you need to do is open your game1.cs class and add your using statement as shown in Figure 3.
Figure 3: Using Statement
Oh, but there is so much more to do!
After you have added the using statement, you have to declare the HUD, a viewport, and a string with the CurrentDirectory location in it (Figure 4).
Figure 4: Variable Declaration
Now, drop down to your LoadContent() method in your game1 file (or whatever your top level class is) and initialize your variables (see Figure 5). The reason that we have to initialize in LoadContent() instead of in the traditional Initialize() is because we need the graphics.GraphicsDevice.Viewport to exist, which it does not exist until after all the Initialization() calls have finished.
You need to get the viewport from the GraphicsDevice, add the file name of the HUD xml file to the filename string, and then declare the new HUD, passing in the game, the game’s spriteBatch, the viewport, and the filename (which, if you did a plus equals [+= ] and put the HUD.xml file in the correct location, will allow the HUD to find the file in the debug folder – don’t worry, this does work on an Xbox as well).
Figure 5: Initialize Content
The last thing that you need to do is tell the HUD to draw itself so drop down to your Draw call and call the HUD’s draw call (Figure 6).
Figure 6: Draw Call
Hit RUN and you should see something like Figure 7.
Figure 7: The Game window with the HUD Displaying