• 1. Ikariam
• 2. WeeWar
• Tangent: The Farming Genre
• 3. Tactics Ogre
• 4. Counter-Strike
• 5. X-Com
• 6. Kongai
• Tangent: Technology Trees
• 7. Warstorm

Verbs

The fundamental difference between games and most other media is interactivity. When I want to understand a game, one step is to list all of the verbs available to the players. For example, the verbs in Super Mario Brothers are:

• Start 1/2 player game
• Walk left/right
• Run left/right
• Duck (when big)
• Jump
• Stomp enemy
• Kick shell
• Break brick
• Open question block
• Go down pipe
• Throw fireball
• Touch Axe

I was thinking of this because I played the browser-based trading card game Warstorm and I was astounded when I realized what the available verbs are on the site (ignoring the account management common to any site with user accounts):

• Edit a deck (“squad”)
• Auction a card
• Trade cards with a player
• Chat
• Challenge an individual player to a duel
• Enter tournament or league (tourney with restricted rule)
• Redeem loyalty points (given for interaction/marketing) for cards
• Buy Challenge Coins (premium currency)
• Play a duel

The first six verbs are common to any trading card game. The last item is the interesting one: play. It looks like I didn’t descend into the same level of detail I did for Mario, but I did.

The player selects which of their decks they’d like to use and the duel proceeds like War. The computer turns up the top card of each deck, applies their effects, and repeats. The only thing the player can do is fast-forward to the end to find out if they won or lost.

I was floored when I realized this, I thought the site was hollow. It’s all about a card game but there’s no game at its heart. It reminded me of gambling in that nearly every verb you invoke involves paying, but unlike gambling there’s no chance you’ll ever get any money back.

I babbled about this to my friends for a few days, trying to make sense of it. Eventually I realized I hadn’t seen where the game was hiding.

Decision Timing

In real-time games (rugby, StarCraft) players are constantly able to take action (maybe with asymmetrical actions, like the separate roles of offense and defense in American football). In turn-based games (Chess, Scrabble, Civilization) players alternate who is allowed to act.

Magic: The Gathering had clever game mechanics that gave players new actions in a preparatory phase called “deckbuilding” prior to playing cards (incidentally inventing a business model). The players make decisions about what actions they want available to them in the matchups.

Warstorm is designed so that all of the actions are up-front, there is no phase of the game besides deckbuilding. It didn’t feel to me like a game because no game mechanic involves direct interaction with the opponent, I didn’t see that I could ever make and change a decision in response to my opponent’s actions (unless we played multiple duels, I suppose). I didn’t even see the game because it was too different from what I was expecting.

But it made me wonder how business concerns drove the game design of Warstorm, a game where there’s little to do besides pay more money.

Business Concerns

When I turned my attention back to Athenge, I saw that my game design implied a lot of business decisions. I like games that require a lot of thought and analysis. I look at the most popular Facebook games and only see pastimes, idle toys requiring action with little thought, minimal direct competition, and even rarer losses. Oh, and tens of millions of players.

Warstorm reminded me that my taste in games is not common. Athenge will be a complex game, lots of instructions and options. It’ll take a lot of time for me, a lone developer, to build. Plus money to buy art, and more resources in marketing to find its non-mainstream audience. There’s risk to anything I choose to build, but Athenge looks to be more risk than it’s worth when I look at the current crop of simple, successful games. I could cut it down more and more, let these business concerns change my game’s design, but I’d rather let them replace my game’s design.

Instead of starting the programming of Athenge now, I’m continuing to improve the successful NearbyGamers and starting on a simpler, much more accessible game I’ve been tinkering with the design of for eighteen months. (Though it’s simple enough that’ll sound ridiculous when you see it, that’s fodder for another blog post). I still plan to build Athenge, but I think it must wait until I’m solidly in the black, until I’m not risking quite so much.

When you’re using one of these markup languages, you’re using HTML anyways. Because they must be translated to HTML to serve as web pages, at best they’re poor translations of HTML. A lot of them are “parsed” with regular expressions, leading to all kinds of interesting bugs with nested tags. MediaWiki (the engine behind Wikipedia) uses two apostrophes for ”bold” and three for ”’italic”’, and then just lets you use HTML for all the cases where these things break. Most markup languages have some passthrough like this to deal with ambiguity or complexity — so while some markups (not BBCode, which is like HTML in brackets) can claim to be easier to start using, users always end up learning HTML in the end.

MediaWiki actually has a decent argument for custom markup in its ability to build templates and fill in particular fields with data. These custom tags aren’t available in HTML, but there’s nothing stopping a site from adding its own tags (which may or may not look much like HTML) that are compiled down to HTML in the exact same fashion.

Some will argue security, that allowing raw HTML would allow people to perform cross-site scripting and other attacks, or include obscene images, or break the page layout, etc. I’m not arguing for letting users use HTML without filtering, it’s absolutely necessary. It’s difficult to protect against the wide variety of attacks, but being difficult doesn’t mean it shouldn’t be done. There are excellent whitelisting libraries available that remove any excuse about rolling one’s own, like Ruby’s Sanitize and PHP’s HTML Purifier.

If you’re building a site, let your users use HTML. A lot will already know it, there are a million free tutorials out there for them to learn it, and after using your site they’ll have a useful skill.

Watching Merlin Mann’s Inbox Zero video and reading the preceeding articles was the impetus for the final push to zero. It’s not that there’s anything I didn’t know in there. But there was the sense that it was not only possible but achievable.

So I immediately did what Mann suggested not to do and spent, oh, a full day changing email clients from mutt to sup. It sounds like an awesome amount of time-wasting, but I read the sup philosophical statement a while ago and it resonated:

The problem with traditional clients like Mutt is that they deal with individual pieces of email. This places a high mental cost on the user for each incoming email, by forcing them to ask: Should I keep this email, or delete it? If I keep it, where should I file it? I’ve spent the last 10 years of my life laboriously hand-filing every email message I received and feeling a mild sense of panic every time an email was both “from Mom” and “about school”.

The flip side of this is that once if you’ve set up automatic filters you have to remember to go check those folders, which is a habit I’ve never been able to form. And once I’ve ignored a folder for two weeks, hell, I’ll leave it another day or two, why hurry to find out if I missed out on something interesting or if I let someone down? Or three days. Or…

