The Making of Traversal Part 2
Published 5 years ago
Breathing Life into the Game
When we last left off, I talked about the creation of the “Back and Forth” prototype.  Now for part 2.
During the prototyping process, I was able to get the player components working, the goalposts, and some of the enemy entities alive and playing.  Once the holidays rolled around, I stopped working on it and the prototype fell to the wayside for six months while I spent a lot of time working on Recovery Quest.  In June I picked it up again and put a little more work into it.  I fleshed out the transition mechanic of changing everything when the player reached the goal and it actually looked pretty cool and felt really good.  That was the point where I decided to run with it.  Before the month was over, the prototype had evolved into a full-blown game.  Sound effects, music, balancing, particle effects, and color schemes all went up in a matter of a couple weeks.
Originally, I intended to do the game with 2D graphics, but I ran into a bit of an issue...I can’t draw to save my life.  Instead I came up with a plan to use 3D graphics with 2D logic (aka 2.5D).  Another problem though...I don’t know how to do modeling.  Luckily the game is meant to be pretty abstract and I am able to do enough composite modeling in Unity to make things look interesting.  On top of that the new shader system in Unity 5 should help make things look really cool.  I decided to go with a motif of abstract shapes for the various game entities with reflective shaders and effective use of particle effects to make things look really neat.  What I ended up doing is grabbing something from the asset store called Advanced Primitives (which, sadly, is no longer on the asset store for some reason), a pack of some fairly interesting shapes that I could use.  The results looked better than I could have hoped.  For the player model, I started with a sphere and encased it with an off-axis edge cube with a simple rotator script on it.  The shader I made for the model was just a shiny pinball-like chrome.  I added a trail effect to the hitbox and the result was this vibrant-feeling almost character that is easy to spot.The enemies were very similar.  Each enemy consisted of two cubes, both on off-axes, with two parent rotator scripts to make it look like they’re almost crawling.  They looked spiky and alive.
I also had a bit of fun with the death effects which came out WAY better looking than I could have anticipated.  Rather than having the objects explode into billboarded 2D particles, I had the idea of making them look like they had cracked and were falling apart.  I used a couple different meshes instead of particle textures with the same shader used by the entity, to give the effect of it breaking into shards.  The shaders didn’t allow me to do a fade so I opted to have the mesh particles shrink to scale 0.  The result: the object looks like it falls apart and the shards shrink to nothing.
When it came time to shore up the design and balance for the entities and their transitions, I ran into some issues that I had to overcome.  The way I designed the transition system was that there would be three different “paradigms” that dictated how the game entities changed, with two rare paradigms to make things interesting.  The player would also shift independently of the rest of the game’s system to allow for even more situational variety.  Originally I only made two different weapons for the player, a gun that shot small damage bullets, and a “slash” weapon that was a more powerful close-range attack.  I found that I needed a third weapon.  After a lot of soul-searching and thinking to other top-down shooter games, I came up with the orbiter weapon and implemented that.
It also took me a lot of playtesting to really dial in how I wanted the transitions to work out as the game played.  I took kind of the shotgun approach with this since I didn’t want to have to do lots of weird graph theory calculations.  At first, things were too sparse, then things weren’t interesting enough, then the game was too unfair and had no strategy.  I also had to add a mechanic where the game will give a small burst of small cubes which act as a kind of baseline for the next transition if there are too few entities on the field.  There was also the issue of no sense of urgency.  I didn’t want the player to take their sweet time to touch the goalpost, I wanted them to have to have to decide between going for it and hanging back and clearing the place out.  What else is there to do but add a timer?  Rather than have a flat time, I wanted it to be a fluctuating time limit based on how the player progresses.  So what I did was have the health pickups add time instead of health if the player is at full health.  This also elevated the importance of not getting hit so that you can more effectively add time, increasing the overall difficulty of the game in an interesting way.
Part 3 coming soon with reception and future plans.
Blake DeBerto
Game Developer - Programmer