Bit Haxorz

You can change code like:

if (accumulator >= test)
{
accumulator -= test;
x += stepx;
}

into

int subtract = accumulator - test;
int hibit = 1 - (subtract >> 31) & 1;
accumulator -= test * hibit;
x += stepx * hibit;

Magic! No conditionals! You might use something like this if you're working on a REAL inner-loop, such as code that'll run on a GPU or likewise run many times on a mobile or handheld CPU.

Efficient Ellipse Drawing - Part 1

This is the first in a multi-part series on drawing ellipses, pixel by pixel. Part 1 (this part) covers the basics of shape rendering, using lines as an example. Part 2 covers drawing circles. Following parts will cover ellipses.

My thesis is that any programmer can learn the math and tricks to write shape-drawing code. That's the point of this series -- to show you how to write your own code. If you just want code to copy-n-paste, go to the bottom of this post.

WARNING: Blogger.com likes to eat my code. I've reviewed this a few times, but there's no promise that it hasn't suddenly gotten hungry again. If something looks screwy, drop a comment and I'll take a look.

Background

I needed to implement efficient ellipse-drawing code in the tile editor I'm making, and I searched the net for some sample code but was thwarted. I vaguely remembered the algorithm, but I knew there was some math involved and some tricky stuff to make it fast, so I wanted to get it right. I looked at some sample code, converted it, but it didn't work. I wound up having to re-derive the equations by hand.

Part of the problem is a general problem with all sample code -- you have a specific purpose which may or may not match the sample. In my case, I was working in C# and had to clip the ellipse to the small tile. Plus little stuff, like how you specify the ellipse. A corner-to-corner definition (a bounding rect) can define an ellipse whose center is a pixel, the point between four pixels, or possibly even a point on the midpoint of an edge between two pixels. How do you adapt ellipse-drawing code to those situations?

The answer, really, is that you have to understand the algorithm itself. If you just want a library to do it for you, you can do that. In this case, that's not what I needed. I didn't want to spend an hour or two finding, downloading, installing, and integrating some third-party library -- or even just a single function -- to get something that I could do by myself in the same amount of time. What I wound up coding isn't actually an "efficient ellipse-drawing algorithm" -- I used a subfunction to calculate the error value for each pixel, with no strength-reduction accumulation code to make it faster. For what I was doing, that was fast enough, and the extra work to optimize the function wasn't necessary.

Goal

My thesis is this: line and ellipse (and circle) drawing is simple enough to learn.

Once you understand the basics, implementing your own code is straightforward.

Drawing a Line

Let's say you want to draw a line on a bitmap. If it's a straight vertical or horizontal line, the code is simple enough:

for (int x=0; x<length; ++x)
{
PlotPixel( x, y );
}

When you implement this algorithm in your own code, changes are it's gonna change to something like this:

int data = bitmap->GetDataPointer();
int offset = x + y * bitmap->GetRowStride();
for (int i=0; i<length; ++i)
data[offset+i] = pixelColor;

This is an example of what I meant above when I mentioned rolling your own. Most likely, any time you take an algorithm like this, you're going to change it enough that it won't look like the sample code you're using as a reference. That's why it's important to understand the algorithm. Straight lines are pretty simple, and you might not see much point here, but ellipses are much more complex.

Let's say you want to draw a diagonal line. That's also pretty easy.

for (int x=0; x<length; ++x)
PlotPixel( x, x );

That's kinda cheating, tho. When you adapt that bit of sample code, more likely you'll do something like this:

for (int i=0; i<length; ++i)
{
x = x1 + i;
y = y1 + i;
PlotPixel( x, y );
}

But that just draws a diagonal line. What if you want to draw a horizontal line, or a vertical one, or a diagonal that's at an angle other than 45º? Usually, you have a routine like "draw a line between these two points," and you have no idea where those two points are relative to each other. The complications pile up.

Let me start with changing that function to one that will draw a 45º line in any direction, including vertical and horizontal lines. Say that x2 and x1 are forty pixels apart. I'm going to draw forty pixels; one at each X coordinate. This means I start at X1, draw a pixel, move one pixel to the right, and repeat. This code handles going left or right with a loop:
for (x = x1; x!=x2; x+=inc)
The trick there is that 'inc' variable. If x2 is to the right (greater than) x1, then the increment is positive (+1). If x2 is to the left (less than) x1, then the increment is negative. I actually do the same thing with y.

Another option is to check to see if x2 is to the right of x1; if it's not, then swap the two points.

Anyway, this function will draw a line between two points, either flat (horizontal or vertical) or at a 45º diagonal.

DrawLine45or90( int x1, int y1, int x2, int y2 )
{
int dx = x2 - x1;
int dy = y2 - y1;
int stepx = (dx < 0) ? -1 : 1;
int stepy = (dy < 0) ? -1 : 1;
int len = dx * stepx;
if (dx==0)
{
stepx = 0;
len = dy * stepy;
}
else if (dy==0)
stepy = 0;
int x = x1;
int y = y1;
for (int i=0; i<len; +=i)
{
PlotPixel( x, y );
x += stepx;
y += stepy;
}
}

On modern machines, conditional code is expensive. Whether you're working on a PC, a modern console, a mobile device, or writing code for a GPU, if statements should be avoided in inner loops. That's why I do this business with stepx and stepy. Those increments also mean you don't need separate implementations for vertical lines, horizontal lines, and diagonals -- this loop does them all. Once you've got len, stepx, and stepy set up, just let it run.

Next: What if you want to draw a line at a different angle, something other than 0° or 45°? That's really the heart of a line-drawing algorithm -- handling lines between two arbitrary points.

From here on (except for the last sample, which is the final working algo), I'll assume that you're drawing a line where dx is greater than dy, ie a mostly-horizontal line.

Here's a simple implementation:

DrawLine( int x1, int y1, int x2, int y2 )
{
int dx = x2 - x1;
int dy = y2 - y1;
int stepx = (dx<0) ? -1 : 1;
int length = dx * stepx;
int x = x1;
int y = y1;
for (int i=0; i<length; ++i)
{
PlotPixel( x, y );
x += stepx;
y += stepx * (dy / dx);
}
}

This doesn't work, though. If dy is less than dx, then you wind up with a horizontal line (image on the left). If dy is greater than dx, then the line doesn't end at your target point -- it climbs at a constant rate and doesn't match what you want (image on the right).





The y value needs to be calculated in the loop:

DrawLine( int x1, int y1, int x2, int y2 )
{
int dx = x2 - x1;
int dy = y2 - y1;
int stepx = (dx<0) ? -1 : 1;
int length = dx * stepx;
int x = x1;
for (int i=0; i<length; ++i)
{
int y = y1 + stepx * (i * dy) / dx;
PlotPixel( x, y );
x += stepx;
}
}

The next trick is to get rid of that division in the inner loop. The way we do that is by conditionally incrementing y. This is why we assume a mostly-horizontal line. Since Y will change by either 0 or 1 each time through the loop, we can always change X but only sometimes change Y. For a finished implementation here, you will probably want two functions -- one for steep (mostly-vertical) lines and a separate function for shallow (mostly-horizontal) lines. The code samples will still be able to handle cases where point one is above, below, to the left, or to the right of point two.

OK, so to get rid of the division, we just keep an accumulator, adding dy every time, and check to see if it's greater than dx. We're going to have to watch the signs, tho.

DrawHorizontalishLine( int x1, int y1, int x2, int y2 )
{
int dx = x2 - x1;
int dy = y2 - y1;
int stepx = (dx<0) ? -1 : 1;
int stepy = (dy<0) ? -1 : 1;
int length = dx * stepx;
int x = x1;
int y = y1;
int yAccumulator = 0;
int yIncrement = dy * stepy;
int yTest = dx * stepx;
for (int i=0; i<length; ++i)
{
PlotPixel( x, y );
x += stepx;
yAccumulator += yIncrement;
if (yAccumulator >= yTest)
{
yAccumulator -= yTest;
y += stepy;
}
}
}

Final Algorithm

