#33: The Fun Factorby Shannon Appelcline
November 26, 2001
You'd think if anything would be easy, it'd be this. Build a game that people will enjoy. It seems like a very basic premise. I mean, games are supposed to be entertaining, aren't they? Yet, somehow, there are a lot of game designers and engineers alike who mess this one up. They create games that just aren't fun to play. They're boring or repetitive or seem unfair or ... whatever.
The games fail, and the engineers tend to end up not only with egg on their faces, but also with a vague sense of confusion. They don't understand what happened. How could their game not be fun?
How Games End Up Not-Fun
The reasons for a game not being fun can actually be very wide and varied. Bad luck, things turning out differently in practice than they seemed on paper, unfortunate conjunction of Jupiter, Mars, and Pluto, whatever. When it's all said and done, however, I suspect there are three reasons that contribute more to the not-fun-ness of games than anything else.
1. The game designers design for themselves, not the players.
This classic error is especially prevalent in the world of online games. I think things developed like this:
Many of the earliest online games were created at universities. These included MUDs and MUSHes, but also any number of multiplayer graphical games, like xconq, netrek, and even nethack. The engineers who wrote these early games were hackers--programmers who wrote games for the sheer joy of watching the pieces of code fit together, and then seeing what happened when they actually ran.
Many of these hackers were, I think, shocked when they released their beautifully crafted, terribly hacked, code to the world and suddenly found they had players. They'd never been writing for anyone but themselves, building little monuments to computer code purity and to game design philosophy within their virtual worlds. Pleasing other people had never been an issue for them.
Today many of these same once-student once-hacker online-game-programmers are working for the big companies, churning out MCRPGs to be played by tens of thousands ... and they're still not thinking about what will please players. Instead, they're continue to consider those beautiful philosophies and that pure code, and they keep building stuff to please themselves
A good game designer has to actually look at the market, and see what the public likes, not just what would please him.
2. The game designers don't listen to the players afterward.
When an online game is released, it most definitely is not done. There's the whole question of administration, which I briefly mentioned last week. But, there's more than that. Engineers need to keep working, for at least awhile, balancing, fixing, and expanding the systems that they built for their initial release. Players are going to have lots of opinions about what should be done.
It's easy to fall into the old customer support trap that claims "the customer is always right." In truth, this is a fair bit of malarky. Quite often, the customer is wrong. He might want you to do something for his own selfish interest or he might ask for a change without truly understanding how it affects the game overall. But, it's equally easy to fall into the reactionary view on the other side, and to refuse to listen to what your players say at all.
The correct answer is somewhere in between the two extremes. Players are going to spend a lot more time playing in your game than you ever spent programming it, and in a few months they're going to have much more insight into the game than you do. So, listen to them, and consider the ideas that they have. They might be totally different than your own ideas, but they might also be better.
3. The game designers get caught up in beautiful abstractions.
It's pretty easy to come up with an absolutely beautiful idea for a game system, engineer it, and then have it fall flat on its face. Ultima Online, for example, did something that MCRPG designers had been trying for a decade. At release, it included an ecological simulation which respawned monsters based upon where monsters currently existed. It was simulating breeding, and had the possibility to be a lot more realistic than the traditional "reset" systems where a killed monster just reappeared after a little while.
Unfortunately the ecological simulation didn't do a good job of taking player influence into account. As a result all the monsters got wiped out, there were no more to breed, and players started having not-fun in a big way. Origins did the right thing. They scrapped the ecological simulation and replaced it with a more traditional "reset". They were able to put their beautiful abstraction away when it crashed and burned in the face of harsh reality.
It's a lesson that any game designer would do well to learn.
How Games End Up Fun
That's all well and good, you might say, but I want to make a game fun. How do I go about doing that? As with not-fun, fun is a mixed bag. What's truly enjoyable is different for every one of us. Nonetheless, I think I can once more highlight a few things that can, in general, increase the fun-ness of MCRPGs.
1. Set Your Player's Expectation Correctly.
This is a good general rule for any type of interaction with a customer, player, or client. They'll be happier if they know what they're going to get before hand.
You get the idea!
2. Offer Rewards.
In general, players are going to be happiest when they're being rewarded, be that via experience points, cool new items, monsters killed, or whatever. What types of rewards you offer to players, and how you do so, can influence "The Fun Factor" quite a bit. So, I'm going to save the topic of rewards until next week, when I'm going to devote an entire column to it.
3. Make Sure You Have Fun Players.
You want to encourage great role-players, great socializers, and compassionate competitors who are going to be fun to be around. At the same time you're going to want to discourage people who are going to wander around spoiling every one else's fun.
In many ways, the background that you create, as presented in the "rooms" of your game forms the core experience of a player in your MCRPG. But, equally important, is the palette of other players that you present the players with. You need to make sure they're fun to be around.
4. Constantly Offer New Experiences.
As I'm going to discuss down the road in "The Dynamic Dilemma", one of the hardest things to do in an MCRPG is to constantly offer new experiences, because you've got a limited staff of gamemasters trying to stay ahead of uncounted hordes of players.
On the other hand, there's little doubt that these new experiences form some of the greatest fun in a game. Players love to solve brand-new puzzles, to explore new rooms, to find new objects, and to meet new NPCs. They love to see plots develop that slowly change the landscape of the land that they're familiar with.
In other words: change is good.
Engineering for Success
So, how do you do all of this? Even knowing all of these problems and all of these fun-filled activities, how do you make games that actually are fun?
It's pretty easy to avoid the don'ts if you're aware of them. Just:
As for the things you can do to directly ensure fun ... I'm going to punt on two of the questions--the issues of rewards and dynamic games. They're very definitely pure engineering issues, but they're also pretty big topics. I'm going to talk about rewards next week; I have a fair amount to say on them, some of it controversial. The issue of dynamic games is even bigger, and so I'm going to spend three or more articles on it, but not till next April(!), as it's the last topic planned in this current series.
Ensuring that you have fun players tends to be an issue of social engineering ... not about game systems, specifically. But, as I've mentioned before in this column, in Thinking Virtually #18, The Game is What the Game Is , you can engineer social systems by engineering game systems.
Want to encourage good players? Easy. Create a game system that lets people give each other "roleplaying" points for great scenes, then let players buy neat bennies with those points. Or, create a game system that allows sufficiently trusted players to banish trouble makers. Or, keep new players isolated to a specific portion of your game until you've proven yourself.
Any game system you create will encourage certain types of play. As you consider the criteria I've set for fun, or as you discover new ones yourself, consider how game systems could encourage those types of play.
Want to make sure players have good expectations? You can't exactly encourage that sort of game play, like you could encourage good players, but you sure can build game systems that do great jobs of setting player expectations. Do your game systems have limitations? Can only wizards cast spells? Can only knights enter your court? Can players only understand their own languages? Make sure your systems all do a great job of explaining these limitations. Have your magic system explain "Only Wizards can cast spells," not just say "You can't do that."
The more your game systems explain themselves, and the more your players understand their limitations, the happier they'll be.
If I can impart one message through this column this week, it's this: the whole question of whether players will have fun is pretty central to the design of your game. But, as you discover what is fun and what isn't you'll be able to engineer game systems to support the most fun activities.
Your game systems are tools; use them.
And that brings me to a close this week. Next time I'm going to get a little closer to the nuts and bolts of engineering fun by explaining the psychology of rewards.