And so I’ve poured all of my email into sup’s index and started mercilessly hacking away at that last couple hundred messages I hadn’t yet dealt with. Read and delete, or archive, or note on my to-do list, or suck it up and start another email with “I’m sorry it took so long to get back to you…” And now it’s cleaned out, to my pleasant amazement.

There is, of course, the terrible chance I’ve missed something important, but I couldn’t let that risk of something getting lost in the upheavel continue to paralyze me. Perfect is the enemy of good. If you’ve been waiting on a reply from me about anything and didn’t get it in the last few minutes, I’m sorry, please let me know. And if you’ve thought about contacting me but haven’t because I did so poorly with the last few emails, I’m sorry, I’m going to keep trying to do better.

As thanks, I’m giving away a $40 Amazon Gift Card to one randomly-selected participant. The drawing is open until October 16, 2009 or until 500 responses have been collected.

I’m exploring the design of a potential related product and trying to learn more about people’s experiences with backchannels. I’ll write a follow-up blog post when I have some results to share and determine whether or not I’ll be building a product.

And please, please: if you have a moment, share the link to this blog post with anyone you know who might be interested in taking the survey. I would really appreciate help in getting a lot of responses.

The backstory for Firefly is pretty simple, China and America expanded into space and were the dominant cultures as the resources of Earth were exhausted. Humanity left for a new solar system to make its home and along the way the two cultures fused into the amalgam depicted in the show.

Why, though, does it depict a culture with Chinese style, language, and art without any Chinese people? Is it cultural appropriation? Outright racism? The vagaries of casting?

No, no, of course not. In the proudest tradition of fanwanking, I’ve discovered an entirely in-universe explanation. There are dark hints of the answer to this question.

In the episode Shindig, River (who knows government secrets she’s not supposed to) has a minor freakout and tears the labels off some cans of food. Book helps settle things down, saying “She didn’t harm much. We’ll have a few mystery meals.”

But what a dark expression for such an innocuous comment.

In the pilot, May lays out the ship’s amenities and says they offer “protein in all the colors of the rainbow”. So the fare must be pretty bland, Book soon says “The important thing is the spices. A man can live on packaged food from here ’til Judgment Day if he’s got enough Rosemary.”

Later in the show it becomes clear that Book isn’t all he seems to be — he has a government ID card that gets him prompt service from otherwise hostile bureaucrats and a bounty hunter claims he’s not really a priest.

The character Jayne, though, is exactly what he seems. Big, dumb, strong, tough, and heavily armed. Mostly dumb. He has a hard time keeping up in conversations.

And yet Jayne speaks and understands Chinese fluently, never even a pause when he or another character switch languages. Does this guy look like he spends his evenings curled up with a language workbook?

No, clearly he’s learned by osmosis, and it’s not cultural osmosis. Let’s put the pieces together.

Government secrets, dark mutterings from someone who’s not who he claims to be, multilingual morons. And endless cans of protein.

Yes, it’s what you’re thinking. The Americans and Chinese may have left Earth together, but the Chinese never arrived. The Americans turned on them and, using the technology behind Spam and other abominations, manufactured canned protein from their companions.

This cannibalism is the darkest government secret, the reason River lost her mind and tries futilely to destroy food while a hidden government agent downplays the outburst.

The Firefly movie, Serenity, revolves around River’s knowledge of an atrocity the government has kept secret for years or decades. Maybe River uncovering shocking secrets was going to be a recurring element of the series. With the show canceled, we’ll never know. But at least now we know why there are no Chinese people on the show.

There are two basic strategies for keeping a changing URL pointing to the same content. Either only part of the URL changes and you look things up by the stable piece (as with the slugs in my previous blog post) or you keep track of old identifiers with pointers to their current identifiers.

On NearbyGamers, tags are used to identify what games players are open to playing. But there are a huge number of variations: the game Dungeons and Dragons might be listed as D&D, DND, D&D 4, D&D 4th ed., or many more (and that’s before spelling errors).

To deal with this, I borrowed a mechanism from Wikipedia. Users can edit a tag to redirect it to another (which may not have a redirect set to a third, to prevent all sorts of annoying problems). In short, the Tag object might just be used for its column pointing to another Tag.

This is functionally equivalent to having a table of redirects. When a request comes in for a particular Tag, I could check a TagRedirect table to see if that tag appears in the from column and redirect the visitor to the Tag named by the to column.

Redirects are one of the ways your app will have to scale to meet users’ activity. Thinking about redirects as an explicit table makes it clear you have options for how to deal with it: you could add a date column and expire old entries, or limit the number of redirects one user is allowed to make (perhaps over time), or limit the number of redirects one entity allows. You could even replace this database table with a distributed key/value store like memcached (or preferably something more permanent).

So allowing users to edit URLs leads to one of three things: either you don’t allow them to edit the real identifier, you maintain a table of redirects, or you accept broken links.

NearbyGamers also uses the third strategy: if a gamer changes their handle, the URL is updated without any kind of redirecting. I considered redirects, but then no one could ever relinquish a handle.

URL design is not easy. Allowing users to influence what a URL will be is often really valuable but adds to the difficulty of designing your URLs. This is one of the interesting bits of computer programming where there isn’t a single answer, you have to pick your tradeoffs to match your needs.

Except for the few shots on the Metro, I recognize pretty much every single shot as within walking distance of my home… though he left out the Starbucks across the street from me.

In related news, I’ll be moving back to Chicago on August 1st.

I disliked JavaScript until I read some of Douglas Crockford’s articles arguing that it is the world’s most misunderstood programming language. I pieced together a vision of a nice language burdened by misfeatures and poor implementations. In JavaScript: The Good Parts, Crockford fully realizes that vision in a dense, enjoyable book.

If you find yourself writing in JavaScript and not enjoying it, you need to stop and read this book. (Or even if you’ve just wondered why Steve Yegge obliquely goes on about it.) The book feels a bit like Kernighan and Ritchie in that it tersely defines the language and lets the reader work through the implications. I especially appreciate that Crockford assumes a competent reader and rewards patient and thoughtful reading rather than bulking up on exposition and screenshots. It’s very uncommon in modern writing.

The book opens by defining the syntax of JavaScript with a series of railroad diagrams that are far more enjoyable and readable than BNF:

Next it defines objects and functions and derives useful patterns for working in JavaScript. The Module pattern he gives on p41 “…can eliminate the use of global variables. It promotes information hiding and other good design practices.” It’s a nice piece of code to deal with a personal pet peeve.

