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!