M. Brandon Miller dot com

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.

Progress is being made in the world of XNA.  I spent a while figuring out the right way to load in the assets and properties mentioned before in a hierarchical format.

I've spent a lot of time gutting the sample platformer game of most of its' game-specific code.  I was going to toss out the whole system of 'tiles' for the background until I looked closer at how they worked.

At first I thought having such a large number of collidable objects would be a horrible drain on performance for anything larger than one screen, but then I realized that the grid was more than just a way to lay out levels, it was also a convenient way to sort things for collision detection, since we know where on the grid the relevant actors are.

I did, however, disconnect the collision and graphics elements of the grid.  As it stood, the collision type and texture were wired together.  I also added in a data-driven 'tile set' xml, which brings back memories of RPG Maker already.

I'm still going to support colliding actors who don't fit nicely into a series of cubes, but I'll be keeping this grid around for now to help lay the foundation for platforming adventure.

Today's screenshot still uses the sample assets, but it was screen-grabbed from my own XBox, so that's exciting.

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 . . .