\n 1) Set up 6DOF ship controls that felt good. Not necessarily identical to the original Descent, but along those lines.
\n 2) Recreate visuals similar to Zombie Gunship (essentially inverted greyscale, with object highlighting)
\n 3) Incorporate this into a small prototype game, as a sandbox for something bigger.<\/p>\n
![\"original\"](\"http:\/\/www.ludumdare.com\/compo\/wp-content\/uploads\/2014\/05\/original.png\")
<\/a>All image effects\u00a0applied<\/p><\/div>\n
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.<\/p>\n
<\/span><\/p>\n 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 \u201cDrag\u201d and \u201cAngular Drag\u201d on the rigidbodies, so that when you stop pressing a direction the ship glides to a halt as if it\u2019s 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.<\/p>\n 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\u2019m no shader jockey, so rather than going down the rabbit hole of creating this shader, I decided I\u2019ve 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 \u201crainbows\u201d on the terrain. I also added some Sun Shafts to enhance the \u2018dusty\u2019 feel of the environment.<\/p>\n Example of SSAO+fog interaction: Fog turned off<\/p><\/div>\n Example of SSAO+fog interaction: SSAO turned off<\/p><\/div>\n 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 \u2018Right Way(tm)\u2019 to do this is probably using a \u201creplacement shader\u201d 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 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<\/p><\/div>\n Goal (3) is really gameplay, and I\u2019ll be first to admit it\u2019s a little uninspired and a bit \u201cmeh\u201d. My initial goal was really to just a \u201cshoot stuff\u201d 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\u2019t 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 \u2018minimum viable product\u2019 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\u2019t good enough in “Deep Dome” to make it work.<\/p>\n 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<\/a>. I hadn\u2019t used this software much, especially version 2, but it\u2019s fairly intuitive if you\u2019ve 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\u00a0music, 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.<\/p>\n This is the first time I\u2019ve ever made and animated skinned mesh character. Common sense says I shouldn\u2019t 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\u2019s still a significant personal milestone.<\/p>\n I need to put more time into learning how the nuts\u2019n\u2019bolts of how Unity image effects, and shaders in general, work. It\u2019s a testament to Unity\u2019s 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\u2019t imagine what I would have been able to come up with if I\u2019d understood more of the details.<\/p>\n 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.<\/p>\n General responses to comments on the entry:<\/em><\/strong><\/p>\n 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.<\/p>\n 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 !<\/p>\n Sorry if the controls seemed a bit much (I’m looking at you orangepascal<\/a> Maybe this will be the foundation of a bigger better game in the future, but for now I’ve got several other projects<\/a> that have to be pushed out the door first.<\/p>\n \n Tags: postmortem<\/a>, unity<\/a><\/p>","time":"May 19th, 2014 4:38 am","title":"Deep Dome postmortem"}<\/a><\/a>GL.Clear(true, true, Color.clear)<\/code> in OnPreRender()<\/code> – 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\u2019s billboard are square, it doesn\u2019t cover the whole screen – this isn\u2019t 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\u2019t remember to add that until after the compo.<\/p>\n <\/a> ). 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.<\/p>\n