After the sections on recursion, scope, closures, currying, and memoization I was surprised not to see a section on the Y combinator, which allows creating recursive anonymous functions. There’s a blog post with a nice derivation, but it seems oddly absent from the book.

More glaringly missing, though, is code to copy JavaScript objects and arrays. On p22 he writes “Objects are passed around by reference. They are never copied.” and a code comment on p64 explains how some code avoids a related bug, but Crockford never talks about how to create shallow or deep copies of objects and arrays. It is flatly bizarre to see the topic raised and warned about without any giving a solution to an interesting and common JavaScript problem. (I personally use jQuery.extend.)

After dealing with objects and functions, Crockford combines them to talk about JavaScript’s unusual prototypical inheritance, then moves on to a nice explanation of working with arrays and regexps. After talking about the standard library and giving style notes, there are a couple nice appendicies explaining what he left out and why and presenting JSLint for automated detection of common pitfalls.

There are a few odd notes like an imprecation against continue (indeed, none of his code tries to “fail fast”) that feels like it must be based on old scars inflicted by manual memory management in C/C++. The only really puzzling oddity was in the chapter surveying the standard types. He gives JavaScript reimplementations of Array’s pop, push, shift, splice, and unshift methods (but not concat, join, reverse, slice, or sort) for no discernable reason other than a mention on p98 that he’d wanted to write a self-parser in JavaScript for a chapter he contributed to another book.

I don’t think too much about these few oddities, though, it takes a certain amount of chutzpah to distill a beautiful language from a clunky, heavily-abused language and it’s harmless to see that manifest a bit of quirky style. Mostly I spent my time reading, pondering, and tinkering with the example code. There are some great examples for creating objects and working with the prototypical inheritance, and the array sorting code (p80) is an especially inspiring bit of useful code.

The only serious negative of the book is the incessant and distracting typos. There are countless small code layout issues, bad line breaks in comments (p39), weird indentation (p40), added line breaks in code (p41), occasional camelCase. There are also a few typos in the code segments that will cause weird exceptions or, worse, silent failures. If the book didn’t have so damn much useful content I’d suggest waiting for a third printing to correct these errors (I read the Sept 2008 printing, look for a [9/08] or later in the lower-right corner of the copyright page). The poor copyediting is compounded by O’Reilly’s awful errata page; you can’t filter by printing and it includes many duplicates, making for a frustrating slog through clutter to track down why a particular sample doesn’t run.

In spite of the flaws, I strongly recommend JavaScript: The Good Parts to anyone who regularly works with JavaScript. If it seems that I’m not making a good case for it, it’s because the power of the book is the enrichment gained from working through its examples and the negatives are easy to diagnose and explain. Read it. You’ll gain a new perspective of the language and refresh your toolbox with new techniques. Most importantly, you’ll stop being annoyed at writing JavaScript.

I’d be really interested to see how many of the themes on various WordPress sites include function calls like eval, call_user_func, base64_decode, unpack, ord, chr, etc. as an indicator of hidden spam.

It’s pretty easy to design a game looks fun on paper but doesn’t actually work in practice. Maybe you have too many or too few rules, maybe players never have to make a serious decision, maybe it just feels… off, which means your playtesters are too polite to tell you it’s not fun.

So, we played. And quickly discovered poorly-defined terms, gaps in the rules, bad instructions (up there with Time Walk), worthless options, and gigantic imbalances.

But it was fun.

We spent as much time talking and tinkering with the design as we did playing, but the fundamental gameplay mechanic was, thankfully, fun. So I know it’s worthwhile to spend the time developing that for the web so it can get lots of playtesting and improvement and balancing.

This is a nice milestone, so I’m going to mention that I’ve picked a name for the game: Athenge.

It doesn’t really mean anything, I was playing around with words and my brain connected the high-tech @ sign in email addresses to prehistoric henges. It’s short, spellable, pronounceable, doesn’t sound like any offensive words, and, most importantly, the domain name was available. I’ve tagged my earlier posts on the web game, so they’re collected on the tag page if you’re curious.

• Developer Day Notes 1: Opening Keynote
• Developer Day Notes 2: Give Your Sites a Push with Comet
• Developer Day Notes 3: Natural Language Acceptance Testing
• Developer Day Notes 4: A Ruby 1.9 Case Study on Upgrading RCov
• Developer Day Notes 5: Lightning Talks
• Developer Day Notes 6: Browser-Based Visual Programming with Lily and the Monome
• Developer Day Notes 7: JavaScript Testing in Rails
• Developer Day Notes 8: Making Life More Enjoyable With Python
• Developer Day Notes 9: Programming In Interesting Times

I’m not taking notes at Happy Hour, so that’s all. A very friendly little one-day conference, lots of fun. Thanks to Viget for planning and hosting!

Lets say player A finds a exploit to duplicate a item and decides to exploit it. He continues to exploit it for a few weeks then player B finds the bug and reports it.
How would you catch player A? And what are some systems to watch/catch exploits/bugs/cheaters.

Logging, logging, logging.

When a player advances a level, log it. When a player buys something substantial, log it. When a player transfers items or money to another player, log it. When a player makes any significant achievement, log it. Then do things like count how many items the average player gets in a day or the average time it takes to go from level 9 to 10. Look at whoever’s doing things way faster or stronger.

On top of that, do a daily snapshot of a player’s stats (money, level, items, etc.) in case your other logs fail to notice where the resources are coming from. Then you do the same sort of analysis.

If you don’t have any logs and you want to find who abused an exploit you’ve only just realized, you’re going to have a hard time. If duping an item requires visiting a particular page, or visiting two pages in quick succession, your web server logs will have *something* you can look at, you can compare player IP to any suspicious entries in your access.log. If only a particular item can be duped, look in the db for who has lots of them — actually, you can do this for *any* item.

What you always have in your favor is that cheaters quickly get greedy when they realize what they’ve got and think they’re getting away with it. They won’t just go up a level now and then, they’ll go up ten today. They won’t produce a handful of extra gold for the occasional purchase, they’ll produce a million. Look for the outliers.

Logging isn’t just useful for catching cheaters, it tells you a lot of important things about your game. Are players doing well? Do players use the newly-deployed feature? What signs are there before someone abandons their account?

There are a lot of great things you can learn from logging and analytics and I plan to get into them in the coming weeks. This post is about a smaller topic, though:

How do you deal with all those logs? Aside from storing them all, processing them could be a lot of work.

