Speaking of hours, I missed responding to something in his previous update:

Eventually, I’m going to create web interfaces for a lot of this stuff, but for now I’ll have to do any settings and etc. by hand in the database. By the way, the interface work isn’t strictly game-related and can be handled outside of So Play We All hours.

After the first week we said hours had to be budgeted towards code, but not marketing and blogging. It’s vague here, Jim, what are you referring to working on? If “interface” means HTML frontend, that’s code that’s gotta get counted, Luke and I both did a bunch of template work on budget.

Anyways, this week Jim’s got some nice top-to-bottom functionality done in his rendering engine. It felt a bit like my update about finishing off code from last week. He’s rendering a basic page:

We do not have DisplayRegions yet, so I am just some simple text. However, this page is now valid XHTML and not simple plain-text!

Congrats on the milestone, Jim.

Luke had writer’s block, so there’s not a lot to say there. I’m a bit puzzled that he doesn’t say “coder’s blocK” because the hours are budgeted towards that, but I can see how it’d be easy to open a code editor and then stare at it.

I’ve chatted with Luke a bit about his game design and thought it was pretty solid, similar to stuff I’d seen on Three Hundred Mechanics . This really sounds like he’s trying to see the entire design up-front and getting overwhelmed by it. His big questions are all certainly important ones, but maybe it’s worth figuring out if there’s a way to take smaller bites.

Jim’s got his first progress that doesn’t sound to me like he’s reinventing a wheel. The template for a page is broken down into DisplayRegions, each of which has a Controller (“Component”) responsible for loading the right data.

It’s an interesting PHP-styled take on MVC. The top-level code that handles each request isn’t a controller action, it’s basically a template split into code/settings (“DisplayEngine”) and markup (“PageTemplate”). The template then lists what controllers and actions should be invoked to handle the request, which is a not how I’ve ever seen any web MVC work before. It feels pretty stereotypical of PHP to have a template running the show, and I wonder how much logic is going to leak into them as a result. A common pattern is that a section of a page with links to register and sign in — or, if there’s a user logged-in, to edit account settings and log out. Jim, in your system, where does that if (logged_in()) { [settings/logout template] } else { [register/login template] } live?

This week, Jim had a brief but significant update, writing:

Well, after so many weeks of being seriously far behind, I’ll finally be making the progress towards being able to render a complete HTML page.

He’s written his Page, Session, and Form classes to the point that he’s only held back by not being able to template pages from displaying real pages. I’m a little surprised he got votes in this week’s poll without anything to demo, but it’s nice to hear things are coming together for him.

Actually, maybe I should be worried that he’s going to start displaying a game sometime soon. So let me mention a great Rails feature you should spend time reimplementing, Jim. The pending release of Rails 3.1 includes HTTP streaming, basically the ability to send parts of the page while still working on generating the page.

This is how PHP’s page-as-script model works out-of-the-box, but it often leads to bugs when state changes during the page rendering. I’ve seen a lot of browser based games with a bug where a page says you have 100 minerals in the header and then, lower in the page, say that you only have 50 because loading this page performed an action that spent 50 minerals. Having an explicit stage that builds and renders a page usually prevents these bugs at the cost of being able to send enough information for the client to get working at downloading page assets while the server is still performing work. Continuing to support that may cost Jim enough time in gold-plating to keep me comfortably ahead.

(But just in case it doesn’t the 3.1 announcement also mentions an asset pipeline that compiles and compresses CSS and JS for faster pageloads. Have fun, Jim.)

Luke laid down code for cards. I know I’m helping the enemy, but I’ve got to tweak it. His code is:

 
class CardController < ApplicationController
  def play
    play_sym = "play_#{@card}".intern # PH: this should be .to_sym
    self.send(play_sym)
    render :action => play_sym and return
  end
 
  def pocket
    pocket_sym = "pocket_#{@card}".intern
    self.send(pocket_sym)
  end # PH: no explicit render here? Feels like a paste error
 
  protected
 
  # plays
  def play_roland
    # Play the game to see what happens when you play the Roland card!
  end
 
  def play_water
    # Play the game to see what happens when you play the Water card!
  end
 
  # pockets
  def pocket_roland
    # Play the game to see what happens when you pocket the Roland card!
  end
 
  def pocket_water
    # Play the game to see what happens when you pocket the Water card!
  end
 
