This is the first article in a series I’m calling Practical Game Design. (cross-posted here on Gamasutra)

The idea is to look back on the great masters of game design over the past few decades and extract some useful techniques from their games that we can immediately use in our own. I’ll stick to specific examples as much as possible.

The first one comes from Shigeru Miyamoto himself, and although it might be known by other names, I’m going to call it “The Rule of Threes.” This is a practical level design technique that introduces the player to new challenges gradually.

This technique is a favorite of Shigeru Miyamoto, and really helped differentiate his games from all the other punishingly difficult NES titles of the 1980′s. This technique does not makes your games “easier,” however.  Instead, it makes your games more “learnable” by making sure that the player has been “primed” before the real challenges begin. The best part is, you don’t do this with boring, pedantic tutorials. You just do it with gameplay. As Raph Koster would say, the player learns by having fun.

Since this is Practical Game Design, I’ll explain the technique through example. Let’s take a look at the original Super Mario Bros. and see how the Goomba is introduced.

Step 1: Introduce the Challenge as simply as possible

The first time we ever see the Goomba, he’s just walking straight towards us. No tricks, nothing fancy: there’s just one of them and he just slowly lumbers in our direction.

Note that this is the easiest possible way to challenge the player with a Goomba.

For most of us, this isn’t much of a problem. Stomp him or hop over him, and you’re good. But, back in 1986, this being the first video game many people had ever played, many players would have been killed by that first Goomba. But that’s no big deal – one life down and start from the beginning, no progress lost. Try again.

Note also that it is literally impossible to get past the first Goomba without learning the game’s most fundamental skill: jumping. This means that the game designer can assume that any player that gets past this initial point knows how to jump.

Okay, first Goomba has been jumped over. Move to the right a bit, and here we see our second Goomba.

He’s bouncing back and forth between two pipes, and we are standing on a pipe.

This is one step up from the easiest possible Goomba challenge. More importantly, however, this shows us a new dimension to the Goomba. Before the player needed to merely stomp the Goomba or jump and let it pass. Now we have a different situation: it will bounce back and forth when it hits a pipe. The confined space changes the nature of the challenge.

This one isn’t particularly difficult, either, and the player is likely to get past this stage fairly quickly. As soon as the player is past this point, the designer can assume the player has absorbed his first two lessons.

Next, we see this:

A variation on the challenge we were just given, here is a wider span of two pipes, with two goombas moving back and forth together.

This one is interesting, because it’s both easier and harder than the last challenge. It’s easier because there’s more space, and because you can stomp both Goombas at once, and harder because there’s twice as many of them, so that even if you get one, you might still die.

It only takes about 10 seconds to make it through these three challenges, but already the player has been given a very good introduction on the game’s first enemy type. We’ve learned the basic skill we need to deal with it (jumping), and we’ve been given a quick but representative sample of the various situations in which Goombas will be thrown at us.

This might seem a bit simplistic, but there are plenty of games in which the player is not properly “primed” for new challenges before they’re presented. Instead, the player’s first encounter with the new challenge is to be beaten in the face with it unexpectedly. Not only is this frustrating, but the player is unlikely to learn much from this scenario. The Rule of Threes is a great solution to this problem.

So, back to Super Mario Bros. Now that Miyamoto has introduced us to the Goomba, what happens next?

Here we have Goombas falling off of ledges and threatening the player from above. This is really the first time in the game where Goombas are presented as a challenging threat. Imagine if this was the first thing that greeted you upon playing the game. Sure, plenty of us hard-core gamers with decades of experience today would have no problem with it, but as a 5 year old in 1989, I can imagine being plenty frustrated. That simple 10-second build up of gameplay really helped prime me for this situation back then, and it will work the same way for players today.

This is what’s really important about level progression. In essence, you’re building a learning curriculum for the player. You present the challenges in isolation before you ramp things up, so the player learns individual skills first, which can be layered together into more complex skills later.

The Rule of Threes can be used across many scales, both in and out of levels themselves. Each world in Super Mario Bros. consists of 3 preliminary levels, and then a challenging “castle” level, after all. In this way the Rule of Threes is applied throughout the structure of Super Mario Bros., kind of like a fractal.

Just look at the last corridor of the first castle, before you meet Koopa for the first time:

The Rule of Threes in action: Preparing the player for Koopa

Rather than just let the player deal with Koopa and meet instant death, the player is given a short training course on fireballs. First, a fireball comes straight at you in isolation. Then, the terrain changes and the fireballs come at different heights. Finally, the fireballs start to come more quickly. The player has been “primed” for battling Koopa before the fight has even begun.

Obviously, there’s nothing magical about the number three. I picked it as it seems like a nice rule of thumb – once you’ve shown something to the player a minimum of three times in different situations, you can start to mix it up without being completely unfair.

There’s plenty of other useful techniques and interesting structural lessons to be learned here, but I’ll just keep this short for now and leave those for future posts.

Let me know what you think! Is this helpful to anybody?

It’s been a while, and this post is to explain where I’ve been this whole time. Last anyone was listening, I was hard at work on Super Energy Metropolis, the sequel to Super Energy Apocalypse, and doing some prototypes of that game. Well, life threw me a few monkey wrenches between then and now and I’m here to explain where I’ve been.

First, I got married, then I got a job, and then I decided I really ought to finish my Master’s thesis.

So, I got married last May and took some time off. Then I was hired by Anthony Pecorella, an employee of Kongregate.com, to work on a side project of his called CellCraft.

Anthony got a grant from the McArthur foundation to do an educational game, and contacted me after playing Energy Apocalypse. Some press releases about the project: here’s one from Wake Forest and here’s one from Gamasutra.

Basically, the idea is – a real time strategy game about cellular biology, where the player is the cell. I’ve been working part-time on this since May 2009 and we’re almost finished. We’re due for release in early March. I’m really excited about this one. Here’s a teaser graphic:

Now, the other half of my work day has been spent finishing my Master’s thesis. HARC, being amazing as usual, decided to fund the thesis, which is largely why I got the paper done in less than a year.  This is also why Super Energy Metropolis has yet to materialize. I’ll probably do SEM some day, but for now it’s tabled indefinitely. I’ve just got too many irons in the fire and HARC is interested in other things right now.

For the thesis, I decided to take Super Energy Apocalypse and evaluate whether it increases player’s knowledge of energy economy, and if so, by how much. We did a whole research project on it, collected all kinds of data, crunched it, collated, and stapled it, and now the paper’s finally done. I’d post it here, but my professor wants to shop it around to journals first, so we’ve got a one-year journal hold on its online publication. Check back in January 2011, hopefully we’ll have it published by then

So, sad as it is to say, Super Energy Metropolis will have to wait for a while before it sees the light of day. But rest assured, dear gamers, that we’ve got tons of other cool stuff coming out the gate here at Brain Juice Games!

Dynamic Pollution

So, it’s been a little while since my last post, but I’ve been hard at work on both the analysis of Prototype 3 as well as the upcoming Prototype 4 code, which I’ll post in a little bit.

So, with Prototype 3 we added dynamic pollution – ie, pollution that would stack over time and be emitted in proportion to human activity, rather than just magically appear around roads and buildings. What were the results?

Well, I’m pleased to say this simulation is starting to look a little bit like the actual situation we face:

• There’s actually an incentive to use roads now. The cars system works pretty well.
• Factories and roads are not dangerous just by themselves.
• The pollution builds up nicely over time and then dissipates
• Congested roads build up smog quickly, but if they’re nice and spread out, pollution doesn’t stack up too badly.

The dominant strategy is no longer “pack ‘em in like chickens.” Let’s take a look at a couple of scenarios I set up:

Suburbs & long highways

In the above scenario, we’ve cloistered off our houses at the top of the screen to keep them as far away from pollution as possible. Then we’ve connected a highway down to our factories at the bottom. People zip to work, plug in their hours, and then zip back home. There’s a bug or two with the way pollution displays, but we don’t care too much because this is a prototype and we’re just trying to get a feel for how it works.

In general, this is pretty cool. We can notice some problems already: that super-thin road is creating some serious smog pollution. Now, the cars spend so little time in that pollution that they only get affected by it a little bit. This makes me think of some things:

• We need to model traffic. A clogged highway has this exponential effect when it gets clogged: more cars make them all slow down, which makes them stay on the road and produce even more pollution. I think I can throw in a little modifier that makes it so that congested roads slow down cars. Might be good to research some actual traffic simulations for this.
• Local air quality and health is not quite enough of an incentive for the player to reduce all pollution. You see, as long as the player can just drive his/her cars through the pollution, it doesn’t matter how smoggy the roads are if it doesn’t directly affect the health of the city’s people, sine the game doesn’t model any other ill effects. What we’ll probably do, is make the pollution disappear from the local system and enter “global” (as in “global scope”) system.

This smog system is interesting so I’ll touch on it separately real quick. Instead of like in Energy Apocalypse, where smog was only an overall problem, this model takes into account the local, air-quality issues of smog as well. You see, transportation isn’t nearly as large a contributor to global emissions as say, Coal power plants, but most of us live a lot closer to highways than power plants, and we have to breathe that air.

What we’ll do then is use both systems – local and global, for this game. Smog comes out of your little factories and cars, and produces health problems, then dissipates. But when it dissipates, what that means is it’s going out of your city and into the surrounding atmosphere – specifically, into the land the zombies inhabit.

This is an interesting opportunity to model something my boss, Robert Harriss, has been talking about – stocks and flows.

Okay, next example:

The world is my parking lot

Here was another situation that resulted in high health for people and a fast rate of production. Basically, you put your houes on one side of the map, and produce roads to get them to work. Now, if you only have one way to get to a factory, that road gets really smoggy, so instead you just build roads all around. People spend very little time on a given road and have multiple routes to get to work, overall smog is low and health (and production) are high.

The problem with this model is that there is no dis-incentive for “paving the earth.” There is no incentive to NOT develop roads, because unpaved dirt gives you no reward. At this point, we might have to consider adding features outside of our “roads, houses, and factories” prototype toolset and start adding other features we’ll eventually see in the full game.

Also, this model still produces about as much smog as the previous one – it just spreads it out so it dissipates faster and doesn’t make people sick. That’s good locally, but those emissions have to go somewhere, they don’t just go “away,” so again, another strong reason to start modelling what happens to pollution when it leaves the immediate local system.

Finally, I decided to test out the classic “suburbs / inner city” model to see what would happen:

Suburbs + Inner City

Here, people live in the suburbs and commute downtown to work, with a big beltway/loop all around the city. (Kind of like modern-day Houston).  So, the industrial core gets polluted pretty fast, and you can tell that overall health is a bit lower than some of the other models. People aren’t stabilizing at gold levels of health, but tending towards blue and even dipping into grey now and then. They heal up pretty well at their very clean homes, but the center gets polluted and STAYS polluted. It stabilizes and then doesn’t get much worse, but obviously this is not an ideal way to run a city – it moves your problem “somewhere else”, away from where you live,  but the smog still accumulates and it does make people sick while they’re working.

People have been commenting that the sizes of buildings are a bit of an oversimplification – and in game design terms, I have to agree. Equivalent graphical size implies some sort of physical equivalence – and in real life, factories can house much more than a single household of people. Also, roads are absolutely enormous, and you run out of map really quick.

So, in the next version what we’ll do is start playing a bit with scale: we’ll scale up factories, scale down houses a bit, and scale down roads even more. Once it all works we’ll see what implications that has on the strategies that work best,a nd even the effects on pollution. Then, we’ll start talking about adding other features, notably : bringing energy into the equation. This is Super Energy Metropolis, after all!

Prototype 3 : Dynamic Pollution

So, after prototype 2, we learned that we were going to have to deal with pollution in a more dynamic way, not only for accuracy’s sake but also because there still was no incentive to build roads.