One common answer is Amazon S3 (with EC2 for processing) which stores ridiculous amounts of data if you don’t mind some network latency. That’s nicely suited for logs where you rarely actually want to see the damn things, you just want to see reports and compilations and other whatnot.

This is such a nice obvious idea that Amazon has fairly recently created Elastic MapReduce, which makes it fall-down easy to run Hadoop on your data in S3. Hadoop is, outside of the Google Mothership, quickly becoming the standard way to sift through terabytes of data for the useful bits. Elastic MapReduce looks like such a win that I’m not really looking hard at other options for my game anymore. (After looking at all the sysadmin work Amazon Elastic MapReduce saves my only surprise is that they charge 15% more for it than the regular EC2. Now that they’ve built EMR the cost is down to ongoing maintenance for a strong driver of S3/EC2 use, why give the big customers any more incentive to decide they’d save money moving it in-house?)

So I was kicking around the question of how you get this data up to S3 with another developer and it seems like after you import any existing data you’d probably want to minimize the precious outgoing bandwidth of your phenomenally successful game’s data center. It occurred to me that you could parallelize much of the logging of user actions.

The basic idea is to create logs on both the server and client, have the client use their bandwidth sending logs to S3, use checksums from the server to make sure clients aren’t doing anything funny, and fall back to uploading the server’s authoritative log if so. There are two basic strategies:

First, clients could log directly to S3 using Browser-Based POST. Your app gives the client a token that allows them to upload a specific amount of data to a specific place in S3 and the app does an HTTP POST of data. You’d probably want to do this on a regular basis (in case the client suddenly drops offline) and have a process compile them into larger logs.

Alternately, you host a web server or other daemon on EC2 (probably using a reserved instance to lower the cost) to process and store the logs as they’re delivered. I like this slightly less than the previous store-and-process model that deals with failure and fits Hadoop’s model a little better.

This seems like a handy way to cut down on one expense, though overly-complex for my initial needs. I’m nearly certain I’ll use Elastic MapReduce for log processing, though.

A Wired article provides some evidence that Mission Architect has been, in the opinion of the game’s lead designer Matt Miller, abused to create unfairly rewarding missions for powerlevelers. He said:

Some of you have taken the stance of “how does powerlevelling hurt the game?” and “shouldn’t I be able to play the game the way that I want?” What we want to make clear is in order to keep the game fair, balanced, and challenging, we have to maintain a risk:reward ratio. This is a ratio we’ve spent years attempting to achieve. Mission Architect is not immune to this, and we are taking swift action to see that the problems players are seeing and are being exposed to are remedied. board post

This is an odd statement. I understand the “fair” comment, it sounds like a lot of the pushback is coming from players who are outraged that other players are able to reach the endgame content with a significantly reduced time investment. But “balanced” and “challenging” shouldn’t be affected by powerleveling, it should only mean that players arrive at the balanced and challenging endgame content faster.

Another MMORPG creator, Eric Heimburg, put it differently:

Once you reached that top of the hill, if there’s nothing left to do or see, players are likely to move on. Length of enjoyment (equals) amount of money earned, so developers have a strong incentive to keep players from gaining power and levels too quickly.

The very first thing that popped into my head after I read these two quotes was:

A multiplayer game is deep if it is still strategically interesting to play after expert players have studied and practiced it for years, decades, or centuries. Balancing Multiplayer Games

If the City of Heroes endgame is so shallow that it isn’t balanced or challenging or enjoyable, the solution is not to stop people from getting to it so quickly. Miller said:

If we say that the definition (of abuse) is ‘you gained 4 levels in under 30 minutes’, then someone will make sure that they gain 4 levels in 31 minutes, so they can claim they were within the allowed limits and not abusing.

Sirlin nailed that one, too, in startlingly similar terms (highlighted):

The thing to be banned must be able to be “completely defined.” Imagine that in a fighting game, repeating a certain sequence of five moves over and over is the best tactic in the game. Further suppose that doing so is “taboo” and that players want to ban it. There is no concrete definition of exactly what must be banned. Can players do three repetitions of the five moves? What about two reps? What about one? What about repeating the first four moves and omitting the fifth? Is that okay? The game becomes a test of who is willing to play as closely as possible to the “taboo tactic” without breaking the (arbitrary) letter of the law defining the tactic.

Or in a first-person shooter game, consider the notion of banning “camping” (sitting in one place for too long). No friendly agreement between the players is necessary for the ban, which at least means it’s enforceable. The server can monitor the positions of players, and it knows exactly who breaks the rule and can hand out penalties accordingly. The ban is enforceable, but the problem is being able to completely define camping. If camping is defined as staying within one zone for 3 minutes, and if it really is the best tactic, then sitting in that zone for 2 minutes 59 seconds becomes the best tactic. It’s a slippery slope because there will always exist camping tactics arbitrarily close to the specific kind of camping that is banned.

What Should Be Banned

A rule is not only arbitrary but secret and may cause players to be permanently banned from using the Mission Architect or playing the game at all is a really bad sign. It implies that the gameplay in City of Heroes is so broken that the game’s developers don’t know what’s wrong and can’t make a game that supports long-term, high-level play (that is, the most profitable play). Miller’s refusal to release a risk:reward ratio sounds more like City of Heroes hasn’t internally defined one and is only trying to staunch the increased exhaustion of players.

I don’t know City of Heroes, and I don’t know its creators, so I’m not going to say that this is certainly the case or that they fail at game design. That’d be obviously false, CoH has a large and probably generally quite satisfied userbase. Why are so many people playing so happily if the gameplay is broken?

The answer I can see is that Sirlin’s experience and topic choice is games that support high-level tournament play and City of Heroes isn’t trying to be that. It’s happy to be more of an unserious entertainment, a pastime, than a proving ground for people to challenge and rank their skills. Tournament games can be pastimes, but the reverse is almost never true.

Each of the massively multiplayer browser games I mentioned earlier capitalizes extensively on this Karma effect, to the point where some of them don’t even bother to have a graphical side anymore: all you have and play with, is tables with different rankings and statistics that define how well you do: amount of resources, number of bases, successful attacks executed… and that’s it. Playing the game merely means issuing commands with a button, and if your command worked those numbers get higher. And, boy, do you happily obsess over getting them up over time. Indeed one could say that games like these use only the Karma effect, throw a big fat SQL table and a user profile at it, sit back and watch user loyalty go through the roof.