DrawLine( int x1, int y1, int x2, int y2 )
{
int dx = x2 - x1;
int dy = y2 - y1;
int stepx = (dx<0) ? -1 : 1;
int stepy = (dy<0) ? -1 : 1;
int lenx = dx * stepx;
int leny = dy * stepy;
int x = x1;
int y = y1;
int accumulator = 0;
if (lenx >= leny)
{
int increment = leny; // note the substitution here
int test = lenx;
for (int i=0; i<lenx; ++i)
{
PlotPixel( x, y );
x += stepx;
accumulator += increment;
if (accumulator >= test)
{
accumulator -= test;
y += stepy;
}
}
}
else
{
int increment = lenx;
int test = leny;
for (int i=0; i<leny; ++i)
{
PlotPixel( x, y );
y += stepy;
accumulator += increment;
if (accumulator >= test)
{
accumulator -= test;
x += stepx;
}
}
}
}

Further Parts

Part 2 - Drawing a circle
Part 3 - pending; circle complications
Part 4 - ellipses

Difficulty Levels in Games

I enjoy a good challenge, but I don't like losing.

Most console games, e.g. platformers, have relatively low death penalities. Whether it's save points or infinite respawns, dying only sets you back a few minutes -- the time to run back to where you were before. Really challenging games might require that you re-run an especially difficult gauntlet -- the biggest setbacks might be ten or twenty minutes.

The Lego games -- Lego Star Wars and Lego Indiana Jones -- are prime examples. "Dying" means you lose some points, but you can get them right back most of the time. The biggest setback in the game is realizing you skipped a level, that you went through a one-way door and now have to replay the entire level to get back to a previous screen. Which is only relevant if you're trying to get all of the secrets/treasures/etc in a level.

I used to enjoy playing the Hardcore difficulty levels on FPS games, but the single-player portion isn't usually a skill challenge; it's more often annoying and time-consuming than challenging. I just want to see the content. After playing a few levels of Doom 3 on the highest difficulty setting, I decided to go back and play on a lower setting, just to breeze through it.

One of the side effects of that choice was that the game was much less scary. When the spooks and scares didn't suggest that I'd actually die, then I didn't need to fear them. It was actually fun, in a horror-movie sort of way, to conflate the fear of getting your progress thwarted conflated with the fear of the demons. Turn the lights on, play during the day, and crank the difficulty level down, and the game loses any emotional impact it might have had. If you like horror movies, you probably know seeing one late at night is the best time. When the house (or movie theater) is quiet, every little creak and groan can make you jump.

But the Lego games aren't about scares. They're about content. You get to play through the movies, which is fun, and you get to spend time looking for hidden secrets. Both are great fun, and neither one is the sort of challenge that can even have setbacks. I remember playing the old Sonic games, and Mario, and whatnot, and in those, death was a threat. But you only died while you learned a mechanic; after a while, death wasn't so much an ever-present threat as it was something to keep you on your toes. Ratchet and Clank, Banjo Kazooie, and Sly Cooper are similar. Dying (at least, dying several times and losing all of your Lifes) could set you back a good bit, maybe fifteen minutes, but you didn't die that true death very often.

As I mentioned in my previous post (about train tycoon games), I've been playing Railroad Tycoon 2 again lately. I bought RRT3 and Railroads! (aka RRT4) at the same time, and I'll go through them again later, but for now I'm playing through this high-rated classic game.

When you screw up in RRT2, you lose the mission. You don't have to win the mission. In fact, you could just Resign your way through the game and see what each of the levels is about. There's no content block -- the entire game is open to you as soon as you buy it. So what's the challenge? Somewhat like a toy, the challenge is up to you. You don't have to get gold medals, but it's the highest reward the game offers. So you've got a few choices -- play all the missions through, win or lose; win all of the missions; or win all of the missions with gold medals.

For me, getting the gold medals was my goal. It was a bit of a pain, because I had to learn how to make money. I played through all of the Canada mission (#6) and lost -- I had nowhere near enough money to win. I wasn't really sure why. I looked around a bit, and from the comments I saw, I realized that I needed to focus more on long-distance hauls, be less focused on getting strictly to each coast (going to Halifax early is a waste of time), and to spend more time supplying and exploiting the industries available. Another change I made in my second run-through was to be more careful where I laid tracks, exploiting terraforming and avoiding congested routes.

A lot of learning is required to do well. Unlike, say, Lego Indiana Jones, I can't just plow my way through an RRT2 mission and win. The game makes it hard to pay attention to elevations, but I can't just ignore them. The game makes it hard to mind consists and stations, but I can't ignore them either.

When I lost the Canada mission the first time, I felt like it was out of my control. I didn't know what I was doing wrong. When you lose a life in a platformer, it's usually pretty obvious what you did wrong -- there's lava there (oops, didn't see it the first time); you have to fight this boss a different way (and a few minutes of trial and error usually shows you how); or you need to time your jumps and swings and whatnot better. There are skills in some of those games, timing related skills, and usually practice is a trivial way to increase your skills.

In RRT2, I found out that it takes six years (about ninety minutes of real time) to send a train from Halifax to Vancouver. Geez! I started a year too late. Figuring out how long it'd take to send a train that far... is not really possible. The best you can do is to spend a half-hour testing and measuring, and that's a horrid waste of time. F that.

Platformers are often safe exploration games. Or, if you have good combat skills in the game, the challenge isn't too onerous. Once you defeat the foes, they stay dead, then you can go explore without hindrance. Other games force you to explore the mechanics -- how do you make money in RRT2? You have to tease the profit equation out of the game.