As you can see, people will now turn into little cars whenever they touch a highway square. They will then move significantly faster than a person moving on dirt, but the downside is they will start leaving little trails of pollution down behind them. This pollution is a very small amount, but if a lot of cars travel over the same area, it will quickly build up.

More details and the playable prototype link after the jump

So, a quick list of all the changes:

• People now turn into cars when traveling on roads (modeling people getting into their cars to drive on the freeway). Seems like a nice way to abstract that. If you build roads, people will buy cars and use those roads.
• When a person has transformed into a car, they will produce smog so long as they are still in “car” mode.
• When a person puts in a man-hour of work in a factory, it produces a small bit of pollution. (Still haven’t modeled an expanded radius of pollution for factories). This is different from prototype 2 where factories produced a static amount of pollution for the duration they sat there.
• Basically, pollution is now produced by cars and factories rather than just being plopped down on the map with them. Pollution dissipates over time, and also stacks if it is produced by multiple overlapping sources. If the production rate is higher than the dissipation rate, it builds up, otherwise, it fades away.

Health, productivity, etc, all work the way they did in version 2, as does the little priority menu. Just so people know, it’s just a quick and dirty system I threw together (though I suppose now is a good time to prototype interface as well). “Build” means “Construct new buildings”, and “Produce” means “Make some more product by working in a factory.” If one is set higher than the other, then they will favor the other when choosing between jobs, with some minor glitches in the AI. It’s not perfect, but the intended effect works – when you put Build on hi priority and Produce on lo priority, people tend to work on construction jobs before going to the factory, which fixes the “factory as labor thief” problem from prototype 1.

At any rate, the main changes to this version are dynamic pollution. I’m thinking it works pretty much the way I intended it to, but I’ll see what you guys think before posting my final analysis, now that we have a decent crew of regular commenters

Here’s it is! Click on the image below to play!

Click here to play Prototype 3!

This does not look healthy

So, what’s clearly going on here is that pollution is DEFINITELY having an effect on our population. Also, it’s easier to tell what’s going on with the little dots in the buildings.  Now, you can’t see it because this is just a screenshot, but our product output has slowed to a crawl. All those green workers (deathly ill) will still work like normal, they just won’t get anything done. This is because they are dragging themselves in to work, coughing up their own lungs as they struggle to stand, and then dragging themselves home.

So, this prototype is mostly successful, in that it solves most of our old problems, but there’s still some issues here, and some brand new problems as well.

More analysis after the break

Just a reminder, here’s our pollution system:

Road and Factory pollution patterns

And pollution DOES stack.

So, here are the basic observations:

• As long as you don’t build a road or a factory next to another factory, people can heal up BOTH while they’re resting at home, AND while they’re at work, because the factory doesn’t produce pollution in its own square. I don’t know why I implemented it this way, because this totally assumes that facilities pollute the countryside and not their own working conditions.
• Building a road right next to a house will make that house polluted, which means a person can not use it to heal up to maximum health.
• Building factories next to each other QUICKLY creates deadly pollution levels
• There is still little incentive to produce roads because of the static pollution they produce.

Also, forgot to mention this in the previous post, but we’ve added a new “priority” control that lets you decide whether your people should focus on “build” tasks (constructing roads, houses, and factories) or “produce” tasks (working at factories). This will later be expanded as more features are added later.

Here’s an example setup:

Experimenting with different transportation setups

The Northern houses use roads to ferry them on to work quickly. However, we have to keep the road one square away from their house to avoid contaminating the house. This results in them having to travel through one square of work ANYWAY. Then, they zip through the road squares and off to work. The time they save traveling quickly is offset by the pollution they experience in the dirt square before the road, as well as the extra distance to the factory.

In this prototype, it makes no sense to build a road that’s not connected to a building directly, because otherwise you still have to travel through dirt squares, and polluted ones at that, if you leave off the first and last road square to a building. It therefore makes no sense to build roads at all, because you might as well just build the factories themselves a square away from the homes that supply their workers, as the Southern city models.

Now, I knew going into this prototype that it was a very unrealistic model (roads have environmental effects such as erosion and lowered rainwater absorption, etc, but they do not produce smog just by sitting there unused), but I was really surprised by the unintended consequences of over-simplifying the model like this.

So, let’s look at the Southern cities. They get to work, heal up while they’re there, and then go home and heal up, too. The only place they suffer pollution is in the one transit tile between home and work, so their net health gain is positive.

Taking a look at the Northern city, they have to transit to work, and since the road is directly connected to the factory, they don’t heal up when at work. Overall, they break even at “good” health but don’t ascend to “great.” Also, they take longer to get to work (they have to travel one dirt tile ANYWAY) and have lower productivity. The Southern city has a much higher output AND higher health.

So there are clearly some problems here. Now might be a good time to start delving deeper into research and getting some numbers for these things. I still want to do more prototypes based on my instincts, but I’m seeing how research is becoming more and more necessary to direct even these simple design questions, now that I can see how an oversimplified model can drastically change results.

Here is what I found to be the ultimate strategy (more or less) for this prototype:

No roads, houses built close to factories, but spaced out.

This is basically just another revision of the “pack ‘em in like chickens” strategy from the first prototype, but all in all it’s not nearly as odious a strategy : build work places close to the houses the workers live in, and keep them far enough away to contaminate work and living conditions.

Of course, seeing as this game is supposed to be about TRANSPORTATION, this prototype doesn’t cut it. It’s still a success in that it answers some questions and tells us where to go next.

My thoughts for the next version:

• Pollution needs to be modeled more accurately. Ie : pollution is caused by ACTIVITY.
• We need to de-abstract people’s movement a little. Why do roads cause pollution? How about, we make people turn into cars when they’re on a highway, and zip to their location really fast. Much faster than now, say something like 4 times as fast as a person walks. (Good enough for now because we aren’t modeling realistic land area usage yet, so even our distances are abstract).
• Cars will pollute while they’re on the road. They won’t produce much individually, but collectively they’ll produce a lot if the same stretch gets congested
• Factories produce pollution only when people are working at them.
• Factory’s pollution radius should be larger than just a square. If pollution levels get high enough, it can have an effect on the whole area, not just a small amount. This also adds to the “stacking” effect of pollution.

