All posts by nkleiter

Building Something Cool Chapter 3: “If You Love Something, Set It Free”

March 2015.

On March 2nd, Unreal Engine announced it was becoming free.  Along with that, Unreal released version 4.7 of its Unreal Engine software.  It was a huge day for our little capstone project.  Everything seemed to be clicking into place.  Not only were we knocking out a surplus of tasks early on, but we were also on the forefront of a game design MOVEMENT.  We were ecstatic.

Then we read the release notes.  This epic update was not just changing the game design mantra and buffing an already polished design – it also changed a whole slew of inbuilt function headers, names, and so on.  This is good and all, but more than half of our c++ classes and functions had to be re-written or updated, which was a huge setback.

Sam, Isaac, and I toiled over the hundreds of lines of code we had all already written in an effort to fully integrate 4.7.  We deleted classes, pieced together broken function calls, renamed dozens of outdated references, and debugged our butts off.  Though Kurt and Julia were able to continue work without many interruptions from the update, by the time Isaac, Sam, and I were done updating…

April 2015.

… well, you see where I’m going with this.  After a sprinting start in the first week of March, I had stumbled on the usable actor class I was supposed to implement.  Isaac had only finished half of the animations we needed and still had not started testing out the VR mode. Of course, Sam was still popping out c++ classes like it was his job (it kind of was, but that’s a different story).  However, he was now doing so at an admittedly frustrating pace, due to having to relearn many of the class/function declarations he had already learned, along with having to adapt all of the new stuff into an entirely new architecture (we were now using mostly blueprints).

Beyond the setback of the update, we were hurting in some other implementation fields.  Kurt was struggling with the incredibly complex art of AI in Unreal Engine (for which debugging is often impossibly abstract).  Sam was being crammed with not only his work, but most of the overflow of other group members’ issues.  Julia was having to make some hard design choices, especially when deciding which elements were superfluous and which were essential.  As for me, I had no attached sounds, no player market to speak of, and the usable actor class (I finished a couple weeks into April) was proving to be much less useful than previously thought.

And to top all of this off, STEM backed out of their promise to have developer kits out before the middle of March.  The due date was two or three weeks away, and all of the sudden we had to explain to our professor that an integral part of our design, hand motion, was no longer viable.  We had to scrap a huge piece of our user experience, which upset several of the members of the group immensely.

We were in a nuclear meltdown.  A month and a half ago, we were at optimal cruising speed, and now we were in atmospheric reentry with a malfunctioning parachute.

However, we knew what we had to do – plug on and get this thing finished, come hell or high-water.

Building Something Cool Chapter 2: Dev Days

In this installment of Building Something Cool, I will be going over the first few months of development of our project, and I will discuss the challenges we faced while learning and growing accustomed to the Unreal Engine interface.

