Senior Capstone: a Simple HUD or Screen Overlay in Kismet and Flash

Updated 16 June 2014

This tutorial covers a quick method of creating a very simple HUD or screen overlay using Kismet and Flash.  Assuming you have your image ready, this should take you about two minutes to put together.  You can use it as a starting point for a Kismet-based HUD if you'd like, but I'd recommend it as a means of prototyping or for simple screen overlays, as things will get messy pretty quickly.

A sample of what you can do with this method

Update 16 June 2014: Step Zero: prepare your UDK map

Thanks to commenter Glorius for pointing out that this does not automatically work right for the UTDeathmatch game mode, as I was using UDKGame for my project.  If you're using Deathmatch, the first thing you will want to do is hide the HUD that comes with it.  This is something that can quickly be done in Kismet, don't worry.  You just need the "Toggle HUD" node attached to an "On Level Load" node through the "hide" option, with the target set to "All Players."  Here's a picture of that for clarity:

Simple, but effective

Please comment below if this does not work for you for some reason.  It should not affect the pseudo-HUD I'm about to show you, but it should hide your ammo and map graphics if you're using Deathmatch and any other graphics from game modes that use an UnrealScript-based HUD.

Step one: prepare your image

In this case, I wanted a pseudo-HUD that would show the player how to equip the different items in their inventory once they picked them up.  My first draft was a sloppy .jpeg, while my final version (shown above) was done in Illustrator.  What program and file-type you use is up to you-- just make sure it's of the quality you want and something that will play nice with Flash.  I'm not entirely sure about scaling yet, so I recommend saving it at whatever size you want it to be on the screen.

Step two: making the Flash file

After you have the image ready, you'll want to drop it into Flash.  For this project I just went with their default canvas size, but you might want to alter it to be the right resolution or ratio for your image and game.  If you haven't used Flash before, you can just drag your image in from wherever you saved it on your computer.  Get the image place where you want-- again, for noobs like me, there are align tools under "Modify..."  When it loos good, hit "File > Export > Export Movie..."