Prototype 2 : pollution & health

So, we learned some things from Prototype 1. We’ll reiterate quickly the things we planned to do for this prototype after the jump, followed by a link to the playable Prototype 2.

• Fix the visual clutter
• Implement pollution (hopefully to encourage spreading out buildings)
• Implement health (to provide reward/punishment for pollution)
• Allow destruction of buildings (for now they just instantly disappear for no cost)
• Buildings now have the same movement cost as dirt (to encourage road building)

We decided to start off with a very simplistic modelling of pollution, buildings just produce a fixed amount of pollution around them no matter what. Since we already defined the design for this next prototype in the previous posts’ results, we’ll just go ahead and show off the prototype and then analyze it in the next post. Just a few more notes about some minor differences we made from the last proposed design:

Changed "Dead" to "Deatlhy Ill" for now

• We’re going to use gold for the “Great” condition because green connotes “sick.”
• We’re not going to implement people dying yet, they just go down to sickly green instead, the lowest health.
• At “deadly” health levels, a person has an output of ZERO, but will still work for a full 8 hours, getting nothing done but still occupying work space!

So, we’re ready to go! Off to the prototype:

Click to play this prototype!

Well, my first instinct on playing the game was that the ideal solution would be something like this:

My original strategy

…but, that’s not quite how things turned out Read on to find out more!

So, here are some things I immediately observed:

Good stuff:

1. This is pretty fun! You have little dudes moving around and they do stuff! It’s fun to manage indirectly like this.
2. Transportation does seem to matter! If there’s no roads to anything, it takes people forever to get there. Also, if your factories and houses aren’t built in a good setup, your output and construction rate is really slow because it takes people forever to get to work.

As for the rest of it, we’ll have to do that in paragraph form because it’s too involved to just list them.

Visual Clutter

This prototype is hopelessy visually cluttered. A factory with three people working on it is almost impossible to make out:

When programming this, I as the programmer was mostly interested in what the people were doing – there’s actually a fairly complex algorithm going on in the background as people get summoned by various “employers” (construction jobs or factories), keep track of their hours worked, and their current work state (idle, in transit, working, going home, sleeping, etc). I even made them have little indicators of their state – three dots for idle, a little hammer for working, a “zz” sleep bubble, etc.
But, it seems to me that as a player, I didn’t really care. I just wanted to know what was going on with my buildings and my city. I think a better solution would be to make my people only fully represented when moving around. When they’re actually IN the factory we would just do this:

Because, honestly, if the people are at the factory, we can ASSUME that they are working there. Furthermore, we need to be able to actually see the factory. Three little dots can easily tell me the same information as three people icons standing in front of it with hammers. We can do the same thing with houses:People who are at home are only going to be doing one thing there : “sleeping.” By that we mean, they are at home, resting, relaxing, whatever. This way, you can easily tell at a glance just by looking at the map when people are in transit – just look for people icons! Little dots on houses and factories tells you where everyone is currently residing and/or working, and clears up the visual clutter. Then, we don’t need the little icons telling you a person’s state : if he’s moving away from the factory, we can assume he’s going home, if we even care. Most of those little “status indicators” were useful to me for debugging purposes, but have little in-game value, IMHO.

Some Strategy findings:

1. It is REALLY important to get houses up before factories, because there’s no way to prioritize labor jobs except by distance.  Lesson : make a little priority button that the user can set (Construction vs. Production)
2. Since “product” isn’t used for anything, I found myself mostly motivated to get my economy up and running first and then maximize “product.” This meant that I delayed building factories as long as possible. There’s nothing wrong with this, as there were plenty of construction jobs for people building other people’s houses. We’ll have to see how viable this strategy becomes when zombies come and attack
3. Without anything other than my own impatience as a drawback, there wasn’t any real incentive to maximize transportation. There should probably be some other sort of motivation (like zombies). Eventually, we also need to tie people’s production back into the economy somehow, and find out how we’re going to model resource use so we can build off some of the stuff we had in Energy Apocalypse.

Pack ‘em in

I mentioned earlier what I was expecting the ideal strategy to be : nice little sectors divided up by task, housing over here, industry over here, with transportation linking them together. My friend Sean, who is an expert at breaking games, immediately found the dominant strategy to be something like this instead:

Dominant strategy : pack 'em in like Chickens

In the early prototype coding, I originally had buildings count as very high-cost terrain, forcing people to walk around them instead. This resulted in some really weird pathfinding because they would do everything in their power, even walk way out of their way in the dirt, just to avoid walking across a single building tile. This was especially problematic because the beginning and end point of every path was a building tile. Not thinking, I just made a building tile equal to a road tile in terms of pathfinding cost.

Big Mistake.

You see, doing it this way, and having there be no time pressure, makes it so that there is NO value to building roads, ESPECIALLY given that you can’t destroy anything you’ve built. A road costs a third that of a building, but who cares? Wait three times as long and you get the speed bonus AND a useful building. Add to this that it’s not realistic to be able to move through residential and industrial areas at highway speeds, and I think it’s clear I need to change that part.

Now, with a prototype you’re not trying to make an exploit-proof system. The purpose is to make something that’s quick and rough around the edges, and you can ignore the exploits in a game session and play it the way it was intended to, to see if it works. But you still have to pay attention to those exploits in strategy, because it tells you a lot not only about your core game mechanic, but what needs to come next.

So, fix it so buildings cost the same as dirt or more to move over. Problem solved. But there’s another problem.

Even with that fix, the ideal strategy is still OBVIOUSLY to build at least two houses for every factory (since there are 3 work shifts in a 24 hour day), and then pack them together as closely as possible, so you can have the maximum number of factories staffed for the maximum number of hours per day.  It’s like one of those industrialized chicken farms where the animals are stacked together like bricks.