And here we get to what I ranted about in yesterday's post: the feedback loop for figuring out that equation is slow. Deadly slow. "F this, I quit" sort of slow. Lose the mission enough times and you go hunt down a FAQ. Why bother solving it by yourself? I kept losing the Whistestop Tour mission as my train ran out of sand, and I thought, wtf?! There's only one way to get the gold medal, and it requires (as the game often does) to ignore the help that the game offers. (That Whistlestop mission offers you an upgrade if you get to a town in time, but there's no way to get there -- none of the engines are fast enough to get close enough before you run out of sand.) These are trial-and-error lessons, but the downside is that you have to error a lot, and spend a lot of time doing so, before you move on.

Games should calibrate themselves to players. If a player doesn't have the skill or the knowledge to get a gold medal, platformers give them silver and bronze medals. They say, "thanks for playing, here's your twinkie" and tell you you did a good job and let you move on to the next game, brag to your friends that you finished, and score a few achievement points.

Telling the player "ha-ha! You lose! Now you have to do that all over again!" sucks. And it sucks in builder games where you build this big cool rail empire... then never see it again. You throw it away. As awesome and profitable and elegant as it was, it's gone. Oh, and cuz you lost? Yeah, you're throwing it away with nothing to show for it but some bruises and an admonition to try harder next time.

The skills you gain when playing sports and lose, at least, are something. Throwing away my cool rail empire and the hours I spent building it just to gain skill at beating the remaining levels -- that's not really a skill I want to be proud of. I can't say "I accomplished nothing last night but learning how to beat this game that I'm gonna play for a couple more weeks then never touch again." Who cares? Getting better at shooting baskets, or pitching, or hitting, and saying "well we lost and I sprained my ankle, but I think I learned a lot about the sport" is worthwhile.

Tycoon War : Transport vs Railroad

I've been playing Transport Tycoon and Railroad Tycoon II recently, so here's a post on the differences between them.

Obvious Stuff

Transport Tycoon covers all sorts of transport -- trains, planes, buses, trucks, ships, helicopters. Railroad Tycoon has only trains, but adds in economic 'tycoon' gameplay elements -- your "avatar" has a personal net worth, he can buy stocks and receive dividends. Some of the RRT2 missions focus on that aspect.

And that again is another major difference: TT is a toy, but RRT2 is a game. The first hour of TT gameplay is challenging, especially if you start with buses. Making money with buses and trucks is very difficult. They can pay for themselves, but expanding your empire with just road vehicles is definitely a challenge. But if you start building trains and hauling goods, it's very easy to make cash. Once you get a few coal trains running, money is no longer and object and it turns into a toy.

I like the toy aspect of TT. Once I have all the cash I care to spend, I start building giant, all-encompasing rail networks and elaborate switching and signaling systems. Elegant train networks are Art. But, since it's a toy, and because one needs to switch from diesel and steam trains to electric (rebuilding your entire network), and then later upgrade to maglev, you can't just continue making a more awesomest network. So I build up the network to a certain point then start over. Typically my 'games' last for one session, or a day. The next day I play, I start a new game.

Whereas with RRT2, after a few hours, you finish the mission and move on. You don't have to, but with the enticement of future missions and gold medals to be won, why stay with a finished mission?

Building Routes

First, to be clear, both games work with underlying square-tile engines. Track is built from tile to tile, and can go in eight directions (ie the four cardinal directions plus the 45-degree angles).

To build a route in TT, you have to lay track in straight stretches. Vertical climbs are very obvious; a given tile-to-tile segment will either be level, up one level, or down one level. The entire map might have eight or so distinct levels. Elevation changes are an important aspect of gameplay and I'll cover it in more detail later.

In RRT2, you can lay track tile by tile if you want, but the game provides an automatic track-stretching algorithm: select a start, drag to the end, and the game will figure out how to curve the track between the two points. Nearly every pair of adjacent tiles has an elevation change; elevation changes comes in .1 value increments, with slopes of up to 12.0 (or more).

A side-effect of these decisions is that track-laying is a critical gameplay element in TT, and not a concern in RRT2. You can be picky about how you lay tracks in RRT2, but why? The game generally discourages the player from being critical about the path that his trains take.

In TT, when two trains occupy the same track tile at the same time, they crash and burn. In RRT2, one train stops and the other passes. You can build two-way rails in RRT2, but that just means trains can go in both directions -- one can't overcome another. If you have a steep mountain grade or just a long stretch of track, and trains with varying engines and loads, in TT you can build extra rails. That, again, is part of the play to TT -- build efficient routes. In RRT2, since trains won't crash and building (and controlling) additional lines is difficult to do, you basically ignore the problem.

Efficiency is a big part of TT, and difficult to pay attention to in RRT2. Yet it has a very similar effect in both games, and is a critical component to successful route-building.

Elevation

One of the basic mechanics of both games is the option to choose which engine pulls a given train. Different engines have different speed characteristics -- fuel costs, maintenance costs, acceleration, reliability, and how well they deal with climbing. Even with the best, strongest engines, climbing up a steep slope (in TT, several levels; in RRT2, a slope over 2.0 or 4.0) causes a significant slowdown.

The smart track-builder avoids elevations as much as possible. When the money starts rolling in in TT, I start terraforming like crazy -- digging holes through hills, leveling mountains, in-filling valleys -- just to avoid level-changes. Fast trains means more profit. Both games reward quick delivery, and a train that's not climbing a hill can be delivering more goods, too. When you avoid hills, you win twice -- more profit from what carloads you do deliver, and the opportunity to deliver more carloads.

With TT's focus on track-building and the obvious level changes, it's easy to make efficient routes. It's a big part of the game.

RRT2, though.... It basically hides elevations from the user. Because of the fractional level changes and the isometric display, it's often hard to figure out whether a given stretch of land is level or slightly sloped. When you lay track, the UI will show you the level change from tile to tile, but it's not always obvious whether it's a climb or a descent. The game makes it hard to make efficient routes.

Implicitly, then, you're not supposed to be efficient when playing RRT2. Just build your stations and your trains and move on! This is one of the things that defines getting gold medals from missions vs silver or bronze -- if you pay extra attention to what's going on, turn on the grid, carefully lay your tracks, and even do some landscaping, you can dramatically increase the speed your trains take through some routes.

Stations

Station-placement is a minipuzzle in both games. It's surprisingly similar, because of the shared mechanic -- catchment area. TT stations are relatively cheap (tho maybe that's because I'm used to having more money than I need), and their catchment area is always four tiles from the edges of the station (you can create stations that are longer or have more tracks). RRT2 has three different station sizes, with each bigger and more expensive station having a larger catchment area.

RRT2 has missions and it's difficult to establish a cash cow, so you're always concerned about optimizing station placement. Stations are expensive. You're only going to build one in a town, and there's no options to build longer stations or multiple platforms, so you have to choose a good location. Elevation is a consideration, too, for the tracks coming in to a town's station.

Economy

Ok, so you bought your stations, laid the track, and now you need to figure out where to send trains. Both games have Industries that produce goods; some are strict producers (grain farms, cattle ranches, coal and iron mines), others are intermediates (especially steel), and others produce final goods (such as "food" and "goods"). Plus cities generate mail and passengers.

Trains make money by delivering goods that are in demand. TT cares less about 'demand' -- either a station accepts a type of good (and pays a rate depending on how far the good has travelled) or it doesn't. In RRT2, a station will have a demand rate for goods. In both games, stations pay more for goods that are delivered quickly -- especially passengers and perishable foods. Other goods, such as coal, don't "expire" and therefore the pay rate doesn't depend on how long a train takes to get to its destination. TT has a weird model, where it's very lucrative to haul coal across the entire map, which isn't realistic. It's a game, there's tons of unrealistic things going on, but this aspect of the economy model seems out of place.

Trains & Consists

Consists switch things around: in TT, a given train has the same consist throughout its entire life. You buy the engine, attack coal cars and passenger cars and mail cars, send it off, and (usually) never change what's attached. In RRT2, you can change consist at every station. It's easy to set up a route, with one train, that brings grain from station A to station B, and then carries baked bread (ie, "food" manufactured at a bakery from the grain you delivered) back. Unlike the other mechanics I've mentioned above, it's easier to tweak consists in RRT2.

Yet this fits many of the other gameplay elements in RRT2: you can be picky, but who's picky? Specifically, you can change the consist of a train right before it gets to a station (or even when it's unloading), so that it loads exactly what that station has available at the moment. If you spend a lot of extra time micro-managing the game, exploiting the finer points of the UI, you can dramatically improve your return.

I generally stop doing that micromanagement after a while, because it's a repetetive, mechanical task. It's not even a puzzle. It's almost the sort of thing I'd like to assign an algorithm to. More on that later!

Speed

TT's trains move much faster. Both games have map sizes that are roughly equivalent, and both have game-speed controls (letting game-time move faster or slower), so you'd think it wouldn't matter. But one of the side effects of this is that inefficient routes matter much more in RRT2. Since the missions are time-based ("achieve goal X by 1896"), you can't afford to waste time, and one inefficient route can kill you. It takes as much as six game years to cross a map in RRT2, whereas my slowest routes in TT take about four months, and that's for slow trains going up and down hills from corner to corner. Most of my "long-distance" trains take about three months to get to their destination; the vast majority hit a new station once a month. Since journeys take so freaking long in RRT2, several of the missions are to just make one trip -- say, send two trains from one side of the map to the other.

This effectively adds randomness to RRT2. Did this train make money this year? Did your company stock go up or down? Was the route so long the train ran out of sand and water right before it got to the destination? Did you not build the expensive sand, water, and maintenance sheds at the last station it was at? Doing well means either getting lucky, or building your lines to minimize dependence on all this randomness. You're not managing trains and delivering goods; you're figuring out how to build lines that are short, and get a bunch of trains to hit the stations where you built roundhouses.

The slowness of RRT2 also means that it takes years to see if a given plan works out. Was trying to branch out to enough remote locations to get that steel plant running a good move? Years later, you find out: no. Too late, the deadline for the mission is too close, start over. Or, just skip the mission. Play around a little bit, wait til it tells you you failed, and move on to the next mission. If you do that, RRT2 becomes a toy, too -- if you don't care about the goal, then the goal might as well not exist.

I want to succeed, though. I want to figure out how to build profitable train runs, to turn a small bit of starting capital into a big empire. Which means failing missions, and then playing them over and over until I get the gold medal. Bleh.

The Designer Told Me Not to Worry

I'm moving into meta-issues here; consideration of gameplay elements from a game-design standpoint.

It's easy to focus on the factors that a game makes obvious. When games make stuff obvious, the designer is saying "pay attention to this factor." When factors aren't obvious, when they're hidden, it's difficult to assume that you are supposed to pay attention to it. It's like the game designer is telling you not to worry about it.

