A good month has gone by since the initial whiteboard brainstorm. I’ll summaries some of the discoveries rather than doing the tedium of a the blow-by-blow account of challenges, problems and solutions of the Turgid Sewer Rat.

Working in groups is challenging. This one I was ready for, so wasn’t too surprised as group members failed to show to class. Some have pulled out of the course, which does surprise me, as we are two thirds through and so close to the end.

Without the manpower, parts of the project won’t get programmed. But we had in our initial design identified the critical core components of the game. Without these, we have no game:

o level loading and display;

o collision detection;

o player and non-player movement in the world;

o doors, and the switches to activate them.

Everything else – music, sound effects, hand-drawn backgrounds, fluid animations, graphical HUDs, menu screens, movie cut scenes – would all wait. The core components was the grit around which out pearl could grow.

Even if there was complete group-breakdown and the bulk of the work fell to just one person, the the core components were manageable enough that there would at very least be a bunch of pixels roaming the screen, collecting other twinkling pixels, hitting some pixels that would move other pixels that would allow the first set of pixels into another part of the pixel world.

At it was, three of us got the bulk of the core component completed.

Team Funky is made up of a rotating membership.

Of the core components, three of them were critical, and needed to be completed to some degree at the same time.

Funky Member 1 worked on “collision detection.” The principle of this is that clusters of pixels are going to be moving about the screen, and at times connect with other clusters of pixels. What happens next depends on what those clusters are meant to be.

o Player hits some treasure. The treasure needs to disappear from the screen and the player’s score increase by some amount.

o Player hits wall. The player isn’t allowed to overlap with the wall and needs to be ‘pushed back’ into the room.

o Player hits albino rat monster. Albino rat monster will get angry and swipe at player with claws the size of scimitars.

Mediating between all of these interactions is the collision detection manager. Every update of the game, the collision detection manager is called to see if there is a collision between X and Y, and if so makes sure Z happens.

Of all the critical core components of the game, this was very critical. It also involved a mess of delicious mathematical geometry, so when TF1 got it working he deservedly could not wipe the smile of his face.

But to make sure it worked, the player needed to be moving around the screen. TF2 worked on this, scavenging code from our old Asteroids game. We would have a birds eye view of the Turgid Sewer Rat moving through sewers, so TF2 did not need to mess about with a gravity component. Instead he had to think hard about player interface, and what would be comfortable and intuative for the player when using a controller. This is still being decided on, but at very least we now had a tiny Turgid Sewer Rat that could be moved about the screen.

While this was happening, I was putting together the code for loading the level. We had decided to store the level definitions in two text files. One would store the level walls, doors, and switches, while the other would have all the objects and spawn point for the things that would populate the sewers.

A few technical points: We’re using a 1028 X 7xx screen size. The map is a series of tiles 32×32 pixels. This means each section of wall, each door, each door switch, and each background tile (ground, water, toilet water) is a square 32 by 32 pixels. The map would therefore be a grid 40 tiles wide and 32 tiles high.

When a level is built, the map file is first read and stored, then the object file. On each update of the game cycle, the objects are drawn on top of the background map.

And here is where the all-important collision manager works its magic. Each tile and object has a bounding box created around it, and the manager calculates if there is any overlap at any point. If it is the player and a ground tile, then the play just passes over it. But if a player collides with a wall, they need to be pushed back into the room.

Player, walls, collisions. Somewhere in this, TF1 got our first enemy onscreen. Clusters of sprites that will be our albino rat creatures that follow the Turgid Sewer Rat when he gets too close.

Final core components were switches and doors. This involved tinkering with the collision manager so that when a player collided with a switch, the corresponding door(s) will open (or close).

Enough core. On with the level design!

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.

As a colophon: We are going to programming this in XNA framework, which is the Microsoft framework for Xbox and Windows games. To maintain revision and version control, we are using Perforce.