Obviously this is efficient, but only because a lot of things aren’t being modeled. Since our game is about energy economy and pollution as well as transportation, here’s where the next features to be modeled start to trickle to mind:

1. Pollution. Start by abstractly producing “pollution” in adjacent tiles to factories and roads. Follow this sort of pattern:
   

   Factory Pollution

   And a similar pattern for roads, but less:

   

   Road Pollution

   This is just to test to see if these things producing pollution will encourage players to space things out. Pollution effects will stack, which means that any stretch of road is going to have a value of 2 pollution on each road tile itself, and a 4×4 stack of factories will have 5 pollution each, with a 9×9 stack producing a whopping 12 pollution in the center factory. Note that there is no pollution in the center tile itself, that is determined by whatever is adjacent to it.

2. Health and living conditions. Pollution is not going to matter if it’s just a number. So, we’ll hit the player where it hurts: productivity. Their people currently produce at a rate of 1 man hour per hour. Depending on that person’s health condition, that rate will go up or down. Here’s an idea for what’s coming next:
   

   Pollution affects people's health

3. The color-coding system will be problematic for color blind people, but we’ll change that later and just use this for now. We’ll come up with some function that adjusts people’s health as they move through tiles.It’ll probably be something like this :A person has 24 “health hours” assigned to him, all beginning at a value of 2. To get the health of that person, we sum these up and divide by 24. (24×2 /24 = a beginning pollution rate of 2, in the  “Good” range) Then, every hour, we take the average amount of pollution that player was exposed to.Examples: If you spend 1 hour in a pollution level 3 tile, you get 3 pollution assigned to that hour.  If you spend an hour spread equally in a pollution level 0, pollution level 1, and a pollution level 2 tile, you get 1 pollution assigned to that hour. Whenever you get a new health hour, we bump off the oldest one in the array and add this to the end of the list. So a person’s health gradually changes over time as he’s exposed to increasing levels of pollution, and their productivity falls or rises with it. If their average pollution reaches 7, their health drops to “dead” and they are deleted from the game (or fall down on the spot, creating pollution, and someone needs to carry them away and give them a proper burial, depending on how realistically macabre we want to get).

Obviously, all of this is going to later be subjected to real-world research to make sure that real scientific findings match my intuition, and adjust numbers according to an eventual real-world model instead of this totally made up one.

The whole purpose of this is just to find out if our most basic, basic, approach to the game is on a good foundation. Once we’ve “found the fun” as Shigeru Miyamoto calls it, then I’ll spend a month or so with my nose in a pile of books making sure the game is also a half-decent ecological simulation.

So, we’re halfway to the design of the next prototype. As soon as it’s ready we’ll have another post documenting its conception and execution, followed by another post about its assessment and where to go from there. Feel free to leave your comments and let me know what you think!

We’ll keep doing this until we eventually produce the actual game

Similar to Super Energy Apocalypse, but on a city-wide scale. Now instead of trying to carve out an individual little survivalist base, you’re trying to rebuild civilization proper.

Sneak peek of where this is going:

Read this post to learn more and play this prototype!

Whereas SEA’s focus was mostly on power plants and fuel sources, SEM’s focus will be squarely on Transportation. Our first principles are as such:

1. Game should teach players about TRANSPORTATION
2. Game should teach players about energy economy
3. Game should teach players about pollution sources
4. Emphasis on macro-management, not micro-management
5. Emphasis on strategy, not tactics

With Number 1 being our biggest priority.  So, to start with, I was inspired by Daniel Cook’s quick-and-dirty Post-it note design docs approach.

The gist of it is this: You scribble down your ideas on a Post-it note (this is to force you to keep it short), build it, and see if its fun. There’s only enough room to write a small amount, so you are only going to test one mechanic at a time this way.

So, the first and biggest question on my mind was : how are we going to cover transportation in Metropolis? In Apocalypse we automated all the garbage trucks and engineer vehicles – their AI sucked, but it kept the player from having to babysit the workers in his economy, something that endlessly annoyed me in games like StarCraft.

The first principles of this prototype are a sub-set of the entire project. We are trying to figure out how to accomplish two things:

1. De-emphasize micro-management. The city “runs itself,” with you making big decisions.
2. Model transportation in a way that models real-world problems to the player clearly.

This prototype is only dealing with things on a totally miniscule level with tons of huge hand-wavy abstractions. We don’t care about food, energy, building costs, any of that yet. We’re just trying to model a basic, basic economy and transportation game and see if that is fun, because what we settle on at this stage will be the core of the game. We want to find something fun that says some real things about the way these problems are in real life, and move on from there, adding both fun, as well as more accurate real-world content.

So, adhering to the post-it note idea a bit loosely, I scribbled my thoughts down in big handwriting on a single page of my sketchbook:

Click to see full size version

Since not all of you will be able to read my fabulously legible hand-writing, the goal of the prototype game is to create a workable city which has four elements:

1. Houses
2. Factories
3. Roads
4. People

And then make that thing run really efficiently so as to maximize your output of  “Product.” There’s no victory condition or anything, just play with it and see what happens.

The game has the following rules:

Houses:

1. When a house is built, it is instantly populated by 3 new people
2. People will leave their homes to work, and return to sleep.
3. People will ONLY go back to the house they originally came from.
4. Each house can accommodate 3 units of people.
5. A new house takes 24 man-hours of work to build.

Factories:

1. A factory that has no people in it will call on any nearby people to work there.
2. Factory workers will produce “product” at a rate of 1 product per man-hour of work.
3. A factory can accommodate 3 workers at a time.
4. A new factory takes 24 man-hours of work to build.

Roads:

1. Roads take 8 man-hours of work to build.
2. People travel twice as fast across roads as they do “dirt” (unoccupied space).
3. People travel at the same rate of speed across buildings as they do roads.

People:

1. People begin as “idle” and wait for work to summon them.
2. People path find to their summoned work location, taking the shortest route there.
3. People will seek out work and work for 8 hours. If they finish a job before then, they will continue working until they have worked for a full 8 hours.
4. After working, a person will pathfind home and sleep for 8 hours, then seek work again.