image courtesy of Zak Parrish, (unreal engine's channel)
Image Courtesy of Unreal’s Zak Parrish

December 2014.

After getting our design fleshed out, it was time to get started with the real work for the project.  Knowing the sheer amount of stuff we wanted to have in our game, we decided to start early.  Before the semester had come to a close, we had already tested our peripheral, the Oculus Rift, and had a github set up for our project.  There was an uphill battle ahead of us, but we took early steps to ensure that we were up to speed before we started our climb.

January 2015.

Having made a repository for Angelis, set up a virtual reality lab on campus (with some badass new graphics cards), and hammered out our design, it was time to write some code.

Cue the classic Scooby-Doo line, “let’s split up, gang.”  Sam, Kurt, and I began work on the C++ classes.  Julia started doing some level design.  Kurt also began work on AI research.  And, Isaac began hammering out some code for the character animations.

I was tasked with creating a usable actor class.  For this, I needed to make it so that we could form actions around specific objects in the game world.  If you clicked on a spawner node, for example, a weapon would spawn close by (or in your inventory).  If you walked in front of an elevator, the up or down arrows would light up when the reticle was over, and the elevatory would move correspondingly.  This was also important for several character interactions, such as picking up a weapon or handing a weapon to an ally.

Kurt was working on AI classes.  For this, he needed to create a diagram of ways the AI interacted with the world.  This involved creating a state diagram, with four super-states – rest, patrol, alert, and attack – and many sub-states and nodes.  Also, he had to manually create cover nodes for the AI to interact with.

Sam had reign over all of the character and weapon classes.  He would gather attributes from our shared Trello page, then file them accordingly into classes.  After this, he would tie them in with character or weapon blueprints and get them all working in one of our test maps.

Julia, after reading up on several design books, was working diligently on creating a captivating level.  After creating one based on her original design, she made the revelation that it was entirely too large for use in the game mode we had in mind, and so she made up a new, more relevant level model.

Isaac was making slow-and-steady strides in the animations department.  Finding assets and applying them to our current characters and weapons was his first task, most of which were readily available in the Unreal Engine asset store.

A couple weeks in, and we had already made strides that some groups weren’t even thinking about yet.

February 2015.

Barring some early midterms, most of us were putting hefty hours into the project every week.  With the semester beginning to fly by, we knew that persistence was paramount to finishing on time.

I had compiled a comprehensive list of game sounds, as well as finalized my economy formulas; I was falling behind on the usable actor task, but I made some real headway on sound assets.  Kurt and Sam ground out several working test levels and characters.  Isaac found some useful information about an upcoming VR mode for Unreal.  And, Julia finished her level entrance.

Things were shaping up fast and we were ahead… but that wouldn’t last.

The Ten Rules of Gaming

Here is a little story I wrote when I was a junior in high school in 2009.  It’s one part hilarious, two parts relevant, and many parts facetious.

I thought that this would be something funny to write about. So here are my ten rules of gaming.

Rule number one-

We do not talk about gaming… to attractive women. Gaming, while it may be the ultimate form of entertainment, is also the ultimate lady repellent.

Fight club ref. Solid start.

Rule number two-

The noob is a subgenre of human that is the scum of civilization and deserves to be crushed in all situations.

Amen, little me.

Rule number three-

Any gun that is cool and/or useful in a first person shooter is not to be used EVER in online play. Those who use such weapons are dirty nooblets and will be trolled. such weapons include, but are not limited to:

the noob tube (CoD)

the sword (halo)

the sniper rifle (any fps)

the chainsaw feature (Gears)

Rule number four-

Screen-watching results in nut-punching. Don’t do it.

Rule number five-

If you can’t tell me what any of these abbreviations mean, you need to gtfo:








Rule number six-

Just as being social requires consuming copious amounts of alcohol, gaming requires consuming large amounts of mountain dew and sometimes energy drinks or dr pepper.

Or alcohol.

Rule number seven-

The C stick is not a valid instrument in super smash. This is the most sacred rule of gaming. Violations of Rule seven result in severe punishment.

Rule number eight-

Trolling is not cool. It is off-limits unless trolling a noob or a troll.

Rule number nine-

Anyone who humps people they kill in Halo is an 11-year-old nooblet vagina.

Rule number ten-

Achievement gamers are NOT real gamers. Achievements are cool but real gamers game for the experience, not for the experience points.

And that’s my list of the ten rules of gaming.

Well, there it is.  Little me… err… skinny me wasn’t playing around with that writing style.  I have to say, getting serious on the last rule kind of brought all of the elements together (and it is definitely something I haven’t changed my attitude on).  I hope you enjoyed this old list of gaming guidelines.  I know I did.

Building Something Cool: A Long First Chapter


The following is a history of my own experience with making a shooter centered around VR technology.  It started out as a capstone project, and has become a recurring source of work and experience.  This post is about the capstone part, but will be continued with many chapters that go over my (along with some of my team’s) current struggles and accomplishments in continued work on this project.

September 2014.

As we all sit in Capstone class discussing our collective worry about what we could do that might be meaningful, I have no hesitance.  I have known what I wanted to accomplish since the day I chose Computer Science as my major – to make a game.

The professor walks in, a large bag in tow.  As he unloads packages from the wrappings of a garbage bag, something catches my eye.  It is a piece of popular culture I immediately recognize: an Oculus Rift Dev Kit 2.  Hot off of being bought out by Facebook, I have some reservations about Oculus’ application with my project ideas, but possibilities keep popping in my head.  I’m thinking “What kind of simulations could work well in VR?  How about remaking a classic game like the original Star Fox in first-person VR?  How reasonable is the overhead with running an application in VR?” and so on.

After discussing all of the new toys and giving us the usual “this is how the real world works” lecture, the professor gives us our assignment for the week: put up an ad on the Blackboard page for the class about what we want to make.

If my memory serves me, I was the first to slap an idea on the discussion board.  Before the professor could even finish his sentence, I was scratching a prompt on the message boards: “Let’s make a game using the Oculus Rift.”

It did not take long to catch on either, as I made contact with my first potential group partner within a few hours: Kurt.  An enthusiastic IT major with experience in AI and modeling, Kurt is a perfect fit for this project.  Better yet, after informing him of my interest, Kurt tells me that he has already recruited the interest of several other candidates: Isaac, who has modeled and animated with Maya, Julia, who has an artistic background with experience in C++, and Sam, a C++ aficionado.  Within 48 hours, we already have 5 enthusiastic CS/IT majors with a unified goal of making a VR-capable video game.

This was it.  The ball was officially rolling.  I, along with my new partners, was about to be a sprouting game designer.

October 2014.

Within a few weeks, our group was up to 6 bright-eyed programmers: myself, Kurt, Isaac, Julia, Sam, and Fernando, who had experience with the Oculus Rift.  We had a name, Project Angelis, a story for our game, and a general idea of what we wanted to do.

A space shooter set some time in the next century, your mission is to capture and hold an abandoned space station array above a planet that is prime for colonization. By surviving against waves of enemy-faction mercenaries, you and your crew can establish their place as the prime stockholders of this “Next Earth.” (via our gitHub wiki page)

This was our game idea, and it sounded pretty awesome.  We were building a first-person shooter that had one game mode vis a vis Nazi Zombies or Horde Mode (Gears of War), and also had one map, but had a ton of room for added content in the future.  Moreover, we were building a VR experience, because we did not think there was enough out there for VR: it was a hot field ripe for exploration.

Here is a log of many of the design ideas we were shoving on paper as fast as our hands could type:

  • one mode, one level, increasingly difficult waves (difficulty modifier), more points (money) for player character every level, enemies not harder per AI guidelines but have more health and stronger weapons
  • sci-fi setting implies space background, weapons with “energy,” space station area
  • VR is going to require some heavy work with HUD
    • the idea here is that there is no real HUD, by the sense of the word
    • for example, all “energy” for weapons on arm, rotating a STEM peripheral or pressing a button activates this display
    • could show energy for each type of weapon (regular, special, heavy, whatever), player health, so on
  • VR also requires very high FPS, like 60-70, so we have to optimize for that
  • triggers for waves, and also environmental hazards present
  • have to handle player seeing through walls using Oculus by making screen dark at certain angles (head tilt)
  • support enemy and friendly AI
  • pause and menu function integrated
  • no effects on player camera (rain, etc.)
  • ambient noise and weapon sounds

We had our hands full, meeting 2-4 times a week to discuss the logistics of our game.  It was beginning to take shape in impressive fashion, though.

Mid-October – November 2014.

Inevitably, as we proceeded, we began to garner a few road bumps.

Deciding which engine to use was initially a struggle.  CryEngine offers incredible graphics, the potential of great performance, a wide kit of physics tools (oh, those water effects are hard to resist), and cross-platform abilities.  Unity (which was the only free one at the time) is wonderfully accessible, has a low learning curve, and boasts a huge asset library.  Unreal Engine also has a moderate asset library, and it has the potential to show the same graphical fidelity of CryEngine.  But where Unreal truly shines is in its helpful ‘VR Mode.’  Ultimately, the high learning curve with CryEngine and Unity’s poor editing capabilities gave a slight push, and we decided to go with Unreal.

Kurt, our self-appointed AI Lead, was working on research for AI methods for our game, and was uncovering the truth about AI – its nearly-insurmountable complexity.  Not only was it going to be difficult to script the AI in the first place, but he was going to have to do all of that on a platform he had never developed for.  Thankfully, several books proved incredibly helpful, and Kurt was able to get the research he needed done in time to start development (if you are curious about AI, check out Kurt’s favorite author, Matt Buckland: AI Techniques for Game Programming or Programming AI by Example).

Another problem we ran into was the sheer amount of content we were wanting to put in our game.  We assumed things would be easy or implied in game design (animations would just be there, guns would automatically fire, and so on).  Thankfully, early on in development our professor, who was experienced in game design himself, warned us that we needed to keep it simple.  “Don’t sell me too hard on this thing,” he reminded us.  And truly, this was some of the most poignant advice he could offer to the beginning game designer, as the most prolific mistake made in the gaming world, possibly the professional world as a whole, is making promises you do not deliver on.  We still wanted something special, but realized quickly that we were going to have to cut back.

Despite these problems, the design phase was running along smoothly, and our game was about to be radder than a radroach from the Capital Wasteland.

December 2014 or End of First Term.

Fourteen weeks and 75 pages of design documents later, we handed in our final paper.  Angelis was officially in development.

Here is a comprehensive list of our functional requirements up to this point: Oculus, STEM, and Omni integration; User menu enabled; At least one game mode & one level with enemy and friendly AI; Ambient noise and dynamic sound included; Environmental interaction such as weapon and friendly AI shop and score; And, of course, it was to be a first-person shooter wave-survival game.  Our non-functional requirements included: High framerate must be maintained to ensure low Oculus disorientation; All elements of the game mode included (how many waves, points, etc.); Game must have a functional economy (point systems included); Many weapons must be usable and animated correctly; Minimize disorientation in any way; And, level must be designed with playability in mind.  Of course, many other factors were taken in for our design, but this is a hint at what we had spent a semester discussing and writing about.

As the semester finished, we had solid designs for weapons, our environment, our game mode, story, sound, and the level flow.  Overall, it was a huge success, but the hardest part was yet to come.

On Writing – Making Your Own Words

photo courtesy of
photo courtesy of

Shakespeare liked to invent his own words, often using currently available words to make them mean something else (most often just changing them from nouns to verbs, verbs to adjectives, etc.).  Such words that we still use today include puke, gloomy, dauntless (hey, Divergent), and jaded.  This is undoubtedly one of his greatest contributions to the English language, and is one of his most praised achievements.  That being said, I absolutely love to shakespeare (see what I did there, noun -> adj).  I like to take cool words and give them new or added context / meaning.  For example, in my first post, I use the word “vermilion” to describe something as beautifully bright.  Vermilion is one of those exceptionally titled crayons you find in the 152-pack, and say to yourself “well, that’s a sweet name for a color.”  It is a very bright orange-ish red, and it is quite beautiful : perfect for an adjective meaning ‘bright.’  I thought it would make for an great example of a word that can be given new meaning.

Making new words is great, and whether or not I have the same mastery of the English language as Shakespeare, it seems worth it to establish my writing by using my own dialect borne on an already-established form.

An Introductory Post

As a first foray into blogging, I feel it appropriate to establish intention, background, and motive in order to explain what it is I am doing here and who it is I am blogging to.

Initially, I had the intention of solely expressing myself through written word.  After relatively little thought, it occurred to me that something worth reading does not include just my opinions or inexperienced writing.  Thusly, my intention is the following: to provide adequate journal of my quest for improvement in the fields of programming and written language.  Hopefully, it will provide relatable expressive hopes, victories, and struggles, and will inspire some to express their own journeys.

A little about myself: I am a Computer Science student at the University of Missouri.  I grew up on a farm in a small, rural Missouri town, where I was not blessed to have much access to internet during my 18-year residence.  Following a little self-intervention and a bit of light programming in college (after finally having a consistent internet connection), I was able to come to terms with what I was passionate about.  Thusly, I ended up on the long, arduous road of programming.  I’m hoping to make it into the (currently not very) lucrative area of game design– I’ve made a couple Asteroids remakes in C++ so far.  On the other side of creative expression, I’ve been writing (bad) poetry for about 8 years now, and I love to jot down the occasional short story or write the occasional political essay.  Behind all of this, I’m a pretty normal guy – I swim, play a bit of tennis, dominate some Smash (melee, of course), and drink a little too much beer on the weekends.  In any good work, I feel it is important to know who is writing.  Therefore, here is a little piece of this new blogger.

Many would argue that the hardest part of creation is motivation.  What is going to make this thing worthwhile?  Who will even pay attention to what I have made / am making / will make?  Why am I doing this (or worse, what am I going to even make)?  For this page, motivation was easy.  Starting from a need for a little resume boost, creating a blog eventually evolved into a place where I could publish my thoughts clearly, record my progress over the course of my education, and possibly relate to others who are ‘finding themselves’ in their own studies.  The eventual hope is evolving this blog into a webpage that is relatable and interesting, studious and vermilion.