M. Brandon Miller dot com

Now that the website is fairly stable and the initial volley of resumes as been fired, it's time to keep the programming and game-design skills sharpened with some side projects.

During my FIEA adventure, we looked into XNA and C# during the programming class when we were learning to develop networked tools that could modify a game on the fly.

I picked it back up to try and devise a reasonably-scoped side-project to undertake.  Much like in the case of my first game at FIEA, I began by looking at a simple sample platformer and I began to think of how to modify it.  

I made a few basic changes and felt like I had a good feel for it, but then I decided that after everything I had learned at FIEA and 360Ed, I should actually set up a versatile and well thought-out class structure rather than just jumping in to making the little hero do different, amusing things.

It wasn't long before I ran head-first into the various ins and outs of the XNA content pipeline, which was explained surprisingly well in a number of places, but my desire to leap headlong into gameplay lead to my getting tangled up in the series of tubes.

Once I was freed from the maze of pipes and I had my xml files resulting in asset data, I found myself desiring and rebuilding a number of old, familiar digital friends from the Conspiracy Code games, such as 'asset' and 'property'.

While such classes would be rather different for a one-man 2D C# game than a 3D team effort in C++, it was still sort of odd and nostalgic to see a somewhat familiar structure taking shape.

Well, the tubes are becoming decidedly less frustrating, so hopefully I should be getting some of my own wacky programming art into this game soon.  When I do, this will be the place to see it.

Something that didn't really get fully shown off in the Master Plan play-through is the sheer variety of vehicles that the player can create, and to be honest, this video still just scratches the surface.

However, it does show off a few amusing possibilities.  The first vehicle is a very compact, enclosed vehicle with which I actually tried navigating the streets without exploding any buildings . . . for a while.

The second shows off a somewhat amusing option that came up in the play testing back at FIEA, building a vehicle with no weapons and ramming everything.  One member of the team even managed to defeat the final boss by building a giant hammer at his height and ramming it into him.  For my example, I tried building a train engine, because it's something I don't remember ever trying to build before.

Finally, I brought back the massive machine from the Vehicle AI Demo. I believe my inspiration for this one was the Guntank.

Rather than wasting any time, I'll just jump straight into the next round of rapid prototyping.  Also, pirates.

This time the focus was on telling a complete story with the game.  This game was a particularly wacky take on high seas survival horror.  The wackiness peaked when the team decided to include an enraged and undead sea cow as a pivotal plot point, and then hide this fact until the moment the game was presented.

On the technical side, I took what I had learned about platforming and punching and expanded it to a quasi-3D environment similar to classic beat-em-up arcade games.  

Of course, beating up zombies will only keep them down for so long, so to permanently dispatch them, there's a more gruesome approach in which our hero puts his hook hand to work.  The zombie is actually removed immediately during this move, and the hero and zombie then appear in a canned 'finishing move' animation.

The trade-off between the two was intended to be the time that must be spent in that animation, as the game becomes a race against the clock starting with the second stage.

In addition to the pirate-on-zombie violence, the game also featured a looting and pillaging system in the form of a lock-picking mechanic, which I pretty much stole entirely from Oblivion.

However, the twist here is that lockpicking must be done in real time while on the run from zombies.

Here is some of the Actionscript that displayed the lockpicking UI.  It could be overlaid at any time provided the hero was close enough to the object he was trying to unlock.

I included the first part of the ending here in part to credit the students who worked with me on this and in part because of the zany.

Today I wanted to look at another fun topic involving robots and explosions.

For the first round of Rapid Prototyping at FIEA, each team was given an existing intellectual property to work with, chosen at random from a list provided by the students.

I was lucky enough to be on the three-man team that received the topic of Transformers.  Our team of programmer, producer, and artist decided to base our game on the fight between Optimus Prime and Megatron from the begining of the 1980s animated move.

On the code side, I actually began using my individual game as a base.  I stripped the level down to one platform, added a second player, and bound the 'camera' to the mid-point between them.

As for the actual fighting action, I altered my run-and-gun shooting code to 'shoot' what I called 'punch zones'.

The 'punch zone' class and a sample of the 'punch zone' 'shooting' code can be seen here.

These zones were actually based on the hit-sparks from the previous game.  Visual flashes that would vanish within an instant.  They were altered to be invisible boxes that would appear in an instant to deliver a blow and then vanish.

This idea of having moves project hit-boxes was one I picked up by over-analyzing M.U.G.E.N. during my spare time in my undergrad years.  This is probably fairly standard practice in 2-D fighting games, but I don't think it would have been obvious to me in such a short time had I not spent so much time staring at fighting game debug information.

The two fighters 'shoot' these boxes at certain times during their various attack animations, and the boxes have a variety of properties, such as damage and hit-stun and knock-back.

The system for determining which attack to deal out wasn't terribly elegant, amounting to a series of if statements and arbitrary code numbers, but for a two-week rapid prototype, it allowed us to get in a surprisingly large number of fighting game features.

After that serious look into the code driving my Cohort's final FIEA project, let's look at something a bit more light-hearted from the very, very beginning of my time at FIEA.

Through the miracle of modern video capture, I've managed to record the entirety of the first ever game I made during that grand educational adventure.  This was a mini-game I made individually, building on a side-scroller template provided for the assignment.

The programmer art nature of it really shows in the way that there are flash gradients on everything, but I thought the heroine's running animation came out ok.

So the story behind this is that we were given some Actionscript resources and told to make a game in two weeks.  My initial thought was to take the sidescroller template and try to make a run-and-gun like a Contra or a Metal Slug.  

However, it was around this time that I began going to the producer classes and I began to think about trying to come up with more interesting game designs.

