M. Brandon Miller dot com

During my time at Phyken Media, I wound up working on a lot more than just the Wizard Ops Titles listed over here.  I developed an number of other prototypes and projects that wound up exploring some interesting territory.

Here's some early gameplay from one of them.

At first glance, the 2D air combat may look like an imitation of Luftrausers, but if this project went through to completion, the end result would actually be a lot more like Galak-Z, since this is a game about randomly generated transforming anime robot adventures.  Actually, at the time this was developed, I think 17-Bit's own transforming robot was still a secret.

I've actually wanted to try to capture the fun of the Jet that turns into a Giant Robot for some time, and this is my first try with an actual gameplay prototype.  I decided to start in 2D since it was much lower scope and less likely to disorient players.  I also imagine that most players have some idea of how a jet and a fighting robot would handle in a side-view video game space, and how those two things would handle differently.

My initial pitch for this concept involved transitioning between a Contra-style run-and-gun and a Gradius-style shoot-em-up control scheme, since those were different forms of gameplay that accomplished similar goals (moving to the right and shooting everything).  One of my colleagues at Phyken suggested the more free-roaming style of arcade dogfighting, and I think it works better.  The end result was intended to be closer to swapping between Luftrausers and an Assault Suits style of play.

I did want to avoid stealing the signature stall-out action from Luftrausers, so I attempted to add some basic physics that caused the Jet to glide a bit when thrust was not engaged.  It's also worth noting that the jet takes damage from ramming into objects at high speed, but the mech does not.  At one point in development, there were buildings with destructible pieces and a viable strategy was to fly towards them at high speed, transform and crash the mech through the building.

No in-game art assets were integrated at this phase, so the aircraft consist of primitive shapes and the mech form is just the default ninja from this 2.5D Platformer Starter kit with some jet parts bolted on to him.

The team and I had some pretty crazy ambitions about procedural generated content.  The stages and the story of the game were planned to be randomized.

At this phase, though, it was just the terrain that was constructed at random.  A number of terrain prefabs had variable puzzle-piece end-points that would be snapped together to form the stage.  Then, the stage would actually loop infinitely as the player flew over it.

This was a fun project to work on, but ultimately I wound up moving on to other prototype projects . . .

After several years of neglect, the resume displayed here has finally been altered to reflect my more recent adventures, most of which have involved Wizards.

It's almost been four years since I began my adventures learning the ins and outs of mobile development in the Unity Engine, which seems pretty crazy.  Hopefully I'll have some more detailed stories of how all these events came to pass in the weeks ahead.

Another rare website update has appeared.  Not too much exciting to say at the moment, but I have finally updated the games list with a more complete list of links.  For me, this has been used mostly to wax nostalgic about old game projects, but the most relevant links for readers might be the links to the iTunes and Google Play stores for the mobile titles I've worked on.

I haven't said too much about those games here, but that may change in the coming weeks.  I'll see if I can get the OK to talk about some of the behind-the-scenes of those wizards-who-are-also-commandos.

So it's been years since I updated this website, but I do still exist.

The reason for my long absence is that I began working professionally with friends new and old at Phyken Media shortly after the FIEA Picnic in early June.

Without the need to job-search and network, my website and that XNA game quickly fell into neglect.

My professional adventures continue, so I can't promise regular updates here, but I have been reminded of this website's existence, so I should at least set to work cleaning up the e-cobwebs.

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.

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.