end

 
class CardController < ApplicationController
  # I'm guessing from usage above @card is just the name for a card as a string
  # and that it's loaded from the url by a filter, note that I use it differently.
  before_filter :load_card
  after_filter :default_render_card
  
  def play
    @card.play
  end
 
  def pocket
    @card.pocket
  end
 
  protected
 
  def load_card
    @name = params[:card]
    @card = "card/#{@name}".camelize.constantize
  end
 
  def default_render_card
    render :template => "cards/#{request.action}/#{@name}" unless performed?
  end
end
 
# add in config/application.rb:
module Oaqn
  class Application < Rails::Application
    config.autoload_paths += %W(#{config.root}/app/cards)
  end
end
 
# and then create app/cards/roland.rb:
module Card
  module Roland
    def pocket
      # code for pocketing
    end
 
    def play
      # code for playing
    end
  end
end

So now the cards each get a source file to themselves, templates have their own per-action dirs (better swapped to per-card dirs, if there are more actions), there’s less duplicated code, and it’s far easier to test these smaller pieces. The only thing missing from this example is the fact that Luke may have to pass some game state into the methods. As long as there’s not too much it’s probably worth being explicit about.

2011-07-09: Luke actually used this code and found it didn’t work as written. I found an explanation; either add ‘app’ to autoload_paths instead of ‘app/cards’, or drop the Card wrapper.

Meanwhile, in the past, Jim wrote some PHP, and I’m not touching that language.

No, in seriousness, Jim talked about why he has some identifiers surrounded by __ (which I’d called python poisoning). I haven’t dug into his code (again, PHP), but it looks like it might be an InBandSignal to reuse Events as framework steps.

And then he talks about session fixation attacks, which are have been protected against out-of-the-box on PHP with the session.use_only_cookies setting for a while. I was a bit confused, I’m pretty sure he’s actually describing session capture attacks. Oh, and there was some other stuff about writing code to store sessions in the database. If you’re curious, Jim, here’s the code for a Rails app to do that, which appears commented-out in the stock config file for your editing convenience:

 
  Oaqn::Application.config.session_store :active_record_store

It includes support out of the box for keeping sessions in cookies (encrypted, of course), your SQL database via ActiveRecord, or Memcached. I’m curious, how much of your budget did you spend storing sessions?

And, you know, I’m a huge fan of card games, so it’s nice to see another one in development.

As great as that is, Jim got my vote in this week’s poll.

In a post titled Deity Development he responds to some criticism and then links to the documentation for the abstract work I was hassling him about doing the last few weeks. I’m glad to tangibly see his progress, and it looks like he’s got a solid core built now.

Meanwhile, Jim is apparently suffering from Python poisoning, because he’s naming events __LIKE_THIS__. He’s swirling into madness:

Once Version 1 is stable, I’ll compile a list of “official” Events that developers can utilize in their own projects.

No, I didn’t make that up. Not only is he thinking about a framework for multiple games, he’s thinking about a published framework for multiple games. Not, you know, his game. I see why Luke earlier used the phrase architecture astronauts. Jim, you are a great many abstractions away from writing a game, and I think the air is getting thin.

More encouragingly, Jim’s been writing about some of the deities in his game world: Dani, Rhegar, Nuri, Shisane, and Kesok. I understand the setting is largely based on long-gone-by D&D campaigns. It’s great to see some player-facing information.

Meanwhile, Jim’s done great, getting code live for the first time. I took a screenshot:

The first page has a simple login form. There’s no way to register an account, and any login/password you enter gives you the above message. In his blog post, Jim wrote about the code

At that point, it was a fairly easy task to take the user object and add its data to the display for rendering. I chose to go with something like:

Hello %user%! Your account was created at %time% on %date% and you last logged in at %time% on %date%. Enjoy your stay!

STOP IT. You are writing a template language in a template language! Templates are the one thing PHP actually does pretty decently (well, it’s not Haml, but it’s way better than TAL)! Wrap PHP’s output buffering around include() and get on with your life before you find yourself implementing conditionals and loops.

This is part of a larger topic I have to respond to:

This is mostly because I had to rush myself just to even get this far and put in lots of sloppy code. So, I’ve decided that I don’t care how far ahead the others get, I am not going to worry about matching their pace.

Really, it was an unrealistic goal that I’m glad to be letting go of. They’re using a pre-built framework which means they have options to solve a lot of their issues right out of the box. I, on the other hand, have to implement even my low-level functionality. This means that I’m going to be slower to execute no matter what happens. That’s the price that I pay for wanting to use my own implementation. The positive upside is that once I manage to solve these issues, they’ll be solved for me in all of my future games and I’ll be able to skip this tedium the next time around. …

Sure, it slows me down in terms of this competition, however, I will have 100% control over every aspect of the process which is not something that I would have if I were to leverage Drupal to build the game.

I know you write good code, Jim, but satisfice, man. You’ve got the worst time demands of all of us. Luke and I aren’t barfing into our editors and making sure it passes a syntax check, we’re taking acceptable components from other people so we spend our time on the important bits.

Last week I bought and added a theme to Oaqn. I was hugely tempted to tear it apart and make sure everything was perfect, with semantic class names and no unused code and efficient selectors and and and… Instead I added achievements, a feature that will help inspire and retain players for the lifetime of my game. That code’s not perfect, either, I already know I’ll want to tweak it to add some kind of bronze/silver/gold upgrading medals — but now I’ve got something decent in place and I can get closer to a running game.

Finish a game. So Play We All.

Allabrilyn

Jim wrote about a lot of technical progress, but unfortunately it all falls into the category of invisible infrastructure, there’s nothing for a player to see. It really reminded me what a huge boost Heroku is for hosting: not only is initial deployment about 5 minutes, it prevents you from spending time tinkering with your server setup for only minimal gains. (I don’t know how he got more votes than me, I suspect sympathy from similarly frustrated PHP coders.)

In all, it’s been a difficult 4 hours… but well worth the effort, in my opinion. I believe the extra headaches I’m taking now will allow me better flexibility in the long-term.

The bulk of his post seems to be about improving his own ORM and site infrastructure. Ouch. It sounds like he’s written some nice code, but this contest is about building one game, not building the next ten games.

Maybe the Real Ultimate Power of Drupal will make it a breeze to drop in community features like a forum and a chat, but right now he has nothing to see and he’s falling behind.

Fantasy Adventure

I’m glad to hear Luke’s stepping up his game after his brief blog posts for week 0. Not that I don’t mind easy competition, but I don’t want people to think I rigged the contest by setting myself up against a sucker. :)