It would be funny if it weren’t dead true. Most of these games feel like you’re using Excel to solve linear programming problems with starships as your desktop background while teenage psychopaths misspell obscenities at you.

Yeah, it’s that much fun. Now imagine it goes on for weeks. I used to call these “spreadsheet games” and only settled on farming games because at least it’s a verb that describes what happens to you.

I think the only think worse than how awful some of these games are is the fact they have tens of thousands of signups.

No shit, quite often tens to hundreds of thousands of signups. Not active players, of course, sane people give up pretty quickly on these games. But the games are successes in that they find an audience that can support their expenses.

I disagree, though, with the idea that scores and rankings work anywhere:

In society this number is often our salary, but for example in Reddit this is called ‘Karma’ and the founders are so aware of the psychological effect they don’t even bother to give an actual meaning to it! And they don’t need to: people will do what it takes to boost their Karma. So let’s dub this – extremely strong – effect the Karma Effect[...]

There’s an awesome book titled 21st Century Game Design that did — no kidding here — actual research into gamers and did a cluster analysis to break down gamers into four groups (eat your heart out, Richard Bartle).

Their four clusters are Conquerors, Managers, Wanderers, and Participants. Conquerors want to dominate the game or other players and are motivated by (and even take pleasure in) anger, frustration, and boredom. Managers want to master gameplay more than win, and they enjoy plot and politics. Wanderers want experiential games that can explore, tinker with, and perhaps display finesse. Participants are not frequently gamers at all but are heavy socializers when they do, enjoying collaboration and shared emotion. (And grab the book, this is a small piece of the good content in this book; I took 5 pages of notes from it.)

Conquerors are the sterotypical “hardcore gamers” that comprise the bulk of gaming culture both by weight and volume (and that’s volume as in taking up lots of space and volume as in loud as hell). These karma, spreadsheet, farming games appeal squarely to the conqueror demographic with confrontation, violence, stark functionality, numeric goals, and explicit ranking.

Nobody’s exclusively in one of these clusters so high scores can pull at a lot of people, but they’re not nearly as universal a motivator as hearing the words “Hey, that was a nice move” from someone you respect. It’s harder to build a game that drives that kind of social interaction, but I think it’s more rewarding.

The blog post also shares some ideas about nesting the game within itself. When working on my game design I worked out how a single turn is nested into a match, which is nested into the base-building game, which is nested into the overall game community. It was a nice exercise in thinking of the entire system as a game to ensure it’s fun at multiple levels of abstraction from the core second-to-second mechanics. The ideas he comes up with remind me a lot of some of the ideas in Sean Howard’s 300 Hundred Mechanics project, especially the Composition Army and Procedurally-Generated Content Cards 1, 2, and 3.

(My thanks to David Bremner for his help in supplying the Windows desktop for the screenshot.)

When you’re collecting resources and upgrading your cities there’s a positive feedback loop at work: you can build a bigger sawmill, hire more children to mine, reach a faster warp factor on your starships, all so you can bring in more resources. Games often address this by making upgrade costs grow multiplicatively or exponentially while the returns increase linearly, but usually the rate of return grows faster than the rate costs increase. If that last sentence made your eyes glaze over, think of compound interest: the more you have, the faster you earn more. The rich get richer.

I traded email with Wouter Smet, creator of the web game DiceAttack. We talked a little about WeeWar and that got me thinking about positive feedback loops because it has one of the worst positive feedback loops I’ve seen. I’d like to give a proper definition and use WeeWar as an exercise in game design.

Here’s the start of a game of WeeWar. I’m going to use screenshots to explain some concepts, but you should sign up (it’s free) and play a game or few against the AI to get a feel for it. To save the pluralization hassles and parenthetical caveats, I’m going to write about WeeWar as if it were only two-player (as it’s most commonly played) rather than multiplayer free-for-all. Everything works the same except that it’s easier to explain myself and give examples. Remember, you win by defeating all of your opponent’s units and capturing all the bases.

Feedback is the game’s response to player actions. There’s UI feedback, where clicking a unit highlights the places I can move it to:

But in this post I’m only talking about game feedback, the in-game response to player actions, like how moving my trooper onto the neutral base starts the capturing process or I spend credits to build a tank.

A feedback loop is when the feedback affects itself. Each base I capture earns the income and provides the staging area to produce more troopers to capture bases. You can really see this in effect if you play the City Sprawl map, every game opens with a flurry of capturing bases and producing more troopers as quickly as possible.

Feedback is positive or negative. The base/trooper example is a positive feedback loop, each time it happens it makes it more likely it will happen again. Negative feedback isn’t something bad happening to a player, it’s a change that makes it less likely for other changes to occur. Let me make the distinction clear:

Losing a unit is negative in the sense that it’s bad, but it’s not negative feedback. Losing a unit is a positive feedback loop, each loss makes future losses more likely because you have reduced attack power and you lose opportunities to use the bonus of attacking an enemy unit with several units in one turn. Losing a unit would be negative feedback if each loss made future loss less likely, perhaps by increasing the health of all your remaining units or teleporting the attacker backwards.

As far as I can see WeeWar doesn’t have negative feedback, let alone negative feedback loops, and I’ll talk about why this is bad in a bit.

Feedback can be weak, strong, or anywhere in-between. To make the unit loss loop weaker the lost unit could be rebuildable by a special repair unit or available at reduced price back at the base, or heal the unit and send it back to a staging area behind the base that constructed it. To make it stronger, we could add an explosion so that destroying a tank damages the allied units touching it, or make a unit’s defense depend on how many allied units they’re within a hex or two of.

Most multiplayers games have feedback. Some racing games and party games don’t; nothing you do will affect how quickly your opponent runs a mile. Chess is interesting in that losing pieces is such weak feedback loop; the ease of taking pieces and importance of position and arragement mean that an individual piece doesn’t count for as much.

Back to WeeWar. Bases are a zero-sum resource, each base you capture is a base I lose. (This is true despite the initial expansion into “neutral” bases, each is a potential resource that players are directly competing for.) Zero-sum resources tend to come with strong positive feedback loops, and WeeWar is a perfect example of this.

Every base on a map is worth the same amount of income. That amount differs between maps but usually ranges between more than enough to produce the smallest unit and enough to buy a mid-sized unit. Most battles involve four or five units on a side, so the ability for each base to produce an entire unit means that bases are quite valuable.

