M. Brandon Miller dot com

This is the big one.  This project went beyond a prototype and is actually listed as  an unreleased title on the resume.  The core gameplay was mostly complete, although it would certainly need some more iteration after additional testing.

As a note for legal purposes, the audio from this in-development build is a series of copyright-infringing placeholders and I claim no rights to that part of it.  It exists here just to show that work on setting up audio was being done.

Once again, I was trying to think of a type of game that would be low-scope, yet unique.  In my research into arcade titles, I discovered how rare the sort of Puzzle-VS style Shoot-em-up was.  There was a sequel to Twinkle Star Sprites, which I didn't know about, and there are a couple of Touhou Project games in this format, but that was all I could find.

But what would our unique theme for this sort of game be?  Since the Phyken team had recently visited the Kennedy Space Center, I proposed making the two vertically scrolling ships competitors in a literal Space Race.  Shortly thereafter, we decided that sending cartoon animals into space had just enough basis in fact to make it a more fun route.  It wasn't long before we settled on dog breeds from around the world piloting spacecraft.

It became a sort of alternate-history Canine Cold War in which a World Warrior-like array of international Space Agencies were engaged in battle-missions as they ascended into orbit. 

The cast began with six planned dogs and spaceships, but eventually it expanded to nine, with the center slot being an unlockable final boss character.

​The game's gameplay took place in game fields that could be instantiated.  The primary form of field was the competitive game field, of which two would normally be created.  However, the character select screen features two small custom gamefields that demonstrate the abilities of the various spacecraft.

The game's tutorial system uses an alternate version of the standard gamefield instantiated in the center of the screen with a special UI on the side.
​

Speaking of tutorials, the game featured this how-to-play demonstration, which would also play alternately from the game's attract mode when left idle.

It may be a bit too fast to read in its' current state, although everything it covers is covered in greater detail in a series of actual tutorials.

Here is a sample from one of the early tutorials.  It demonstrates the Touhou-inspired hitboxes and then rolls into the rules of the game.

The way gameplay flowed and was scored was revised a few times, and I believe that the later parts of this tutorial are still based on one of the earlier revisions, actually.  However, at the time they were developed, they explained the various elements of the Interface and the basic and advanced rules of play.

In the end, while the game was relatively easy to quickly develop, the gameplay may have become a bit more complex than I expected.  I wanted there to be depth to the player-versus-player action, and as a result I ended up adding things like using a bomb to recover after being hit and several different types of attacks that are thrown back and forth from field to field.

Also, an arcade mode with a story was developed.  I mostly skip through the placeholder-filled dialog, but the systems and the script were in place.  It probably needed a lot more proofreading, but I was happy to add it.

If the opponent on the left looks like they're firing slowly, that's intentional.  The AI in arcade mode has restrictions placed on their ability to shoot quickly and recognize and avoid obstacles.  As the player progresses, these restrictions lessen until eventually they reach the final boss, who is playing much more effectively, at least in theory.
​

Another way to see the AI at maximum power in this build is to view the game's attract mode, where we can see two AI-controlled ships going all-out at the maximum difficulty.

Over the course of a match, the more ships one player can quickly destroy, the more and more powerful the ships that appear on the opponent's screen will become.  This can quickly causes a back-and-forth escalation.

Destroying the gray ships causes red ships to counter-attack the opponent, and destroying red ships provides resources that will launch an attack unique to the player's ship on their opponent.  Players also accumulate a sort of Fighting-Game style super meter that they can spend to launch summoned attack ships, and eventually a boss on their opponent's field.

Meanwhile, behind the scenes, and invisible value is rising that increases the number of ships sent with each attack.  Whenever a boss is summoned, this value resets back to the minimum.  However, each time it resets, it increases more quickly the next time, to ensure that all matches eventually reach a climax.

There was also a dynamic music system.  Since I developed this before music was created for the game, I used the Soundtrack from The Wonderful 101 as a suitably epic placeholder.

The game starts off with low-tension music, but after one character has taken damage and a boss has appeared, high-tension music will be the default.

Each character also has two unique themes, one for their boss, which plays when it is summoned, and a desperation theme that plays when that character has only one hit left.  If both players are on their last hit, there is a unique theme for that.

In arcade mode, there is also a unique theme for when you battle your rival, and for the final boss.
​

From an engineering standpoint, the most challenging and fun part of this project was creating the AI opponents.  

Early on, I wound up coming back to my own website to read up on the reverse steering code from Master Plan in order to enable the AI to back away from bullets and other dangers.

Of course, in order to create a fun game, I also had to build an AI that could lose.  The AI was set up to have a level of stress, based on how long the match had been going and how many objects were on screen.  When under a lot of pressure, the AI would use escape mechanisms, like charged special attacks and their bomb.  However, as the stress rose, the AI also had a chance to not notice bullets when performing its' movement calculations.

The system isn't perfect, but it did provide a series of variables that could be used to, in general, make opponents harder or easier to defeat.

To debug this system, I wound up drawing a lot of lines in the Unity Editor to show what the AI was thinking about and why it was doing what it was doing.  

At one point in development, the AI began grinding against the wall of the gamefield, even when there were no discernible threats.  Eventually, thanks to all the debug information, I discovered that the AI was trying to chase down a ship in the other player's field.  This had arisen due to the game's extensive use of object pooling systems.

Thanks to the lines, this rarely occurring bug was much easier to fix.

The second prototype from my time at Phyken Media was planned as a lower scope research and development project.

I wanted to come up with an idea that was simple, but also something that didn't already exist.  I put out there that I couldn't think of any intersection between the run and gun and cute 'em up sub-genres, which led to the ideas that gave rise to the second prototype.

Eventually, the shooting action was dropped in favor of more of a focus on melee combat, which gave me the chance to try implementing a system I'd wanted to try out for a while.
​

I began working on scripting hit-boxes to play alongside animations on the first prototype.  It wasn't in the build I demonstrated, but at one point the mech from had a melee attack.

The sample ninja from the platformer toolkit is hard at work once again, this time without any robot parts.  His slide is used as the placeholder for all of the different melee attack animations.

Those animations and attacks are all part of a scripted combo system. The flow of moves into other moves and the positioning of all the hitboxes were all laid out in the Unity Editor.

From the earliest stage, I wanted to try to support a number of character-action style features, such as canceling attacks into dodges and jumps, as well as some form of dodge offset.  At this phase, dodge offset was automatic, but I did have plans to make it something players could manually activate.

Here we can see more of the combat in action, including the launcher.  We can also see that the physical impact on enemies is scripted on a per-move basis, with some moves flagged as knocking enemies down.  The floating enemy, who was part of the run-and-gun tutorial, is immune to knockdown.

The main feature on display here is also a hold-over from the run-and-gun version of the prototype, the level scripting.  Those two red bars on the side of the screen would be hidden during the actual release of the game, and they represent barriers of the player's screen.

A series of triggers based on entering trigger boxes and defeating enemies determines how far and in what directions the screen can scroll.  It can lock the player in to a combat arena, or limit how far they can backtrack.

I'm still not sure of the most efficient way to allow the player to drop down through platforms.  This version of the game maintains a list of drop-downable platforms and flags the player as not colliding with them when they give the command to drop.   Eventually, I hoped to script enemies to do this as well.  However, as the game moved on to something that played less like Rolling Thunder, this became less of a priority.

While I was looking forward to pursuing the elusive feel of a character action game, the team would eventually set our sights on another prototype which would prove even more entertaining.

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