In seriousness, Luke did great this week, he got my vote in the poll. We both used Devise for registration, but he got his basic install much faster and then streamlined it to make it easier for people to get into his game.

Yes, into his game! I’m not sure if it’s just static text or he created a basic player object with a few attributes, but he threw together a decent template and you could click around to move between different locations. Currently there’s just a bit of cute story to read, but that’s enough for the player’s imagination to start filling in gaps and imaging a world. (Also, bonus points for using delightful PlaceKittens, I’ve bookmarked that as a resource.)

That ability to fire the imagination is a great sign for Luke’s prospects. Time for me to go step up my game in response.

Showing off his superior time management skills, Jim quickly posted about Allabrilyn. It sounds like a collectible card game (or maybe LCG). That the collectible elements are units for a tactical game is… awfully familiar.

I dropped Athenge as a project because I realized I love the genre, but it’s actually really uncommon. Tactical wargames have a hardcore fanbase (a blessing and a curse), but it’s certainly not a big one. And building a game around PVP that’s mostly based on the player’s skill progression means there’s going to be a lot of dissatisfied bad players who don’t want to participate. So I think it’s great that Jim is building my kind of game, but I worry about his market. (And Jim – don’t just sell random packs, add a premium currency that players can use to auction/sell cards between themselves with so that you don’t create a secondary market that gives you support hassles but not income.)

Next up, Luke explained Fantasy Adventure Game. I loved this post (though of course, not so much that I voted for it over myself). He’s immediately willing to be imperfect in public by beginning with a terrible working title. It’s a great sign for getting over embarrassment to develop something great. I’m terribly jealous that he included financial info from the start; I’d wanted to but it slipped my mind. More guts!

As for the game itself, it leaves me a little flat. I’ve seen too many games default to fantasy; I hope he finds ways to turn his ignorance into interesting genre redefinition rather than middle-of-the-road generictown. It really sounds like it’s a single-player RPG (having not played KOL), so I think he’s going to have problems with producing content (items, quests, skills, etc.). Multiplayer interaction, competitive or cooperative, is wonderful content because you can set up systems that players fill up with content. It takes a fraction of the time to code a PVP game like chess than it does to write a text adventure like Adventure, and chess is probably fun for far longer because it becomes about other people, and people are interested in people.