In fact, they’re generally so valuable that capturing one single base from your opponent ensures victory. The battle may rage on for many turns after but the capturing player will almost never lose the lead. The positive feedback loop is too strong for anything else to matter.

So in WeeWar you don’t win by capturing bases, you win by capturing a single base. The gameplay is all about the push back and forth between units, which has been very finely tuned because it’s gotten so much attention. I don’t find WeeWar fun because I expect to be pushing the other player back and forth, maneuvering to flank or retreat. Instead it feels more like the meat grinder of trench warfare, trying to stay one step ahead of the rock-paper-scissors unit balance while rotating injured units out and producing fresh ones. I never feel like I have significant choices, just a formula to follow.

Since the game isn’t really about capturing bases, I’d expect the most successful maps to provide each player with a cluster of bases to defend with significant terrain between them to engage in battle in. This isn’t currently the case, the list is dominated by novelty maps and the maps the game included before the map editor was public. I think is a function of the newness of the map editor and the fact that I can’t restrict the view to see only what maps are most popular among elite players (who want to play on the best-balanced maps).

So, can I imagine how to remake WeeWar more to my liking?

With the game so finely balanced, I’d probably want to introduce more randomness. Let battles be less predictable. Then remove many of the units that are just upgraded versions of each other, like the set of Tank, Heavy Tank, Berserker. Maybe salt in some special abilities to units, like being able to freeze an enemy unit in place for a turn, stop them from attacking, add to the defense of neighboring units, etc. The abilities would make units more interdependent so that you build battle groups instead of send out single units so often, and you’d have to re-balance and change your groups as units are lost. The goal here is to make play more varied, with more strategies and options than just hitting your opponent.

Next, I’d reduce the importance of bases by making the win condition about capturing and controlling otherwise useless immobile flags on the map. Then it’s nice to capture and hold bases, but not overwhelmingly important. The player has to decide between taking flags or taking bases the opponent to slow them down from taking flags. Another approach would be to make it possible for the player to construct their own bases, making the game a balance between economic and military expansion (worked pretty well for StarCraft).

Or maybe change nothing except replace alternating turns with simultaneous turns (my current favorite cure-all).

I’m not going to claim that these ideas are The Perfect Solution, just that I think they’re decent options for improving the gameplay. This calls for lots of experimentation and playtesting. My real goal with throwing these ideas out is to keep exercising my analytical and creative game design skills as I work on my game design.

• 1. Ikariam
• 2. WeeWar
• Tangent: The Farming Genre
• 3. Tactics Ogre
• 4. Counter-Strike
• 5. X-Com
• 6. Kongai
• Tangent: Technology Trees

Talking about Ikariam reminded me about technology trees because it has a particularly big and complex one. When I was playing I created a graph showing how to unlock everything so that everyone in my guild could quickly develop as we needed.

In the diagram below, pink rectangles are buildings, green parallelograms are actions, solid blue circles are ships, red hexagons are military units (with their costs), and the empty circles are technology achievements (color indicating which of four tracks). It sounds really complicated and is overwhelming at first look, but it serves as reference for any player with a little experience.

It’s worth noting that this is long out-of-date; updates to the game have extensively added, rearranged, and repriced things. I created it with graphviz’s dot utility. It’s a great tool for easily making the directed graphs that show up over and over in computer science. (And read Anathem, it’s a captivating novel that, yes, prominently features directed acyclic graphs.)

OK, that’s all the “Yay, technology trees are keen!” that I can manage.

The Purpose of Technology Trees

They do have some uses. The first three are heavily intertwined:

First, tech trees linearly organize options over time. If a new player could choose from the start whether they wanted to produce smooth-bore or rifled barrels for their soldiers, they’d have to be a suicidal masochist to choose the former. Usually the later technology uses different, a higher quantity of, or more precious resources (like going from bronze swords to steel swords), but often the improved option is such an large improvement that it’s not a real choice which to use. A tech tree makes it possible to present these things in a linear fashion to players to make the game more rational and learnable.

Tech trees also act as gates on content consumption. Until you’ve reached a particular level of development, you can’t use the warp drive and are confined to exploring your solar system. This makes sure that players don’t skim over expensively hand-scripted characters and hand-designed locations (though most PBBGs procedurally generate content). Gating also ensures that players will have opportunities to recognize all the options presented by content — to continue the example, it’d be easy to overlook your mineral-rich asteroid belt if you could immediately cruise off to the stars, and you might end up hamstrung by lack of iron or the knowledge of where to find it and how to mine it. Gating keeps players from being overwhelmed by options and content until they’ve had some time to read help files and make some new friends they can ask questions of.

The third function of a technology tree is to greatly increase the power scale of players. MMORPGs have infamously large power scales: you go from barely triumphing over garden slugs to slaying gods in a casual manner befitting Richard Dawkins. The game Settlers of Catan has a smaller power scale: you start collecting resources from two towns and could grow to five towns and four cities. Chess has a flat or declining power scale.

The final use I’ve seen is as a sink. High-level players often have more resources than they know what to do with, so they lose the fun of hard choices (like equipment in Tactics Ogre). Technological advancements that provide quantitative improvements (that is, shave some percent off of sailing time as opposed to unlock the ability to build steamboats) act as sinks that excess resources can be poured down. This works especially well when the advancements are expensive, ineffective, and public so that players get bragging rights rather than becoming invincible powerhouses.

Technology Trees Usually Suck

Most persistent browser-based games take those first three purposes and crank the dials all the way up. Players use technology trees to go from pointed sticks to nova bombs, from a small space to the most fertile or productive places possible.

The biggest problem with trees is that they act as ratchets. Once you’ve learned The Pulley you always know it and can’t lose it. That’s fine in a game of bounded duration like Civilization or StarCraft, after an hour or few the game is over your research disappears. You don’t start your second game of Civilization back in the stone age knowing how to produce nuclear weapons. But PBBGs are open-ended, a player has a technology until they quit playing entirely (probably being driven to it by someone farther along).

So players get the height of an even bigger power scale to drop rocks on each other from, and if they don’t have a sink for their extra resources they’ll probably shower them onto a guildmate to ratchet themselves up with.

One StarCraft mechanic often shows up with horrible consequences. In StarCraft, there are a number of enhancements that give special powers to units (such as the ability to burrow into the ground or turn invisible) that mean a defender who hasn’t researched the countermeasure cannot attack those units at all. This works in a 40-minute game where the defender gains access to the countermeasure around the same time the attacker gains the power, but in a PBBG new players may be dropped in next door to someone who has played for months and the countermeasure may be weeks away. Awful!

