I've been making some progress on my personal practice project.  It's not moving at rapid prototype or Game Jam speeds, but it's been an interesting exercise in exploring some old and new coding ideas. 

I also opened up Blender and made this inverted cylinder so we can see our little big robot in his natural habitat of the cylindrical space colony.  The textures are very much programmer art, but it does rotate to create the illusion of running down this endless series of tiled roads.

Most of my work on this has been less visually interesting, as it's been setting up a lot of code infrastructure.  Going from being the sole dedicated client engineer in the Phyken days to working on bigger projects was a valuable learning experience that helped me grow my skillset.  However, after spending 6 years on one project, I did kind of get used to things like Event Systems and UI Managers just pre-existing whenever there was a new feature to implement.

Once there's more interesting action in motion, I'll see about getting my video capture capabilities back up and running so I can share that.

Here's quick little post to say that I've started up another personal side project during this round of the job search.

As you may be able to see, I've taken a sprite of my old programmer art protagonist and reworked it into this legally distinct anime robot.  Pardon the artifacting, I wanted to get an animated gift up in a hurry.  That's actually the purpose of this guy, just to get a really basic animation on-screen so I can start diving in on the architecture side of things.

I took about two steps into the project before I realized that I did not still have access to the Event system we used at SciPlay, so I made an attempt to engineer a similar one.  Other things I'm just kind of doing for practice.  Does the game state system need to involve a Factory?  Probably not, but I think the last time I used a Factory was at 360Ed, so I should give that a go.

This might just be a self-improvement exercise between interviews, but if the little Primary Color Space Samurai gets up to any adventures, I'll be sure to share.

Dungeons were a similar mix of primary colors and basic circular iconography.  The MapTool provided assistance with lighting and vision while I moved around big circular icons representing characters and points of interest.

Here is one of the more elaborate dungeons, in which an underwater shrine has been torn at by spatial anomalies that have caused it to intersect with other environments.

However, I wanted to experiment with something a bit more visually clear and fun.  I didn't have a big box of figure tokens or even a collection of fantasy artwork, but I did have a fairly extensive knowledge of retro video games, which lead to an idea.

Near the climax of 'season one' of the campaign, the party invaded the fortress of the primary antagonists.  One of the villains had created an intelligent magical artifact that had unexpectedly gained self-awareness during a prior story arc.  They then sought to re-create this project in order to create a sort of magic-based AI to control systems within their fortress.

When the party stepped onto what appeared to be some kind of Teleporter pad to travel to the next floor of the ship, they instead found themselves pulled into the D&D equivalent of a Tron-like scenario, in which they were transported it the Magic AI's realm of information.

I used this as an excuse to re-create a simplified caricature of the campaign thus far using retro video game graphics to represent the world as seen via this information-based magical creature.

Taking assets from Dragon Quest, Final Fantasy, and many others, I assembled this map, which was a big hit with the players.  It was both visually interesting, and it was a fun way to look back on where we had been as this story neared its' conclusion.

Oh yes, the higher fidelity room there was hidden from the players.  There were a number of secret back door terminals they had to find in order to escape.  They were all hidden in very classic sorts of retro-game ways, so everyone was quick to play along and find them all.

I liked the clarity afforded by the visual style so much, I wanted to keep using it outside of this magical information world, but I needed a way to show that our heroes had returned to reality.

I decided to borrow some 16-bit assets from Final Fantasy IV to create the remainder of the final dungeon, in part because FF4 contains both assets for a fantasy castle and a giant ominous computer core that can be easily assembled.

When it came time for our next adventure, the retro style returned in full force, resulting in amusing things like a school of teleportation magic with Mega Man boss doors outside it's lab.  Eagle-eyed viewers may also be able to spot some NPCs who are clearly Touhou Project characters.

Since the NPC tokens were basic 16x16 sprites, I would often modify and customize the retro assets to give characters more unique tokens.  While I'd never claim the title of pixel artist, dabbling in these basic edits and learning the actual palette limitations of the NES would inspire me to create placeholders for all the projectiles and explosions in the final Phyken Media prototype game.

Years later, I would try an even more elaborate visual style in an adventure that was even more strongly influenced by video games, but I'll save that tale for another time.