Other Stuff:

1. There is a clock that keeps track of time, it counts up from 00:00 to 23:59 and then resets.
2. There is a “product” count. The ostensible goal of this prototype is to see how quickly you can produce “product.”
3. To build something, the user clicks on a button, then somewhere on the map, and a “ghost” appears. Up to 3 workers move to that location and work until it is finished or until they have finished their daily work quota.

I think better in pictures so you can see why the diagram was easier for me than spelling out all these rules. I came up with most of these rules as a way to implement the above diagram when I set out to program this thing.

I worked on it until the early morning hours one night, and was pleased with the results. Here it is!

Click the image to play!

I’ve already gotten an assessment of the prototype, which I’ll follow up about in the next post.

Edit: Here’s the results!

Le Steve Jobs

Design. Talk about a mystifying word. I don’t know about you, but for years, when someone said “Design” I always thought of an elite group of intellectuals in black turtlenecks, berets, and fake French accents going, “No, I theenk eet needz more red!”

Then, I went to Architecture school and learned how to make video games. I know what you guys are thinking – “What in tarnation could Architecture school possibly have to do with video games?” Well, in detail, not a lot at all. In principle, quite a bit.

You see, those imaginiary faux-French “designers” I just mentioned? They’re the same group of people I used to think of when the term “Architecture,” was mentioned, just in that case they were saying, “No, I theenk eet needz more flyeeng buttrezzes!” The point was, I imagined that “design,” “architecture,” or any other creative enterprise was a mystical, magical art – where you just intuited your way to a final project, kind of like how people who know nothing about cooking imagine that the way to make soup is by randomly throwing things in a pot, turning on the heat, and seeing what happens.

Gumbo : Mmmmm... Cajun!

That all changed when I went to Architecture school and learned a little trick called, “Design by First Principles.”

Design by First Principles is simple, really : all design projects, be they video games, cathedrals, constitutions, etc, all come from the interplay of three things:

1. First Principles (FP’s)
2. Limitations
   
3. Design Decisions (DD’s)

First principles are your goals. But more important than that, they have nothing to do with implementation. If you’re trying to cross the river, your first principle is “get to the other side,” not “swim across.”

Swimming across is one way to accomplish your first principle, but you could also do that by finding a bridge, using a raft, or building a matter teleportation device. All these other things – swimming, using a bridge, etc, are design decisions, ways you go about accomplishing what you’ve set out to do.

And of course, the laws of physics, the fact that humans are not fish, the fact that clothes get heavy and weigh you down when they’re wet, etc, are all limitations.

Believe it or not, “Design” is just problem solving by another name. Once you realize this, design ceases to be hidden magical art and becomes a process you can actually learn and teach. And you don’t even have to pretend to be French! This should come as a great consolation to people who are allergic to black turtlenecks, as well as the French, who are probably sick of being stereotyped by this point.

So, where do we begin? Well, the first question you ask, is you look at the project you’re about to design, and you ask yourself: “What the heck am I even trying to do?”

First Principles in Architectural Design

Let’s start with an architectural example: a Gothic Cathedral. Have you ever wondered why they’re designed the way they are? Well, somewhere in Old Europe, a team of Engineers, Architects, and Clergymen (and I’m sure there was quite a bit of overlap between those positions) sat down and asked themselves, “What are we trying to do?”

Notre Dame Cathedral

They probably came up with a list like this one:

1. Let’s build a really big Church.
   
2. It will be a landmark for our city and attract tourists.
3. It will remind people of the majesty and glory of God.

So that gave them some guiding direction. Next, they had to sit down and look at their fundamental limitations. These are problems that, try as you might, you cannot do anything about. These are things like : budget, time, amount of labor available, etc. For our cathedral-builders, their list of limitations was probably something like this:

1. We’ve only got wood, stone, glass, and iron as basic building materials. (ie, no portland cement, reinforced concrete, modern steel, plastics, etc)
2. Gravity likes to keep things from being tall – it has to not fall down.
3. We’ve only got candles and natural light for lighting. (No lightbulbs, electricity, etc).

Budget wasn’t as big a concern for the Kingdom of France for this project as it is for us on ours, so that didn’t really factor in. Anyways – they wanted to build a Cathedral on a truly monumental scale. To mark the celestial nature of the place, they wanted it to really be brimming with light. Now, before the advent of electric lighting, this was a hard thing to do, construct a huge building and have it not be, you know, dark inside.

So, what’s an architect to do?

“Candles?”

Well, that’s a start, but we’re going to need more than that.

“Let’s put in some windows! Really big windows! Windows all around, stained glass windows!”

Okay, that’s good! But… we’ve got a problem. You see, with our primitive building materials, creating huge windows is going to eat up a lot of our wall support space. Now we’ve got these huge windows, and nothing but tiny little ribbons of masonry trying to hold up an entire Cathedral. We’ve got a serious structural problem here, and we just can’t get around gravity.

“What if the walls didn’t have to carry the load?”

What? What are you talking about?

“Well, you see, what if we just, you know, moved the load? Then the walls could just be filled with windows.”

But where would we move the load? And how?

“Well, like, stick half of an arch on the side. We’ll call it a, I don’t know, a flying buttress or something. We’ll put them all around. It’ll be like having a bunch of really tall guys leaning over and holding the building up so the walls themselves don’t have to.”

Flying Buttresses - Designed by First Principles

And that’s how you design a Gothic cathedral. Those flying buttresses didn’t come out of nowhere, they were a design decision to a problem defined by first principles and fundamental limitations.

First Principles applied to Video Games

So, buildings are fun and all, but we make Video Games. So, let me trot out an example I’m sure you’re all familiar with, and relate it to this specific methodology:

Let’s say my name is Shigeru Miyamoto, and I’m making a game called Donkey Kong. My task right now is to design the main character. Here are my first principles:

1. Make him look like a person.
2. Make him animated.

That’s it. My goals are pretty simple for this project. What about my limitations?

