Early in the jam I had a bunch of different ideas. This is pretty normal. I liked the theme, so much so that it almost gave me too many options for achievable small games I would have enjoyed making. In the end I went for my ‘fallback idea’ – something I’d wanted to try if I could tweak it to fit the theme: a Descent-like game with visuals similar to Zombie Gunship.
What I wanted to achieve was:
1) Set up 6DOF ship controls that felt good. Not necessarily identical to the original Descent, but along those lines.
2) Recreate visuals similar to Zombie Gunship (essentially inverted greyscale, with object highlighting)
3) Incorporate this into a small prototype game, as a sandbox for something bigger.
All image effects applied
I’m happy since I feel like I largely met goals (1) and (2), with some detours, while the gameplay component of (3) isn’t nearly refined enough.
For (1), I created a ship controller based on applying appropriate impulse forces each frame to a Unity rigidbody. Compared with a kinematic (non-Newtonian) object where you just move the position of the transform directly, using forces had the advantage of having proper rebound physics for collisions with terrain, obstacles and enemies. The key parameter to tweak here was “Drag” and “Angular Drag” on the rigidbodies, so that when you stop pressing a direction the ship glides to a halt as if it’s in a viscous liquid or dense atmosphere. I think I managed to get the feel of the controls working reasonably here, but they aren’t yet perfect. Also, as noted by a one commenter, colliding and rebounding with the rings can be annoying. Ignoring these collision will be something to experiment with in play testing to see if it reduces unnecessary frustration without spoiling the challenge.
For (2), I started with standard Unity Pro Image Effects. I quickly discovered there was no “invert colours” effect in the standard set. While this should be one of the simplest effects to make, I’m no shader jockey, so rather than going down the rabbit hole of creating this shader, I decided I’ve have to just go for visuals that were similar but not the same using what I had on hand. After a whole lot of playing around, I found a combination of Screen Space Ambient Obscurance (similar to SSA Occulsion) interacting with grey fog, plus Contrast Enhance and some noise gave an interesting grainy greyscale effect. This appears to be exploiting some artefacts many games would try to avoid – for instance, the Ambient Obscurance modifies the fog so that distant objects can all be seen, but still become coloured by the fog. By adding a local point light to the ship, and some nice splashes of colour to the terrain, the result was a grey noisy world with local “rainbows” on the terrain. I also added some Sun Shafts to enhance the ‘dusty’ feel of the environment.
Example of SSAO+fog interaction: Fog turned off
Example of SSAO+fog interaction: SSAO turned off
During initial play testing trying to shoot stuff and navigate rings, it became apparent that the objects of interest were not visible enough in the grey grainy world. I needed a way to highlight them. I made a second camera higher in the stack and added the rings and enemies to a Unity layer that only that camera could see. The ‘Right Way(tm)’ to do this is probably using a “replacement shader” on the camera, but instead I made a cyan-tinted transparent RenderTexture showing the output of the second camera rendered to a billboard and positioned it in front of the main camera. Even though this second camera was set to Depth Only, the alpha transparency channel didn’t work as I expected, so the main camera beneath it couldn’t initially be seen. I fixed this by calling GL.Clear(true, true, Color.clear) in OnPreRender() – not really sure why setting the initial buffer to transparent pixels was required, but it worked. This camera setup has the cool side effect of enemies and rings being visible through the terrain (which is invisible to this second camera). Since the texture and it’s billboard are square, it doesn’t cover the whole screen – this isn’t actually what I wanted, but it has the interesting effect of keeping enemies and rings greyscale when they are in peripheral vision. It looks better with a vignette filter applied to it, but I didn’t remember to add that until after the compo.
Here’s what it looks like without the second overlay camera highlighting rings and enemies … compared to the original above that Mech enemy just right of the nearest ring is almost impossible to spot
Goal (3) is really gameplay, and I’ll be first to admit it’s a little uninspired and a bit “meh”. My initial goal was really to just a “shoot stuff” game, but having done various styles of space shooter before, I knew there was a lot of work required both on the AI, wave design and scoring side of this to make it interesting. After spending time on (1) and (2), and making terrain, textures and enemy models, I felt like I didn’t have time to make the original gameplay goal fun or engaging. Ideas of a 3 stage, race, then shoot, then race+shoot structure were quickly discarded as too large in scope. I instead decided that a quick 3 lap time trial where people could compare scores would be a better ‘minimum viable product’ for a 48 hour game. I left the enemies in as an extra challenge and for some flavour, tuning the behaviour a little to try and suit the new gameplay, however as others have noted, it seems a little confused as to whether it wants to be a racing game or a shooting game. Actually, I think there are examples where both can work in some form (Wipeout, Death Race, the run for the exit in Descent, or even Mario Kart) but the enemy AI isn’t good enough in “Deep Dome” to make it work.
Instead of going down the rabbit hole of improving the enemy AI, I chose to stay up late putting together a simple background track in Caustic. I hadn’t used this software much, especially version 2, but it’s fairly intuitive if you’ve used and tracker & soft synth before so I was able to come up with a very simple techno track with a bit of an EBM / cyberpunk feel. Not amazing music, but I think it works to set the tone. As a result for spending time on music, the enemy AI remained quite brain dead (face and follow), but it was enough to cause the player a nuisance (sometimes too much of a nuisance) while navigating the track. I also spent far too much time trying to make random procedural terrain with Terrain Composer – powerful software with a horrible UI that I can never remember how to use properly.
This is the first time I’ve ever made and animated skinned mesh character. Common sense says I shouldn’t have even tried this during a 48 hour game jam if I’d never successfully done it before, but after many years of tutorials and attempting to use Blender, something just clicked. I suppose this is a result of perseverance, along with improvements to the Blender UI and documentation. The “Mech” walking animation is really bad, and uses the old legacy Unity animation system rather that Mechanim, but it’s still a significant personal milestone.
I need to put more time into learning how the nuts’n’bolts of how Unity image effects, and shaders in general, work. It’s a testament to Unity’s success in “democratising game development” that someone like myself who is not a hardcore graphics programmer can throw something like this together in 48 hours – however you can always do more by learning more, and I need to learn more. Maybe some naivety is an advantage, since you try crazy things, but I can’t imagine what I would have been able to come up with if I’d understood more of the details.
I’ve done a bunch of game jams now, some have worked out okay and some didn’t. I think next game jam I need to have a timer every 3 or 6 hours, where I must stop and prioritise what is important for the “minimum viable product” game. Throw out what’s not essential for gameplay and work on the most critical task or feature first. I generally try to do this anyway, but a more structured method would prevent me losing track of time while engrossed in implementing features that aren’t actually very important (e.g. terrain details). For this game, I did maintain a list of features and assets, but failed to effectively triage them. Also, the ‘improve gameplay’ task wasn’t given enough priority, partially since it’s a difficult thing to break down into micro-tasks – I’ll have to investigate techniques for doing this and work on it.
General responses to comments on the entry:
First – thanks for checking out my game and commenting ! On the whole we agree about the gameplay deficiencies – shooting or racing but not both would probably have worked best.
Yes, the system requirements are a little high, and it’s probably not very efficient. I recently upgraded my graphics card after many years with a Geforce7, so I didn’t notice how poorly it ran on “lower spec” machines until some more testing after submissions closed. It will run at acceptable frame rates on OUYA at 640×360 though !
Sorry if the controls seemed a bit much (I’m looking at you orangepascal 
). I tried to keep the controls as FPS-like as possible, since this is what many people are used to. Of course, if you don’t play those types of games, the controls could be a little unfamiliar and overwhelming. The barrel roll was just for fun and could be ignored. I also left out strafe up/down for simplicity, but in a bigger game the option would be there to use it.
Maybe this will be the foundation of a bigger better game in the future, but for now I’ve got several other projects that have to be pushed out the door first.
Tags: postmortem, unity
What was interesting is that the original whirlpool had a clean, clear cut, unpixelated design. What we found though, is that all that detail in motion made it incredibly hard to focus on the other details like where the player, coins, and enemies were located. Instead we pixelated it, and stacked a partially transparent copy out of phase (at a slightly lower frame rate). This allows us to get a background animation that doesn’t repeat for much longer without the hit to download size.
The red X was supposed to let you know you’d be sacrificing a chest, but instead indicated to players that they were not allowed to click it.
