The final assignment for my Certificate II in Information Technology (Game Programming) is to create a complete game from the ground up.
We are given a certain amount of guidance from our tutors, but ultimately the complete project including the initial concept, coding, sounds, and art work are to be our own.
There are times when I love being in my thirties. It is where sky-high ideas get hit by the pragmatic bat of “prior experience.” The early-twenties version of myself would get wrapped up in the ultimate badass game in a fantastic world, and draw detailed maps, work the out local culture, and spent hours honing names.
This time I considered the resources first:
o We have nine weeks.
o I usually only have time to code during class: three to four hours twice a week.
o I have completed two games assignments already, so have a wealth of code to steal from.
o I am working with two other students, who already also have two previous game assignments, including some kickass features that I didn’t implement.
I love a whiteboard. I have two traits that are useful with a whiteboard: I’m a visual person, and I tend to think aloud. And when I brainstorm, everything goes on the board. Every little comment that someone makes, especially those “here’s an idea…no I don’t like that idea” ideas. This fetish for whiteboards developed early in my working life. I hated meeting where ideas would be quickly shot down before they were entirely out of someone’s mouth.
So when myself and the two other students (collectively referred to herein as “Team Funky”) stood in front of the whiteboard, were churned through what we were all thinking very efficiently. One member wanted to try a real-time strategy game (RTS), which made me feel a touch of vertigo considering the interface, algorithms for movement, AI, possible networking, and so forth. Basically, it was orders of magnitude more complex than what we had achieved so far.
Nevertheless, we liked the idea of something with a top-down view, rather than fiddling with the physics of side-scrolling platformer (and the very clunky engine provided to us for our second project.) Also suggested was the sort of gameplay in one-character missions in RTS games like Starcraft and Warcraft.
Suddenly we became tangled in the mire of talking about classes of weapons, breeds of monsters, and flavours of treasure.
Ultimately, our tutor directed our discussions by posing the question:
What is the core mechanic that make the game fun?
This refocussed us, and we came up with the following game elements:
o The player has a top-down view of the world.
o The player controls a character through a maze/labyrinth/dungeon.
o The player searches for treasure and the exit. (Solving the maze.)
o The player encounters traps and monsters they will have to fight or avoid.
Story in a game, our tutor warned, was like plot in a porno. With certain exceptions, no one cares about it. At any rate, at this point we needed some theme or plot of some sort to hang our design off. We universally rejected any kind of fantasy or mythology theme (the Minotaur or elves or dungeons). On the board went Science Fiction, Final Fantasy and Steampunk. And bunch more words followed – catacombs, labyrinth, sewer. Somewhere in the mess of talking and words fell the following:
Turgid Sewer Rat.
Sometimes, a name just fits.
Imagine a large fellow, decked out in Steampunk leather, goggles, and hand-cranked weaponry.
Our summary of the game play for our slowly-growing game design document went like this:
The city-state of Tien Kwan is a thriving metropolis. Deep beneath run the city’s bowels: the winding network of sewers.
Whenever a citizen drops something down their toilet – spectacles, jewellery, continental pornographic lithograph – they call on the one man who can navigate the sewer to retrieve their treasures: the Turgid Sewer Rat.
The player will control the Turgid Sewer Rat through the maze of sewerage under Tien Kwan to avoid the albino creatures that populate the labyrinthine system and retrieve the lost treasures of the citizens above. They will have a bird’s eye view of the maze as they fight off the sewer inhabitants, avoid traps, and find treasures to fulfil their contracts.
Once the design document is done, including the types of monsters, goals and so forth that the player will encounter, we will get on with the coding.
Speaking of which: we started making a rough plan of what sort of things needed to be coded first. We had a series of tiers. Tier 1 would be laying down the code for displaying the maze and the controls for moving the Rat. (In particular, I want to use one of the methods one of the other team members used in their Jumpman project where the camera moved with the player, and the maze moved relative to this.) Sorting out the base class for the walls and other characters in the maze, as well as sounds, would also be part of the first tier.
Tier 2 will involve expanding on the enemies and treasures, as well as developing a number of levels. Tier 3 includes developing a more advanced artificial intelligence for the enemies, plus a bunch of other features we’d love to have in but won’t be absolutely necessary to the project as a whole.
So onward, where angels fear to tread.