…for me, at least. Today, I gave my notice to EA that I’d be leaving. I’m moving on to (hopefully) bigger and better things. More importantly, we’re moving closer to family so that grandparents can see their granddaughter more than once a year! 
So, the About page has been officially updated: I am now just an indie game developer, no longer trapped in a corporate game developer’s body.
Let’s start our deconstruction with the most basic feature of the player’s character, Link: his movement. Link’s movement displays a surprising amount of subtlety. If you play The Legend of Zelda for a while, you’ll notice that Link doesn’t ever get hung up on obstacles due to unexpected collisions, nor do you ever just miss a bad guy by a pixel or two when attacking him. Yet at the same time, you’ll notice that Link moves fluidly through the gameworld; even tough the environment is tile-based, you can tap the directional pad and link will move a single pixel in that direction. If you’re moving to the left and decide to go up, down or right, Link instantly moves in that other direction when you change directions on the gamepad.
What’s happening here is a very neat trick. While Link can move a single pixel at a time, in any direction, the longer he continously moves in any direction the more he gravitates toward aligning himself with the underlying grid of the screen. The tile grid for LoZ is 16 tiles wide by 14 tiles high (including 3 tiles for the status display at the top of the screen). Each tile is 16×16 pixels. Link operates on a half-tile grid, though (32×28 tiles, 8×8 pixels each). As Link moves, if he’s not currently aligned with the half-tile grid, he is adjusted, one pixel at a time, toward the closest correction. As a result, if Link is 4 pixels off alignment he’ll line back up with the grid after moving 4 pixels.
In case that description doesn’t make sense, here’s an exercise to help demosntrate the technique:
Assume Link is basically in the center of the screen, lined-up with a tile. In other words, Link occupies a whole tile, just as he would in a strictly tile-based game (like a traditional boardgame or wargame). If you tap on the directional pad to the left, Link will move one pixel to the left. If you tap again, he’ll move another pixel to the left. This is pixel-fine control, which makes Link’s movement feel fluid.
Now, if you hold the directional pad to the left, Link will move continously. As soon as you let up, he stops. If you hold left then immediately reverse to hold right, he instantly changes direction (as he does for up and down as well). This is basically lag-free, which makes Link’s movement feel responsive.
Okay, return back to Link sitting squarely on a tile. If you tap left twice he’ll be two pixels over the left edge of his starting tile. Now press up four times. You’ll notice that after each press Link will move up one pixel. But, he’ll also move to the right one pixel, either the first two times you pressed up or the first and third times you pressed up (I don’t have the game in front of me and I can’t remember the rate at which it corrects). So, even though you never press right on the gamepad, Link has now returned to the same horizontal position as he was when he started (before you moved him left two pixels). This is the built-in correction.
What does this correction do for you?
The correction prevents the subtle but annoying problem wherein the player would “snag” on the corners of objects that he anticipated passing by. The more the player moves contiously the more aligned Link becomes, which has the same effect as speed-sensitive steering in a car.
The correction also has benefits for attacking as well. When Link attacks (with his sword, for example), the “kill zone” lies in the tile(s) immediately along his facing direction. Since enemies align along a similar half-grid as Link, the correction serves to line up Link with his enemies (as opposed to missing the enemy by a few frustrating pixels).
Observant readers will observe (as they are known to do) that this “feature” doesn’t appear in the SNES sequel, The Legend of Zelda: A Link to the Past . Even though the gameworld is still tile-based, player (and enemy/NPC) movement is not strictly aligned on any grid. We get the same corrections though, but using different mechanisms.
Movement is corrected by “rounding” the corners of most things Link can collide with. Thus, when he encounters them the “physics” of the game deflects him at a 45-degree angle along his direction of movement (e.g., if he was moving north/up and encountered a corner he would move northwest/east until he passed the corner).
Attacking is corrected in a similarly interesting way. Instead of Link’s sword having a killzone along a straight line down his facing direction, his sword “swipes” in a large arc, an arc that happens to be pretty close to full two “tiles” in the gameworld (one directly in front and half above and half below). This allows the player to attack while slightly mis-aligned with an enemy and still land a blow.
The result for both actions in both games is the same: the player’s desire is successfully expressed in the gameworld, regardless of the potentially pedantic ways of the computer.
It’s no secret that the Legend of Zelda (NES) was a watershed game. The game still has an open-world feel that titles to this day fall on their face trying to emulate, even in this post-GTA design world. This was the first game I ever played that truly was open in the sense that I could go anywhere in the game and basically approach (or avoid) any obstacle as I saw fit. The game also fits the bill as the prototypical example of an action-adventure video game, and the series (with a few minor exceptions) has continued that tradition since.
What is there to learn from a game that originally released in 1986? Twenty years later, there are still design subtleties in LoZ that are overlooked. The game is a perfect example of simple mechanics played out on a vast and varied playing field. From a complexity perspective, the game represents something achievable by any single individual given today’s technology and tools, yet we have the efforts of huge teams with comparitively bottomless budgets failing to capture the subtle qualities that simply make this game work.
In what I hope to be an insightful series of essays, I’ll be deconstructing the elements that I feel make LoZ a relative Citizen Kane of the genre, and see how those successes can translate to useful lessons in today’s games.
As a bit of a preface, let’s look at the game’s premise and detail the overall mechanics of LoZ. The premise follows the classic Hero’s Journey, with Link (the player-controlled character, who was so-named because Miyamoto saw him as the player’s “link” into the game world) out to save Princess Zelda from the evil clutches of Ganon. To achieve this goal, Link must acquire the objects of mythical power (the tri-force) and the one weapon that can kill the ultimate evil (the master sword). To this end, Link travels to many different locales (deserts, forests, mountains, dungeons), doing battle with many monsters and finding many unique weapons.
The mechanics are straightforward. Link is represented onscreen in an top-down view. The player has direct control over Link: the directions on the gamepad (left, right, up, down) correspond to movement onscreen (west, east, north, south, respectively). The A & B buttons are mapped to various actions, usually one of which is mapped to Link’s sword while the other is mapped to a special weapon or inventory item. There’s no jumping. To pick-up an item, Link simply collides with it.
The gameworld is divided into two sections: the Overworld and the Underworld. The Overworld is composed of mountains, trees, bushes, rivers, lakes, rocks, etc., what you’d expect from a classic outdoor adventure landscape. The Underworld is represented by dungeons whose entrances are hidden throughout the Overworld. Each dungeon (of which there are 9) is self-contained with one entrance/exit, each one containing a boss monster and usually an item of significance near their end. The dungeons don’t have to be visited in any particular order, but some of them have accessibility barriers that require attaining items of significance from other dungeons in order to be successful. The final dungeon is home to Ganon, whose defeat is the final goal of the game.
The gameworld is viewed one screenful-at-a-time. When Link hits the edge of the screen (or a doorway on the edge of the screen when in the dungeons) the game “pauses” momentarily while the view shifts/slides to the new screen, at which point player-control resumes. Each “screen” is usually transient, with enemies regenerating and other elements “resetting” when a player exits then returns to a screen. Enemies cannot pursue Link out of one screen and into another, nor can Link attack from one screen into another. Thus, each screen represents a self-contained segment of gameplay, rarely dependent on what came before it.
Enemies are generally very “stupid” and normally just follow set movement patterns. Outside of bosses, few of the enemies actually pursue the player, and most are killed in one or two hits from the player’s sword. Most enemies attack the player with “contact damage,” though some launch projectiles along whatever direction they are facing. Often, enemies leave behind some kind of reward on their death, usually a coin (or “rupee”), heart (representation of Link’s life or hit points) or other refillable items (arrows, bombs, keys).
Of course, all of this is probably not news to anyone reading this, as I would hope everyone is familiar with this classic. It can be easily located in ROM form to play in your favorite NES emulator, or you can grab the version for the GBA (the re-released NES classics). I have both, in fact!
Our first topic (which will be posted either later tonight or tomorrow night) will be some observations on the movement and attack mechanics of Link.
Well, looks like even the man (or rather, The David) himself applies GTD to the software process (or more accurately, his CTO does). Here’s 43Folder’s two part series on the subject of “Getting Software Done” (part one) (part two).
While it’s not too much in the details (unfortunately), it does provide an interesting supporting point to my earlier post:
Another key with all of this, and a somewhat revolutionary approach, is that we don’t track bugs and feature requests in separate places. It all has to get done anyway. And because maintaining a comprehensive inventory of everything that needs to get done in one place, accessible by all the relevant people, we can very quickly re-calibrate to focus on what’s critical. Sometimes that’s a bug. Sometimes it’s a great new feature. Either way, we use the system to support us like a giant radar screen, and good communication in person, by phone, email, and IM to determine what’s critical and go after it.
Can we apply David Allen’s Getting Things Done process to software development? If it can organize the hectic life of a Fortune 500 CEO, couldn’t it help out the lowly software developer? A recent blog post from a coder in the Google trenches, “Good Agile, Bad Agile” suggests to me, “yes.”
This morning, I read a post over at King Lud IC that seems to indicate I’m not the only one who read “Good Agile, Bad Agile” and thought, “hey, this could apply to gamedev!” Of course, there are already folks applying the Agile process to gamedev (notably, the folks over at High Moon Studios). From the sounds of it, they’re happy and successful. But, I know Clint (High Moon CTO) and Noel personally, and those are two guys who I’d expect could make any process successful. They’re dedicated, meticulous, and above all clever. How about the rest of us?
Like many web professionals and software developers, I’ve been lured by the cult of personal productivity. It’s rather ironic, then, that I’m also infamously considered a procrastinator and referred to by my parents (when speaking to their friends) as “extermely laidback.” Of course, I own up to both of those descriptions. Perhaps they’re the underlying motivation for my constant pursuit of a “better system”?
I’ve found Getting Things Done (or GTD as its referred to by those in the trade) to be an ideal system. It has some basic rules, some lose theory around those rules, and a whole ecosystem of software and blogposts guiding anyone wishing to embark on the journey. For purposes of this discussion, here are the basic tennets (cribbed from the 43Folders linke above):
So, how do we apply these tennets of GTD to the software development process? Or more interestingly for the readers of this dear site, how do we apply this to game development (thinking of the indies)?
I find this one to be the most satisfying, the most fun. It’s the carrot that really gets the process moving along. It’s brainstorming, but with more depth and detail. You’ll want to make an exhaustive list of all design features, technology hurdles and content requirements. Don’t stop and do anything, and don’t spend too much time thinking. The goal is to make as complete a document (list) as possible of what needs to be done. Try to be as specific as possible, but don’t worry too much about the granularity (as that will solve itself later). You should be telling yourself, “if I don’t write this down then it’s basically like it doesn’t exist.” Make your thoughts tangible, or they’ll never happen.
The three D’s: delegate, defer, delete. There are lots of details you won’t have to worry about. If you just starting your design for a new game then don’t fret over how you’re going to collect credit card payments when its finished. You can worry about that if and when you finish the project. If you’re the programmer and you’re not quite sure how the artists are going to produce all the content for the game, stop, delegate that to the artist and have them worry about that. This is all in an effort to save you from the fourth D, distraction.
I’m using activeCollab, a web-based project management app (a free, self-hosted competitor to Basecamp). Basecamp is a great option as well. Large organizations often use Microsoft Project. I’m sure there are other options as well. A simple to-do list could work as well, but the less structured it is the more onus is on you, the user, to keep things organized and useful. The critically important thing is that the repository is something that you’ll use, and use often and regularly. As a result, I’d suggest using a piece of software that you’re in love with, if possible, and you want to have an unreasonable desire to go and use it at every chance (to close those open loops).
If you think of a new idea, put it in the repository. If you run across a bug, put it in the repository. Whatever you do, don’t have multiple places for these things to be kept; keep it all in one, centralized spot. Don’t keep a notepad on your desk and promise yourself you’ll type the stuff up in a few hours or at the end of the day. Do it now. The advantage is that you get these “open loops” out of your brain so that your brain can be used for more productive things. Computers are great at “remembering” things, let them do the grunt work.
There’s one exception to this: the two-minute rule. If you can act on something in less than two minutes, then do it. The overhead of “using the system” isn’t worth it for something so small. Two minutes isn’t an absolute, but don’t stretch the exception too far or you defeat the purpose of the rule (as you start to get distracted!).
Multitasking is trivial with modern computers. While context-switching is one of the most expensive “atomic” operations a computer can perform, it still is well under a second. For people, on the other hand, context-switching is expensive, very expensive. It breaks “flow.” So, instead of just plowing through your lists of tasks in the order they come, divide them into “contexts” that dictate when the appropriate time is to work on them. This is particularly useful for the one-man-gamedev-shop where you wear the hat of programmer/artist/designer/producer. I’d recommend having contexts like: Photoshop, Websurfing/Research, Visual Studio, Level Editor. When you’re in a specific context, look to that “list” to see what you should do next.
Also, if your “master list” tracks such useful information such as estimated time required for a task, use that information to as a secondary criteria for context. Have 15 minutes while you wait for some software to download? Do a little websurfing/research. An hour while your significant other is getting ready for work in the morning? Finish the icon for your application in Photoshop.
Consistency in applying these policies is what makes them successful. Refactoring is also a big win.
Now, I don’t mean refactoring in the software sense. I mean refactoring the process. Part of the advantage of the simple process and the whole GTD system is its kind of introspective nature, where GTD practicioners are always looking for ways to refine and enhance the GTD system while still embracing the fundamentals of GTD.
But there’s an even more particular way in which you should apply the ideal of “iterate and refactor.” In the case of your master list, you’ll inevitably have items on it that the GTD crowd calls “projects.” Projects are tasks that are in fact meta-tasks, something like “Organize the Closet” which aren’t really directly actionable. When you hit upon a “project” in your list, you need to look at it and determine what the “next action” is, i.e. what can you do tangibly to move this forward.
In fact, GTD has “reviewing” as an important element of its process. One should regularly (daily, twice-daily) review all of the meta-level stuff, like projects, and determine where they stand (completion, timing, etc.) and populate their master to-do list accordingly. Again, this is an aspect of the “refactoring.”
Well… there’s a ton more I could write on GTD-as-software-process, and I certainly plan to do that. This post is somewhat vague in areas, a bit hand-wavy in others… it’s my first shot at getting these ideas down, but I’ll definitely revisit it in the future.
I’m looking forward to getting stuck in Limbo. He’s looking for C++ programmers, but I was first struck with how perfectly this game could be done in Flash. With Flash’s new filters and improved performance, I’d guess he could get the exact same results, cross-platform and with a lot less development pain than C++.
It’s a great example, though, of the kind of results we’ll see as more people with classic art and graphic design backgrounds (with a sprinkling of programming experience) are brought into the gamedev fold. The in-development footage on his sight is hauntingly beautiful, and an inspiration to say the least. Makes me remember those first few hours playing Out of this World, still one of the few games to deliver so much on so little.
Speaking of Out of this World, I’ve always thought it’d be awesome to see that game remade in Flash (it’s largely rotoscoped with a vector-like graphic style, very applicable to Flash development). Hell, if it fit on a 1.44MB floppy and ran on a 286, surely it can run full-speed in Flash on a modern day machine? Those are the kind of side-scrollers people need to be making… there’s a lot of life left in that very simple mechanic! (And the side-scroller view? Well, that aesthetic has worked for “comics” for a hundred years.)