1. He’s got to fit inside 16×16 pixels
2. 16 colors on screen at once (and probably only 4 for our character)
3. Very limited animation

According to Chris Kohler in Power-up: How Japanese Video Games Gave the World an Extra Life, this is how it went down (in my own paraphrase):

Mario : Designed by First Principles

1. We don’t have enough detail to make a recognizable face. Let’s give him a moustache, since that implies both a nose and a mouth really well.
2. We can’t really make convincing hair, so let’s just give him a hat and some sideburns.
3. We can’t make out his arms and legs when they move if they’re the same color or have patterns on them. Let’s give him overalls so his movement is more clear.
4. Simple color scheme – blue can be used as “black” hair, a dot for his eye, as well as undershirt and shoes. Red can be used for the coveralls and the cap, and we can even reuse his flesh tone as a yellow button on his overalls to further sell the concept.

Ta-da. Mario has been born! He was one of the first video game characters that players really related to, in no small part because he didn’t look nearly as generic and faceless as the rest of the supposedly human characters in arcade games at the time.

So, we can see how to take our first principles, work with them to get around our limitations, and achieve our goals. But what happens when your limitations change over time? What happens to design decisions then?

Leaving First Principles behind : a case study

Final Fantasy : A truly legendary game

As a case study, let’s take a game I’m sure you’re all familiar with. It’s called Final Fantasy.

So, once upon a time a down-on-its-luck game company called Squarewas really looking for a hit. So, they decided to try something new. Instead of another action game like they had before, they decided to create a game kind of like the popular Enix hit, Dragon Warrior.

You can read the background in lots of places, like here.

Ironically recognizing that the success of the company sank or swam with this game, it was called Final Fantasy by it’s director, Hironobu Sakaguchi.

It is immediately clear that this game was heavily inspired by Dungeons & Dragons. In the first game, even the magic system was the same as D&D – you learned spells in various “circles” (“levels” in FF), which you could cast a limited number of times before you ran out. On going to an inn and resting, you would regain all your spells again. (In D&D, this was because mages had to spend meditation time every evening “re-memorizing” spells they’d cast during the day).

For the purposes of this discussion, we’re going to focus on the design of Final Fantasy’s combat system.

Although you often see people play D&D with miniature figurines for their characters moving about on a grid, this is a pretty modern phenomenon. It might have been around in the early days, but for the most part, the Dungeon Master would describe a battle (“There are six ogres in front of you!”) and you would issue your character’s commands to him. The whole thing was fairly abstract and required some imagination, but, with the right Dungeon Master, could be a thrilling experience.

It’s my speculation that this is what Hironobu Sakaguch was trying to capture in Final Fantasy.

So, my guess is his first principle was:

1. Find a way to capture the D&D combat experience in a video game

His limitations were many:

1. There is a hard limit on the number of moving sprites the NES can handle at once.
2. There is a limited number of colors on the NES
3. There is a limited amount of screen size on the NES
4. There is no scaling technology on the NES
5. We have a small budget. This could be our last project.

So, what this means, is that you couldn’t do nice big illustrations of monsters roaming around the screen that the player could interact with. If you wanted to do things in real-time, you’d probably have something that looked more like the Legend of Zelda:

In Zelda, you fought with simple, blocky monsters because that's all the detail they could afford.

Here, Link moves around and beats things up with his sword, or his boomerang, or whatever. It’s certainly a classic, but it wasn’t really the same as it is in D&D at all. This is more of an action game.

Perhaps he could just have made the monster bigger and more detailed? Where, there’s a problem there. You see, on the NES the limit is not just on the NUMBER of moving sprites but also the size – because bigger sprites are just made of smaller ones. A big creature the size of 10 smaller ones could hit the limit all by itself. So, if you want big, detailed characters, you could only have maybe one moving around on the screen. And if it’s animated, you have such memory restrictions that you might not get to even have all that many different types of monsters in a game, and Sakaguchi wanted the kind of fully-fleshed out beastiary with hundreds of monsters that we’ve come to expect from Final Fantasy games.

So his team eventually hit upon a solution: abstract the battles.

Final Fantasy's abstract, turn-based battle system

Instead of trying to simulate a battle in real-time, he made a nice digital approximation of D&D (and, of course, borrowed quite a bit from Dragon Warrior, itself inspired by D&D). In this system, you move around the overworld, and occasionally monsters attack you. The game takes you out of the overworld and into a battle mode.

“Hey guys! You’re being attacked! There’s four ogres in front of you.”

“Cool! I want to cast magic missile!” (Or, you know, FIRE 2).

This way, we show the monsters on the left, with nice big illustrations, and the characters on the right. Since both of them are bigger, we can even show a little bit of animation – but not so much that we overwhelm our budget and memory constraints. Final Fantasy went on to be celebrated for having some of the best graphics of not just an RPG, but any kind of game, of its time. By “zooming in” to a Battle System, they overcame the limitations that depicting everything in the overworld came saddled with and achieved their objective.

Fast forward 14 years and 9 sequels to Final Fantasy X.

So here we are, in this lush, fully realtime 3D-rendered environment, not on the NES, but on the PlayStation II. It’s even got voice acting! It looks really slick. And here I am, randomly wandering around in this beautiful environment, there’s nothing around but me and suddenly-

Final Fantsy X's, um, abstract, turn-based battle system

Smash, smash, tinkle, tinkle. The screen “breaks” (along with my sense of immersion) in what’s known as a “battle transition” – and here we are. We’re over on this side, and the monsters are over there, and here’s a menu with the usual variations on “Fight, Magic, Item, Run.”

I’m not 100% sure about Final Fantasy X, but a lot of other contemporary games would even take the player from their specific lush 3D environment into a generic one vaguely representing the terrain to host the battle.

You see, back in Final Fantasy I, the “context” for the battle was an overworld where the character was a centimeter tall and just a blob of color traipsing around a vast map. The best we could do was maybe stick some trees in the background to represent where we were having a battle. But now, we’re already rendering that lush 3D environment! Couldn’t we, you know, just stick some monsters in the forest we’re already in, rather than jump to a generic one?