I also have one criticism to level at both games: there’s nothing for the player to identify with. In Oaqn, the player controls a single caravan, that’s them in the world. (And I very likely will add some kind of human player avatar to play dress-up with eventually, because that’s even better.) In Allabrilyn and FA, the player controls a collection of characters, so there’s nothing for them to feel represented by or invest in the well-being of. This is why RPGs (and many other games) have a heroic mime character leading the party, so the player has an empty template to fill up with their personality. It’s much harder to do that with a deck of cards or a small troupe, and it’s a powerful motivator for casual online games.

My lengthy braindump rocked this week’s poll, with 6 votes for me, 1 for FA, and 0 for Jim (who I guess is not even active enough on the forums anymore to even vote for himself). I’m happy for that, but I think I’m going to face stiff competition that’s constantly thinking of things I’ve missed. So all I can do is plan to steal those things like revenue details for next week, muahaha! (Speaking of which, I’d better go put in my hours before I wind up owing these guys money.)

The Setup

You are a survivor of the zombie apocalypse in a town with up to 39 other players. It runs on a 24 hour cycle, and each day you get six Action Points (refillable 1-3 times per day, depending on what items are available) to scavenge for items and build up shared town defenses. If you die (which can happen individually or because your town is overrun in the nightly zombie attack), you can join right back into a new town tomorrow.

The core game mechanic is a sort of iterated prisoner’s dilemma, you have to choose to keep things back from the town or contribute to the town, and then socializing with other players to decide what defenses to spend your very limited resources on.

But the basic prisoner’s dilemma isn’t much of a choice, you learn after the first town or two that it is always much better to collaborate with your town, you cannot survive solo at all. But this does take you a town or two to learn.

The typical town is dominated largely by newbies who haven’t yet learned the necessity of collaboration. They don’t form a majority of members, but it only takes a handful of newbies to waste key early resources or disable town defenses shortly before the attack. The mechanisms required to police this are weak, the game simply doesn’t report who wasted the resources to start construction of the wrong building.

The Grind

This is where the grind comes into play. You can collect experience points that carry over between towns. There’s still no character improvement, the only benefit is unlocking the ability to play in towns that require 100xp. That is, in towns that have no newbies.

The typical newbie-ridden town fails in 1-3 days due to wasted resources and compromised defenses, so a good attempt will earn you 6xp, but 1-3 is typical. You’re staring at 20-40 towns, 2-3 real-life months, before you can start in a town without newbies.

Experience points really do track player experience in this scenario. The player will definitely be very well-experienced by the time they reach the milestone. But it’s incredibly frustrating because you’ll be playing the same game over and over: day 1 everyone yells to build a workshop but someone wastes the needed resources on a portal lock instead, day 2 a bunch of people get stranded outside of town and need rescue, day 3 the town fails. (Sometimes this all happens on day 1, or someone doesn’t give the needed click to turn on the defenses so there’s a total party kill of the town.)

I’m in a guild (“coalition”) with two friends so we’ll appear in the same town, but none of us has moved to get us into a new town in two weeks because the game is so boringly repetitive. We understand the basic mechanics, but we simply can’t play because there are too many newbies and idiots. I could see this being an awesome game to play with a dozen friends, but I don’t want to subject them to several months of grind to get to the “real game”.

A Solution

One thing the game does do right is that if you join a guild with 100xp-friends you can still be pulled along to their town. You probably won’t be a problem newbie because you’ll be relying on your friends in a town that’s already running smoothly.

Spitballing with Ammon (who I’m currently staying with in Austin, TX), I think one improvement would be to start sorting players by experience points immediately. In addition to the 100xp cutoff, put players into towns with similar amounts of XP every time they join a new town.

Each successive town the player joins they’ll see fewer newbies in a town that survives a little longer. Even if there’s a bit of a grind up to 100xp, it’ll be more fun because you’ll see new things each town.

Second, the game really needs to give complete disclosure of who spent resources so that experienced players can quickly and directly responds to newbie wastage. If a newbie already isn’t paying attention to the forums (where people always repost the now-standard Day 1 strategy), they’re not going to learn what not to do because no one knows who they are to reach out to (and perhaps smack) them.

I know a lot of my readers think about game design, what are your solutions? You have a game that’s built around collaboration with other players, but it’s frustrating because new players can’t effectively collaborate.

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.

I’ve kept an eye on the established game industry’s reaction and seen a lot of comments about how the successes of Zynga (Mafia Wars, Vampire Wars, Farmville) and other companies has been based on novelty and cheap distribution. The best essay is Zynga and the End of the Begining. If you’re interested in the growing wave of social games I strongly recommend reading the whole thing (uh, and if you’re not, now is a good time to give up on this blog post), but the specific bits I want to talk about are:

Viral game developers, such as Zynga, have little or no commitment to developing deep or rich game experiences because the market has not really rewarded that kind of activity. However that lack of depth is precisely the reason why viral gaming is showing signs of weakness typical in any runaway success.

Viral gaming up until this point has largely been a game of distribution plays rather than content plays, which is why the developers don’t really spend a lot of time on the depth of their games. In online gaming such as massive multiplayer games or first-person shooters players do not need nudging to come back and play again and again because the experience of playing is so good that they choose to return. No Facebook game comes anywhere close to offering that. They are closer to idle distractions.

Zynga’s games are not being built with renewal in mind. They are experiences built to appeal to novices and they inherently assume that novices are all there is. So they are simple to play, undemanding, lack challenge or consequence, and rely on time-oriented tasks. They may not realise it but Zynga, Playdom and Playfish (and others) are quietly educating millions of novices to expect more and then not delivering it to them.

There’s a simpler explanation that’s less palliative to the gaming industry: there’s a much larger audience available for these games than the ones they’ve been making, even making in the “casual games” genre.

This mass audience wants games without much of any conflict between players, though they’ll sometimes put up with a little for the sake of feeling dominant (eg. Mafia Wars’s fairly impersonal player attacks). They don’t want “Game Over” screens, they may not want any loss to even be possible.

That rules out direct competition, and a lot of indirect competiotion, through the ability to show off successes to friends is essential (not just useful for distribution).

If I’m being cynical, I’d say this adds up to offering people the illusion of advancement and improvement greased by an entertaining spectacle of cute graphics and lighthearted story. Maybe “game” isn’t the right word, maybe we should call these “toys” or “pastimes” or something else to differentiate them from games where players advance skills in competition against AI or players.

My game design keeps mutating and I think it’s turning into one of these passtimes. I started out with something very much like a contest and now it’s about self-expression and collaborative art. It will beta (one of these decades) with very few or no game mechanics at all. I don’t really know what to call it, even though it started as a game.

Street Fighter taught me about yomi: knowing the mind of the opponent. You can’t just play the odds and do the textbook-correct responses, you have to adapt and anticipate your opponent’s moves. The game is merely a medium through which you play against the other player.

Games vary in how much they require skill at yomi, and it occurred to me that a game including yomi skill precludes a game having a Nash equilibrium.

a solution concept of a game involving two or more players, in which each player is assumed to know the equilibrium strategies of the other players, and no player has anything to gain by changing only his or her own strategy unilaterally. If each player has chosen a strategy and no player can benefit by changing his or her strategy while the other players keep theirs unchanged, then the current set of strategy choices and the corresponding payoffs constitute a Nash equilibrium.

Stated simply, Amy and Bill are in Nash equilibrium if Amy is making the best decision she can, taking into account Bill’s decision, and Bill is making the best decision he can, taking into account Amy’s decision. Likewise, a group of players is in Nash equilibrium if each one is making the best decision that he or she can, taking into account the decisions of the others.

Wikipedia

Games like Street Fighter, Kongai, coker, chess, are interesting because they don’t have evolutionarily stable strategies, every player is obliged to change their strategy in response to another player’s change. If a game (or one decision in a game) has a Nash equilibrium, there is no value to yomi, the player doesn’t need to know what the other player plans.

I love the way that poker straddles the line between the two. The contest of who has the best hand is indirect, I can’t take cards out of your hand, you can’t prevent me from drawing, we make our separate choices and win solely by ranking.

But betting is direct competition because players can choose to fold, can drop out rather than risk more resources. It’s a sprint where the players can’t see each others’ positions on the track, only claim “I’m at 40m” or “I’ve lapped you” and the truth of the positions are revealed at the showdown. Betting is a proxy for success, and bluffing is signaling a win when you’re actually losing.

Bluffing uses incomplete information to turn indirect competitions into direct competitions. I only know of Bullshit and Liar’s Dice that could be played without bluffing (and would then be simple luck games, like War).

Because I’ve been thinking so much about bluffing and in/direct competition, I’m tinkering around with a design for a poker variation that includes direct competition. I suspect it won’t be as much fun, indirect competition often leaves a losing player feeling they could’ve done won if they’d played a little differently. Please leave a comment if you know if any that already do or other games that play with similar mechanics.

• 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.

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.

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.