TT makes elevation obvious. You see specific elevation changes, and work around them. You deal with whole units. RRT2 works with fractional units, and hides them, too, and on top of that gives you a tool for building rail lines that effectively avoids tweaking elevation changes. You can't see what the elevations are, so how are you supposed to take it into consideration? It tells you how steep the route will be, but so what? Can you really work around that? It's the sort of thing that I wind up just ignoring -- until I realized that I needed to pay attention to it, turned on the grid, and started getting obsessive.

Train Management

I'm just going to consider these two models as train-building games. They both provide more, but I want to look at them as lessons for building a similar train-buliding game. What lessons do they teach?

In both games, you spend money buying stations, laying track, and acquiring engines. Then you
make revenue by sending the trains around. Your score depends on how well you manage your engines, and how efficiently you played the station-placement and track-laying minipuzzles.

So, really, let's start there: your SCORE depends on how well you play those minipuzzles, and then how well you manage the resources you have available -- goods waiting at stations, and the trains you have to transport the goods around. Theoretically, the games should make that easy to do. Yet neither really does.

In TT, it's possible to open up a miniwindow for each train; a small version of the game window proper, showing where the train is in the world. If you open a bunch of these, you can see how your trains are doing. This is really only effective for seeing if the train is lost, or stuck in traffic. Checking out what it is carrying -- a full load or not -- requires opening up a sub-window. There is an All Trains window, and you can even put trains into groups to limit what you're looking at. The window shows profit and loss, and (for some car types) whether the car is full. But so what? This only tells you that a route is unprofitable. To change consist, you need to send the train into a depot -- which means taking the train out of service for a while. And also distracting yourself from doing anything else until the train gets to a station. You could leave the window open, and go build more tracks or something, but when I do that usually the train gets to the depot and I don't notice for a while -- and then I have to remember what I was going to do anyway. RRT2 lets you change consist immediately, tho it will only take effect the next time the train arrives at the station -- ie, cars won't magically appear or disappear while the train is en route.

(Speaking of which, RRT2 does let you replace an engine at any time, magically, wherever and whenever, while TT again requires that you send that train into a station. OpenTTD does have an option to auto-replace engines and road vehicles, though, which is nice. It's annoying to require sending the train to a depot, especially if the depot isn't on the line, so this is a bandaid over a bad feature. A better solution would be allowing the player to replace engines anywhere, anytime.)

In TT, you can also pop up miniwindows for each station, which lists the goods waiting for pickup. But since you can't actively manage consists, your primary option for changing what gets carried is to add more trains. Lots of passengers waiting at that inner-city station? Buy more trains!

RRT2 likewise has a trains-list view, which takes the entire screen and shows six whole trains! Omg! Six! The normal UI (ie not this trains-list window) has a listbox down at the bottom that shows all your trains, and it's a great tool. It shows the consist, whether each one of those cars is full (recall, in RRT2 a car is either empty or fully loaded; no in-between), how far it is to its next stop, the name of that next stop, current speed, status (needs water/sand/repairs), and the value of the cargo that it's carrying. This is great stuff -- this is everything you need to assess whether you've got a good route or not.

Except that it only shows four trains. When you've got a dozen trains running and a bunch of stations to manage, seeing only four trains is a kick in the teeth. And you can only look at trains OR stations, not both. The station info panel is also nice; it shows what goods a given station is supplying (and it what quantity), tho not what the demand level is. Again, the view is limited -- only two stations at a time.

Conclusions

Let's go back to my summary of what these games are about:

Your SCORE depends on how well you play those minipuzzles, and then how well you manage the resources you have available -- goods waiting at stations, and the trains you have to transport the goods around.

There are three minipuzzles in both games: station placement, track layout, and engine/consist choice. For the most part, in both games, once you've done any of these (say, placed one station), you don't go back and change the choice. You might tweak a train route, or change a consist, but you can't spend the entire game doing that. Maybe that's how you consistently win the gold medals, but it seems awfully obsessive to me. Tweaking consists at every train arrival is just dull. Plus, I don't want to drag each mission out into a 12-hour marathon session, because (like I said above) if something doesn't work out, you have to replay the whole mission all over again. Bleh bleh bleh.

The strategic element to both games is similar -- what industries to you chase down? Do you branch out to Northern cities, or stay focussed on reaching the west coast? This is great; it's a big part of transportation-empire building. Good stuff.

I just want better tools.

I want TT to tell me, on, say, hover-over, what's waiting at a station. Missions would be fun, too. Some players put out quiz-like puzzles, saying stuff like: "fix this juncture" or "extend this network to include Town X without interrupting the existing traffic." More of that, plzkthx. Get rid of depots. Make train building easier. Since, for the most part, you build a train once, set its route, then leave it alone forever -- flexible tools for managing that route make no sense. The tools should be optimized for the tasks that you perform often. Don't give me the chance of sending a train into the middle of the lake -- if you want me to choose a station, give me a list of the fucking stations. Srsly. Fix the long-distance gravy train and it could be a fun challenge to build a network encompassing the entire map.

RRT2 should start by getting rid of the tycoon aspect. Other than the missions where it's the specific goal, it's completely ignorable. In fact, you should ignore it, because milking money from the company via dividends makes it much harder to grow the company. I haven't even gotten into how labyrinthine the stock-market aspect is. There's a lot of statistics there, but wtf? Who cares? And graphs beat pages of text any day -- TT and other Chris Sawyer games have all had great charts. Give me those. Give me good train and station overview tools. Give me explicit terraforming tools. Let me see more than four trains or two stations at a time, without hiding everything else.

Sometimes when I'm playing TT I think, "I wish there was more variety in the buildings." That's a great thing for a designer to have players complain about, because it means they're not bitching about everything else. And I have been bitching this whole post, but I still do enjoy the game.

Good Minipuzzle Examples

A couple weeks ago I made a post about minipuzzles, and one thing I left open was how to make good minipuzzles. I'm going to talk about that today, but first I want to summarize what I've said earlier about terminology.

Terminology

Many console and computer games have minigames, like a section within a platformer game where you play a shooter for a few minutes and then go back to normal platformer gameplay. I'm not talking about those.

When I say puzzle I mean what I said about the difference between puzzles and games: they both have goals but puzzles are static whereas games are dynamic, either through randomness or by having an opponent.

Minipuzzles are often not separate activities within their game, and minigames often are. I've mentioned the station-placement and track-layout minigames in train-building sim/tycoon games. Placing a station is a normal part of gameplay. Calling it a minipuzzle calls attention to the fact that there's a subgoal in play -- that you can ignore the rest of the game for a moment and focus on one small puzzle: how does the player place this new game element in order to maximize future score and minimize up-front cost?

Subgoals

That hints at one of the critical factors in good minipuzzles. The station-placement minipuzzle challenges the player to compare up-front cost and future score. The player is making a strategic decision -- should he spend more now to make more later, or are his current funds tight enough that he will just take a cheap solution instead? Is this one particular station important enough to his future plans that he needs to be careful in placement? The conflict between cost-now and revenue-later is a common strategic element.

Making it a good puzzle demands making the decision difficult. If the player can trivially choose the solution to a cost/revenue puzzle, then the decision doesn't add much to gameplay. The question shouldn't be just one of "A or B," as I'm describing it here. The station-placement minipuzzle actually asks the player where to place the station among dozens of possible choices. One placement will capture more big buildings in the town but cost more; another blocks an important road; a third captures a couple big buildings but requires the destruction of another.

Design Your Own

But what about your game? I figure the best way to describe how to add minipuzzles is by example.

I was working on a city-building game recently, and decided I wanted to put some minipuzzle-type ideas into it. City-building was already on a grid, so I had a great start. With a wide range of choices, a player might choose a solution randomly, or based on aesthetics. Limiting the choices gives the player an easier chance to apply a metric to his decisions. I'm reminded of Mark Lepper's research into choice: give people too many choices and they're always unhappy, thinking they didn't choose the best outcome. Like a 401k that offers you hundreds of possible investments, or a an insurance plan with dozens and dozens of options. How can you evaluate them all? You can't, and the result is a nagging feeling that you chose poorly. I've used my buddy Antoine's quote before and it's fitting here, too: "Perfection is achieved, not when there is nothing left to add, but when there is nothing left to remove." Make the puzzle simple and limit the player's choices.