A sequel to Wizard Ops Tactics was planned that sought to streamline the gameplay and the team-building process.  The base game used a point-buy system where each unit and weapon had a cost for bringing it in to battle and if I recall correctly, battles could take place at various tiers of power which would limit the scope of each player's forces.

The sequel had army templates that players could unlock that would let them slot in forces and items of various strength in order to compose their squad.  The sequel also removed the fog of war mechanics, but it kept the capability of some units to sneak around unseen.  Overall, I believe it was set up to be more intuitive while keeping much of what made the game fun.

Oh yes, in addition to being the first online multiplayer title I worked on, this was also my first truly free-to-play mobile title, as it featured in-game purchases to unlock booster packs of units and the like.  While I contributed a great deal to the design of both Wizard Ops titles, I was not so adept at  interweaving the game with the business side of things.  Thankfully, I had a team to help wear the hats that fit poorly on my head.

So when last we spoke, I was reminiscing about adding spread-shots to the early Wizard Ops Chapter 1 prototype.  It actually took a few iterations and some playtesting before we arrived a the final system of arcane armaments, but ultimately players could bring in two weapons swappable with a button press, and there were a variety of weapons that could be obtained either from a store or as drops from enemies.

This included various fireball-throwing wands and homing magic missiles, as well as more conventional weapons like a rifle and a blunderbuss-shaped shotgun, which were a rare drop from the ordinary enemy soldiers.

All enemy shots manifested as blue orbs, but when the firearms were in the player's hands, they were actually a hitscan weapon.  However, I drew a tracer projectile on-screen to help give it more visual flare.  If I recall, the tracer is actually the fireball sprite stretched extremely thin.

I had forgotten until writing this that the guns ejected shell casings with little stars on them.  That's probably terribly anachronistic, but it is a Wizard doing it, so it's probably best not to think too hard about it.

On the other hand, particle effects were definitely something I had to think on throughout the project.  It actually began with many more traditionally animated sprites, but after much experimentation and a trip to a Unity conference, I found that particle systems had better performance even on lower-end mobile devices.

Thus, I took a lot of the existing art assets and attempted to repurpose them into suitably dramatic displays of particles.  I still probably went overboard in a few places, but it was certainly fun.

While the world has yet to see the continuing adventures in Wizard Ops Chapter 2, that doesn't mean there wasn't plenty of post-launch support for Chapter 1.

In addition to developing tools for designing levels, I took a crack at designing quite a few additional challenge stages and other additional levels.

I also began to try to break the rules of the game's early stages, adding levels that scrolled in new directions and repurposing enemies in new roles. 

As the art team at Phyken Media grew, we saw a wide variety of visual  improvements as well.  Enemies that were once programmer palette-swaps gained distinct appearances and the levels themselves gained fidelity and character.

New levels also offered opportunities for players to gain new weapons, which meant engineering new behaviors for them.  In 1.3, we saw the addition of the Flamethrower Wand and the 'Dirigibomb', a blimp-shaped missile that exploded into a lingering cloud of flame.

These required damage-over time status effects that could be placed either on enemies or on the field.  Stacking these together was a potent combination.

However, the peak of additional Wizard Content was yet to come . . .

The desert stage broke all the rules.  It was the first stage to feature a transition from ground combat to aerial combat and then back down again.  It also featured a sloped section as the player transitioned from one vertical plane to another.

It was also intended to have a much more fast-paced dramatic tone to it.  It felt like it was laying the groundwork for a more dynamic adventure with bigger set-pieces.

This stage also had a new kind of boss enemy, representing the Wizards' nemesis in a giant mechanical worm.  One of the early ideas that drove our imaginations about Wizard Ops was the idea of doing a military commando story where the tanks and helicopters were based on Da Vinci's renaissance-era designs. 

This naturally lead to the idea of an antagonistic force that was attacking a medieval kingdom using whimsical renaissance-inspired military hardware.  In particular, I like the Da Vinci screw being applied to the airboats that drift across oceans and swaps as they fire on the player.

Next time, we'll take a look at the Wizards' next adventure, as they take a more strategic approach to explosive mayhem . . . 

