May 12, 2009—
Avoid All Contact
The game I chose to work on for the 2008 uDevGames contest was one I’d had in my design notebook for awhile. I picked it because of its simple gameplay and simple graphics, making it something I felt was doable by the contest deadline.
The game idea involved maneuvering through levels of narrow, twisty passages, filled with static, animated and/or free-floating obstacles while trying to avoid contact with almost everything. Controlling your avatar would be accomplished by simply dragging it with the mouse, and gameplay would be at a methodical but hurried pace.
After coding up a simple level, I realized the gameplay I had initially envisioned was … well, … boring. There was too much stopping and starting and the pace was too slow. I did notice though, play was most enjoyable when zipping around corners or maneuvering amongst spinning obstacles. At this point I decide to change the gameplay a bit: The idea would still be to race though levels as fast as possible, but your avatar would move faster, and there would be the added challenge of collecting pick-ups along the way. Also, the surfaces you couldn’t touch, instead of being everywhere, would be placed such that getting at pick-ups and/or maneuvering through tight spots would be more challenging.
Making the game more arcade-like and less action-puzzler, worked well. The feed back during the development process was very positive, and other than having to reconcile some design decisions made when the game was to be played at a slower pace with the newer, faster pace, implementation went very smoothly.
Probably, the most challenging and time consuming parts of development where the creation of the game’s graphics and finding the music and sound effects. Though the graphics are very simple, I none the less had to redo them several times before I had things looking OK. Finding the music and sound effects involved going through hundreds of music loops, and listening to hundreds of different bleeps, bloops, clangs and clicks before finding just the right ones.
What Went Right
Making use of previously written code
Every time I begin to learn a new coding tool with the intention of writing games with it, very early on, I code up some basic stuff to make my life easier: Logging, Input Handling, Display Handling, In-Game console, etc. This helps me learn the new tool and also gives me something useful to work with. This time around the tool was Unity, and I had just about finished re-writing this foundation code when the contest rolled around. Having a basic set of functionality I was familiar with (the API actually started off in C/C++ years ago, then moved to ActionScript, then to Blitz3D, then to C#, then, as of this writing, to Boo) allowed me to hit the ground running.
Doing proof-of-process coding
Even though I decided to enter the contest shortly after it was announced, I did not officially enter until almost a month later, just days before the entry deadline. The time between deciding to enter and actually entering was spend doing proof-of-process coding.
After I had gone over the basic design, I selected features I was most concerned about implementation-wise. They were things like avatar control, collisions, animated obstacles, using a hex-grid/-tiles, etc. For each of these features, I coded up little demos to prove to myself I could do, technically, what the game design called for. It was not until I was confident I could code the game that I entered the contest.
This pre-coding worked out great because, since I had already solved most of the technically difficult/ambiguous problems before beginning to code in ernest, I was able to move much faster when coding the rest of the game and not worry about being stopped cold by a implementation hurdle I was not sure how to surmount.
Dividing game internals into managers
After entering the contest, I began thinking about the internal structure of the game. I had spec’d out how the game was going to look and behave from the outside, now I had to figure out how the game was going to look and behave from the inside.
I began to think about how the game’s internal logic was going to flow, from the time the game loaded up until the player exits. This process naturally began to suggest “managers” that needed to be responsible to certain things. Things such as Level Loading, Splash Screen Display, Score Keeping, etc. Over time these managers began to solidify and become more defined, and I was able to begin assigning specific tasks directly to them (instead of placing internal game tasks into a big list, unsure of where they’d get handled). An example of one such manager with some task assigned to it is below:
- Manages the display/animation of the Timer display during gameplay
- Handles end-level display of time stats
- Registers with
PlayerCraftMgrfor notification when start-/stop-timer area are entered
- Handles display of time gain/loss messages that appear above players craft
- Allows the adding/removing of time
- Keeps tally of total unused time
Task were purposely kept general, without a lot of details: just enough to give me a high-level view. I started off with about 19 managers, but wound up, through simplification and combining some overly specific managers, with nine in the final game.
Having the program neatly divided up kept the code very manageable and allowed me to move quickly when it came to task delegation.
Spec’ing out all resources needed
Simultaneously with working out the games internal structure, I began thinking about the resources that would be needed. Resources like Graphics, Music, Sound Effects and Visual Effects. I looked over the game design and thought about the gameplay and what the player would be seeing and hearing as they went through the game.
I came up with a list of about 14 graphics resources (eg. player avatar, wall tiles, game logo), about 4 pieces of music (eg. Title Screen/ Main Menu, End-Level, In-game), about 15 sound effects (eg. bad collision, button clicks, collect pick-ups) and 4 effects (eg. Avatar appearance, collect pick-up). The final totals where graphics 15, music 7, sound effects 6 and effects 0. I had initially envisioned the visual effects being particle based, but since I was wary of diving into Unity’s particle system, never having used any particle tool before, I scratched that idea and instead created all effects by manipulating the scale, tint and transparency of game objects.
With the a list of all resources in front of me, I was able to prioritize them from must-haves to nice-to-haves. This gave me peace of mind knowing at which points I could draw the line as far as resource creation went as opposed to getting stressed thinking I had to create them all no matter what.
What Went Wrong
Simplifying the design too much
This was the big thing that went wrong. I was so worried I might not have enough time to complete the game, I trimmed away too much of the original design and wound up making the game less fun in the process.
The general consensus of the feedback I received during voting, from both my peers and the public, was the game was too short, and there were a lot of features they would like to have seen: high scorers list, power-ups, more graphic variety, different modes of play, etc. They liked what was there, enough for me to finish 4th over all and 3rd in gameplay, but they were “left wanting more.” The irksome thing for me is that almost feature suggested, plus more, was in the original design, but I trimmed it all away!
Just like I prioritized my resource list, I should have prioritized the feature set. I should have looked over the game design and said, “These features are very important, these somewhat important, these not so important, and these I’ll cut.” Instead I basically said, “These features are very important, all others get cut.”
Three to four weeks after I started coding the actual game, and 3-4 weeks before the deadline, my game was already feature complete! I had really nothing left to do but find/intergrate the music and sound-effects, design levels and tweak things. This is probably why I placed 2nd in audio and 3rd in presentation: I had over three weeks to devote almost exclusively to just those two things.
I attribute my gross over estimation of how much time I would need, somewhat to all the prep and design work I did before actually beginning to code the game (not realizing how much it would speed things up), but mostly to my unfamiliarity with my main tool, Unity. As I worked on the game I was often pleasantly surprised at how quickly I could get things accomplished. Functionality I needed was either already built in, or could be devised with a few lines of code. Even now as I look back over my source code, I’m surprised at how little I actually had to write, and this is including the code I wrote strictly to allow me to build the levels.
I’m very pleased with how everything turned out and with the overall experience of competing in the contest. Also, the feed back on the game has been very positive overall, including some great suggestions for improving the game.
Looking forward, I plan to go back to the design phase, re-evaluate my original game design, take into account the feedback I received, and re-design/flesh-out the current game. This means more levels, difficulty tiers, more graphic variety, more play modes, orbs of different levels of maneuverability, etc.
Also, a number of people mentioned how they thought the game would work well on the iPhone/iPod Touch, and in all honesty, that was another of the reasons I choose to work on this design. So, who knows: you may see a version of Manuev’It! appearing on an iPhone before too long!
- Developer: David Guy
- Title: Manuev’It!
- Genre: Arcade
- Team Size: 1
- Development Time: 3 months
- Hardware: 2 GHz Intel Core 2 Duo iMac w/ 4 GB SDRAM; running Mac OS X version 10.5.6
- Critical Software: Unity Indie, GIMP, Pixen, Audacity, Cheetah3D
- Lines of Code: Approx. 3900 (~2600 Specific to entry; ~1300 Reused)