Secondly, when the monsters are represented by static, non-moving illustrations, and my own characters are just tiny little icons, it’s acceptable that one of them waves his sword to indicate “Bob attacked the Ogre with his sword.” It’s an icon of a hero attacking an icon of an Ogre. But when they’re rendered with textures and lighting, and sitting there breathing heavily, it’s really strange to have them just sit there patiently, waiting for the other guy’s turn to run over, beat him on the head, and then run back to his proper place in line.

I don’t know what the solution to this problem necessarily is. And for the purposes of this design discussion, it isn’t necessary. I just use this example to point out that the limitations have changed. The same first principle, “Re-create the experience I had fighting monsters in D&D with my friends on my living room table” looks a lot different when you can render things in full 3D with animations and scaling and all kinds of other technology. The method used in Final Fantasy X was not designed with Final Fantasy X in mind, it was designed for Final Fantasy and just re-used.

So hopefully this gets you thinking about how to design things. There’s a million different solutions to any design problem, I’m just here to make people aware of a method that’s really worked throughout the ages. It works for buildings, it works for character design, it works for video games, it works for dang near anything. So get out there and make something cool! You can even wear a beret if you want

Night-time in New Texas : Zombies abound!

Some of you might know a bit about the Super Energy Apocalypse story. If not, you can read about it here at Jay Is Games.

My boss, Robert Harriss of the Houston Advanced Research Center, was really happy with SEA and has decided to keep me on for at least one more of these projects. If HARC rides out the economic crisis, I might even have a full-time job. So, Bob (as he insists on being called ), has been talking to me about what our next project will be. This is the first in a series of posts on that train of thought.

First, I assessed how things went with both versions of Super Energy Apocalypse. That’s what we’ll talk about today.

PROS:

1. People liked it! Feedback said it was a lot of fun.
2. People seemed to learn some stuff!The most important lesson we wanted to communicate was that “energy does not just magically come out of a wall socket.”
3. The “attacking zombies” mechanic seemed to work out pretty well, I received a lot of positive feedback about this from not only players but other game designers. Although it has nothing to do with educational material, it serves as a good motivation to learn the core mechanics of the game, which have a lot to do with the game’s message.
4. The baked-in tutorial seemed to work effectively in getting players ramped up on all the game’s features.
5. People seemed to enjoy the story, and I even got a few comments along the lines of “OMG  b3st story 3VAR in a Fl4SH game!!!111!” Which were cool, but probably just because standards tend to be low in the flash games market because of all the amateur games.  When you start competing with the big boys (ArmorGames, CasualCollective, etc), though there’s a whole ‘nother level to live up to.
6. We had DRASTICALLY fewer bugs on SEA:Recycled than on the original.
7. Performance was much, much better. Lag reports were still around, but we went from, “It slows down to the point that I can’t play,” to , “It gets kinda slow sometimes.”
8. Sandbox mode was a huge success, and essential for the game. People loved playing around with this.
9. Got some great feedback on the Theme Song We’ll have our first batch of MP3 sales data in March to see if putting it up on TuneCore has helped us out financially.

CONS:

1. We had mixed results on people grasping the greater nuances of energy economy. The game was supposed to model the “flow” of energy transformations. Ie, players would switch to electric cars while running coal plants, build more coal plants to meet the new energy demand, note that smog was going UP after the switch, and learn a lesson about managing an entire system’s pollutant output  (the whole economy) rather than just one sector (transportation). Some people grasped this, but a lot of people didn’t make these connections.
2. Players absolutely BLAZED through campaign mode, usually in one sitting, and the game lost replay value after that. Also, there was little incentive to play it on harder difficulty modes since the story(the main payoff) was exactly the same.
3. The baked-in tutorial annoyed a lot of people, even though it was useful for getting new players up to speed. The fact that it integrated into the story and basic level progression, as well being part of your cumulative socre, made it fundamentally un-skippable, which was irritating to repeat players.
4. Only about half of the in-game sound events were volume-adjustable because of the slap-dash way sound was implemented, . This annoyed people. Kongregate fans rose up with one voice demanding a “Mute” button. I had no idea this feature was suppoosed to be standard but now I do.
5. Badges based on my statistics never worked right on Kongregate. Not sure if this was my fault or Kong’s, but it’s something that people complained about so it’s noted here.
6. We really needed a whole “challenge mode” with at least 25 different scenarios, for real replay value. People blazed through the 5 included “challenges” fairly quickly. Again, needed more replay value.
7. The whole “upgrade” system really distorted what was going on. People would upgrade a nuclear plant to level 3 and then compare it’s statistics to a level 1 geothermal plant and try to draw conclusions based on that.
8. Ambiguity in my presentation of numbers. No single power plant used in the game really represents a typical real-world facility. What I did instead was use real-world data to calculate ratios of numbers for each plant (Cost to build : Output : Emissions : Etc). I then would multiply all the numbers in the ratio by a constant value to get the results you see in-game. This means that whereas our “Coal Plant” in game might represent, say (not real data, just making stuff up for example’s sake) 2 “typical” Coal Plants, a “Solar Plant” might represent something like 100 of those facilities, and the cost, output, and emissions would reflect that. I really need to come up with a way that takes land use into account so that players can more easily compare different power sources.
9. The game needed more research numbers and data presented as such. I got too zealous in trying teach purely through mechanics. I think the players wanted a little prompting with a little mini-encyclopedia with info about each facility, power, and fuel source.

All in all, not bad for my first “professional” game projet. The project was a success, and we succeeded in getting our most basic message across : Energy doesn’t come from nowhere, it comes from power plants, and you can’t begin to talk about energy economy (especially transportation and fuel economy) without talking the rest of the system into account. There’s a difference between truly “reducing” emissions and just moving them around. Ethanol fuel increases emissions through increased farm use, and electric cars only make sense if your power grid is also low-emissions. (Electric cars running off a coal-powered power grid are really coal powered cars).