M. Brandon Miller dot com

I'm alive.  Hooray.

There are three reasons for the lack of posts as of late.  The first cause is that, the search for employment has heated up and demanded more of my time, which is a good thing.  The second reason is that I had proceeded far enough with the engine that I felt that I needed to step back and decide what sort of game I was intending to create.  This resulted in a lot of game design brainstorming that, while productive, did not make for good video.   The third reason is 3D Dot Game Heroes, which was completely legitimate research into developing retro-style games.  Yes.

The bosses in Beat Hazard, with their random assortment of turrets, reminded me a bit of the super procedural bosses in Warning Forever.  This rekindled an idea I had for making a game with this engine, namely, the generation of random side-scroller bosses.

The first type of boss I could imagined creating a simple set of, interchangeable powers and behaviors for was a character similar to our hero.  A guy with a set of attachable weapons and armor that do various things.  I thought back to the endless supply of Robot Masters from the Mega Man games and came up with the next phase in this process.

Random boss guys should drop their random boss weapons when defeated.  This made the immediate mental connection with my recent experience playing Borderlands and Torchlight.  A supply of random boss 'man' characters dropping random weapons could make for a highly amusing 'loot treadmill' scenario.  

I won't get into too many further details of the assorted silly game ideas I had, but they were numerous and silly.

But were they fun?  To determine that, I began laying out plans to develop some of the basics of the system and prototype it out, starting with a system by which I would randomly generate weapons for our side-scrolling protagonist.

The early phases of that can be seen in this video, where ten or so random weapons are dropped into the inventory.

These weapons have properties that are rolled for on various tables including increasingly rare gun attributes.  

The most important may be the type of projectile fired.  While the bullets have few differences at this early phase, they do pull from different asset files that can define stats such as damage and velocity, as well as what sub-class of bullet they are actually defined by.  This will allow me to do things like having a grenade that respects gravity and bounces without changing the core 'dynamic gun' class at all.

I also added some basic stats on the back-end to define things like hit points and attack power.  I also added some basic RPG-Style flying numbers, although they're pretty much all '1's at this point, but the systems are coming together.

Orange world!  A practice 360Ed picked up from Valve that I'm applying to this project.

This should help me skip over the programmer art stage and get more features in quicker, but it should also prevent any of this stuff from slipping in to a final game.

Early this week I added the ability to pause the game, and alter the flow of time for different actors.  To demonstrate this, I went with the obvious parody route of giving the hero slow-motion cool shades.

Then I spent a while trying to get a basic inventory and equipment UI system going.  It's very placeholder, but it seems to be working so far.



Oh wow that's orange.

After the success with shoes, I moved on to try and re-integrate the basic enemies from the XNA Platformer example back in under my 'Character' umbrella.  The enemies now use a movement system much more similar to the player character, and they obey the law of Gravity, amongst other things.

They still just wander back and forth for now, but that was all I needed to go ahead with player versus enemy collision detection and response.

To do this, I added the concept of 'conditions' to the game characters.  Conditions act after equipment and further alter the actions and movement of Characters.  In this case, the condition I added was 'HitStun' which causes the guy to throw up his hands and move with very little friction for a short time.

With this came a few minor additions like robbing the player of control and adding a temporary invulnerability to prevent stun-lock.

Then, to fight back, I added another piece of equipment, a little blue gun.  'Guns' over-ride the normal asset loading when they find a 'bullet' amongst their children.  Rather than adding it to the hierarchy, they store it off in a hidden place and then clone it and attach it to the active room when fired.

This should allow for a wide variety of data-driven guns that shoot various things.

Finally, this afternoon I looked into the XNA particle effects sample and quickly integrated it into my engine so that the enemies could explode when hit with bullets.

Double video post today.  Since the last time I've spent a while working on the collision detection.  I wanted to keep things simple for now, but I ran into some edge cases and other wackiness that it took me longer than I would have liked to hammer out.

Also, I was frustrated by my efforts to get cross-platform save data working due to my failure to convince the XBox to ignore certain items during serialization.  Eventually I would up creating a stripped-down version of my property object for saved data.

So once that was over with, I decided it was time to add some Parallax backgrounds, and what I stumbled on to was the whole issue of the draw order.

The current solution is not as elegant as I'd like.  There's pass that traverses the actor hierarchy and demands that everyone line up their renderables into one of several different rendering layers, then the actual draw calls are made after that.

This will probably need serious optimization later since the whole "everybody, get in here" happens every frame.  However, for now, it does allow different tiles in the room tileset to be drawn on different layers, while still respecting the actor hierarchy for things on the same layer. 

Also present today, doors!  The blue spaceship that isn't a parallax object is a door that the player activates with a button press, taking them to another 'door' in another 'room'.

Today's second video is a very simple sample of the idea of 'equipment', special children of the player and certain other actors that modify and respond to their actions.

In this case, we have gear that modifies the player's physics when equipped, allowing him to jump higher.

These test boots also caused me to realize that I had completely forgotten to cause children to render and detect collision relative to their parent.  I quickly added that in, so now the hero's boots will remain with him.

So I spent a while yesterday getting a variety of 'camera' options in play.  Eventually I decided for now to just stick with a constant-speed following of the hero for this sample, since my various attempts to add more complicated physics would require too much polish to look right.

The 'zoom' on it can be set via the same asset properties as everything else, either on the camera asset or in the world that calls in a generic camera.

This camera is also tracking not the hero directly, but an offset point set by a property on the hero, who, as you may notice, is an old retro hero from an unfinished project of mine that pre-dates my FIEA adventure.

He is also scaled up from his original sprites, which, while it looks rather fuzzy, is another fun-filled feature added in the past day.   The bounding box also scales with the sprite and remains tied to the sprite's origin.

I'm going to have to find some sound effects and music in the public domain for future demos.  For today's Youtube demo, I hope no one objects to my briefly stealing from Kirby.

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.

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.

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.