Note: I've been using "mechanic" to refer to what the game does "behind the scenes", and using "gameplay" to refer to what the player does with his time. However I'm used to using "game mechanic" and "core mechanic" to refer to what I'm now referring to as gameplay... I think I need to revise my nomenclature. (See my previous post on game design theory for some discussion on these terms.)
Definitions
Players give many reasons for playing games, but do you trust your players? Are they all sufficiently introspective and educated to understand their own motivations? They know if they enjoy something, but I'm talking about why they enjoy it. I'll go into my own theory of fun at some later point, but for now, let me say that one of the reasons that players enjoy games is the status that they can show off for their achievements.
I'm not talking about achievement directly. If happiness is the achievement of value, then a well-adjusted person is happy (and enjoys a game) when he achieves game goals that he values. But that's not status -- status is telling your buddy how you did in the game last night, or riding your new mount through a capital city in Warcraft.
The issue is a bit complicated becomes there's both showing others as well as knowing that you achieved that status item. The braggart doesn't care about getting a status item except to the extent that he can brag about it. The latter is like the guy I mentioned above, someone that has internalized the game goals as his own values and enjoys the status symbol as a record of achievement.
My point is that it doesn't matter why a given player wants a status item -- just that he does want it.
The lesson is obvious: put status items in your game.
Examples
Many games have implicit status items. In RPGs, it's your character's gear. This is one of the great driving forces in WoW: do you have your dungeon 3 set? A flying mount? An epic flyer? Tier 4? Tier 6? Legendaries? Status in MMOs also comes from the group you play with: has your guild cleared Kara, Gruul's, or Black Temple? How far are you through the Plateau? I'm calling these status items implicit because the only obvious score in the game is your level - and is the same for all players at max levels.
In platformers, progress through the game and the accumulation of collectibles and tokens are status indicators. The game tells you what the status items are, and how many you've gathered so far. Yet these items are intrinsic to gameplay; the game is essentially nothing but pushing your status up.
In multiplayer first-person shooters, your status is your standing on the leaderboard. There's not much else to the game other than that score. Single-player shooters might also have a leaderboard that's shared; XBox 360 games typically have a Live component that shows how you measure up against the playerbase. (Level-based shooters have implicit status measured as progress through the game.)
The 360 brings up another way of gaining status: achievement points. I was playing Guitar Hero with a friend last weekend and he was going for a bunch of easy achievement points to push his Gamer Score over the 20,000 mark. We were joking about the arbitrariness of the achievement, even while going for it.
That's the way the brain works
It's the way the brain works -- which is my message here. Even if you know you're shooting for an arbitrary or meaningless goal, you do it anyway. Some people gloat in their shiny new beemer or tier 4 set piece or gamer score, and for them status symbols are clear motivators. The rest of us kinda catch the same disease by association. We might not feel the need to tell everyone about our status, yet we seek it just the same.
It's the score, it's what you're supposed to do.
This ties in a bit with my previous discussions on open worlds. Be careful of removing any sort of status indicator, or your player might think he's stumbled on a toy and wonder what he's supposed to do with it. Obviously we don't want to play or design boring games that people feel stuck playing just because they're chasing some status symbol. However, if your game is good, that status symbol can show them the way.
Don't be afraid of character levels; players like them. Use them to point your players towards the fun stuff you put in the game.
Friday, August 1, 2008
Thursday, July 31, 2008
Slowing Players Down
Players vary wildly in the amount of time they have to spend on a game. Some -- teenagers, the retired, the unemployed, addicts -- can spend nearly every waking moment playing a game. As far as the average player is concerned, this level of dedication is effectively identical to the player that spends every evening (say, five nights a week) playing.
And then there's casual gamers, a hard bunch to pin down. Some play casual games as much as the hardcore addicts mentioned above, but somehow they don't "count" because they're not playing "mainstream" games. Obviously I have issues with this distinction, so I'm just going to bypass the issue. What concerns me here is players that play one of these addictive games (like, say, WoW) but only casually, one night a week or maybe a few hours a week scattered here and there.
One common thread of discussion in MMO design is the disparity between these two groups. Some players will pour thirty or forty hours a week into a game and others just a handful. How do you keep the second group relevant? One obvious answer is by Slowing Players Down, a solution that can be implemented in numerous ways.
Of course, any attempt to categorize such a range of concepts doesn't really capture the full range of possibilities. Categories are there to help us cope. So don't take my categorization as an attempt to define all possibilities. I'm just categorizing to help explore the range of solutions.
One solution is to cap the amount of progress players can make over a period of time. Another option is to give players distracting time-sinks that might be accomplished offline instead, allowing casual players to catch up to more dedicated players. A third solution I'll explore is to give players resources that replenish in real-time. The non-solution, letting hardcore players outpace their slower fellows, is the foil by which I'll compare the other solutions.
Cap Progress
In China, players are only allowed to play for five hours before their abilities are suddenly decreased in power. Limiting the amount of experience players could gain in a session only limits players levelling up; players in the end-game are also limited if their abilities suddenly don't work any more.
This is a severe encouragement for players to just log off. They might stay online and socialize, but often a major enticement of socialization is the possibility of getting a group together to do something. When that possibility is gone, the only thing left to do is chat. Certainly, some players might continue chatting, but I think this is a mechanism that will catch most players.
Putting a hard time-dependent limit on players abilities is fairly harsh. Generally you want your players to play your game. For an MMO, time investment is the major factor influencing "score" or status within the game. Heavily-invested players continue to play more because they want to maintain and protect that investment. This is a mix of the endowment effect and emotions such as commitment and attachment. When you tell players they have to stop playing, they might realize that they can stop playing -- that maybe they can be doing something else with their time. I found it much easier to stop playing WoW after periods when I was away from home or lost internet connectivity at home. Being frustrated when one wants to play (eg when the servers are down) associates those negative emotions with the game. When the stop rules are arbitrary, the player also grows to resent the developers and the game by association.
That's not to say that you can't get away with it. Tuning the stop rule is tricky, though, and you'll also be pissing off some of your player base.
Ultimately, I consider this solution the default; the cop-out easy solution to take when you can't build anything else into the game to help balance out the disparity between hardcore and casual players.
Time-Sinks
Another simple solution is to make players do something boring and time-consuming to progress. This is like the hard-cap, above, but ... well, soft. ATITD happens to have a number of these time-sinks. The problem here is that dedicated players get stuck doing something boring if they want to progress. Some hours, progress is fun; other hours, progress is boring. Hardcore players decide your game is boring, and then bam! they stop playing altogether and unsubscribe.
The trick is coming up with a time-sink that can be accomplished offline, but yet is still fun. Giving the players the option of pursuing a different advancement track dodges the progress issue. But you effectively bundle two games into one product, which means you need to two games. If hard-core players will be spending as much time on (say) tradeskills as they will doing combat, then tradeskills need to be as deep and interesting as combat is. Making combat sufficiently interesting and balanced to keep players subscribed is hard enough and now you want to make two systems that complicated?
A solution like forcing players to run around, on foot, to continue progressing is punishment. You're better off putting in a hard cap.
Real-Time Resource Replenishment
Eve uses this sort of model: players gain skill points whether they're online or not. Eve's developers CCP have effectively dodged the problem of developing two different games. Most MMORPGs have two major forms of score: assets and experience. ('Assets' includes both gear and gold.) Eve just sunders the XP into its own pool. Players can continue accumulating Isk in Eve while they play online, but if they want to take a break they can log out and know that tomorrow they'll have higher skills available.
WoW itself uses this model somewhat in their rest system, and in fact this problem -- helping casual players to keep up with the hard-core -- was the major reason they introduced it. In WoW, you gain "rest experience" whenever you are logged off. It accumulates fairly slowly; you won't be able to keep pace with your catassing buddies, but gaining XP more quickly when you do have it is refreshing.
ATITD uses this model, somewhat, but it's tied in with the rest of the game being a slow, tortuous death. Am I biased? Do I sound jaded? I think I'll move on.
Travian also uses this model: your resource farms continuously produce more goods according to wall time. Every (e.g.) twenty seconds or so you see one of your resource counts tick up. I've never played Eve, but I've played Travian, and this mechanic seems the best to me for solving this process. Players that excel in Travian pay attention to the costs of infrastructure, resource, and military units, and develop strategies that help them maximize growth. The game isn't about clicking on your town and building new grain farms and iron mines; it's about deciding which one to build first -- or if you should recruit more troops instead.
And there lies the crux of the issue. Whereas the two previous methods were ways of hamstringing and punishing players, here is a mechanic that assumes an equal footing. The even distribution of resources to hardcore and casual players alike levels the field out considerably. There are still ways for the hardcore player to extract more resources from the game but it is nothing like the disparity between WoW catassers and casuals.
Conclusion
If a game allows a player to gain a significant advantage by spending more time online, one can't "fix" that by throwing in a couple hurdles. Nor is it the sort of thing one can throw in at the last minute. A holistic solution is more effective as well as more elegant. In Eve and Travian, the slowdown mechanism is intrinsic to basic gameplay.
One might take issue with slowing down players at all, and that's something I'll tackle at a later time.
And then there's casual gamers, a hard bunch to pin down. Some play casual games as much as the hardcore addicts mentioned above, but somehow they don't "count" because they're not playing "mainstream" games. Obviously I have issues with this distinction, so I'm just going to bypass the issue. What concerns me here is players that play one of these addictive games (like, say, WoW) but only casually, one night a week or maybe a few hours a week scattered here and there.
One common thread of discussion in MMO design is the disparity between these two groups. Some players will pour thirty or forty hours a week into a game and others just a handful. How do you keep the second group relevant? One obvious answer is by Slowing Players Down, a solution that can be implemented in numerous ways.
Of course, any attempt to categorize such a range of concepts doesn't really capture the full range of possibilities. Categories are there to help us cope. So don't take my categorization as an attempt to define all possibilities. I'm just categorizing to help explore the range of solutions.
One solution is to cap the amount of progress players can make over a period of time. Another option is to give players distracting time-sinks that might be accomplished offline instead, allowing casual players to catch up to more dedicated players. A third solution I'll explore is to give players resources that replenish in real-time. The non-solution, letting hardcore players outpace their slower fellows, is the foil by which I'll compare the other solutions.
Cap Progress
In China, players are only allowed to play for five hours before their abilities are suddenly decreased in power. Limiting the amount of experience players could gain in a session only limits players levelling up; players in the end-game are also limited if their abilities suddenly don't work any more.
This is a severe encouragement for players to just log off. They might stay online and socialize, but often a major enticement of socialization is the possibility of getting a group together to do something. When that possibility is gone, the only thing left to do is chat. Certainly, some players might continue chatting, but I think this is a mechanism that will catch most players.
Putting a hard time-dependent limit on players abilities is fairly harsh. Generally you want your players to play your game. For an MMO, time investment is the major factor influencing "score" or status within the game. Heavily-invested players continue to play more because they want to maintain and protect that investment. This is a mix of the endowment effect and emotions such as commitment and attachment. When you tell players they have to stop playing, they might realize that they can stop playing -- that maybe they can be doing something else with their time. I found it much easier to stop playing WoW after periods when I was away from home or lost internet connectivity at home. Being frustrated when one wants to play (eg when the servers are down) associates those negative emotions with the game. When the stop rules are arbitrary, the player also grows to resent the developers and the game by association.
That's not to say that you can't get away with it. Tuning the stop rule is tricky, though, and you'll also be pissing off some of your player base.
Ultimately, I consider this solution the default; the cop-out easy solution to take when you can't build anything else into the game to help balance out the disparity between hardcore and casual players.
Time-Sinks
Another simple solution is to make players do something boring and time-consuming to progress. This is like the hard-cap, above, but ... well, soft. ATITD happens to have a number of these time-sinks. The problem here is that dedicated players get stuck doing something boring if they want to progress. Some hours, progress is fun; other hours, progress is boring. Hardcore players decide your game is boring, and then bam! they stop playing altogether and unsubscribe.
The trick is coming up with a time-sink that can be accomplished offline, but yet is still fun. Giving the players the option of pursuing a different advancement track dodges the progress issue. But you effectively bundle two games into one product, which means you need to two games. If hard-core players will be spending as much time on (say) tradeskills as they will doing combat, then tradeskills need to be as deep and interesting as combat is. Making combat sufficiently interesting and balanced to keep players subscribed is hard enough and now you want to make two systems that complicated?
A solution like forcing players to run around, on foot, to continue progressing is punishment. You're better off putting in a hard cap.
Real-Time Resource Replenishment
Eve uses this sort of model: players gain skill points whether they're online or not. Eve's developers CCP have effectively dodged the problem of developing two different games. Most MMORPGs have two major forms of score: assets and experience. ('Assets' includes both gear and gold.) Eve just sunders the XP into its own pool. Players can continue accumulating Isk in Eve while they play online, but if they want to take a break they can log out and know that tomorrow they'll have higher skills available.
WoW itself uses this model somewhat in their rest system, and in fact this problem -- helping casual players to keep up with the hard-core -- was the major reason they introduced it. In WoW, you gain "rest experience" whenever you are logged off. It accumulates fairly slowly; you won't be able to keep pace with your catassing buddies, but gaining XP more quickly when you do have it is refreshing.
ATITD uses this model, somewhat, but it's tied in with the rest of the game being a slow, tortuous death. Am I biased? Do I sound jaded? I think I'll move on.
Travian also uses this model: your resource farms continuously produce more goods according to wall time. Every (e.g.) twenty seconds or so you see one of your resource counts tick up. I've never played Eve, but I've played Travian, and this mechanic seems the best to me for solving this process. Players that excel in Travian pay attention to the costs of infrastructure, resource, and military units, and develop strategies that help them maximize growth. The game isn't about clicking on your town and building new grain farms and iron mines; it's about deciding which one to build first -- or if you should recruit more troops instead.
And there lies the crux of the issue. Whereas the two previous methods were ways of hamstringing and punishing players, here is a mechanic that assumes an equal footing. The even distribution of resources to hardcore and casual players alike levels the field out considerably. There are still ways for the hardcore player to extract more resources from the game but it is nothing like the disparity between WoW catassers and casuals.
Conclusion
If a game allows a player to gain a significant advantage by spending more time online, one can't "fix" that by throwing in a couple hurdles. Nor is it the sort of thing one can throw in at the last minute. A holistic solution is more effective as well as more elegant. In Eve and Travian, the slowdown mechanism is intrinsic to basic gameplay.
One might take issue with slowing down players at all, and that's something I'll tackle at a later time.
Labels:
game design,
wasting time
Tuesday, July 29, 2008
Exploring Game Mechanics
Among the Bartles types, I'm primarily an Explorer. Specifically, I enjoy exploring game mechanics. All my charts and spreadsheets for Travian were, in part, to figure out how the game mechanics manifested -- what was the most efficient way to goal X?
With a toy, people develop their own goals. Either they (incorrectly) perceive the game to have a goal that you are "supposed" to achieve, or they explicitly choose something to explore, or they do what they did in the previous similar game that they played. I'm going to explore each of these in turn.
Misperceived Goals
When players project a goal onto the toy, they become frustrated when they get to that goal and they aren't rewarded. The same thing can happen when they are playing a game and misperceive the goal. This is especially frustrating when the game did a poor job of communicating the goal. If it's only once the player has played towards the goal that they understand it then you've lost an opportunity to keep that player happy. (Unless your mechanic is confusing players, in which case you're developing a niche title, and rah for you. I'm not talking about small-market hardcore games.) And some players might get distracted along the way, but that's besides the point.
Challenge is important in games, but only in that it manifests as perceived challenge. Since it's unlikely for a game to be challenging but not seem so, the important point here is the contrapositive: a game that players perceive to be challenging but really isn't. Players succeed and think they're smart in doing so. In the case of our toy with misperceived goals, players find the game to be extremely challenging and themselves to be under par because they can't win. I don't like losing, even if it was a good fight. I prefer losing a good fight to winning on a coin flip (unless we're talking real money, in which case it's better to be lucky), but losing when it's an unfair fight weighted against me just makes me frustrated.
The root of such frustration is misplaced expectations. Manage your player's expectations. If you've built a toy, let the players know.
Choosing Exploration
Experienced explorers tend to know they're explorers. Maybe they haven't heard of the Bartles types, maybe they don't think of it that way, but when you sit them down in front of a toy (or game), they'll go to work taking it apart and figuring out its mechanics.
To them -- or, I should say, to us -- figuring it out is the game. We're curious. I've got a competitive side, and that manifests as wanting to know the rules. Since most games don't document themselves well that often means it's up to the players to figure out how to win, whether one strategy is better than another. In strategy games, this is, really, the point, but there's also a mechanical aspect to winning: just how effective are the various units? If you face two off in a fight, which one will win? Which is more cost-effective? These sorts of explorers are comfortable with math -- at least the basic algebra used to derive these effectiveness measures.
Other explorers want to figure out your AI -- do feints work? Can they draw the NPC troops into an ambush? A great many players fit into this type of explorer mold, and it's generally an explicit part of many games. For toys, of course, there's no goal to win, so exploring the AI in a toy is a chosen goal.
Trying to keep mechanics-explorers happy is a difficult process. The more successful your game, the more people will be trying to figure it out. There's so many people playing WoW, for example, that the only undiscovered rules are those for the rarest and most inaccessible of content. Even in complex-rule games like ATITD, there's enough people pounding at the formulas that a great many of them have been found. There's two things going for that game here, though: (1) many of the rules are still very complex, such that the basic formula is sufficiently obscure that it wouldn't have been discovered except for developer intervention, and (2) the player base is small enough that there's only a small group dedicated to exploring any given mechanic. Yet it's a great example for developers looking for ways to keep their mechanic-explorer playerbase happy.
Default Play
This is the catch-all category. "Default Play" is what happens when gamers are given a toy, and when games don't tell players what to do. Many players (probably most) aren't sufficiently sophisticated to figure out that your 'game' is actually a toy. The distinction itself is somewhat arcane. It's also aggravating when the developers themselves don't know (as is the case with Travian).
This mode of play is the less-offensive younger sister to the first option. I'm saying that players pursue a goal but only indirectly, through the actions that they expect that the game wants from them. Stick a score somewhere on the screen (such as accumulated dollars or gold, or city population, or whatnot) and that becomes the perceived goal: how high can you get that number?
Games like The Sims keep the player so busy in many day-to-day life choices that they might not even know what goals they are pursuing.
The problem with this path is that players might eventually grow bored. Not knowing what goal they are "supposed" to achieve, they wonder why they spend time in the game. This was a problem for me in ATITD, to some extent: I knew what I wanted to do (play with crossbreeding), but I didn't know how to get there. What was I supposed to do in the meantime? I knew I had to somehow level up, but it wasn't clear which way I should go to do that.
And hence the problem with open worlds: when players are allowed to go anywhere and do anything, they often find themselves puttering around a bit hoping they had some direction.
Conclusion
Explorers are a subset of the overall gaming market. A niche, if you will. Catering to them can be very rewarding for those explorers but leaves everyone else scratching their heads. A game like ATITD would, theoretically, be heaven to me, if it wasn't for the atrocious UI and the excruciating primary mechanic (i.e. waiting).
You can add some fun for explorers by hiding some game mechanics. Although this will frustrate some of your early-adopter Achievers, eventually the explorers show up and start mapping the territory. Most games have simple numeric systems somewhere; combat is an obvious place. In addition to basic math and stats, consider adding in ATITD-like mechanics: complex tradeskills or gathering results or world spawns that follow a formula that diligent players can unearth and profit from.
Above all, make sure to match player expectations. Let them know what they're getting into.
With a toy, people develop their own goals. Either they (incorrectly) perceive the game to have a goal that you are "supposed" to achieve, or they explicitly choose something to explore, or they do what they did in the previous similar game that they played. I'm going to explore each of these in turn.
Misperceived Goals
When players project a goal onto the toy, they become frustrated when they get to that goal and they aren't rewarded. The same thing can happen when they are playing a game and misperceive the goal. This is especially frustrating when the game did a poor job of communicating the goal. If it's only once the player has played towards the goal that they understand it then you've lost an opportunity to keep that player happy. (Unless your mechanic is confusing players, in which case you're developing a niche title, and rah for you. I'm not talking about small-market hardcore games.) And some players might get distracted along the way, but that's besides the point.
Challenge is important in games, but only in that it manifests as perceived challenge. Since it's unlikely for a game to be challenging but not seem so, the important point here is the contrapositive: a game that players perceive to be challenging but really isn't. Players succeed and think they're smart in doing so. In the case of our toy with misperceived goals, players find the game to be extremely challenging and themselves to be under par because they can't win. I don't like losing, even if it was a good fight. I prefer losing a good fight to winning on a coin flip (unless we're talking real money, in which case it's better to be lucky), but losing when it's an unfair fight weighted against me just makes me frustrated.
The root of such frustration is misplaced expectations. Manage your player's expectations. If you've built a toy, let the players know.
Choosing Exploration
Experienced explorers tend to know they're explorers. Maybe they haven't heard of the Bartles types, maybe they don't think of it that way, but when you sit them down in front of a toy (or game), they'll go to work taking it apart and figuring out its mechanics.
To them -- or, I should say, to us -- figuring it out is the game. We're curious. I've got a competitive side, and that manifests as wanting to know the rules. Since most games don't document themselves well that often means it's up to the players to figure out how to win, whether one strategy is better than another. In strategy games, this is, really, the point, but there's also a mechanical aspect to winning: just how effective are the various units? If you face two off in a fight, which one will win? Which is more cost-effective? These sorts of explorers are comfortable with math -- at least the basic algebra used to derive these effectiveness measures.
Other explorers want to figure out your AI -- do feints work? Can they draw the NPC troops into an ambush? A great many players fit into this type of explorer mold, and it's generally an explicit part of many games. For toys, of course, there's no goal to win, so exploring the AI in a toy is a chosen goal.
Trying to keep mechanics-explorers happy is a difficult process. The more successful your game, the more people will be trying to figure it out. There's so many people playing WoW, for example, that the only undiscovered rules are those for the rarest and most inaccessible of content. Even in complex-rule games like ATITD, there's enough people pounding at the formulas that a great many of them have been found. There's two things going for that game here, though: (1) many of the rules are still very complex, such that the basic formula is sufficiently obscure that it wouldn't have been discovered except for developer intervention, and (2) the player base is small enough that there's only a small group dedicated to exploring any given mechanic. Yet it's a great example for developers looking for ways to keep their mechanic-explorer playerbase happy.
Default Play
This is the catch-all category. "Default Play" is what happens when gamers are given a toy, and when games don't tell players what to do. Many players (probably most) aren't sufficiently sophisticated to figure out that your 'game' is actually a toy. The distinction itself is somewhat arcane. It's also aggravating when the developers themselves don't know (as is the case with Travian).
This mode of play is the less-offensive younger sister to the first option. I'm saying that players pursue a goal but only indirectly, through the actions that they expect that the game wants from them. Stick a score somewhere on the screen (such as accumulated dollars or gold, or city population, or whatnot) and that becomes the perceived goal: how high can you get that number?
Games like The Sims keep the player so busy in many day-to-day life choices that they might not even know what goals they are pursuing.
The problem with this path is that players might eventually grow bored. Not knowing what goal they are "supposed" to achieve, they wonder why they spend time in the game. This was a problem for me in ATITD, to some extent: I knew what I wanted to do (play with crossbreeding), but I didn't know how to get there. What was I supposed to do in the meantime? I knew I had to somehow level up, but it wasn't clear which way I should go to do that.
And hence the problem with open worlds: when players are allowed to go anywhere and do anything, they often find themselves puttering around a bit hoping they had some direction.
Conclusion
Explorers are a subset of the overall gaming market. A niche, if you will. Catering to them can be very rewarding for those explorers but leaves everyone else scratching their heads. A game like ATITD would, theoretically, be heaven to me, if it wasn't for the atrocious UI and the excruciating primary mechanic (i.e. waiting).
You can add some fun for explorers by hiding some game mechanics. Although this will frustrate some of your early-adopter Achievers, eventually the explorers show up and start mapping the territory. Most games have simple numeric systems somewhere; combat is an obvious place. In addition to basic math and stats, consider adding in ATITD-like mechanics: complex tradeskills or gathering results or world spawns that follow a formula that diligent players can unearth and profit from.
Above all, make sure to match player expectations. Let them know what they're getting into.
Labels:
explorers,
game design
Monday, July 28, 2008
Power is Power
or, On Information Management as a Game Mechanism
Power is Power.
or
Power¹ is³ Power².
Power¹ is the ability to express complex ideas. Power² is power -- buying power, the power of command, the ability to get more done. What does "is" mean? Well, see, it means "is." Try to keep up here.
I'm still playing Travian. As part of playing the game, I've developed a complex information-management system that lets me assess what's going on in the game world and perform actions in a fast, efficient manner.
Specifically, I've created a map of all the other players in a 21x21 grid centered on my village. Once a day, I copy that map (it's text in a monospace font) and update all the population numbers. This lets me assess who is growing and who isn't. Also, I add in markers indicating the race of the player at that village, what guild they're in, if they're still in Beginner's Protection (and therefore can't be attacked), and, if I have already attacked them, whether it was a profitable raid.
Good players in Travian have a city that is constantly growing in population. It's how you get more power (military power, in this game). Hence, it's important to assess how strong my neighbors are. If they're not growing quickly, then they're weak players. If they're not growing at all, then they're inactive and I can then raid them with impunity. If they're growing quickly and allied, then I definitely stay away.
It took me the two weeks that I've been playing the game to move to my current system. It'll probably be tweaked further. I started with a post-it note, with the populations of the villages around me; I was basically only indicating which villages were active (by hilighting the population with, um, a hilighter). Then I switched to a text file. Then I made the map larger -- it grew from 7x7 to 11x11 to 36x48 and then shrunk to 15x15 (with two lines of 8 characters per village) and now to its current 21x21, five characters-per-village format. The width fits just fine on my monitor, allowing me to have the game open in one window and the text editor open next to it, with no overlap.
Basically the process I went through was to record different statistics and find out which were important to me. I was also subtly tweaking how I was storing and representing the information to make it easy and effective to use.
And all along, I thought, "why doesn't the game give me this information already?" This is precisely the sort of thing that a computer program would excel at.
I don't really need all this extensive record-keeping. (What does "need" mean, anyway?) (And I haven't mentioned the spreadsheet that tells me who to attack next, either.) Luckily, it doesn't take long to manage. It's unlikely that past winners and other successful players keep these kinds of records. At one point I was playing four games, though, and in that case these sorts of records are essential. But if you're only playing one game, chances are you can memorize what's going on around you without much effort.
The nice thing about records is that you don't have to memorize anything, and places where your memory might be fuzzy -- well, you don't have to worry about that. You've got the hard copy to tell you what's what.
But what if the game tracked all this stuff for me? Then I wouldn't even have to bother. And other players would know, also, if the players around them were inactive, or growing slowly, and what race they were (at a glance, without requiring bouncing through a few pages), and if they were under BP (without requiring bouncing through many pages), and how many other local players were in the same guild, and at a glance where all the big-pop cities were.
What if the game gave that information to everybody? I'd have a much harder time extracting profits from my inactive neighbors; everyone else would know about them. My opponents would make fewer mistakes, increasing the challenge. The game would shift from being one of good information management plus some basic strategy to being almost all strategy. I'm reminded of Costikyan's comments on Campaigns for North Africa: the game accurately simulates matters such as where individual pilots are and how much water each battalion has, but who cares about that stuff? Generals have staff that worry about that stuff. Strategy is hard enough without also having to micromanage pilots and water.
Some games, generally PC sims, wargames, and the like, depend to some extent on making the player manage these resources. It's busy-work. It keeps the player busy, thinking he's doing something meaningful (and, indeed, if he botches it, his troops die). But it's not a great challenge; it's a puzzle within the larger game. It doesn't lend color to the atmosphere of the game and often also has no effect on the outcome of the game -- unless you fail at the sub-task.
I think a hodge-podge of activities can work. I really enjoy Transport Tycoon, even after all these years and despite it's toy-ness, because the collection of activities in the game fit the theme of building transportation infrastructure. The game isn't really about building an empire; that's something that happens while you play the infrastructure-building game.
This is a perspective that should help you hone your game. If all of your gameplay is related to things that the Chairman of the Board would never bother with, then don't make your player take on the role of Chairman. He's the Chief Engineer, or Architect, or what have you. The chairman plays with toys -- he sets his own goals. If you decided to make a game, make the player's role match. If the gameplay fits the player as an Architect rather than Chairman, then maybe your product would work better as a game rather than as a toy.
Sim City is definitely a toy. In later versions, you micromanage stuff like water distribution, and to some extent playing around with the transportation network was Architect-y, but the gist of the game -- zone and wait -- is a toy. It's like a giant ant farm. Set some parameters and watch it go. If you wanted to take that product and make it a game, I think the mechanics would have to change a lot. When you want to give the player goals, you also need to give him ways of achieving those goals, and the more direct the better.
If Travian made all my record-keeping obsolete, I think it would change the flavor of the game. Diplomacy would be a much more obvious aspect. With stiffer competition for farms, keeping farms alive and eventually bringing them in-house would be more important. Wars would be fought over inactives, since everyone would know what pieces were in play. Mechanics would have to shift to emphasize strategy, or else it becomes pure diplomacy. Or maybe diplomacy would be the major goal!
Is your product a toy or a game? Is your player an architect or a chairman?
Power is Power.
or
Power¹ is³ Power².
Power¹ is the ability to express complex ideas. Power² is power -- buying power, the power of command, the ability to get more done. What does "is" mean? Well, see, it means "is." Try to keep up here.
I'm still playing Travian. As part of playing the game, I've developed a complex information-management system that lets me assess what's going on in the game world and perform actions in a fast, efficient manner.
Specifically, I've created a map of all the other players in a 21x21 grid centered on my village. Once a day, I copy that map (it's text in a monospace font) and update all the population numbers. This lets me assess who is growing and who isn't. Also, I add in markers indicating the race of the player at that village, what guild they're in, if they're still in Beginner's Protection (and therefore can't be attacked), and, if I have already attacked them, whether it was a profitable raid.
Good players in Travian have a city that is constantly growing in population. It's how you get more power (military power, in this game). Hence, it's important to assess how strong my neighbors are. If they're not growing quickly, then they're weak players. If they're not growing at all, then they're inactive and I can then raid them with impunity. If they're growing quickly and allied, then I definitely stay away.
It took me the two weeks that I've been playing the game to move to my current system. It'll probably be tweaked further. I started with a post-it note, with the populations of the villages around me; I was basically only indicating which villages were active (by hilighting the population with, um, a hilighter). Then I switched to a text file. Then I made the map larger -- it grew from 7x7 to 11x11 to 36x48 and then shrunk to 15x15 (with two lines of 8 characters per village) and now to its current 21x21, five characters-per-village format. The width fits just fine on my monitor, allowing me to have the game open in one window and the text editor open next to it, with no overlap.
Basically the process I went through was to record different statistics and find out which were important to me. I was also subtly tweaking how I was storing and representing the information to make it easy and effective to use.
And all along, I thought, "why doesn't the game give me this information already?" This is precisely the sort of thing that a computer program would excel at.
I don't really need all this extensive record-keeping. (What does "need" mean, anyway?) (And I haven't mentioned the spreadsheet that tells me who to attack next, either.) Luckily, it doesn't take long to manage. It's unlikely that past winners and other successful players keep these kinds of records. At one point I was playing four games, though, and in that case these sorts of records are essential. But if you're only playing one game, chances are you can memorize what's going on around you without much effort.
The nice thing about records is that you don't have to memorize anything, and places where your memory might be fuzzy -- well, you don't have to worry about that. You've got the hard copy to tell you what's what.
But what if the game tracked all this stuff for me? Then I wouldn't even have to bother. And other players would know, also, if the players around them were inactive, or growing slowly, and what race they were (at a glance, without requiring bouncing through a few pages), and if they were under BP (without requiring bouncing through many pages), and how many other local players were in the same guild, and at a glance where all the big-pop cities were.
What if the game gave that information to everybody? I'd have a much harder time extracting profits from my inactive neighbors; everyone else would know about them. My opponents would make fewer mistakes, increasing the challenge. The game would shift from being one of good information management plus some basic strategy to being almost all strategy. I'm reminded of Costikyan's comments on Campaigns for North Africa: the game accurately simulates matters such as where individual pilots are and how much water each battalion has, but who cares about that stuff? Generals have staff that worry about that stuff. Strategy is hard enough without also having to micromanage pilots and water.
Some games, generally PC sims, wargames, and the like, depend to some extent on making the player manage these resources. It's busy-work. It keeps the player busy, thinking he's doing something meaningful (and, indeed, if he botches it, his troops die). But it's not a great challenge; it's a puzzle within the larger game. It doesn't lend color to the atmosphere of the game and often also has no effect on the outcome of the game -- unless you fail at the sub-task.
I think a hodge-podge of activities can work. I really enjoy Transport Tycoon, even after all these years and despite it's toy-ness, because the collection of activities in the game fit the theme of building transportation infrastructure. The game isn't really about building an empire; that's something that happens while you play the infrastructure-building game.
This is a perspective that should help you hone your game. If all of your gameplay is related to things that the Chairman of the Board would never bother with, then don't make your player take on the role of Chairman. He's the Chief Engineer, or Architect, or what have you. The chairman plays with toys -- he sets his own goals. If you decided to make a game, make the player's role match. If the gameplay fits the player as an Architect rather than Chairman, then maybe your product would work better as a game rather than as a toy.
Sim City is definitely a toy. In later versions, you micromanage stuff like water distribution, and to some extent playing around with the transportation network was Architect-y, but the gist of the game -- zone and wait -- is a toy. It's like a giant ant farm. Set some parameters and watch it go. If you wanted to take that product and make it a game, I think the mechanics would have to change a lot. When you want to give the player goals, you also need to give him ways of achieving those goals, and the more direct the better.
If Travian made all my record-keeping obsolete, I think it would change the flavor of the game. Diplomacy would be a much more obvious aspect. With stiffer competition for farms, keeping farms alive and eventually bringing them in-house would be more important. Wars would be fought over inactives, since everyone would know what pieces were in play. Mechanics would have to shift to emphasize strategy, or else it becomes pure diplomacy. Or maybe diplomacy would be the major goal!
Is your product a toy or a game? Is your player an architect or a chairman?
Labels:
game design,
status,
travian
Friday, July 25, 2008
Selling Add-Ons
Games, both single-player and multi-player, have recently been selling small Add-Ons much more often. The model is small, incremental payments -- like pinball or arcade games, really. Micro-payments were theorized to help the webcomics industry get started but that didn't happen. MMOs do periodic macro-payments. The costs of Add-Ons on both PC and console games is somewhere between these two, and I'd hazard that it's helped many otherwise marginal projects reap big rewards.
I remember one of the devs from Iron Realms talking about how a few (hundred?) of their big fans could spend a thousand bucks a year on their game, and those core players could pay a hefty percent of a project's development and maintenance cost. It's somewhat like the core fans that indie musicians, authors, and game developers look for: a few fans that are so dedicated, they not only spend much more than the average fan but they also help proselytize your products.
At the core of the idea is the notion of charging different amounts to different customers. At the other end of the spectrum from those core fans is the broke and or miserly fans that don't want to pay $15/mo. But they might pay $15/yr, especially if you can break it down into tiny payments that they can somehow squeeze out of whatever meager resources they have. Paying for some gold in Travian, for example, can be done with an SMS. If mommy is paying for your cell phone, you can just squeeze in one SMS a month and get your gaming fix. Save up a few bucks by stealing lunch money and maybe a friend will help get those dollars transferred to PayPal.
There's a bunch of great benefits to this approach. The guys that can afford to burn $50 a week on your game can do so -- you've got a business model that takes as much money from your rich customers as it can. Broke fans can build a community and a customer base, especially if the core game is free. Get them hooked, and then when they do come across some money they'll spend it on your game. In the middle are the players that are willing to spend $5 to $20 a month -- usually the majority of the audience for traditional business models. Except now you've given those guys an extra little incentive to spend even more. If they were happy spending $14/mo on WoW, they might have the resources to spend a lot more, and if you tell them they get 25% more production for just $1.20, they'll jump.
Small amounts of money are easy to spend. Gabe & Tycho mentioned this recently -- price something at a buck and it becomes much easier to try something.
The elephant in this room is, of course, iTunes. Consumers don't want to drop $15 on a dozen tracks, knowing they like one of them but hoping that the rest don't suck.
Or maybe it's just that the kids that used to scrimp and save to buy their media now, instead, just download it from some bit torrent. You can't convince a kid to mow a lawn to buy your CD if he is willing to click-click and download it for free. The only way to get him to spend money is to prevent him from getting it any other way.
This is probably the saving grace of games nowadays. PC games seem to be going downhill. Those that are still around are the few big, mainstream titles -- casual games like The Sims and games that require online play like WoW or Team Fortress 2. I remember players in the game rental market worrying about the state of the industry, and honestly I have no idea how they're doing now. I think the used games market has replaced it, but I guess I should just shut up about that and look for an educated opinion.
I haven't really mentioned console examples but that's not because I don't mean to include them here. I was just using PC examples. "DLC" for XBox 360 titles and (I guess) the other consoles is another strong market. $5 for a horse? No, but I'll pay $5 for an expansion pack, or $1 for some gamer tags.
I think selling Add-Ons like this is the way of the future. It's customization in a way-- instead of charging users $15 for a CD, you charge them $15 for a dozen tracks of their choice. Sophisticated consumers don't want you telling them how to have fun; they want options. Business realities mean the box itself is gonna cost $50, but the extras let you extend the game without having to sell that, too, in the initial box.
I remember one of the devs from Iron Realms talking about how a few (hundred?) of their big fans could spend a thousand bucks a year on their game, and those core players could pay a hefty percent of a project's development and maintenance cost. It's somewhat like the core fans that indie musicians, authors, and game developers look for: a few fans that are so dedicated, they not only spend much more than the average fan but they also help proselytize your products.
At the core of the idea is the notion of charging different amounts to different customers. At the other end of the spectrum from those core fans is the broke and or miserly fans that don't want to pay $15/mo. But they might pay $15/yr, especially if you can break it down into tiny payments that they can somehow squeeze out of whatever meager resources they have. Paying for some gold in Travian, for example, can be done with an SMS. If mommy is paying for your cell phone, you can just squeeze in one SMS a month and get your gaming fix. Save up a few bucks by stealing lunch money and maybe a friend will help get those dollars transferred to PayPal.
There's a bunch of great benefits to this approach. The guys that can afford to burn $50 a week on your game can do so -- you've got a business model that takes as much money from your rich customers as it can. Broke fans can build a community and a customer base, especially if the core game is free. Get them hooked, and then when they do come across some money they'll spend it on your game. In the middle are the players that are willing to spend $5 to $20 a month -- usually the majority of the audience for traditional business models. Except now you've given those guys an extra little incentive to spend even more. If they were happy spending $14/mo on WoW, they might have the resources to spend a lot more, and if you tell them they get 25% more production for just $1.20, they'll jump.
Small amounts of money are easy to spend. Gabe & Tycho mentioned this recently -- price something at a buck and it becomes much easier to try something.
The elephant in this room is, of course, iTunes. Consumers don't want to drop $15 on a dozen tracks, knowing they like one of them but hoping that the rest don't suck.
Or maybe it's just that the kids that used to scrimp and save to buy their media now, instead, just download it from some bit torrent. You can't convince a kid to mow a lawn to buy your CD if he is willing to click-click and download it for free. The only way to get him to spend money is to prevent him from getting it any other way.
This is probably the saving grace of games nowadays. PC games seem to be going downhill. Those that are still around are the few big, mainstream titles -- casual games like The Sims and games that require online play like WoW or Team Fortress 2. I remember players in the game rental market worrying about the state of the industry, and honestly I have no idea how they're doing now. I think the used games market has replaced it, but I guess I should just shut up about that and look for an educated opinion.
I haven't really mentioned console examples but that's not because I don't mean to include them here. I was just using PC examples. "DLC" for XBox 360 titles and (I guess) the other consoles is another strong market. $5 for a horse? No, but I'll pay $5 for an expansion pack, or $1 for some gamer tags.
I think selling Add-Ons like this is the way of the future. It's customization in a way-- instead of charging users $15 for a CD, you charge them $15 for a dozen tracks of their choice. Sophisticated consumers don't want you telling them how to have fun; they want options. Business realities mean the box itself is gonna cost $50, but the extras let you extend the game without having to sell that, too, in the initial box.
Labels:
business
Thursday, July 24, 2008
Silver Bullets
As Fred Brooks says, there are no Silver Bullets.
The basic message is that there is no language, tool, organization structure, or practice that will magically solve your problems and let you ship software on time. People who have read his 1987 essay come away from it avowing to never use a silver bullet -- but I think the result is often that they instead use a different phrase to refer to their silver bullet.
If you've got a practice in your organization that is essential, the sort of practice that anyone using your given language and tools would be a fool not to use, then that's your silver bullet. Do you have seven different pointer wrappers that everyone must use? That's your silver bullet. Do you require programmers to write an interface for every class that they implement? Are naming conventions the sine qua non in your office? Are you lax on a number of XP practices but absolutely adamant about unit tests?
Just because you don't call it a silver bullet doesn't mean it isn't.
Complexity is a hard problem, and ignoring some problems can produce an order-of-magnitude decrease in productivity. There's a difference between being avoiding willful ignorance and requiring some critical practice. I've often run into people that had a bad time "at their last job" or "on the last project," and are committed to avoiding that problem at all costs.
This is dropping context, though. The solution will remove the problem (but see below), but was the problem destiny or was it the result of an organizational shortfall? Maybe their last project had a lot of dangling pointers and memory leaks; using pointer wrappers won't make that problem go away. It doesn't even make it harder. Adding complexity to a project makes working on it more difficult, painstaking, and error-prone. Although they're trying to remove what they see as a flaw in the language (in this case, unmanaged memory), the solution doesn't change the language. Programmers can ignore, misuse, or work around pointer wrappers. Plus they've got to throw out their old understanding of the language and use a "new and improved" flavor of the language. All of their experience, previously very valuable, now works against them. It's simple to follow someone else's explanation of their solution, but understanding it and grokking it sufficiently to use it yourself is not trivial or fast. Forget using it adeptly!
Training programmers to understand memory allocation and giving them a model (such as 'ownership') to follow goes a long way to reducing memory misuse, makes them better programmers, is something they can use for the rest of their career, is a topic well-documented in books, magazines, blogs, and seminars, and requires no new tools or code.
The basic message is that there is no language, tool, organization structure, or practice that will magically solve your problems and let you ship software on time. People who have read his 1987 essay come away from it avowing to never use a silver bullet -- but I think the result is often that they instead use a different phrase to refer to their silver bullet.
If you've got a practice in your organization that is essential, the sort of practice that anyone using your given language and tools would be a fool not to use, then that's your silver bullet. Do you have seven different pointer wrappers that everyone must use? That's your silver bullet. Do you require programmers to write an interface for every class that they implement? Are naming conventions the sine qua non in your office? Are you lax on a number of XP practices but absolutely adamant about unit tests?
Just because you don't call it a silver bullet doesn't mean it isn't.
Complexity is a hard problem, and ignoring some problems can produce an order-of-magnitude decrease in productivity. There's a difference between being avoiding willful ignorance and requiring some critical practice. I've often run into people that had a bad time "at their last job" or "on the last project," and are committed to avoiding that problem at all costs.
This is dropping context, though. The solution will remove the problem (but see below), but was the problem destiny or was it the result of an organizational shortfall? Maybe their last project had a lot of dangling pointers and memory leaks; using pointer wrappers won't make that problem go away. It doesn't even make it harder. Adding complexity to a project makes working on it more difficult, painstaking, and error-prone. Although they're trying to remove what they see as a flaw in the language (in this case, unmanaged memory), the solution doesn't change the language. Programmers can ignore, misuse, or work around pointer wrappers. Plus they've got to throw out their old understanding of the language and use a "new and improved" flavor of the language. All of their experience, previously very valuable, now works against them. It's simple to follow someone else's explanation of their solution, but understanding it and grokking it sufficiently to use it yourself is not trivial or fast. Forget using it adeptly!
Training programmers to understand memory allocation and giving them a model (such as 'ownership') to follow goes a long way to reducing memory misuse, makes them better programmers, is something they can use for the rest of their career, is a topic well-documented in books, magazines, blogs, and seminars, and requires no new tools or code.
Labels:
agile
Monday, July 21, 2008
Game Tutorials & Instructions
In my ATITD rant follow-up, I mention the importance of explaining how to do stuff to players. Here I wanted to talk about what happens when you don't explain things -- beyond players just not playing.
I'm playing Travian (sign up and get me gold!) with some guild-mates. The rules and etiquette of Travian are hidden. They're not obvious. What is the game about? How do attacks work? There's competition, so according to the nomenclature I set forth in the previous post on Game Design Theory, it's a game. It has goals, but they're not clear. Evidently the goal is to build a Wonder of the World. I think maybe you need to be in an alliance that builds 4 of them; I'm not sure. There's no "How to Win" post somewhere that I could find that out; I'd have to chase down someone's stickied forum post -- on maybe the .com forums or the .us forums, who knows?
How does one get started playing the game? Just jump in and click and you'll find out. What do you do? Either find out the hard way, or spend a lot of time reading the forums and gleaning some idea that way. Let me be clear here: you don't go to the forums and, oh!, there's a post explaining everything! No, you go read a ton of posts and get a slightly less foggy idea of what the game is about. There's some early build orders posted, for example, but they kinda assume that you know what you're doing after that. Players have no goal given to them early on.
Learning the Game is Our Game Mechanic
There seems to be the idea that "figuring it out is part of the game." This is a common thread in several of the indie-ish games I've seen, whether it's something semi-well-known like ATITD or Travian or smaller single-player games or whatnot.
If learning how to play is one of your game mechanics, then your game is an Alternate Reality Game where you have to surf web pages and ask questions in forums -- but you get called a noob for a while. Do you enjoy being called a noob? I don't.
The 14-year-olds get called noobs because they haven't learned to use search features. I guess there's older kids that are just as annoying. In fact, there's probably decent folk that post questions in the forums just out of frustration. There's a pattern here that I've mentioned in previous posts: Hide stuff from your players and they wind up engaging in behaviors that piss off your elder players.
What Really Happens
When your game first comes out, no-one knows how to play (except the kids in beta). Since those kids in beta know their way around, they'll make posts on the forums to show off their knowledge. Don't think that "the players get to learn the game mechanics" is a feature. It's not. Trial-and-error isn't a fun, strategic, or rewarding way to learn something, so even that's not a great thing. Maybe a few dozen people 'learn' your game the hard way, the rest learn through some mix of hard knocks and forum browsing, and your "game mechanic" is now over.
New players aren't strictly forbidden from finding out how to play the game; they just have to get that knowledge from the elders. Some newbs will find out, others will just get frustrated and quit. The elder players are those that already know what's going on. Some of them (often highly regarded by the community) then pass that knowledge on. The lack of documentation means that some elders have to take on the role of mommy and teacher, and assuredly some of them really enjoy that role. But you're losing players just to make a few people warm and happy by providing the documentation that you should be providing anyway. Those knowledge-mavens will find something to write about; they always do. You wind up with a game structure where you have: a set of in-crowd elders that have learned everything the hard way; a set of up-and-coming players that are poring a lot of time into learning your game (when they could be playing it more, or otherwise enjoying their life); and a bunch of nubs that are getting frustrated, making stupid posts, bothering elder players, and either leaving or maybe becoming non-nubs.
If you gave the players good documentation, your nurturing elders would find something else to write about -- like good strategies. They'd participate in design and meta-game discussions. They'd build the community, rather than just stem the leaks produced by shoddy docs.
Good documentation helps to build your player base. Players like knowing what they're supposed to do. They enjoy games that have score-cards. Tell your players how to play and tell them the goal and then let them figure out how to win.
I'm playing Travian (sign up and get me gold!) with some guild-mates. The rules and etiquette of Travian are hidden. They're not obvious. What is the game about? How do attacks work? There's competition, so according to the nomenclature I set forth in the previous post on Game Design Theory, it's a game. It has goals, but they're not clear. Evidently the goal is to build a Wonder of the World. I think maybe you need to be in an alliance that builds 4 of them; I'm not sure. There's no "How to Win" post somewhere that I could find that out; I'd have to chase down someone's stickied forum post -- on maybe the .com forums or the .us forums, who knows?
How does one get started playing the game? Just jump in and click and you'll find out. What do you do? Either find out the hard way, or spend a lot of time reading the forums and gleaning some idea that way. Let me be clear here: you don't go to the forums and, oh!, there's a post explaining everything! No, you go read a ton of posts and get a slightly less foggy idea of what the game is about. There's some early build orders posted, for example, but they kinda assume that you know what you're doing after that. Players have no goal given to them early on.
Learning the Game is Our Game Mechanic
There seems to be the idea that "figuring it out is part of the game." This is a common thread in several of the indie-ish games I've seen, whether it's something semi-well-known like ATITD or Travian or smaller single-player games or whatnot.
If learning how to play is one of your game mechanics, then your game is an Alternate Reality Game where you have to surf web pages and ask questions in forums -- but you get called a noob for a while. Do you enjoy being called a noob? I don't.
The 14-year-olds get called noobs because they haven't learned to use search features. I guess there's older kids that are just as annoying. In fact, there's probably decent folk that post questions in the forums just out of frustration. There's a pattern here that I've mentioned in previous posts: Hide stuff from your players and they wind up engaging in behaviors that piss off your elder players.
What Really Happens
When your game first comes out, no-one knows how to play (except the kids in beta). Since those kids in beta know their way around, they'll make posts on the forums to show off their knowledge. Don't think that "the players get to learn the game mechanics" is a feature. It's not. Trial-and-error isn't a fun, strategic, or rewarding way to learn something, so even that's not a great thing. Maybe a few dozen people 'learn' your game the hard way, the rest learn through some mix of hard knocks and forum browsing, and your "game mechanic" is now over.
New players aren't strictly forbidden from finding out how to play the game; they just have to get that knowledge from the elders. Some newbs will find out, others will just get frustrated and quit. The elder players are those that already know what's going on. Some of them (often highly regarded by the community) then pass that knowledge on. The lack of documentation means that some elders have to take on the role of mommy and teacher, and assuredly some of them really enjoy that role. But you're losing players just to make a few people warm and happy by providing the documentation that you should be providing anyway. Those knowledge-mavens will find something to write about; they always do. You wind up with a game structure where you have: a set of in-crowd elders that have learned everything the hard way; a set of up-and-coming players that are poring a lot of time into learning your game (when they could be playing it more, or otherwise enjoying their life); and a bunch of nubs that are getting frustrated, making stupid posts, bothering elder players, and either leaving or maybe becoming non-nubs.
If you gave the players good documentation, your nurturing elders would find something else to write about -- like good strategies. They'd participate in design and meta-game discussions. They'd build the community, rather than just stem the leaks produced by shoddy docs.
Good documentation helps to build your player base. Players like knowing what they're supposed to do. They enjoy games that have score-cards. Tell your players how to play and tell them the goal and then let them figure out how to win.
Labels:
game design
Subscribe to:
Posts (Atom)