However, actually using something of this scope as a VR Chat world was kind of a performance nightmare.  This sent me down a rabbit hole of learning about how Unity handles baked lighting and occlusion culling.  Sadly, as I am not much of a 3D artist myself, I was ill-equipped to fix overlapping UVs when the baked lighting began to cover certain walls in bizarre artifacts, but I had a fair amount of luck with culling.

The bowels of the starship were filled with editor-only gray cubes that ensured that as few rooms as possible were visible from any given point on the vessel.  As a result, the ship became playable enough for us to hang out within over the holidays.

However, the culling wasn't sufficient for taking trips outside of the ship.  For that, I had to implement a more crude form of virtual airlock.  While in the hangar, you can press a switch that disables all the local objects in the middle of the ship before opening the bay doors.  It's not perfect, but it let me ride a little hoverbike around the body of the ship, so I'm counting that in the win column for now.

Here's a look back at what was intended as the first chapter in a grand tale of martial magecraft.  We can see the levels from fairly early in development and their progress towards the final release.

When I'm able, I always like to get the gameplay on-screen and working with whatever is on hand so that we can begin iterating on the look and feel to make it as fun and engaging as possible.

However, even these early glimpses are not the first iteration of this title.

Wizard Ops was born from a number of FIEA Alumni engaging in an idea-mapping exercise, which determined that there were a number of quirky connections between the idea of being a Wizard and being an armed Commando.

Mainly, the idea that both were ostensibly practitioners of well-guarded secret techniques, but also both were most likely to be portrayed in fiction as a lone man standing in the midst of a series of massive explosions.

This lead to the development of a prototype that I will call "Chapter Zero" in which the user controlled all four wizards in a side-scrolling mission.

The gameplay was a mix of turn-based and real-time action.  It handled sort of like the Worms series mixed with the ever-popular Angry Birds, in which you would activate a character and have a limited degree of movement on a side-scrolling stage, at the end of which you would use one of your spells, causing all sorts of physics-driven mayhem.

The idea was that the Wizards would be charged with all sorts of fantasy-flavored tactical operations, like rescuing npcs or toppling castles, and the player would have to get creative with burning, freezing, and smashing the  environment in order to accomplish them.

However, I struggled with optimizing the physics, and level designs proved difficult for the team to consistently envision.  We needed an idea where we could prove the core gameplay was fun before venturing any further on this quest . . .

For my part in this mechanical exploration, I turned to a wide variety of classic arcade games looking for ideas.

With the idea of whimsical special operations already on my mind, I looked back to one of the more obscure Konami four-man licensed arcade titles, one that tapped into some of my oldest childhood memories of imaginary military operations . . .

I had seen more traditional vertical and horizontal-scrolling shooters translated to the mobile platforms with ease with games like the Unity-driven Air Attack and a variety of ports of classic Cave shooters.  However, I had yet to see a title take advantage of the 3D engine for this sort of behind-the-back shoot-em-up approach.

However, it still could be controlled simply by touching and moving in four directions, so as long as the player had enough screen space to see around their finger, it could work.

Since it's a simple matter to give a Wizard the ability to fly, it would be possible for some stages to follow the Konami G.I. Joe pattern of having a character move left and right and move a reticle vertically, while other stages could allow for more freedom of movement, similar to a title like Space Harrier.

Days later I had our Wizard  marching forward and firing placeholder bullets, and it didn't take long to see that there was a fun core idea there.

However, when I looked back to another Konami commando for inspiration, and tried putting in a Contra-style 5-way spread gun, I quickly discovered that optimizing for low-end mobile devices would be its' own arduous quest . . . 

 . . . but then I learned about object pooling, so thankfully the 3 and 5-way fireball spread wands did make it into the final game.  

I've been spending time with this long-running board game mascot, and, more importantly, a fantastic team at SciPlay in Austin.

I had a lot of fun working on the city-building meta-layer surrounding these games of chance and an assortment of other features.  I'm not sure if I'll be able to serve up anything for the Code Snippet section in the near future, but I will say that spending 6+ years working on a live game with a big team definitely helped me expand my horizons.

I'll be spending some time in the near future cleaning up a vast assortment of broken links and updating both sizes of resume, but I'm also hoping to share any personal projects that get going to keep the coding skills sharp as I awkwardly mix a metaphor of passing GO and advancing to the next round of life.

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.

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.