Social Dynamics in Travian

Travian is a browser-based MMO. I've mentioned it a few times before. The game is a cross between Risk and SimCity. You construct buildings and improve them, train troops, and go wage war. Players have villages that spawn on the big grid, which ranges from -400 to +400 in both X (east-west) and Y (north-south). There are roughly 20,000 people on each server; right now, there's around 12,000 people that have been active on my server in the past week.

Only one person can win, but that win is really for his alliance. And, since alliances are limited to 60 people, his confederation (which is a group of alliances; there is some in-game support for confeds). After a server runs for about 10 months, an NPC race show up. You (and your alliance) beat them up, get plans for a new building type, then you up that building to level 100 (whereas 20 is the max for most building types).

Out of those 12,000 active players, roughly 120 will be said to win. That's 1%. What are the other 99% doing?

Usually alliances in the game divide up into the quadrants -- to the northeast, southeast, southwest, and northwest of the origin. That's four confederations, one per quadrant. Those confederations might be two or three multi-wing alliances, so generously about 1,500 people are in the running to win. That still leaves over 10,000 people that are actively playing and not likely to win.

And let me qualify that 'likely to win' bit. Prices in the game are exponential -- a level 2 building is 29% more expensive than level 1, level 3 is 29% more expensive still, and so on. A player with all level 20 buildings is 29% more powerful than one with all level 19 buildings, and nearly thirteen times (1278%) more powerful than one with all level 10 buildings. If you're not up there at the top, you have no chance to compete.

The players in alliances outside of the top 4 have 0% chance to win. I haven't chased down who has won each game; I'm don't even know that it's recorded anywhere useful. But once you drop off the top dozen alliances, power drops considerably. Number 20 is 1/3rd the size of #1, number 40 is half of #20, and the 60th alliance is an order of magnitude smaller than the top dog.

So what do you do? Or, what do I do? If I'm not in one of the top few alliances, then I'm just ... having fun? Not winning, that's for sure. So why play? Why do other people play?

Judging from the forums, the two main reasons people play this game are (1) they're stay-at-home moms, or (2) they got beat up a lot when they were kids.

#1 is somewhat related to my previous post about who has time to play games that require you to log in frequently -- kids, college students, and the unemployed. Stay-at-home parents are kinda like the unemployed. And those are the people that play. Kids (and college students) are still coming to grips with being beaten up a lot; Travian is a great outlet. Someone pisses you off? Destroy their village and everything they've spent months working on! Hah!

It's a war game, though. Some people lose.

It's funny to see how some people respond to being attacked. A good many don't realize the "war" aspect of the game. And it also seems the developers want to hide that part, too. Not a lot of stay-at-home moms like getting their village destroyed by 12-year-old kids. The solution seems to be "don't tell them that happens," then just hope they don't find out. It's not like every mom gets her village 0-popped. When 12-year-olds gets attacked, whether it's a full-on assault or just a small raid, some of them respond with vitriol characteristic of someone that's just learned some new swear-words and has the freedom to act outside of parental control. More mature

What should someone in this game do when they are attacked? I think a better question is: should you be attacking your neighbors?

There are two reasons to attack another play - (1) to steal some of their resources, called "raiding" in the game, and (2) to destroy some of their buildings and/or kill off their troops. In the late-game, when alliances are competing to finish a world wonder, slowing down your competition is as important as building your own wonder faster. Before that, though, the primary reason to send troops at another player is to steal their resources. A corollary here is to prevent other players from stealing resources, so you attack them to kill off their troops and their ability to train troops.

Stealing resources is a plentiful source of resources. You can easily double your hourly production, and (if you focus heavily on troop-building) gain considerably more from raiding than from you produce through your crops. A maxed-out village will produce over 5000 resources an hour, but can support a couple thousand troops -- which themselves can produce 10,000 resources an hour. Some villages can support 5000 troops, and if that type of village is your capital, it can support up to 180,000 troops. Raiding is big business.

But let's look at this at a meta-level. Either you steal resources from someone else, or they use them themselves. If they use their own resources, they can upgrade their own buildings. The game is fairly balanced, such that each upgrade provides roughly the same return. There's a slight negative bias, such that upgrading a low-level resource gives a bigger ROI than a higher-level resources. Hence, "the universe" produces more resources if you let a low-level farm improve himself. Raiding transfers wealth from an efficient producer to an inefficient producer.

But, because of attacks and raids that prevent a player from building anything, a great many people stop playing. Inactive players are a great source of resources -- they aren't using it. And that's a legitimate reason to farm them; a low-level but inactive user is wasting resources. Anything he produces over his warehouse's ability to store it is just thrown away.

So why 0-pop someone? It removes a source of resources from the game.

Thinking about all this suggests, to me, that the strongest way for an alliance to win is to have a bunch of active players building a bunch of villages, raiding inactive players, and suppressing their foes. Raiding active players, if they're not competing with you for resources, seems to be pointless. And if they are competing with you, then allying with them is a better use of resources than throwing away troops on attacking them.

So why not ally with everyone in your quadrant? That seems like the strongest way for your quadrant to win.

And now we get to "your quadrant." Do you really care who wins? Isn't choosing to root on your quadrant just tribalism? "My quadrant is better than your quadrant!" The other 2,999 active players in your quadrant aren't your friends and relatives. They're a bunch of strangers, half of them 12-year-olds (at least in mind).

So let's come back to why to play this game. If you're competent and active, being big enough to get into one of the confederacies-that-has-a-chance-of-winning isn't difficult. If you're not the sort of person that tortures small animals and snaps at anyone that talks to you, you shouldn't have difficulty getting into those alliances. A little bit of diplomacy and a little bit of activity and presto you're in.

So if you've read this far, you, too, have a shot of winning a Travian game. But why play Travian?

Why play any game? Because it's fun, for a chance to socialize, to build up a cool little city, to compete against other players at a game with well-defined rules, for a chance to take out your aggressions on small forest creatures^H^H^H on other players.

But why attack other active players? Isn't that just griefing? I'll explore griefing in a future post.

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.