[Lost content: Unity Webplayer of the actual finished game.]
[Lost content: Countdown timer]
(None of the links presented in the video or in the video’s description work. –Ed.)
1. Used Prefabs
For the first six months that I’ve been in business as a solo independent game developer, I’ve tried to do everything by hand-coding the scripts in Unity. While this has taught me a ton about how C# works, it was a painfully slow process that under-utilized the strengths of the Unity game engine.
Unity can handle a lot of the heavy lifting of creating and managing game objects by using the in-build editor. It’s possible to create crude models, texture them, apply all sorts of components to them like lights, physics properties, controllers, and audio handlers, as well as animate, call, and destroy.
For this Ludum Dare I took the self-imposed chains off and went to town with the editor, and I think the results speak for themselves. I was able to get the game up and running within the first hour. There were a few hiccups, but I was learning an entirely new way of development.
2. Leveraged C# Knowledge
I’m not suggesting that this is the best way to go about learning Unity, but for me, spending that first half of the year immersed in making things run from raw code (plus the six months previous at VFS doing much the same) really came in handy when I finally dove into using the editor. If I needed a script I could write one up double-quick, drop it on my prefabs, and make the magic happen.
It really felt like all that self-flagellation finally paid off.
3. Constrained the Beast!
Once the theme was announced, I immediately drew up a task list that was controlled by several strict limitation on what I wanted to accomplish:
The last item wasn’t really a constraint, so much as a wish. I’ve wanted to get to the state where my mastery over the tools was great enough that I could produce player interaction AND have some kind of mood and character conveyed. I set that as the ‘reach goal’ and believed I could make it happen by keeping the game small with the initial constraints.
1. Uneven Production Distribution
I’m still suffering a bit from linear production drive. I’ll go from the design to the gameplay, then start adding in rough assets with the intent to polish them in ‘art production rounds’ once the game works.
With the use of the prefabs I was able to start compressing and redistributing this a bit more. I need to get over my fear that I’m wasting time by building out a specific asset. I feel like a better approach would be, for example: Alright, I need a terminal the player can interact with. Create a basic model, quickly unwrap and texture it, light it, and apply any audio to it. Then that object is done, reusable, and I won’t wonder if I’ve built everything I need to in that particular object.
I spent a fair amount of time running in circles on the second day wondering if I had enough sound cues and textures done across all the assets. I think in the future I’ll simply make firmer decisions to create a decent asset straightaway, and I believe this will help with overall motivation as the mind will be constantly switching gears to keep up.
That’s it? Really? Only one thing went wrong? I suppose I could cite an overall lack of testing, but with Unity I’m constantly testing under a zero-time iteration cycle. Oh I guess there was one more thing…
2. Use of Unity’s Character Controller
One thing I could have kept from my ‘old’ ways of development was rolling my own physics controller for the player character. For this Ludum Dare I simply dropped the standard controller on a box and got the game running. It wasn’t until the second day when I realized I needed more complex physical interactions that it became apparent a custom controller would be far superior. I plan to rectify this for Episode One, if that gets built.
00:00 Theme announced! It’s Dangerous to Go Alone! Take This! Initial planning begins. I’m a lot more nervous this time around…
00:15 Basic concept hammered out; mechanics, controls, camera pencilled up. Time to build a prototype.
00:47 I have a basic scene with modeled environment, avatar, and character movement.
01:45 Level transitions in place and functioning.
02:36 Basic character animation pipeline in place and functioning.
08:43 Well-rested and raring to go!
09:36 First weapon model done.
13:00 Some interactions done, the beginnings of the first interactive cinematic. Most basic level prefabs done.
13:54 Doors are working.
15:40 Some cinematic/narrative stuff going on now.
16:52 Key cinematic done! Time for lunch and a kip.
20:00 Physics puzzle stuff done. Power overwhelming!
20:51 Nearly at the point of implementing enemies. Once those are in, the rest is iteration on level design until the climax.
1:00:11 Day one is out, and time again to complete. Plenty. Level transitions working perfectly, cinematically. GUI popups functional. All that remains is a handful of enemies and level progression. Oh, and audio…
1:03:07 I should probably sleep, but didn’t want to rest until I had some basic enemies in place. Presenting the SawBot 2000, a flying wheel of death and terror!
1:09:31 Rising on the final hours. Here we go!
1:16:47 7 hours since the last update? Really? A lot of fine-tuning and polishing has been done. Front menu now works, there’s a short (skippable) title sequence, and the game loop is nearly closed. Also got a quick crash-refresher in UV mapping and how Unity deals with audio. Quite an elegant system. Short lunch break then it’s the home stretch!
1:19:16 Game loop is closed. Game runs through the levels and reaches a conclusion. I’ve made another game in 48 hours, and this one is infinitely superior to the first one. And I’ve got 4 hours left to polish. Nice!
2:00:00 Competition is closed, but the game is done and reasonably polished. Uploading now.
2011.04.29 – 2011.05.02