This part I'm a little iffy about because my files derped when I moved my UDK environment to a different hard drive after the project was completed, so bear with me.  You'll want to create a new folder in UDK's Flash repository, which can be found at (wherever you put it)\UDK-(build#)\UDKGame\Flash  So you'll be saving your .swf files in UDK-(build#)\UDKGame\Flash\YOUR_FOLDER  Name the folder and file whatever you want, but avoid using whitespace in your filenames, as it can confuse UDK.

Step three: import the Flash file in your content browser

Hopefully you already know how to do this.  I don't recall it needing any special treatment, so just import it like you would anything else and save it in your project's package.  If you're not sure how to import things, open up your Content Browser and hit the "Import" button at the bottom of the window and then find the file.

Step four: putting it together in Kismet

This part is also pretty simple.  The logic is on level load, start up the "movie" we made.  Here's a diagram of the Kismet:

Yay Kismet!

In the "OpenGFxMovie" node, you'll need to use the drop-down bar to select the .swf file to open.  I just left all the other settings on default.  Now when you start up the game, your fancy screen overlay should show up!

Step five: polish and expanding the code

From here on, you're on your own.  Maybe you'll want to tweak the Flash file to look better, maybe you'll want to show and hide the overlay with a button press, or maybe you'll want to get fancier with the code and have it actually do something interesting.  My next little tutorial will cover how to put replaceable text into Flash files and edit said text in Kismet.

It's pretty hacky and doesn't do anything interesting on its own, but this is a very quick way to get something up on the screen without writing a single line of UnrealScript.  It suited my purposes perfectly, and I hope it'll benefit someone else out there as well.  If you have any problems or questions, please let me know.  It's been a while since I put this system together, so I might not have written the most precise instructions.

Happy deving!

Return to senior capstone scripting tutorial index

Senior Capstone: Reveal

Hello again, internet!  After much hair-pulling and confusion, I was able to package my level into an .exe that actually worked!  I present to you the end results of my senior capstone project:

Project introduction

The actual level

An imgur album of work-in-progress and final screenshots

A fly-through video of the finished level

Overview of the art style and pipeline

Overview of how I made the HUD

Senior Capstone: Project Introduction

Hello again, internet!  It's been quite some time since my last post, but this time I was actually doing something useful between then and now.  That "something useful" is the focus of this post!

This is the final semester of my undergraduate career, thus the semester in which I'm to complete a senior "capstone" project that shows off all the fancy things I've learned in the past four-and-a-half years.  As I hope to eventually become a video game programmer, I wanted my project to focus on programming for a small game.  Believe it or not, the majority of my hands-on school-induced programming experience has been in the Unreal Development Kit, so I approached the professor who had taught me how to use it and asked him to be my advisor.

Our discussions led me to decide that the project should be a short level for an adventure game.  I had those old Flash-based point 'n' click games in mind when I started, but the idea morphed to include a more modern 3D experience, using a first-person camera and allowing for free movement throughout the entire space.  Navigating through the level consists of picking up and using items to solve puzzles.  At this point, these puzzles range in difficulty from putting an object in a certain place to comprehending a logic-based riddle.

My initial level design had a vague, needlessly open layout, but the puzzles I came up with gave me a good start for my revisions.  I haven't actually taken my school's official level design course, so the design I landed on isn't exactly a work of art.  However, my advisor said it would suit my purposes well enough, and I didn't want to argue-- after all, I was more interested in getting the Kismet together than anything else when I started.  Below is the sketch of my general level layout.  For those of you who aren't experts at deciphering scribbles, the map consists of three different ground heights, a few buildings, a few underground passages, staircases in varying states of disrepair, and a player path that sort of resembles an ampersand.  At least, the sloppy way I draw them.  The overall goal is to light the four magical beacons so you can enter the chamber of... erm, something.  I haven't quite figured out the details of the story yet.

This is still pretty accurate, actually...

The level is inside a spacious graveyard, but I'm not currently aiming for a horror game.  This combined with my lack of organic modeling skills encouraged me to decide on a low-poly, low-resolution art style.  As I spent a considerable amount of my summer working on pixel art, it seems like a nice representation of my skills.  If I ever revisit this project after its completion, I may change this approach; for now, it suits my needs well enough.

So far, the most fun I've had was while putting together the Kismet for the level.  Most of my design required relatively simple programming-- things like picking up items and opening doors-- but a puzzle that has you lighting torches in a specific order required some head-scratching and a couple re-implementations.  At this point I am calling on a few Flash files to add some fancy text to a puzzle, but am largely depending on the pre-built announcements of the UTDeathmatch game style.  I hope to replace this with my own solution before the end, even if it's just to replace the HUD with a player inventory display.

I have a small imgur album set up for this project, which I hope to fill as I get more assets finished and presentable.  Of course, I will be updating this blog with more information as I find the time.  My goal is to cover the major parts of this project in detail so that people other than me can benefit from the weird bits of things I have learned and will be learning while I complete this project.

Until next time!

Simple Turret Using UDK and Kismet

/* Long-winded introduction */

Hello, internet!  As I probably haven't mentioned, last semester I was in a course called Virtual Environments at my university.  For our final project, I ended up in a group with a guy who was very eager to make more than just an environment-- he had an idea for an interesting yet simple game level.  Since I like to pretend I'm a programmer, I immediately said I'd love to try some Kismet and see how game-like we could make the level in the few weeks we had to do the assignment.

The "level" we turned in was definitely impressive, considering it came from a beginner-level class that had just barely skimmed over some of the basics of Kismet.  I only feel comfortable saying that because the rest of the class said it was awesome when we presented it, by the way!  However, it was missing one of the most interesting gameplay aspects-- turrets.

Yesterday I started work to add them.  This is what I have so far.

Please note: this is a work-in-progress.  You are welcome to use this code as you see fit as long as you're aware that parts may not work right all the time or at all on your build.  I'm new to this, so I may not be able to answer all of your questions about this code or the inner workings of Kismet/UDK.

Note: the game type used in our level was UTDeathMatch.  I'm not sure if it's a necessary setting to make this stuff work, so I figure it's best to let you know just in case.

/* Turret details */

Our level's turrets were imagined to be rather simple-- player gets in front of turret, player gets shot; player shoots turret, turret falls over and stops working.  The best comparison I can think of is the turrets from Portal.  To accomplish this, I needed to main functions:

1. Shoot at player
2. Respond to getting shot by player

/* Kismet details */

Our first function is circled in red and labeled #1.  My Kismet is a complete mess, so I'll summarize.  The code begins when the player Touches the Trigger Volume I have placed in front of the turret.  Note: don't forget to set the Touch node's "max trigger count" to 0 like I always do!  On touched, it sets our "if" statement to true; if untouched, false.  If true, we go to a section of vector math that gives us a location to spawn projectiles.  For this mesh in particular, I want it to be about 150 units above the pivot point, where the pivot point is currently slightly in front of the turret's gun but level with the floor.  After that, the code gets the player's location as a vector.  This is necessary because the Spawn Projectile node can't have a Pawn as an input for some reason.  Now the PlayerLocation and SpawnLocation vectors are fed into Spawn Projectile.  I have chosen the rocket from the drop-down list in the node's settings, so a rocket will be fired at wherever the player was standing when this function was called.  I included a delay at the end of Spawn Projectile to keep it from shooting too rapidly-- if the player stands in the Trigger Volume, the turret will shoot rockets at him/her every two seconds until the player either leaves the Volume or dies.

Whew!  Seems a lot less complicated in my head!  This next part gets even hairier, so take a breather if that one wore you out.

The second function is the part that's messy and may not be working right.  I seriously doubt this is the best way to handle this, so please let me know if you have a better solution.  Note: the turret is currently set as a KActor-- I don't know if this code will work with any other physics setting!  Our first step, labeled in blue as #2, is actually quite simple.  Here we just get the turret's rotation when the level first starts.  This is so we have a point of comparison in the next step.  In the section labeled in orange as #3, we are telling our turret what it should do when it gets shot.  In this case, we want it to figure out if it was rotated far enough to be considered toppled over.  I put a brief delay after the Take Damage node to give it time to fall, and then get its new rotation.  The code looks like a huge mess here because, unless I'm just doing it wrong, vector math in Kismet is unnecessarily complicated.  It's really just checking to see if the difference between the new rotation and old rotation is significant enough by subtracting the two, getting the absolute value of the result (I had to code this node myself, mind you), and then compare it to a value I determined to be "far enough" (in other words, about 45 degrees multiplied by 182.044 to get the UnrealScript rotational units).  If the rotation of the X or Z component is "far enough," then the turret's Trigger Volume is destroyed and a message pops up letting me know it worked.  Note: you might notice that the Y component is there but not being considered-- that is because shooting the turret in just the right place long enough will cause it to rotate in place but not fall over, which will incorrectly trigger the "death" of the turret.  It looks like it should be the Z component doing this when looking at the turret in the editor, though, so I think it's a byproduct of creating the mesh in Maya, where Y is up.  I'm not sure about this theory, so let me know if you have an explanation!

/* Conclusion */

It always kinda surprises me when I get stuff like this working, even though it looks so simple when you're the one playing the game.  I think next I'm going to see if I can't add a dynamic trigger volume so it'll keep shooting you if you rotate it in place, and then a blinking light or something to make it more obvious which turrets are on and which are off.  I'm starting to think just diving into UnrealScript and making a new class for this would be the best way to finish it off, but I'm not sure how to translate some of the Kismet functions just yet.  I'll be sure to post an update if I do, as it'd be a lot easier to test out a new class than try to reproduce my Kismet!

Thanks for checking out my work.  If you have any questions or suggestions for improvement, please let me know.