Considered to be one of the best games of 2007, Portal has received good review after good review for its originality and excellence in level design. And now that I’ve finally gotten around to playing it, I can see why — it’s a great game. Obviously I haven’t been playing a lot of games in the last two years, and this may put me in a somewhat unique position to point out some game design lessons to learn from ways that Portal could have been even better.

See, there are a number of things that bug me that seem to be so ubiquitous that they don’t even get mentioned anymore. One big one is expecting a game with a 3D engine to be a little bit of everything. For instance, God of War does not need a “walking along tiny planks” section. Gears of War does not need a driving mission. Geisha of War does not need a stealth section. (okay, I made that last one up… sounds like a cool game, though.) If a game’s engine does certain things well and other things not-so-well, best to stick with the things it does well and leave out the others.

Portal has a unique gameplay mechanic that could have easily carried the game on its own, especially with such great level designers. Instead, we have two mechanics that probably should never have been a part of the game. Object manipulation is one of the weakest parts of most 3D engines… unfortunately, there are a number of objects that can — and in many cases, should — be picked up. Boxes need to be carried and placed on switches, which could have been done very simply: you pick up a box, it has a direct relationship with your virtual body. Instead, there’s this crazy magnetic thing going on to try to explain why boxes that you’re carrying are sometimes close, sometimes far away from you; they get stuck on doors and walls, sometimes you randomly drop them, and you can sort of throw or drop them and sort of not so much except when you don’t want to. It makes sense to have something other than you be able to go through the portals, and that’s fine, the physics engine handles it great. But what is up with 3D games and terrible object manipulation? Leave it OUT if it doesn’t work.

Another unneccessary element in Portal is platform jumping. “But John,” you say, “there wasn’t any platform jumping in Portal! You must be thinking of Flinging, one of the cool portal-related mechanics.” Ah, not so! There were a number of times when you were required to jump from platform to platform. And these actually worked okay. What annoyed me was a specific level… let’s just say it was somewhere before the end of level 19…. I spent almost as long on this one level as I did playing all of the rest of the game combined, because I thought that I needed to jump somewhere and it turned out that jumping was not the solution. I assumed that the reason that I was always either short of the jump or way past the jump (an odd situation to find myself in) was because of 1. my inability to master jumping and/or 2. poorly executed platform jumping mechanics. #2 is so common that I assumed eventually I would get lucky and land on the platform I thought I needed to go to. As it turned out, that was the wrong solution to that particular puzzle, and I now believe that those jumps were put there to screw with me and throw me off the scent of the actual solution. I appreciate the game screwing with me in a setting like this, it seems very appropriate; but to do it with a mechanic that is traditionally very weak in a first-person-perspective 3D game just drives the point home that platform jumping in other games sucks.

One more thing I’d like to bring up that many game designers can learn from is Checkov’s gun. Checkov was a playwright who believed that if you show your audience a gun onstage, it should get fired sometime during the play. Otherwise, it is just distracting your audience from what you wanted them to experience. How does this relate to Portal? Early levels in Portal are very sparse and (aside from the cameras) have nothing extra lying around. Later on, you begin to explore areas that have junk lying around: clipbaords, chairs, bolt cutters. Okay, so what’s the problem? These objects would be in this environment, so it adds to the realism, right? No. These objects should have been static, unmoveable scenery. The ablity to pick something up suggests that it might be useful, and serves only to take the player out of the experience. There were two instances when this really hit me: One, when I encountered a chain-link door locked with a padlock. Picking up a pair of bolt cutters from an adjacent room yielded no result whatsoever. Sure, in this game we don’t pick things up with our hands, we use some kind of crazy magnetic thingy, so of course we wouldn’t be able to use bolt cutters on a padlock. DUH, right? Um, sure. Whatever. Two, I was able to pick up and place a chair underneath an opening that I was trying to jump into, but couldn’t quite make the jump. It turned out that I needed to use a box, no bigger than the chair I was trying to use, to stand on to make the jump. So the lesson here is: your players will try to solve puzzles with anything that you give them. It’s okay to screw with them, but make sure that it’s intentional.

None of this keeps Portal from being an excellent game. Rather, such a good game allows these very common pests to rise to the surface… hopefully I’m not the only one who noticed them, and today’s developers are working to eradicate them.

After Day One I was busy for two days. When I started back up I didn’t track my progress as well.

My first priority was creating enough art and sound assets, temporary or otherwise, to be able to finish the coding. I wanted to finish this game before I lost enthusiasm for the project, and the next day I was going to be driving to my sister’s house for a few days, so any work I did on the project after this day would have to be done on someone else’s laptop.

When working on a game I like to get the music done and in-game pretty early, in order to test and make sure that it isn’t going to drive me crazy if I hear it over and over. I wanted the background music to be reminiscent of Vince Guaraldi’s Peanuts Christmas music. Reason is my go-to software for quick MIDI-based compositions. I loaded up a piano and, utilizing my training in jazz piano, stitched together some Guaraldi-sounding melodies. I accidentally stumble across some chords that are much to slow but that I like for the title music. In order to help prevent music burnout during gameplay, I comp three different melodies to the same chord progression, each about 30 seconds long, and set up a loop within the game that will randomly choose which piece to play next. As much of my background is music-related, this was the easy part of the project for me.

My roommates left the apartment to go to dinner and I took advantage of the relative quietude (I live next to a freeway) to record the sound effects. I wasn’t going for perfection here, and not only that, but I had forgotten that I had swapped SD cards between my Roland R09 digital recorder (my go-to device for quick-and-dirty recording) and a camera, leaving me with only 64MB of space, or about 5 minutes at the lowest resolution I was willing to go. (I knew that Scratch was going to compress the heck out of all of the sounds anyway, so I wasn’t too concerned about quality.) As it turned out, I emptied and filled the card about three times. Five minutes is not a lot of time when you are trying to record taunts, snowball impacts, and other such sounds. I used an actual winter coat for coat-related sounds; packing snowballs was squishing cornstarch with a spoon; and snow scatter explosions turned out to be a small bag of nutritional yeast, I think. (I tried out a lot of different substances, so it could have been puffed rice or oatmeal.)

And now it was on to the art. Of all the skills required to make a game from scratch, I’m weakest in this department. I will hopefully find an artist that clicks with me sooner rather than later.

Non-game-related side note, yet relevant to the game creation process: not only was I traveling the next day, so was my girlfriend. She would be going away for the next few weeks, so we wanted to get together before she left. I also wanted to get this game done ASAP. There were some misunderstandings, I brought my work over to her apartment because I thought she was going to be packing and we could hang out while we were both working. Had we both communicated better and earlier we might have prevented some of the drama that was created. As it turned out, we worked things out, but it’s clear that defining boundaries between work and our relationship is going to be something that’s going to come up again soon. And now back to the development proper.

There are four more-or-less identical “enemies” in this game, and I figured if I could make all of the art for one of them, I could use that temporarily for all three and use it as a template for the other there, altering the art while I was away. I’m not a huge fan of drawing with a mouse, so I borrowed a Wacom tablet from my roommate. It was my first time using a tablet, and it was a really awesome experience. All those years of doodling in high school helped me out here and I had my art assets — neutral, taunt, ready to throw, throwing, hit, snow forts, snow balls — done in maybe five or six hours. I really wanted to get this game done before I left, so I pulled my first all-nighter in a long time. I watched the sun rise as I added the code to make the animations and sounds play. Right around 8AM, the latest I could work (I still had to exercise, shower, and pack before leaving at 10AM), I finished the code. The timing of events would still need to be tuned, and the enemies all had the same art, but the code was done; I had been working on the project for about 20 hours, in total.