OK, so you've got a grid, or some other mechanism for restricting choice, now what? A friend pointed me to Medieval Conquest recently, and the game CD had a demo for School Tycoon on it, so I played that briefly. At the beginning of the game, it's hard to tell what a good metric is for placement. Buildings go down on a grid, but it's very difficult to tell what makes for good placement. This is the second key: give the player a visible score. In Transport Tycoon, you can see the size of the catchment area that a station will give you, so you immediately have an idea of how much traffic the station will generate. You also see how much it'll cost you. By giving the player explicit metrics, they are left with the strategy choice of A or B as well as trying to find new arrangements within that limited grid that maximize their chosen balance, too. If School Tycoon had made some placements more expensive (say, by requiring the removal of trees or levelling ground), or included a mechanic that makes some placements more effective and easy to score, then I could have seen a puzzle there. As it is, building placement in that game seems random to me. What makes one placement better than another?

Hiding such factors from new players does add depth to the game -- experienced players will develop a sense for good placement, not just for one building but maybe for a cluster of them. However it removes placement as a minipuzzle. The game seems random to new players, and that means sometimes they'll have an easier time playing the game and other times it'll be harder, and they'll have no idea why. With challenge mismatched, they could be bored or frustrated, or switch from one extreme to the other from play-through to play-through. And then they hate your game, return it, and tell all their friends not to buy it, your publisher will start to hate you, and then your dog will die. :( This whole chain of events could be avoided by giving players an obvious building-placement score up front.

