The Three Biggest Problems Facing PBBG Designers Today

Problem #1: Party Of Two Or Two Thousand

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.

Wish there was more?

I'm considering writing an ebook - click here.

.

John Munsch is a professional software developer with over 20 years experience. He created a series of game development sites (XPlus and DevGames.com) on his own before co-founding GameDev.net in 1999. The blog for his PBBG work is located at MadGamesLab.com.

Tags: , , , , , , , ,

Tuesday, February 17th, 2009 balancing, design
  • Scion
    The first problem i think is fairly easily cleared up by the designers intentions for the game, In the example above Tom has clearly indicated hes is designeing his game for single users....other design for small groups or for large open groups. To me the problem with the number of players is will the game still be fun if played with a different number than was envisioned.

    If your game really needs several thousand players to get going...because they need to create an economy or provide a viable game environment, but the game only has several hundred currently active users then you have a problem. So for me its really how do you solve any mis-match between design expectations and actual conditions.

    Regarding problem 2, this sort of ties into the 'goal' issue that Tom also raised. Most MMORPG players are quite happy to suspend their belief and accept a stasis world, but these kind of setups often lead to unclear game goals...or the goal is simply to keep building up your character. If a game sets clear goals then that might help to retain players.

    The lack of clearly defined goals would also appear to be a major factor in the reduced uptake of game playing amoungst females, at least thats what the literature that ive read says, and is highlighted by Toms wifes comment :)

    As for how to deal with player churn, I think you need to consider this in the design stage and ensure that your game is not adversely affected by it.

    Finally regarding point 3, i hold to the idea that "just because we can doesnt mean we should". Namely just because we can make something complex, doesnt mean we should. The corrolory from einstein..."Everything should be made as simple as possible, but not simpler."

    Im sure we've all seen games where some special event appears to happen randomly with a very small chance, and as developers we can guess that what theyve done is simply generate a random number and compare it to some threashold, Yet amoungst the player base there are all sorts of beliefs and theories about how you need to do this , then that ...then something else and it will increawse your chance of that event occuring....This exemplifies peoples innate ability to overcomplicate things, so rather than overcomplicate your game code, let peoples imaginations complicate it for you.

    I prefer to hide (or eliminate altogether) as many of the variables as possible. Not only does this help keep the game interface simple, it also keeps the games code base simple, and allows room for the players to imagine the complexity. (in fact i may even hint at hidden complexity in the games helpfiles :) just to make sure that the seeds are planted)
  • Red
    Being completely new to the whole programming game scene, trying to predict what the game will actually be like as a result of all the programming is something I consider a bit of a pain. A potential solution for implementing site wide changes that I would consider for large sites would be making them beta-mode first, optional and testable and not a complete change, perhaps only temporary. Then, when the user reaction has been gauged, release it or nip it in the buds.

    Something like that would be a bit beyond my skill for the moment but anyone with that big a site must have some talent at getting the affects they want.

    As for some of the other large-numbers problem, those would vary from game to game, as each has different styles. For myself, I generally prefer single-player with tacked on multiplayer features type games. I have seen large sites handle large numbers of users in that style and it works. The biggest problem I've seen in sites is inflation of virtual money, to be truthful, since sites with user shops and such often have no taxation or anything to balance money in a place where it is constantly being pumped in by new users. Users buy features which they then sell again to make more money-- and the virtual coin goes through the roof like mad.
  • Tom
    For the PBBG I'm developing, these kinds of decisions have been fairly easy because I'm building the kind of game I'd want to play first, with consideration to what others might like second. To me that makes sense because game development is a hobby for me and if no one else wants to play it, at last I'll have fun :)

    Regarding Problem #1, my game is essentially a single-player CRPG with persistence. Each player begins with his own world with procedurally-generated terrain, cultures, and quests. The player can invite other players into his world, perhaps to help with a hard quest or maybe every time he logs in (making it a sort of shared world in that case). Right now the player can invite up to two others, but I'm keeping an eye on how that's working to see if more might be practical. There's also a unified lobby where all players who are logged in can chat and view others' accomplishments.

    On Problem #3 and issues of complexity, I tend to look at it from three angles: the complexity of the underlying systems; the complexity you present to players; and the complexity the players can elaborate from the given pieces. The original iteration of the Magic: The Gathering collectible card game is an example where the underlying mechanics took a lot of balancing, but the choices presented to players within the game were pretty straightforward at any given moment. Nevertheless, the potential combinations of those choices were really fertile ground for novel strategies and deck-building techniques. Personally, I think that as they added more mechanics over time, and thus more choices for players, the game became more difficult to learn and the potential strategies harder to hold in your head at one time.

    The question of how much complexity to present to the player is the difficult one for me. I tend to want to abstract as much as possible of it away, but I suspect there are many players who really want to know what's going on under the hood. I remember Ultima Online originally having skill levels measured in whole numbers from 0 to 100, then later adding the ability to view the fractional skill levels (e.g. 70.25) at the insistence of the players. So maybe the best decision is to let players choose a level of detail that they're comfortable with.

    A PBBG design problem for me is how you bring a sense of purpose to a persistent game. My wife's question about MMORPGs is always "What's the goal of this game?" And it's true that the goal is often "do quests so you can level up so you can do harder quests; wash, rinse, repeat." With my design, I've tried to add some additional goals by having a world "winnable" at which point the player gets to enter a new unique procedurally generated world, perhaps with radically different terrain and cultures to interact with. As an exploration-oriented player, this particularly appeals to me.

    A last challenge I'll mention is more of a technical design question, but it's the classic one of how much work you put on the server and how much on the client, realizing of course that if the client is a browser, as in the case of PBBGs, that the Javascript and XHTML are trivial for the user to inspect and the current values of Javascript variables and any cached images (such as maps) are also readily accessible for a user who know what he's doing. At the same time, the client's computer likely has a lot more unused processing power than your server at any given time and you also want to limit how much bandwidth you're using. Every game design decision ultimately comes down to the question of how I'm going to implement this in a way that discourages cheating but doesn't tax the server unnecessarily.
  • JohnMunsch
    In a single player (or largely single player) game like the one you're working on, I'm content to let the user peek behind the curtain if they want to. Let them look at the JavaScript you download and maybe spoil something in advance, they're only hurting their own enjoyment of the game.

    If they think they're going to get some bragging rights because they finished everything faster than other people I think they'll find that others will be naturally suspicious of any advancement that seems "amazing".

    In multi-player games though, the server has to be the gatekeeper to every scrap of information. As the various first-person shooters have shown over the years, you can't even ship down information about another player's location on the other side of the wall. Somebody will try to hack things so they can see through the walls on their client side or whatever the equivalent is for your game if you let too much leak.
blog comments powered by Disqus

About

Building Browsergames is a blog about browsergames(also known as PBBG's). It's geared towards the beginner to intermediate developer who has an interest in building their own browsergame.
Dreamhost

Got Something to Say?

Send an e-mail to luke@buildingbrowsergames.com!

Follow Building Browsergames on Twitter!

http://twitter.com/bbrowsergames

Sponsors