Designers often don’t recognize how special technology is. A player might gift their resources, raze their buildings, move their cities, fire their workers, discharge their soldiers, quit their guild… but they’ll still have their technology. The advancements available rarely reflect that permanence.

Redesigning Technology

One of the joys of long games like MMORPGs and PBBGs is that they give players the opportunity to eventually try everything the game has to offer. Well, unless the player has to make an irreversible decision like character class, then they create alternate characters or logins and decry the grind back up through the tree.

Looking at StarCraft again, I’ve combined two mechanics to design an improved technology mechanic for my game. First, limit permanent technological advancements to the expensive but low-productivity sinks mentioned above. In StarCraft you produce advancements by constructing certain buildings or spending resources at them, like a Spire to be able to build flying units. If you lose the building, you lose the advancement and can’t build more flyers. The other mechanic is “supply points”, a cap on the number of units you can control at once. Certain buildings and units raise the point cap, and most units count for 1-2 points toward the cap. It’s not a resource you can bank, spend, or trade, it’s solely a limit to the number of units you can recruit. It prevents armies from growing too quickly in the beginning of the game and growing too large in the end of the game.

Combining these two ideas, players could build research buildings to unlock different abilities and advancements. They can’t unlock everything because the cap on research buildings is lower than the number of abilities. Abilities stop being an oddity and are better integrated into the rest of the game mechanics — do you spend your money setting up a gasoline engine plant or buy more horses? Players choose where to specialize based on their opportunities and personalities and can raze and rebuild buildings to change their selection.

This is the eighth and final of a six post series on game design, weighing in at a surprising 6,200 words (I didn’t originally plan on these two tangents, but let’s all toast Douglas Adams while I’m about it). I’ve noticed I’ve picked up some new readers, so let me again let me say I really appreciate feedback. I’m going to return to my regular babbling about whatever shiny thing captures my attention — which is to reiterate that you should feel free to comment, email, or IM because that’s where I tend to pick up topics from.

• 1. Ikariam
• 2. WeeWar
• Tangent: The Farming Genre
• 3. Tactics Ogre
• 4. Counter-Strike
• 5. X-Com
• 6. Kongai
• Tangent: Technology Trees
• 7. Warstorm

Kongai is a very different from all the previous games. It’s an online two-player collectible card game. You build a deck of three to five characters (with, optionally, one item each) and defeat your opponents’ characters.

Each turn you have two choices to make and the results are resolved simultaneously rather than in the more common “I go, then you go” fashion. Range is first: you can leave your character where they are or spend energy trying to get to the near or far range. If you leave your character, the range is whatever your opponent sets. If you both try to set it to something different it doesn’t change. Some abilities work only at near or far, some both. The energy you spend to change range is the same energy used to activate abilities, so there are immediately some tough decisions to make about where and whether to spend your resources and guessing what your opponent will choose.

Second, you each choose an action. You can use one of your characters’ four abilities (mostly attacks, though a quarter or so heal or give status ailments), switch your character out for another (dodging any attack), intercept your opponents’ switch (preventing it and dealing significant damage), or rest your character to recover extra energy for the next turn.

It’s one of those simple-but-deep games because of the simultaneous turns. You don’t flail away at your opponent, you have to outthink them. Kongai’s designer, David Sirlin, has written a bit about the process of designing Kongai and how it’s all about the skill he calls yomi, the ability to predict your opponent’s moves and keep yours unpredictable.

This, in a nutshell, is why I gripe about multiplayer games being primarily about deckbuilding like Tactics Ogre. You only get one try to guess your opponent’s plan. If you guessed wrong, you play a (possibly quite long) battle that you can probably only lose. Only then do you get a chance to change your build to have new tactics to try again. Tactics Ogre isn’t much fun because there’s little back-and-forth between the players, battles are just about lining up and smashing as hard as you can (or, worse, about “leveling up” the power of your characters).

Deckbuilding isn’t intrinsically wrong, it’s fun in Kongai and in Magic: The Gathering even more of the game is deckbuilding and it still works well. Many strategy games like Civilization and StarCraft intertwine the building and using phases. You scout your opponent and deceive their scouts to decide your build and sabotage theirs.

Sirlin’s written an awesome book called Playing to Win: Becoming the Champion about how players should approach competitive games to succeed at tournament-level play (it’s also available free online). His pushes players to understand games as they are designed rather than as they may stylistically appear to play. Basketball can be won by playing the court and constantly harassing other players, not by executing a practiced attack or defending the zone (the Traveller example is even more powerful). I also recommend reading Sirlin’s entire blog, it’s similar in content to his book but from the perspective of the game designer trying to plan and balance a complex game that elite players will do their best to break over thousands of hours of dedicated play.

I was thinking about my game’s design and how to prevent it from becoming a slugfest when I thought of Kongai and read Sirlin. The best strategy in any farming game like Ikariam is to find the weakest player and raid them repeatedly. The best strategy in WeeWar is to steal an opponents’ nearest base and the positive feedback loop generated by bases being a zero-sum resource means you’re almost guaranteed a win. Tactics Ogre is a slugfest because there are no meaningful options, the best move on any turn is to move to the weakest opponent and hit them as hard as possible. The constant refrain here is that you never care what your opponent is doing; nothing they do actually influences your moves because you don’t have significant decisions to make.

Counter-Strike is a highly successful tournament game because players are constantly shifting tactics in the real-time battle. X-Com is the only single-player game on this list, but it would have a good shot at translating to multiplayer because it deals with managing limited resources and knowledge in response to your opponents’ actions.

These are the games that had the biggest influence on my design, though there are certainly others like Syndicate, Eve Online, and muds that have had an effect. I seem to have a habit of working on my design, seeing flaws, adopting from other games to refactor my design, and repeating. I’ve been really happy with my current plans for an unprecedented several months, so I’m moving into playtesting to start getting real-world feedback on how well gameplay works. I’ve got one more game design blog post scheduled on technology trees and otherwise will be returning to my regular babbling about whatever shiny thing captures my attention — which is to reiterate that you should feel free to comment, email, or IM because that’s where I tend to pick up topics from.

• 1. Ikariam
• 2. WeeWar
• Tangent: The Farming Genre
• 3. Tactics Ogre
• 4. Counter-Strike
• 5. X-Com
• 6. Kongai
• Tangent: Technology Trees
• 7. Warstorm