Let me switch genres here. There are elements of World of Warcraft that I consider minipuzzles. Farming mobs can be a puzzle: the goal is to maximize drops while minimizing downtime. The player considers drop rate, their own talents and gear versus that mob (which decides which particular mob they'll have the easiest time farming), and where the mob spawns are. The puzzle is to minimize downtime, either waiting for mob spawns or regenerating health or mana. There's a bit of randomness to this puzzle, so it is a bit game-like, but that's why I mention farming: over thirty minutes or an hour of farming that randomness disappears into noise. The player is left considering, "which of my abilities and in what order do I use them in order to maximize the number of drops that I get per hour?"

Here we have the first two elements: limited choice (the player only has so many spells and targets to choose from) and obvious score (kills per hour, which leads to drops per hour). But there's several subtle points here that makes this such an intriguing puzzle. Some abilities are obviously much better than others; very low-level spells don't pack enough punch to count and some creatures are resistant to certain spells.

But consider DOTs -- damage-over-time spells. They are often expensive to cast and they do a lot of damage, but getting maximum benefit from them means the target should be left alive for the spell to run its course. Throwing it on a creature early in a fight is better than later in a fight, but it's possible that the mob might die too quickly for it to matter anyway. The player might run out of mana after killing a few mobs because he's not making efficient use of mana. Each individual mob dies quickly, but the extra downtime means the player's kills-per-hour number goes down. The player has wound up chasing the wrong goal. At first glance, it's easy to assume that the faster you kill one mob, the faster you kill a hundred, but the addition of downtime complicates the equation. Maybe the best solution is to dot up a bunch of creatures and then run away and let the dots run their course!

This puzzle is interesting because of the interplay of several different game elements. One combat session -- killing one creature -- is the putative goal, but it can't be considered in isolation.

Conclusion

I don't think Chris Sawyer thought of station placement as a minipuzzle when he designed Transport Tycoon. I think the minipuzzle is a natural outgrowth of other design decisions made along the way. The same with World of Warcraft. Farming is a minor part of the game; it's not necessary to play it, and many people skip it completely.

Yet we can still analyze these games, see what was done well, and steal those ideas for our own.

In the next post in this series, I'll cover some minipuzzles that I tweaked in some of my own projects, and consider how I might change other games in order to emphasize the minipuzzles in them.

On Writing

It used to be, when I wrote emails or posts, that I'd spend an hour or more on any decent-sized bit of writing. With this blog, I'm more taking the approach of just spitting out words. The main pages that I go back and give any sort of edit to are those that have somehow garnered hits. My page comparing the strategy and bridge patterns, for example, has been popular, so I went back and cleaned it up.

Usually I start with an idea, something I want to rant about, or a point I want to make. And generally that means starting with an anecdote, the one that prompted the rant in the first place. Or maybe something that gives back-story.

Usually it took me til half-way through the post before I figured out what my point was, and then I'd go back and revise the structure in order to make that point clearly. I reckon that'll happen with this post, too. I just ... rant ... until I figure out a good point to make.

I think the best (short) articles make only one point. My dad likes to write in to newspapers, and he often tries to shove in three or four or more points into every letter. The result is thin -- letters to the editor have to be short, and if you spread that space out then each point is that much weaker. Writing such letters should be an exercise in finding the best, most effective points. Throwing in snide asides also destroys any hope that anyone other than "the choir" would be willing to listen to the rest of your message.

My blog posts have been larger than such short letters, however. They're like medium-length magazine articles -- maybe long magazine articles, given the growing tendency towards shorter articles and more pictures. I'm free to make a few points.

But making one central point is still key. So maybe that's my point here: make one central point.

In what I think have been my best posts, I've gone back and put in a proper introduction and conclusion. I also think it's critical to give an outline at the start of an article. This ties in to what I think is the best way of explaining new concepts: give a broad outline, give some examples, give at least one counter-example (to help set the boundaries of the concept), and summarize at the end. The introduction and the conclusion can almost be the same material.

Public speaking is somewhat related, although there other factors come in to play. For example, I think starting with a suspenseful question or introducing a stirring story at the top of the speech is a great way of generating and keeping interest. Speeches often have captive audiences. With the written word, your audience can glean information much faster but can also leave as soon as they get bored. So should written articles be even punchier? Meh. I don't mind if people don't read my blog. I figure, if you want the information, you'll read it anyway.

Which is a crutch. I guess I shouldn't do that. That makes me want to sit and restructure this post -- but I've decided to take the approach here of not editing and using this post as a comparison point for my personal edification. I have a feeling I'll come back to this post in a month and revise it.

Until then, revel in the spaghetti.

Oh, yeah, another point I wanted to make: people that make forum posts that are filled with bad grammar, spelling mistakes, txtmsg abbv, and a lack of capitalization or punctuation are posts that I ignore. If they can't be bothered to spend a few minutes not speaking like an 8-year old, then I'm not going to spent more time than that trying to decipher their meaning.

I remember reading someone with ADD that said that they tended to make titles and subject lines that had nothing to do with the post within, knew that this confused people, and even acknowledged that he had this problem -- but decided to blame it on ADD, instead of deciding to fix it. What an ass. Knowing that you're doing something wrong, stupid, wasteful, inefficient, whatever -- that's 90% of solving the problem. If you know you have a problem but then intentionally, consciously refuse to fix it -- that makes you a bad person. Even Hitler wasn't that evil.

And with Godwin's law invoked, I'm off. See you next week.

College Degrees and the Game Industry

http://game-engineering.blogspot.com/2008/08/difference-between-pros-and-amateurs.html

Do you need a college degree to get into the games industry?

No. But...

Is it helpful? Hmm. It might be helpful but definitely not required. I know a number of good programmers that don't have college degrees -- one is a programmer in the financial industry. Most dropped out, one left after a clerical error meant he had to take a year off. He spent that year working at a studio headed by one of the most-recognized names in game design.

Do you really want to work in the games industry anyway? It means long hours, with no creative input, and no job stability -- in exchange for working on games. Work is still work; you still have to show up every day and put in hours debugging someone else's code and working with poorly documented 3rd-party libraries.

I've left the games industry to be an indie developer, in my spare time. I have a day job in the normal tech industry, which pays much better, has more job stability, and requires fewer hours. No all-nighters, no all-weekenders, no six months of crunch time.

Greg Costikyan's article Death to the Games Industry brings up some important points about the iniquities in the industry -- as he does also on his blog. Hmm, in fact, his GDC rant is described as "on the iniquities of the game industry".

In short, the business of the games industry is set up so that the vast majority of the profit goes to publishers and company owners, and a vanishingly small amount goes to the line programmers, artists, designers, musicians, and writers. You'll never get rich by joining the game industry proper, nor are you likely to achieve much in the way of critical acclaim. The one-man shops from a decade or two ago have gone on to become famous studio heads, but except for the indie and mobile markets one person can't build a game by themselves. Even then you really want to contract out bits like art.

Getting into the industry requires either real job experience (doing something other than java crap for some defunct web startup) or an awesome portfolio. I recommend getting both. Get a non-games job in your field of interest and work on indie projects on the side. Indie distribution is growing, so it's becoming easier for someone to carve out a profitable and self-sustaining niche.

And that brings me to my point: get a college degree not because it will help you get your first job in the games industry, but because you probably don't want to spend your life as a nameless cog at a faceless international entertainment conglomerate. Maybe you'll do games for a few years and then want out. Or maybe you want to pursue this indie, spare-time route. If you're young and have free time that you'd otherwise give (for free) to a game company, spend it on your own pet project. You'll own it, it'll be a great resume addition when you do decide to move into the games industry, and hopefully the industry will grow to support indie games.

If you really do want to get a job in the games industry, then definitely prepare a serious demo. I talked about the big difference between pros and amateurs in a previous post; if you act like a pro when you're not yet in the industry, your application will be much more impressive.

College is not for preparing yourself to work in industry. Computer science is something academics and researchers do; programmers are more like engineers or craftsmen, not scientists. Go to college for the beer, being well-rounded, joining a fraternity, and meeting babes. For all that, it's definitely worth it.

Mental Economy - Communicating with Programmers Part I

Good programming style is more a matter of communicating well with other programmers than capturing an algorithm elegantly. Sometimes that other programmer is you, in six hours or six years. Being a good programmer starts with good problem-solving skills and a broad knowledge of both algorithms and APIs. Good employees are disciplined and self-starting. Beyond that, on almost any scale of project, is writing code that can be easily understood.

There are a few aspects of inter-programmer communication that I want to cover. The first is mental economy -- how much data your brain can work with at one point. Part two is about jargon, and in the third part of this series I'll cover grammar.

I was working on ellipse-drawing code the other day and, while mired deep in the math, realized that I didn't have a lot of bandwidth to deal with other bits of the code. I've talked to (and, unfortunately, worked with) a number of programmers that think they're great if they can solve really complex problems and fix deep bugs in spaghetti code. I think it's worse having a manager that thinks the mark of a good programmer is fixing deep bugs in spaghetti code.

The problem with spaghetti code is that you spend all your mental powers unraveling the spaghetti, rather than solving the problem. Part of the problem with the ellipse code I was working with was that the paper I was reading from had bugs. So, not only did I have to read and understand what the code was doing, I had to reverse-engineer the algorithm they were using. They had comments like "it's faster to do it this way", without explaining why, or even what the 'stupid' way was.

I liken the brain to a CPU. An x86 CPU, to be specific, according to its architectural definition rather than its actual implementation, which is even worse. Details aside, it only has about 7 (plus or minus two) registers to play with. Having to deal with chasing down the meaning of a new or unknown or poorly-explained piece of data means saving some state off to long-term storage (e.g. a piece of paper), exploring a bit, and then reconstructing where you were before.

That's the point of variable names, subroutines, and classes. It's not to elegantly capture behavior; the purpose of "elegantly capturing behavior" is a means to the ends -- the end of minimizing the subroutines that you'll subject your brain to when you try to parse code.

You can either be born brilliant, or trained. About half of the great programmers I know have learned to be brilliant. They're rational, methodical, skeptical, and mentally disciplined. Writing code that is well-organized makes it easier to read code, and that makes that code easier to extend, modify, and debug. They "work smarter, not harder." They don't have to waste brain power untangling spaghetti, or mentally keeping track of dozens of variables and routines and equations.

If you haven't read that George Miller paper (the "plus or minus two" link above), I highly recommend it.

The Difference Between Pros and Amateurs

I always thought I was a good programmer because, you know, Dunning-Kruger. When I got my first programming job we were using a language of which I only had academic knowledge, and I knew I was out of my depth. I spent many weekends reading and studying and trying stuff out on my own in order to get up to speed and learn everything I could about this "Object Oriented" stuff.

A few years later, I got into the games industry. At the time, I had been following John Carmack's .plan updates, reading books and forums, and trying out computer graphics stuff at home. I had demos and knowledge, but even then, I knew that I was "the new kid" in a company filled with industry amateurs. Whatever I already knew about C++ and assembly and computer graphics, I was working with people that had already been in the games industry for years.

Same thing when I got into C# and Web Services, and then with ASP.NET, etc etc.

The difference between pros and amateurs is that pros do it 40 hours a week.

When I was in the games industry proper, I was typically involved in the interviewing process. Many of the candidates that I spoke to had no prior industry experience, but had taken some classes at school, or done some stuff on the side.

The difference between a year working for a game company and a year taking a class is astronomical. A class is three hours a week of instruction, and maybe that again on a project or homework -- and that's just to learn the basics. And you get the summer off, and a few weeks for Winter break, and so on. A year working for a game company is 60 hours a week working on games -- whether that's art or code or design. Plus whatever books you read on the side (for me, easily more than I ever spent reading textbooks in school). Plus the side projects you work on when you're home. Plus meals and recreation time with other industry insiders.

If you want to get into the games industry, don't read blogs for hours every night and think you're learning. The agile manifesto applies here as well: you learn more by doing than by thinking. Thinking through stuff is great, researching is fine, but there's no substitute for getting your hands dirty.

I remember Dave Sim (of Cerebus fame) saying something along the lines of "every artist has 3000 bad pages in him before he'll draw any good pages." Pretty much everything is like that. Sure, you play Guitar Hero on the weekends, but are you a guitarist? Hah, no-one really thinks that. It takes a couple years of practice before anyone would be willing to pay to hear you play. Art is the same way -- remember those art geeks back in high school? Some of them were pretty good. Not, like, professional good, but pretty damn good for high school students. It takes a lot of effort to get good at something. Games are, of course, the same as everything else!

I'm working on a few WinForms apps on the side, and building them has taught me far better than books. Books are great; they're a leg up. They point you in the right direction. But when you need to do something, having experience under your belt is a much better resource than a book. Some books are better than others in this regard. The Wrox ASP.NET 2.0 Problem - Design - Solution book is great, because you do something useful by following the examples. Reading it is ok, but actually building the samples yourself is much better.

And again, compare that you building your own app. Consider what the professional developer is doing -- he has to get something working. He's on a deadline. He's got a boss looking over his shoulder. He's got a client to impress. He's spending forty hours a week getting his hands dirty.

Are you?

If you want to get into the games industry, then take it seriously. Make it your hobby. Build games, code tools, craft models, paint textures, construct levels. And not just on the weekends, and not after spending the day surfing the web, doing "research."

Quitting - Online Game Addiction

I'm addicted to Travian. I know it's a bad addiction. Yet knowing that, I still don't quit. I write that line and think, "is it really a bad addiction?" Why is it bad? If I could convince myself it's a bad thing, I'd have a much easier time quitting.

I want to do something else with my time, but I also want to preserve my investment in the game. I want to keep growing. I'm close to several big, short-term goals in the game, and I want to keep going until I get there. I don't throw away perfectly good clothes, or a working LCD monitor, or books, or even old computer games that I've already played. It's weird with a game, because what's there has value -- but only to me (but see below), and only in that game world. It's not like I could put this account up for sale on craigslist. It's like sentimental value in that regard, like a useless trinket purchased as a souvenir of a fun time that I once had.

I quit World of Warcraft three times. The first time was because guild drama made playing frustrating. The second time was because I wanted my life back. The third time I quit, it was because I lost interest in spending the time in the world and I found something else that I wanted to do more. I'm ok with playing games. It's like watching movies, or TV shows, or whatnot.

The thing about online-game addiction is that you can't really "sleep on it." I think it's best to quit cold turkey -- to announce to everyone that you quit and get on with your life. Often there's sufficient value in the game that you might want to preserve your progress, to sell your characters off or give them to friends. (No sense in all that value going to waste.)

That value is why I don't want to leave. I have a level of progress that others might envy. (Obviously a great many players wouldn't envy what I have, because they already have more. The same is true with level 70 WoW characters, for example. My point is that there are people, and a good number, that would want a shortcut to a high-level character and/or account.)