So, I made a game in which you stun and disassemble robots in order to build guns . . . which you then run with.  Baby steps.

Still, I had fun playing it when I went back to record this.  The sign at the end still amuses me for some strange reason.

Very late in the project, another student pointed out that Metroid Metal was awesome, which resulted in it more or less becoming the entire soundtrack for the game.

A useless bit of trivia . . . the heroine of this game is actually a side-character from an unfinished retro action-adventure game I made no less than three incomplete versions of prior to my time at FIEA.  In this game she's dressed up in the same uniform as Eri and Fio from Metal Slug.

One of the many things I'm thankful to FIEA for is finally giving me the necessary drive and deadlines to result in me finishing a game.  If I ever get around to posting videos of my pre-FIEA hobby games, you'll see how easily distracted I could be.

This is the commentary post for this code sample.

As mentioned in the Postmortem, the challenge of creating enemy AI was not tackled until fairly late in the project.  So when it came time to attack the problem, the task seemed rather daunting.

Simply navigating the city was a big enough challenge for the AI, but they also had to pose a threat to the player and their giant doom tank.

I sought out the advice of the FIEA faculty, and the idea for this sort of approached was raised.  I would return later to help improve my skills with vector math, and the solution would become vastly more efficient.

The purpose of this example function is to update a series of priority weights corresponding to the radial directions surrounding an AI Vehicle.  Provided are the direction of its' goal (usually a path node or the player vehicle) and the distance to that goal.

The radial directions around the vehicle are given a favorable weight based on how little they deviate from the direction to the goal, and then unfavorable weights are added in based on the positions of obstacles, other vehicles, and the player vehicle.  The algorithm then weights these factors to decide on the 'best' path to travel down.

The AI Tanks will simply turn in place until they face their ideal direction and then press onward towards it.  However, AI Cars perform a simple simulation of driving physics in which they cannot turn unless they are moving either forward or backwards.  As a result, a 'mBackup' flag is set when they are in imminent danger of crashing in to an obstacle.  Their tolerance for nearby threats also drops when backing up, which causes them to get a wider window of safety before they start moving forward again.

A feature I had actually forgotten about until I looked at this file was a somewhat humorous attempt to prevent vehicles from falling into a deadlocked state of constantly waiting for other cars to get out of their way.  Vehicles could actually become frustrated with waiting and begin driving recklessly, without heed for safety.  In particular, civilian vehicles will panic and begin to do this if the player's vehicle gets too close.  This actually causes one to ram into a Squad Car in this video.

The player vehicle is an interesting case as it can also be the AI Vehicle's goal.  Vehicles will drive towards the player until they get within firing range.  However, since ramming in to the player's vehicle is fatal to them, they also try to avoid it once within a certain radius.  It's also worth noting that the 'mSuicidal' variable does exactly what it says on the tin.  It is flagged for enemies who actually benefit from kamikaze tactics.


This function and this class as a whole was a major challenge, but it was also a great deal of fun.  It was very exciting when the cars finally began to avoid one another and successfully navigate the streets of our New Detroit.  However, making them provide a fun challenge the player would require many more hours of work . . . 

I'm in the process of gathering up code samples from my professional and academic adventures with hopes of formally beginning job application action tomorrow.  In the meantime, here's the end result of some of the code I wrote back at FIEA.


One of the ideas in the original pitch for Master Plan was to have the enemies analyze the vehicles players created to look for vulnerabilities.  This had a practical purpose of encouraging players to constantly build better vehicles, but it also had the thematic goal of making the player feel like they were the 'end boss' and that their opponents were the 'good guys'.


While this was originally pitched as a unique feature of the 'hero' at the end of the game, I actually wound up incorporating it in the enemy vehicle AI.  Each different type of enemy has a timer that starts each time the player launches a new vehicle.  Once a type of enemy has finished 'thinking' their squad becomes more accurate and they focus in on specific components of the vehicle.


The police squad cars in this video prioritize disarming the player's vehicle. They shoot off all of the machine guns arrayed on the 'arms' of this machine and then aim for the big laser on the top.


Later enemies have different priorities, like tanks who always aim for the player's cockpit or elite squad cars who try to snipe the highly volatile power sources that players can pick up along the way. 

In today's video I log a run through Master Plan, the final project of my FIEA cohort.  I'll have more to say later about the crazy story of how this project came to be.


For now, I'll just give a quick run-down of what this game is about.  In Master Plan you take on the role of Mad Scientist Supervillain who attacks the city and his heroic nemesis in his personalized mechanical engine of destruction.


At the start and near the end of this run-through, you can catch a glimpse of the vehicle editor used in the game.  All of the objects with glowing rings during the main game are components the player collects to use in that editor.  


Over the course of this play-through the vehicle becomes larger, more dangerous, and more garishly adorned with blinking lights due to the changes made by the player in this editor.


Conversely, these pieces can also be blown off of the player's vehicle by enemy attacks, allowing them to disarm and eventually destroy the machine.

Here's a video I put together of the five rapid prototype games (and one individual mini-game) from my time at FIEA.  

The music actually comes from Master Plan, our the final project.  

I cut off a bit of the UI in the Flash Games (and deal with some white space in the case of the bouncing ball game) so I could keep the whole video at a consistent level of HD shininess.  However, I'll have some more in-depth looks at the individual games later on.

The all-important resume is live in the 'about' zone.  I've also gone ahead and begun a listing of games.  Eventually, I'll try and link those in to blog entries in which I post videos and commentary on said games.


If I upload any of the old hobby games I did in my spare time pre-FIEA, or if I have sufficient spare time to whip up some new ones, I'll list those on that page as well.