“It’ll all be real-time, and we’ll need at least six database servers just to handle the sheer amount of awesome!”

..The reality is, especially if it’s your first game, you won’t be able to build something quite that large(and most of the sites you visit on the internet don’t even use two database servers, anyway). However, that doesn’t mean that you can’t start taking the first steps, by getting something out there.

But what if you’re attached to your design, and that is what you want to build?

The simplest answer is trimming – take your entire design, and start stripping things away. Generally, I find that it’s helpful to make two lists – “things that have to be there”, and “things I want to have be there”. Then, you take all of your design notes and figure out what goes onto which list.

One of the easiest ways to do that is to start by putting everything onto the “things I want to have be there” list. Then, move pieces of your game over, one-by-one. Generally, things that are worth moving over are:

• Self-contained

  The feature shouldn’t rely on any other features to work. You’re getting your game up and running so that you can add more to it, not so that it will fulfill your design perfectly from day one.

• Small

  If one piece of your game will take two months to build, and each other piece averages a few days to a week, that feature isn’t a very good candidate(no matter how cool it is). Especially when you’re building your first game, motivating is hard – the more easy wins you have while you’re building it, the less likely you are to get discouraged and stop. One of the easiest ways to get easy wins is to focus on easy features in your first version.

• Low-resource

  Most of the developers that I have seen starting to build their own games have been working in a shared hosting environment, paying $5/month. And while your game is in it’s fledgling stages, that’s fine – but if a feature on your list calls for six database servers, you may want to keep it on the “I want” list instead of the “I need” list until you can actually justify the resources.

• Playable

  The last, and probably most important point, is that your feature needs to be playable. If that feature you’re considering moving over is really super-cool but isn’t something the players can interact with, it shouldn’t be in your first version. Building features that no one can see is a bit of a gamble even when your game is established; what are your players going to care if they can’t see it?

Once you’ve gone over your list and moved the bare minimum of features over to your “things that have to be there” list, you’re ready to start working on your game. Keep both lists somewhere that you’ll see them often, and while you’re building your game periodically review them – a lot of the time, features that you’ve built into your game will make it so that other features you wanted to have(but kept off your list) are now possible – and even easy.

You know how board games always have something on the side of them that says, “For 2-5 players,” or something like that to indicate how many people the game is sized for? It’s partially a practical thing, they can’t include enough cards or tokens or a board large enough for a group of 30, but it’s also a factor in the game itself. It was never tested for 30 people, for that matter it may just not work very well when scaled to 30, 300, or 3000. There are PBBGs out there with 30,000 people on a single server, how do you even design a game like that?

I have no idea. Literally, no idea whether the game I’m working on now will be fun when I throw lots of people at it. It could suck. It will suck, the creator of BattleMaster virtually guarantees it, and you know what? He’s probably right.

My current hope is that I’ve got a good idea for a game and I’ve taken the same path a lot of games take by giving every player basically the same starting conditions so they’re left to their own devices in competing with other players. But is just starting with a level playing field enough? Is there a way other than playtesting and adjusting, playtesting and adjusting to have a better idea of how to make a game interesting when you don’t even know how many people are going to play it?

One possibility I’ve considered is the idea of forcing division into groups upon the players. Creating a game and really balancing it well for say 25 and then as players join they automatically get assigned to a group until it hits the magic size and the game gets going in earnest. So a single server might be running hundreds of games at the same time rather than one game with thousands of players. Short of sites that let you play real board games online (e.g. http://gametableonline.com/) , I’ve not seen anything like this though and as with all these questions, I’m not very sure how well it would work short of building a complete game and testing it.

I know it does offer some possible advantages because you can actually have certain people fill certain roles. There will be only three people who can be doctors, two police officers, 12 zombies, etc. The roles are set and they play them out till the end of the game. Cooperative games are all the rage in the board game world right now and often they work on this very principal (e.g. Battlestar Galactica). I’m so-and-so and here’s what I can do. I have in-game abilities that maybe nobody else in the game has and vice versa. You can even have traitors who are working against the group but nobody knows who they are or perhaps even if there are any.

But then what do you do when one of them leaves?

Problem #2: Someone Comes To Town, Someone Leaves Town

In addition to being the title of a book by Cory Doctorow that I really enjoyed, this is how I describe a problem that I see as one of the worst ones a persistent online game may face. People come, try it, and then leave never to come back. Or they join it to stay but only a couple of days before it is scheduled to end or after all the empires are all built up and the game experience is completely different from players who started the game together.

Board game players don’t face this problem nearly as much. Sure, people get called away for emergencies on occasion, but the social convention is that if you’re coming to play that you’ll stick with it until the end of the game. Board games tend to have fairly short lifespans compared to PBBGs though. With timeframes of weeks or months their games are much more likely to have people quit because of something coming up or losing interest. What happens to those players? Are they a zombie that sits there unresponsive while the player is gone? Do they become a computer controled character when the player is away? Do they fade away as though they never existed?

New players are more easily dealt with. They can be shunted off to a newly opened game in order to keep them from joining too late. Or, if you design an open-ended game then perhaps it won’t matter when they join. Most MMORPGs are constrained to their world needing to exist in a kind of weird stasis. Yes you obliterated that dungeon full of bad guys yesterday. Today, it’s all put back together so someone else can go do the same thing. You’re living in WestWorld and Yul Brenner’s gunslinger will be just fine as soon as we repair him.

Problem #3: Numbers, Complexity, and the Digging of Holes

The last of three big problems that I see PBBGs having to deal with is the problem of numbers and complexity. It’s not that board games don’t have to deal with lots of variables and complexity too, they do. The introduction of a lot of different elements is what keeps a game from being something easily analyzed and “solved” to the point where it’s no longer fun to play. The problem is again one of scale.

Any board game designer has to deal with complexity by saying, “What can my players manage in their head with a few additional play aids I might give them?” Scoring, number of pieces, number of cards, size and complexity of the board are all constrained by what real people can really hold in their hands/calculate/see. But as soon as you get a computer involved the temptation is to throw out all of that. I don’t have to have only four kinds of armor, I can have 40! I can have 150 different weapons, all with subtly different values for attack and defense. I can even have each one keep track of how sharp it is. It can get worn down over time…

But then that complexity comes home to roost when it’s time to actually playtest that game. How do you adjust a game with four thousand variables without getting your own version of the butterfly effect. One little tweak here makes a huge difference over there, or perhaps even worse, a huge change here has almost no effect because of the unforseen influence of some other things you can’t seen working in the background. The more complexity you put in, the richer your game seems. But at the same time you’re digging your own grave deeper and deeper.

This is probably the most solvable of the three big problems; just scale back. But scale back to what? Unless you’re willing to lock the number of players per game at a fairly small number, what are the effects of a small tweak when it may change things for hundreds or thousands of players? Is it going to completely upset the economy in your game?

In Conclusion

What do you think are the biggest design problems PBBGs face? Have you seen solutions to these problems in existing games or have ideas for solutions that no one has tried yet? I know I’m looking forward to hearing from others interested in PBBG game design on these and other problems.