--

I decided to just take a break and leave the game for a few hours. It worked. I haven't deleted the account, but I don't feel the pull to sit and watch constantly. I don't know if a cold break is better than slowly toning down doses, but if the rest of me (ie my conscious mind) has decided that I don't want to play any more, then I just need to give it time. Eventually my desire to play will go away.

Powerful Players as Incentive

One of the things I mentioned in my previous post is the way that powerful players -- those with high scores, cool gear, and achievements -- serve as role-models to new players.

It is often not, strictly, the players themselves. It's not like they spent their lives getting good at a sport, or a musical instrument. We're talking gamers that spent too much time in a raid dungeon or playing their XBox and so did something that nearly anyone else could do, given enough time. "Role models" isn't the right word; I guess I'm hunting for a better one.

When I was playing WoW, I took a break after about a year of playing, then came back a couple months later. I remember talking to a new level-60 priest and he said I was regarded as one of the best priests on the server. I was definitely one of the best-geared, having played on that server since opening day, but best? How does he know?

I've felt the same way myself, about other accomplished players. And friends. I see someone with high scores, cool gear, etc, and I want to match them. Their accomplishment is a challenge to me, to do better myself, to match (or surpass) their score.

Knowing something is possible is a big part of the incentive to me; it's knowing that I could be even better. It's like, I think I do well and then see a bigger score, and say, "hey, I'm a good player, too, I should have a score that high." I want to have the high score but I'm not as concerned with letting people in my real life that I'm the one with that score; for me the draw is testing myself against a known measurement.

There's a lot of different incentives, really. One of the other incentives for me is closure, which drives collecting. It is an encouragement to get a full set of Tier X equipment in WoW, or to collect all the Pokemon, or have a full set of Magic: The Gathering rare cards from a certain set, etc. Other goals include wanting to be on top; to measure themselves; to crush other players; accolades; or keeping up with siblings or friends. I mentioned jealousy and greed yesterday.

These are all drives that come from seeing other players that have already achieved these goals; I'm not talking about the Achiever/Explorer/Socializer/Killer spectrum here. This isn't really just an achiever thing either -- at least, I don't consider it to be. My point isn't that players want to achieve these things, it's that they see other people that have achieved them and are motivated by that to go do it themselves.

The Lesson here is: make your achievements visible. Give players a chance to show off their
accomplishments. Make sure new players are exposed to the wide variety of power-ups in your game.

And the ways of going about that are plenty: leader boards, flashy gear, XBox Live-style achievements, and providing some way for high-powered and low-powered players to mix.

Mini-Puzzles

I've talked of minigames before, in my previous post about game theory, but when gamers say "minigame" they mean a complete game-within-a-game. Run around in a platformer, take control of a gun emplacement, play Tetris or Breakout or Artillery, break down a wall -- then go back to running around.

The station-placement "minigame" in Transport Tycoon is somewhat gamelike, but the score is ephemeral. There's no win or lose; there's just "better" and "worse", and those measures are fuzzy. I think of it as a puzzle, since there is no opponent, no time limit. There's a goal, and a rough measure of score, and that's it.

What's great about Transport Tycoon is there's a ton of these puzzles in the game. Station placement, track placement, route optimization, and building fast & efficient intersections ("junctions" in the parlance) are all puzzles. And I like puzzles. :) I've got a handful of Hanayama cast puzzles on my desk at work, burrs and other wooden puzzles at home, and I can solve a Rubik's cube. So the game fits me.

One of the main differences between mini-games and mini-puzzles is that the puzzles are integral to gameplay; they are almost meta-games, in that doing such puzzles well achieves a goal beyond what the game sets for you. There's a group of players obsessed with crafting elegant junctions -- both fast and eye-pleasing.

This is definitely the sort of mechanic that makes every game better. Not every player needs to enjoy it; seeing the creations of others is an incentive to try your own hand. These complex junctions are inspiring. As with seeing high-level players in WoW, or the high scores on your favorite XBLA game, knowing it is possible is encouragement to try it yourself. Whether it's jealousy or greed or curiosity or admiration that drives players to achieve the same power doesn't matter. Because your players want to play more.

Would you rather make a game that other designers rate highly, or a game that players love?

My answer is, clearly, the latter. I'm offended--morally offended--by designers that look at games like Myst or The Sims and say "I don't know why people like those games, they're so stupid." That's a topic in itself that I might discuss later but let's gloss over it for now.

Or maybe not. My point of view is not to make games because I want to express myself as a designer -- I want to make something that people will enjoy. Some money would be nice, too.
My goal in this post and in this blog (as it relates to game design) is to figure out how to entertain players.

So back to the topic: I think minigames are 'cheating'. It's easy enough to 'design' a minigame because they are, generally, just executions of known designs. There's some GBA title that I remember being mentioned on Penny-Arcade that's like a billion different 15-second minigames so obviously there's room to stretch. (I feel like I should go look that game up.) Part of the power of the minigame comes from a player's experience with the genre of minigame, however. The power of a minipuzzle by contrast is that it forces the player to make a decision about how he is going to play the game proper.

Take track layout in Transport Tycoon. Building a cheap but speedy rail line around a mountain is no easy task. Yet how that player builds the line affects how his game develops -- if there's enough of a detour to go grab another town easily, if his line will be easy to upgrade, if he needs to buy different engines just to handle this one tricky stretch, etc. And basic stuff like how much he spent on it, and how efficiently the mountain line gets goods to and from each side of the hill.

--

Now, do I have a conclusion? Hmm. The lesson, if any, is "add minipuzzles." The tricky part is how. Sounds like a good future topic, eh? Part II in this series explores several good minipuzzles and examines what makes for a good minipuzzle. Part III, not yet written, will look at ways to add and improve minipuzzles.

Time Sinks and Addiction

Can you be addicted to something that doesn't take much time, money, or energy?

I was thinking about games that pull me in and don't let go. They're addicting because they're demanding. Most games are very demanding; you're either playing or you aren't.

But there's a bunch of games that aren't as demanding -- browser games, play-by-mail games, play-by-email games, the turn-based games that were popular on BBSes back when that was cool, etc. You play once a day, or maybe more, but you're not stuck to the keyboard. I don't think these games are very addictive. You might wait expectantly for the next turn to show up in the mail, and maybe that's a bit addictive, but it's also easy to go a week without playing, or planning, or thinking about the game other than "I hope my turn shows up soon."

Except Travian has been like that for me. You don't need to be at the keyboard all day, but it helps. There are those that play "speed" servers like speed freaks, and have "sitters" (people on the other side of the globe) that play the game with them -- where each one of them plays the game for 12 hours a day.

You can play the game by stopping in once an hour, or every three hours. The game is like compounding interest, though. You collect more resources, which you use to make bigger fields or more combat troops, which then respectively either produce or steal more resources. Which you then re-invest in bigger fields or more combat troops.... The faster you re-invest, the greater the growth. If you delay in turning around those resources, you'll collect a certain percent less -- say, 10%. And just like compounding interest, over the course of a week that 10% turns into 100%. Week on week, it adds up to orders of magnitude.

For me there's this very real, mathematical incentive to re-deploy troops as soon as they come back. Why leave them sitting around when they could be out making money for you?

In some sense the game's a time sink. A more elegant troop-command interface would make sending out raids faster, especially when one is raiding the same targets over and over. A way to queue orders for, say, an entire day would mean you don't need to log in and check so often.