So I thought I’d solved everything and was moving along on my design. Players control 1 or 2 secret agents on an isometric map. Turns simply alternate rather than being based on how much you did last turn. Almost all weapons are ranged and powerful enough to kill in one or two shots. Hm. So why would you ever risk getting into someone’s line of fire, should I add fog of war so the player only knows what their agents can see? I guess I could add stances so characters could hide behind terrain, and maybe 3D to make positioning important…

Doubts crept in. Could a game this complex be playable? Wouldn’t the user interface be overwhelming? I took my notes and went to chat with a game designer.

Me:

So, I’m making an isometric turn-based tactical combat game. And I’m not sure it’ll work because most characters in most turn-based strategy games can take many hits but that doesn’t match my urban combat setting.

Ammon:

That sounds a little familiar.

Me:

I don’t know any games like it. So I’m thinking I should really reduce the distance characters can move and do these other things so they don’t just run straight at each other, but that’s getting complex.

Ammon:

This sounds like X-Com.

Me:

Never heard of it

Ammon:

X-Com is single-player, you have a squad of 8-14 units. Units gain XP but 1-2 shots kill so any unit that survives a few missions is awesome.

Me:

Any enemies were the same size and shape as your units? Did they outnumber you?

Ammon:

Yep.

Me:

And most weapons are ranged? That works?

Ammon:

Yep.

Me:

Huh. I guess I’ll check it out sometime. So I’m trying to decide what a turn looks like. Move and attack vs. move or attack, mostly.

Ammon:

X-Com has action points you spend for moving, turning, changing stance. Different fire modes (snapshot, aimed shot, burst fire) take different amounts.

Me:

What’s the gameplay effect of turning? Are attacks against side/rear better? Is there fog of war?

Ammon:

Yep, fog of war is the primary effect. A shot from behind could be a kill and you’d never even know where it came from.

Me:

Hm. One thing I’m pondering is a ‘guard’ action. So an agent could do nothing on their turn but look out a door and nail someone who crosses by the doorway in one turn.

Ammon:

Yeah, X-Com has that.

Me:

Oh. Do any of these model audio? Like you could hear someone sneaking up on you? [Which means some kind of replay of enemy turns before you take yours.]

Ammon:

Yep, you can hear running footsteps, gunfire. Rockets are effective but attract a lot of attention.

Me:

And all that works? It’s not overwhelming?

Ammon:

The only problem was scaling the power curve. A major element was new technologies, which meant building a base, capturing alien equipment during battle, and spending money to research it. Which would attract the aliens’ attention, they’d come attack your base.

Me:

Huh. That was a big part of my game, building bunks to be able to have more characters but also making yourself a more tempting target for other players.

Ammon:

Yeah, base layout mattered a lot. When you defend against attacks, it’s on whatever floorplan you created. So if your barracks are too far from the entrance, aliens could trash your equipment and kill your scientists before you got there.

Me:

OK, stop talking about X-Com. I can already tell I need to play it because it includes every element I thought was original and spiffy and maybe even too complex.

The X-Com series of games was released in the 1990s. You can find the first couple games (#2, Terror From The Deep, is probably the overall best) on abandonware sites and run them under dosbox or easily pick up the port to modern PCs on Steam.

There’s not a lot of description that early conversation left out. When I played X-Com a few days later, I was awed that someone 15 years ago had created almost exactly the game I was inventing.

I pondered where to go from here. I had the confirmation that I could make as complex a game as I’d considered. But if the game has Been Done, can I learn from it instead of (inadvertently) cloning it?

I’ve always liked game designs with simple mechanics and few numbers. I don’t really like to count into double digits, let alone have 382 hitpoints and decide whether to buy an item that gives me a 6% boost. X-Com requires that players be meticulous about equipping units, sending enough ammo that they won’t run out but won’t overburden and slow them down. It seemed like too much deckbuilding, moving the interesting decisions out of the main gameplay and into the preparation. Battles were fairly repetitive once you learned the basic strategy of how to move under cover, search buildings, provide support fire, and balance your team.

I was still working on my design but wasn’t very sure of it until I thought about another game named Kongai.

• 1. Ikariam
• 2. WeeWar
• Tangent: The Farming Genre
• 3. Tactics Ogre
• 4. Counter-Strike
• 5. X-Com
• 6. Kongai
• Tangent: Technology Trees
• 7. Warstorm

As I left off, I wanted to create a turn-based strategy game on the web with an interesting setting. I was pondering what sort of setting hadn’t been mined out and thought of Counter-Strike, by many measures the most popular online multiplayer game.

In Counter-Strike you are on a small squad (3-8 players, tournament size is 5) against another squad of players, one team terrorists and one team counter-terrorists. It’s a fast-paced first-person shooter (FPS) with deep tactical play as teams attempt to complete or prevent objectives like planting a bomb in a particular place on the map or escorting hostages to an exit point.

In most FPS games your character is heavily armored and can survive lots of punishment before dying. Counter-Strike defined itself by using real weapons that kill in a few or often one shot, so players have to have fast reflexes to succeed in a firefight and execute tactics well to ensure they’re in a firefight they can win. Or, better, aren’t in a firefight at all and have snuck up behind an oblivious enemy. I enjoy the way game calls upon a wide range of skills, but I don’t play it much myself because I’m not fast enough for the combat.

Setting is a funny thing: a person might have loved the Matrix but broadly assert “Oh, I don’t like sci-fi” and leave a game’s website at the first sight of a spaceship. Fantasy games are an overwhelming part of the market because potential players reliably don’t automatically disregard them and they open up a lot of design possibilities that a modern setting wouldn’t (eg. modern settings don’t have teleportation or healing spells, which are really handy for getting characters together and prepared to play).

Counter-Strike chose its setting and extracted mechanics from it to create an enduring game. When I considered the idea of a turn-based tactical game with counter-terrorists — no, better: secret agents — I realized it could solve a lot of my design problems as well.

Instead of slugest combat, most characters would use ranged weapons that could incapacitate or kill in a shot or two. The map isn’t just a pretty backdrop, picking lines of sight and areas of engagement is essential. Players can compete in deliberate missions instead of preying on each other. By maintaining a base of operations, players can have the long continuity that draws them back to the site with short gameplay sessions whenever they’d like to do more than wait a few hours for a trade boat to arrive.

I started designing in earnest. Next: the classic game X-Com surprises me from 15 years in the past.