And yet the game isn't like that. I feel compelled to log in, in order to play "efficiently." I'm addicted; I need my quick little fixes, over and over. I keep coming back for more, obsessively pounding the lever and getting my food pellets in tiny doses.

A similar mechanism happens in "full-time" games, ie games where you generally stay logged in / connected / playing for longer sessions. Tetris has levels; Diablo has levels; World of Warcraft has character levels; Half-Life has levels; Guitar Hero has songs and venues and stars; Mario has stars and levels; etc etc. There's always "just one more" task, and it's small.

Sometimes the task is, well, kinda stupid. I'm sitting here thinking about how to spend less time mucking with Travian, because I'm obsessing over it at the moment. I was tempted to just delete the account, about an hour ago, and move on to the next game -- or get back to writing code. That's because there's not a lot of 'game' to Travian. It's a bit like Chess in that regard; the pieces move rather simply, but it's the complexity of human opponents that makes the game so rich. It's not a puzzle, nor a simple strength or skill test; there's a lot of strategy involved in doing well. (Strategy of the planning variety.)

Addictive games give out rewards frequently. When the player expects some new trinket in a short while, they'll keep playing, and then stay, expecting the next trinket. There's easily more complexity to add here -- such as adding high-level or bigger rewards every so often. And tons of other stuff. But the basic notion -- small rewards at frequent intervals -- is the heart of addiction. All the better if the game demands constant attention and rewards that attention.

Ownership, Aggregation, and Composition

Object Oriented Programming has a lot of associated jargon. You don't need to know the jargon to be a good architect, but understanding the concepts is important.

Short Form: composition is when class A owns an instance of class B; aggregation is when class A contains a pointer to class B (ie as a member variable), but doesn't own it. (Ownership implies that when the owner is destroyed, it will delete its ownees.)

Problem

There's lots of other sites that explain these things. Do they do a good job? I don't think so. I think most of them are targeted at either someone that knows nothing about OO, or someone that knows it fairly well but just wants a refresher. Like me. What's the difference between aggregation and composition again? Oh, composition is when you own the object, yeah, ok... If you aren't familiar with these concepts, then go read up on OO. I'm assuming that you've run across them before, and most likely distinguish between these two when you're writing code.

It's the sort of thing that's almost automatic, if you've learned to avoid pitfalls. Ownership is an important concept because of memory leaks. In C++, you've also got to be wary of dangling pointers and double-deletion. Back (in the olden days) when I was writing C++, I was always very careful to mark which class owned a given object.

In complex projects (especially games) you often have a ton of different objects which each have to reference the same thing. Bullets are fired by players, need to be drawn, create visual effects, collide with world geometry, etc. And in order to optimize several subsystems -- graphics and physics being two time-intensive subsystems -- you might have arcane container types. So how do you keep everything in order?

Solution

The answer is explicit ownership. Make it clear, to yourself and to whomever else is using the code. Put it in comments in the code, probably at the variable declaration and also in the header file for the contained class. If you scribble a diagram up on your whiteboard, make sure you're marking ownership clearly. Have only one owner.

Stay away from two owners. Good architectures would be having one clear owner, or having many owners -- like five, or twenty. In the latter case, you'd use reference counting or some other scheme to control deletion, such as using a globally-accessible (ie Singleton) container or manager or cache for those objects.

Sometimes the problem is something like this: bullets belong to players, but are aggregated within some class in the graphics system. But then a player logs out, the player object gets deleted, and now the graphics system has an empty pointer. Do you reference count this object? Do you keep the player object around (even after the player has logged) until all associated objects are deleted? This latter solution is why you often see players still in the game after their connection has died -- it's not so much an issue of the game not noticing the player has disconnected as the code doesn't want to delete the object yet.

Usually the cleanest solutions I've found to these my-two-dads sort of problems comes from thinking laterally. Do something completely different with bullets. Maybe a custom "reference count" used only by those two systems (although I think this is a hacky solution). Maybe bullets aren't owned by players at all, but contain a reference to a player ID allowing whatever system deals with the bullets to back-track to the player without having to worry about the player object still being around.

Jargon

The are two reasons to learn standard OO concepts. One is to help you become a better programmer. The other is so that you can communicate these concepts to other programmers. For any given concept that you learn, it's important to have a tag, a name, a label by which to refer to that concept. Having to say "that thing where you own this object that then has a pointer to a base class" is messy, when you could just say "bridge" -- which also captures a bit of intention, as well as architecture.

Say someone comes up to you and asks you what the difference between Aggregation and Containment is. Do you know? Can you explain it clearly? Probably only if you use those names a lot. I think ownership is an important concept and I use that word a lot in my code -- but I don't say // this object is aggregated or // contained. That would be lame.

I know the difference between the two. I don't think I'd be able to explain which one is which next week. Maybe, because I spent the time to write a post about it -- but that would be why, not because I use those words all the time. I think they're an awkward way to look at a more fundamental issue -- ownership.

Status as a Game Mechanic

Note: I've been using "mechanic" to refer to what the game does "behind the scenes", and using "gameplay" to refer to what the player does with his time. However I'm used to using "game mechanic" and "core mechanic" to refer to what I'm now referring to as gameplay... I think I need to revise my nomenclature. (See my previous post on game design theory for some discussion on these terms.)

Definitions

Players give many reasons for playing games, but do you trust your players? Are they all sufficiently introspective and educated to understand their own motivations? They know if they enjoy something, but I'm talking about why they enjoy it. I'll go into my own theory of fun at some later point, but for now, let me say that one of the reasons that players enjoy games is the status that they can show off for their achievements.

I'm not talking about achievement directly. If happiness is the achievement of value, then a well-adjusted person is happy (and enjoys a game) when he achieves game goals that he values. But that's not status -- status is telling your buddy how you did in the game last night, or riding your new mount through a capital city in Warcraft.

The issue is a bit complicated becomes there's both showing others as well as knowing that you achieved that status item. The braggart doesn't care about getting a status item except to the extent that he can brag about it. The latter is like the guy I mentioned above, someone that has internalized the game goals as his own values and enjoys the status symbol as a record of achievement.

My point is that it doesn't matter why a given player wants a status item -- just that he does want it.

The lesson is obvious: put status items in your game.

Examples

Many games have implicit status items. In RPGs, it's your character's gear. This is one of the great driving forces in WoW: do you have your dungeon 3 set? A flying mount? An epic flyer? Tier 4? Tier 6? Legendaries? Status in MMOs also comes from the group you play with: has your guild cleared Kara, Gruul's, or Black Temple? How far are you through the Plateau? I'm calling these status items implicit because the only obvious score in the game is your level - and is the same for all players at max levels.

In platformers, progress through the game and the accumulation of collectibles and tokens are status indicators. The game tells you what the status items are, and how many you've gathered so far. Yet these items are intrinsic to gameplay; the game is essentially nothing but pushing your status up.

In multiplayer first-person shooters, your status is your standing on the leaderboard. There's not much else to the game other than that score. Single-player shooters might also have a leaderboard that's shared; XBox 360 games typically have a Live component that shows how you measure up against the playerbase. (Level-based shooters have implicit status measured as progress through the game.)

The 360 brings up another way of gaining status: achievement points. I was playing Guitar Hero with a friend last weekend and he was going for a bunch of easy achievement points to push his Gamer Score over the 20,000 mark. We were joking about the arbitrariness of the achievement, even while going for it.

That's the way the brain works

It's the way the brain works -- which is my message here. Even if you know you're shooting for an arbitrary or meaningless goal, you do it anyway. Some people gloat in their shiny new beemer or tier 4 set piece or gamer score, and for them status symbols are clear motivators. The rest of us kinda catch the same disease by association. We might not feel the need to tell everyone about our status, yet we seek it just the same.

It's the score, it's what you're supposed to do.

This ties in a bit with my previous discussions on open worlds. Be careful of removing any sort of status indicator, or your player might think he's stumbled on a toy and wonder what he's supposed to do with it. Obviously we don't want to play or design boring games that people feel stuck playing just because they're chasing some status symbol. However, if your game is good, that status symbol can show them the way.

Don't be afraid of character levels; players like them. Use them to point your players towards the fun stuff you put in the game.