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.
Thursday, July 31, 2008
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.
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?
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.
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.
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.
Friday, July 18, 2008
Games, Game Theory, and Puzzles
The difference between games and puzzles is that puzzles are static; games have an opponent or an element of randomness. Both have a goal; you can solve a puzzle or win a game.
The difference between toys and puzzles are that puzzles have a goal.
The difference between games and toys is that games have goals. With a toy, you have to think up your own goal. Building toys like Lego blocks and Tinkertoys are a bit puzzle-like in the way they respond to your actions; they don't really 'behave' different. If you built a tower out of them, though, it creates a new context. You can build a fort, or a car. But a toy like that isn't a game unless there's a goal.
--
Game Theory is, well, the study of games. It's the attempt to capture, in mathematics, game-like behavior. It's typically mentioned in discussion of economics, ethics, and politics. You might built a tree of "if I do this, then my opponent might do one of these three things, and for each of his responses, here are my possible reactions...", and then weight each action by some probability and/or 'strength', eg how close you are to 'winning'.
If you play a game against a rule-bound opponent, one whose response to your actions is dictated by a formula that doesn't involve randomness, then what you have is really a puzzle. Puzzles are generally amenable to solving through logic, although some puzzles are grossly difficult to solve without tools. Simple tools would be pen & paper; maybe add a calculator. A more complex tool would be a computer program.
--
To some extent, the goal of the meta-game of poker is to figure out how to turn it into a puzzle. It's not really a puzzle due to randomness, but then, I'm not talking about poker proper. You can sit down and play one hand of poker; that's a game. But if you play against the same opponent over and over again, you can start to analyze your opponent's behavior. Assign each of their actions a percentage, due to randomness. Once you've done that, game theory will tell you how to act.
Likewise, from session to session over the course of a year, you'll face many similar opponents. If you can put your opponents into buckets -- rock, fish, shark -- then you can again apply game theory to the problem.
This is what happens in many video game communities, most especially in RPGs and Sims. Players want to figure out the rules, and then from there figure out how best to beat the game. WoW players figure out where their best items drop and go farm; Sim and RTS players calculate their optimum build orders.
Game designers can do the same thing, of course. It's a great way to find the holes in your design; possible exploits; build strategies that can make the game too easy or too hard.
I guess I don't have a lot to say here. :) I thought it interesting to think that game theory reduces games to puzzles.
The difference between toys and puzzles are that puzzles have a goal.
The difference between games and toys is that games have goals. With a toy, you have to think up your own goal. Building toys like Lego blocks and Tinkertoys are a bit puzzle-like in the way they respond to your actions; they don't really 'behave' different. If you built a tower out of them, though, it creates a new context. You can build a fort, or a car. But a toy like that isn't a game unless there's a goal.
--
Game Theory is, well, the study of games. It's the attempt to capture, in mathematics, game-like behavior. It's typically mentioned in discussion of economics, ethics, and politics. You might built a tree of "if I do this, then my opponent might do one of these three things, and for each of his responses, here are my possible reactions...", and then weight each action by some probability and/or 'strength', eg how close you are to 'winning'.
If you play a game against a rule-bound opponent, one whose response to your actions is dictated by a formula that doesn't involve randomness, then what you have is really a puzzle. Puzzles are generally amenable to solving through logic, although some puzzles are grossly difficult to solve without tools. Simple tools would be pen & paper; maybe add a calculator. A more complex tool would be a computer program.
--
To some extent, the goal of the meta-game of poker is to figure out how to turn it into a puzzle. It's not really a puzzle due to randomness, but then, I'm not talking about poker proper. You can sit down and play one hand of poker; that's a game. But if you play against the same opponent over and over again, you can start to analyze your opponent's behavior. Assign each of their actions a percentage, due to randomness. Once you've done that, game theory will tell you how to act.
Likewise, from session to session over the course of a year, you'll face many similar opponents. If you can put your opponents into buckets -- rock, fish, shark -- then you can again apply game theory to the problem.
This is what happens in many video game communities, most especially in RPGs and Sims. Players want to figure out the rules, and then from there figure out how best to beat the game. WoW players figure out where their best items drop and go farm; Sim and RTS players calculate their optimum build orders.
Game designers can do the same thing, of course. It's a great way to find the holes in your design; possible exploits; build strategies that can make the game too easy or too hard.
I guess I don't have a lot to say here. :) I thought it interesting to think that game theory reduces games to puzzles.
Wednesday, July 16, 2008
Towards a Hermeneutic Theory of Comprehensive Artifactual Construction
[a parody of/editorial on the MDA paper]
Introduction
Computer and video games are more complex than other types of artifacts. People building new cars, warships, commercial airliners, investment and accounting systems, and legal doctrine don't have to deal with the complex, dynamic, and often unpredictable behavior, like we have in games. Games are hard. Harder than these other things, obviously.
Towards a Comprehensive Framework
Lots of different people are involved in making games. We're not all interchangeable cogs. As a result, we can't treat everyone else on the project as if they're exactly like us. I bet you never thought of that, huh?
As games continue to evolve, the behavior of AI-controlled game agents will increasingly come under the purview of non-technical people that don't understand logic, algorithms, and efficiency. Those agents will be part of game design, because obviously they aren't now and haven't been before. As we all know, it wasn't until very recently that AI units had any effect on gameplay.
WTF is "systematic coherence"? I don't think it means anything. I think it's a cover for not knowing what you're talking about. If you hold your goal as a floating abstraction, represented by the pairing of two multisyllabic vagaries, then you can pretend you're doing real work.
Your first paper should be "this is systematic coherence, here's some more examples, and this over here is not." Prove to me that it is a goal. "I'm an academic, I've got a badge, act as if my pronouncements were deep" is just a snowjob.
I can sit here and pretend to know what systematic coherence is, but because you never define it, then we'll never know if what I think it is and what you think it is are the same thing. To the extent that that coherence is the goal of your paper, I think it critical for you to define it.
In Detail
Designers and Players have the exact same fucking view of the game. The designer (or, when the designer doesn't understand the AI, the programmer) starts the process knowing the deepest hidden layers of the game -- the mechanics. But they both perceive the aesthetics of the game, and from there can pick apart the possible interactions that they are offered. These interactions are what I call gameplay: the tasks that players perform while playing a game.
Aesthetics isn't hidden from a designer the same way mechanics are hidden from players. Rather, because the designer starts with a deep understanding of the gameplay and mechanics, he finds it easier to ignore the aesthetics. They carry a low mental load. That's what happens when you get used to something. When you drive down the same road every day, you get used to the signs and the trees and the buildings. You form internal mental blocks that subsumes all of that detail. You ignore it on a conscious level. That's the product of familiarity; it happens to everyone over time.
You shouldn't be focused on the mechanics. If you are, you're a shitty designer. The mechanics are the puzzle of the game, but they exist hand in hand with the gameplay. You can't have one without the other. A great puzzle can frustrate players with gameplay that obscures the mechanics; likewise, gameplay that is too powerful can trivialize your puzzle. Sirlin makes good points here: simple mechanics only made time-consuming via an inefficient interface make for a bad game. Expose your mechanics; let the mechanics be the puzzle, not the interface. I swear at ATITD for this sin.
And I think your "aesthetics" are models of fun. They are all either models or attributes of gameplay, except for Sensation.
"Sensation" is a product of the graphics in a game -- both the technology of the graphics as well as the art. I think this item can be interpreted in multiple ways, so again I'm picking bones with the depth of this paper: define your terms. Rhythm games provide physiological sensations tied to the beat of the music that can be relaxing. Games like Rez provide a meditative visual stimulus that can be sense-pleasure, and to some extent the simple-mechanics of shooters like Geometry Wars provide the same numb-minded sense-pleasure. I find bright, saturated color schemes in many medieval-fantasy games to be visually pleasing. Back when I was playing Quake hours a day, I'd get into The Zone, which was a partly physiological state frequently described of sports players. Meditative/Zone-like games are defined by their gameplay and the simplicity of their mechanics; the color schemes I mentioned above are entirely in the domain of art and aren't a part of the mechanics or gameplay at all.
Fantasy is often purely a result of the art and aesthetics of a game. If you're baking bread in a medieval fantasy world, the fact that it's baking and bread is just a surface gloss; the game only sees counters moving from one state to another. "Ingredient X + Ingredient Y = Product Z." Fantasy doesn't come from having production rules; it depends on the player's imagined interpretation of those mechanics.
I could go on but my point is one that high school English teachers drilled into me: each item at the same depth in your outline should be of like kind. Don't put three apples and an essay on transformative hermeneutics into a list together. (You can tell I'm not an academic because I didn't use the word 'towards' in that sentence.)
The varied list isn't a strong analytical tool; it's great for brainstorming, though. Or rough categorization. If one stops by a campus bookstore, one could likely come back with three apples and an opaque essay. Disjoint buckets provide a quick, easy way to segregate the items pulled from the campus-store grab-bag. (And still, the list would benefit further from more rigorous definitions.)
The strongest value in this paper is the list of fun buckets, but I expect that there's better treatments of fun out there.
Introduction
Computer and video games are more complex than other types of artifacts. People building new cars, warships, commercial airliners, investment and accounting systems, and legal doctrine don't have to deal with the complex, dynamic, and often unpredictable behavior, like we have in games. Games are hard. Harder than these other things, obviously.
Towards a Comprehensive Framework
Lots of different people are involved in making games. We're not all interchangeable cogs. As a result, we can't treat everyone else on the project as if they're exactly like us. I bet you never thought of that, huh?
As games continue to evolve, the behavior of AI-controlled game agents will increasingly come under the purview of non-technical people that don't understand logic, algorithms, and efficiency. Those agents will be part of game design, because obviously they aren't now and haven't been before. As we all know, it wasn't until very recently that AI units had any effect on gameplay.
WTF is "systematic coherence"? I don't think it means anything. I think it's a cover for not knowing what you're talking about. If you hold your goal as a floating abstraction, represented by the pairing of two multisyllabic vagaries, then you can pretend you're doing real work.
Your first paper should be "this is systematic coherence, here's some more examples, and this over here is not." Prove to me that it is a goal. "I'm an academic, I've got a badge, act as if my pronouncements were deep" is just a snowjob.
I can sit here and pretend to know what systematic coherence is, but because you never define it, then we'll never know if what I think it is and what you think it is are the same thing. To the extent that that coherence is the goal of your paper, I think it critical for you to define it.
In Detail
Designers and Players have the exact same fucking view of the game. The designer (or, when the designer doesn't understand the AI, the programmer) starts the process knowing the deepest hidden layers of the game -- the mechanics. But they both perceive the aesthetics of the game, and from there can pick apart the possible interactions that they are offered. These interactions are what I call gameplay: the tasks that players perform while playing a game.
Aesthetics isn't hidden from a designer the same way mechanics are hidden from players. Rather, because the designer starts with a deep understanding of the gameplay and mechanics, he finds it easier to ignore the aesthetics. They carry a low mental load. That's what happens when you get used to something. When you drive down the same road every day, you get used to the signs and the trees and the buildings. You form internal mental blocks that subsumes all of that detail. You ignore it on a conscious level. That's the product of familiarity; it happens to everyone over time.
You shouldn't be focused on the mechanics. If you are, you're a shitty designer. The mechanics are the puzzle of the game, but they exist hand in hand with the gameplay. You can't have one without the other. A great puzzle can frustrate players with gameplay that obscures the mechanics; likewise, gameplay that is too powerful can trivialize your puzzle. Sirlin makes good points here: simple mechanics only made time-consuming via an inefficient interface make for a bad game. Expose your mechanics; let the mechanics be the puzzle, not the interface. I swear at ATITD for this sin.
And I think your "aesthetics" are models of fun. They are all either models or attributes of gameplay, except for Sensation.
"Sensation" is a product of the graphics in a game -- both the technology of the graphics as well as the art. I think this item can be interpreted in multiple ways, so again I'm picking bones with the depth of this paper: define your terms. Rhythm games provide physiological sensations tied to the beat of the music that can be relaxing. Games like Rez provide a meditative visual stimulus that can be sense-pleasure, and to some extent the simple-mechanics of shooters like Geometry Wars provide the same numb-minded sense-pleasure. I find bright, saturated color schemes in many medieval-fantasy games to be visually pleasing. Back when I was playing Quake hours a day, I'd get into The Zone, which was a partly physiological state frequently described of sports players. Meditative/Zone-like games are defined by their gameplay and the simplicity of their mechanics; the color schemes I mentioned above are entirely in the domain of art and aren't a part of the mechanics or gameplay at all.
Fantasy is often purely a result of the art and aesthetics of a game. If you're baking bread in a medieval fantasy world, the fact that it's baking and bread is just a surface gloss; the game only sees counters moving from one state to another. "Ingredient X + Ingredient Y = Product Z." Fantasy doesn't come from having production rules; it depends on the player's imagined interpretation of those mechanics.
I could go on but my point is one that high school English teachers drilled into me: each item at the same depth in your outline should be of like kind. Don't put three apples and an essay on transformative hermeneutics into a list together. (You can tell I'm not an academic because I didn't use the word 'towards' in that sentence.)
The varied list isn't a strong analytical tool; it's great for brainstorming, though. Or rough categorization. If one stops by a campus bookstore, one could likely come back with three apples and an opaque essay. Disjoint buckets provide a quick, easy way to segregate the items pulled from the campus-store grab-bag. (And still, the list would benefit further from more rigorous definitions.)
The strongest value in this paper is the list of fun buckets, but I expect that there's better treatments of fun out there.
Game Design Curriculum
There's a few concepts I want to discuss but I'm not aware of how these concepts are named within the game design community. I don't want to fall into Dunning-Kruger but I'm not sure that the design community does identify these concepts.
I think D-K is worth exploring a bit. It's easy for any game player to say "I could make this game better!" I remember thinking that when I played Warcraft 2. I thought, if only they had more units and more buildings, this game would be more awesome! Eventually I learned the lesson that my good buddy Antoine so cleverly encapsulated:
The example I've seen is often making music; playing in a band. Lots of people have tried playing a musical instrument, so I think a good number of people have experience enough with playing that they can see that you don't just pick up a guitar and be ready to hit it big after a couple weeks of practice. It takes a couple years to get good at playing an instrument, especially if you're expecting someone to pay you for it. Or drawing; I think it's common knowledge that it takes years of drawing and sketching and painting before others will give you money for your scribbles.
So, the context here is: do I know what I'm talking about, or is this the sort of stuff they teach in the first semester of Game Design School? Obviously, there's a problem in that there's not that many game design schools out there. Like, four, maybe. There's no general game design curriculum. It's very difficult for me to say whether or not other people have covered game design concepts that I see.
A few hours of surfing later: there's a lot of thought out there on game design curricula.
I see mention of things like Bartle's Types, but that's fairly rudimentary -- a lot has been added to the Types discussion since then. Nick Yee, for example, has researched player motivations in MMOs extensively. Understanding all of that data isn't the sort of thing you can put into a single blog post. He constantly writes about it. It's a deep topic. A good game designer should be familiar with it; I could see a Game Design Theory course spending a week or two covering MMO motivations.
I'm not a Raph fan. He got several "battlefield promotions" at Origin when the more senior designers on UO left; he was the last one still alive when the game shipped, and now people think that he created the game. He doesn't claim that, but he definitely profits from the design. I remember an interview I had with Sucker Punch (of Sly Cooper fame) and they basically instilled in me the idea of teach-practice-test: give the player a chance to learn a new skill in a safe environment, give them a few easy practice tests to make sure they can execute the skill, then test that skill in a challenging environment.
Raph's Theory of Fun seems to be that sentence, but stretched to book level. Looking a bit deeper, it seems the book is an apology for working in the entertainment industry, from someone that felt pressure from his family to do something "real." Maybe not. I haven't read the book, because, again, I'm not a Raph fan. The book has won tons of awards, though, so what do I know? If some other guy gives it a badge, then it must be a fact that it's brilliant, right? There's not a whole lot out there on video game design. Stop by a bookstore; count how many game design titles you find. I'm at a bookstore about once a week, and 95% of the time the number of design titles is ZERO. So if Raph has one of the top 10 books on video game design, then... um, there's only numbers one through four. I could publish this rambling rant as a book on game design and it'd be the 5th best book ever written on the subject.
Grr. Ok, so enough of that.
"Game design" also applies to board games, pen-n-paper RPGs, etc. I've seen several books on board game or war game design. The design of other games is significantly better documented than video game design.
Game design course curricula that I've seen generally cover the biggies: Raph's book, Bartle's paper, maybe related stuff like McCloud's Understanding books, Costikyan, and Sirlin. Textbooks themselves are scarce: Rules of Play, maybe not any others. That's the only one I know about. There's no series of textbooks for a bunch of different game design courses. The 'meat' of the design portion of the curricula are studios and seminars, anecdote books, post-mortems, and the like.
(Take Computer Science in contrast: you can stop by your local college bookstore and find textbooks for dozens of different comp sci classes. Plus software engineering texts, plus all the lay books on theory and practice for tons of subsets of theory within software development. My point is that there's one game design course textbook. Design courses read other books, the equivalent of lay books. Those books are not courses in game design; they cover aspects of game design, but aren't written as textbooks.)
So... where do I go for nomenclature? I can't justify spending too much time researching a given topic because there's not enough out there to find.
So I'm just going to make it up as I go along.
I think D-K is worth exploring a bit. It's easy for any game player to say "I could make this game better!" I remember thinking that when I played Warcraft 2. I thought, if only they had more units and more buildings, this game would be more awesome! Eventually I learned the lesson that my good buddy Antoine so cleverly encapsulated:
Perfection is achieved, not when there is nothing left to add, but when there is nothing left to remove. – Antoine de Saint-ExuperyAnyway, point being, it's easy to think you, too could be a game designer. After all, you play games. I play games. I can criticize them. Therefore, I can do better. Right?
The example I've seen is often making music; playing in a band. Lots of people have tried playing a musical instrument, so I think a good number of people have experience enough with playing that they can see that you don't just pick up a guitar and be ready to hit it big after a couple weeks of practice. It takes a couple years to get good at playing an instrument, especially if you're expecting someone to pay you for it. Or drawing; I think it's common knowledge that it takes years of drawing and sketching and painting before others will give you money for your scribbles.
So, the context here is: do I know what I'm talking about, or is this the sort of stuff they teach in the first semester of Game Design School? Obviously, there's a problem in that there's not that many game design schools out there. Like, four, maybe. There's no general game design curriculum. It's very difficult for me to say whether or not other people have covered game design concepts that I see.
A few hours of surfing later: there's a lot of thought out there on game design curricula.
I see mention of things like Bartle's Types, but that's fairly rudimentary -- a lot has been added to the Types discussion since then. Nick Yee, for example, has researched player motivations in MMOs extensively. Understanding all of that data isn't the sort of thing you can put into a single blog post. He constantly writes about it. It's a deep topic. A good game designer should be familiar with it; I could see a Game Design Theory course spending a week or two covering MMO motivations.
I'm not a Raph fan. He got several "battlefield promotions" at Origin when the more senior designers on UO left; he was the last one still alive when the game shipped, and now people think that he created the game. He doesn't claim that, but he definitely profits from the design. I remember an interview I had with Sucker Punch (of Sly Cooper fame) and they basically instilled in me the idea of teach-practice-test: give the player a chance to learn a new skill in a safe environment, give them a few easy practice tests to make sure they can execute the skill, then test that skill in a challenging environment.
Raph's Theory of Fun seems to be that sentence, but stretched to book level. Looking a bit deeper, it seems the book is an apology for working in the entertainment industry, from someone that felt pressure from his family to do something "real." Maybe not. I haven't read the book, because, again, I'm not a Raph fan. The book has won tons of awards, though, so what do I know? If some other guy gives it a badge, then it must be a fact that it's brilliant, right? There's not a whole lot out there on video game design. Stop by a bookstore; count how many game design titles you find. I'm at a bookstore about once a week, and 95% of the time the number of design titles is ZERO. So if Raph has one of the top 10 books on video game design, then... um, there's only numbers one through four. I could publish this rambling rant as a book on game design and it'd be the 5th best book ever written on the subject.
Grr. Ok, so enough of that.
"Game design" also applies to board games, pen-n-paper RPGs, etc. I've seen several books on board game or war game design. The design of other games is significantly better documented than video game design.
Game design course curricula that I've seen generally cover the biggies: Raph's book, Bartle's paper, maybe related stuff like McCloud's Understanding books, Costikyan, and Sirlin. Textbooks themselves are scarce: Rules of Play, maybe not any others. That's the only one I know about. There's no series of textbooks for a bunch of different game design courses. The 'meat' of the design portion of the curricula are studios and seminars, anecdote books, post-mortems, and the like.
(Take Computer Science in contrast: you can stop by your local college bookstore and find textbooks for dozens of different comp sci classes. Plus software engineering texts, plus all the lay books on theory and practice for tons of subsets of theory within software development. My point is that there's one game design course textbook. Design courses read other books, the equivalent of lay books. Those books are not courses in game design; they cover aspects of game design, but aren't written as textbooks.)
So... where do I go for nomenclature? I can't justify spending too much time researching a given topic because there's not enough out there to find.
So I'm just going to make it up as I go along.
Sunday, July 13, 2008
The Settlers
From Wikipedia: "Many fans of the franchise consider [Settlers II] the best game of the Settlers series, primarily because future installments changed the transport management aspect considerably." In fact, Blue Byte (the devs) recently remade the game (Settlers II 10th Anniversary Edition) because it had been so successful. Blue Byte have been making Settlers versions for 15 years now. It's fairly popular in Europe, and each game sells (I'd guess) in the 200-500k copies range in the US.
Settlers II gameplay: the game plays on a hex grid. (1) Build buildings, in the interior of the grid. Minions automatically head to the building, construct it, start working there, and place their produced goods on the road in front of the building. (2) Place roads along the borders of the hex grid, connecting buildings together. Minions automatically show up on the road. Whenever a good is placed at one end of their road, they head over, pick it up, and carry it to the other side. I think buildings automatically have a flag out front, so if a needed resource (say, wheat at a baker) gets placed in front, that good automatically goes into the building. (3) Place flags on the road, to subdivide the road into smaller stretches. Your village's population rarely supports enough minions to place roads & flags all over the place, so one has to exercise care when placing buildings, or else you risk shutting down your economy.
Buildings produced stuff. Some required materials to be carted over; others gathered resources from the environment. The woodcutter's hut, for example, produced a minion that would wander the area around the hut, cutting down random trees. The stonecutter's hut needed to be placed near a stone quarry (which showed up on the game map). Mines needed all three types of food (bread, fish, meat) to go, and you needed ore to smelt bars to craft weapons to equip soldiers to take over territories, so the game missions -- "take over territory X" -- meant building a full village.
gameplay in Settlers VI, aka Rise of an Empire, released in 2007, the game I bought yesterday: build resource-gathering huts in random places, build resource-processing buildings in random places, sit back and wait. Missions have around a dozen miniquests within them, which are things like "defeat this troop of bandits" or "deliver 9 pairs of woolen pants to your neighbor" or "promote your Knight to Sheriff". Of course, each of these has prerequisites, which is what the gameplay is. Build the right buildings. But placement doesn't seem to matter much. You can't tweak production or distribution. You can upgrade buildings, but wood (the resource required for most upgrades) is something you just gather more of. It's not like it's scare or that you have to decide carefully what to upgrade. Mostly you just sit back and wait until things are running smooth enough for you to skim some off the top and declare the objective finished.
Puzzle Pirates has minigames that have nothing to do with gameplay proper. "Sailing" and "Bilge Pumps" are Tetris-like/Match 3 kinda games. You play the puzzle minigame for a few minutes, the ship defeats a foe, you move on to the next fight.
I've described Transport Tycoon as having four minigames: placing stations in cities, building efficient tracks over mountains and around rivers, setting up train consists (the set of cargo that they haul from city to city, plus which cities they stop at), and optimizing rail lines to maximize train throughput.
The station-placement "minigame" in Transport Tycoon is very different than what's in Puzzle Pirates: you only place a station once per city, so it's an important but not frequent minigame. But it is a puzzle; it's not just "select a city and hit Build Station Here". You want to place a station that captures as much of the city as possible without razing any of the important buildings. You can be lackluster about it, but I think people that like the game like the challenge of optimizing their station placement. Likewise for building rails around mountains and rivers; you could just slap it down. What makes the game fun isn't "I finshed the mission!" but rather "Isn't my rail line awesome? Do you see how cleverly this station is placed? Look at this rail line! All those trains, isn't it grand?" It's like raising kids: see what my kid did?
Settlers 6 just seems to happen by itself. I wasn't particularly clever about placement. I built a wall around the town, but there was so goddamn much stone that the wall just... man, I could have built a wall twice as big. And there were random obstructions in the way, like this big boulder and a cliff face and a river, but I just kept building walls. Not particularly clever or interesting or expensive or tricky. It's just there. It's like clicking "Build a Wall Around This City" then standing back. You have to micromanage the wall, but you can't do it well. It's busy-work.
I think the main thing is that Transport Tycoon shows you how good of a job you did. Same for Settlers II, and Sim City. The good games invest the player in his decisions. I remember the decisions I made in Settlers II, and Transport Tycoon, and SimCity. In Settlers 6: meh. The buildings are just there.
Settlers II gameplay: the game plays on a hex grid. (1) Build buildings, in the interior of the grid. Minions automatically head to the building, construct it, start working there, and place their produced goods on the road in front of the building. (2) Place roads along the borders of the hex grid, connecting buildings together. Minions automatically show up on the road. Whenever a good is placed at one end of their road, they head over, pick it up, and carry it to the other side. I think buildings automatically have a flag out front, so if a needed resource (say, wheat at a baker) gets placed in front, that good automatically goes into the building. (3) Place flags on the road, to subdivide the road into smaller stretches. Your village's population rarely supports enough minions to place roads & flags all over the place, so one has to exercise care when placing buildings, or else you risk shutting down your economy.
Buildings produced stuff. Some required materials to be carted over; others gathered resources from the environment. The woodcutter's hut, for example, produced a minion that would wander the area around the hut, cutting down random trees. The stonecutter's hut needed to be placed near a stone quarry (which showed up on the game map). Mines needed all three types of food (bread, fish, meat) to go, and you needed ore to smelt bars to craft weapons to equip soldiers to take over territories, so the game missions -- "take over territory X" -- meant building a full village.
gameplay in Settlers VI, aka Rise of an Empire, released in 2007, the game I bought yesterday: build resource-gathering huts in random places, build resource-processing buildings in random places, sit back and wait. Missions have around a dozen miniquests within them, which are things like "defeat this troop of bandits" or "deliver 9 pairs of woolen pants to your neighbor" or "promote your Knight to Sheriff". Of course, each of these has prerequisites, which is what the gameplay is. Build the right buildings. But placement doesn't seem to matter much. You can't tweak production or distribution. You can upgrade buildings, but wood (the resource required for most upgrades) is something you just gather more of. It's not like it's scare or that you have to decide carefully what to upgrade. Mostly you just sit back and wait until things are running smooth enough for you to skim some off the top and declare the objective finished.
Puzzle Pirates has minigames that have nothing to do with gameplay proper. "Sailing" and "Bilge Pumps" are Tetris-like/Match 3 kinda games. You play the puzzle minigame for a few minutes, the ship defeats a foe, you move on to the next fight.
I've described Transport Tycoon as having four minigames: placing stations in cities, building efficient tracks over mountains and around rivers, setting up train consists (the set of cargo that they haul from city to city, plus which cities they stop at), and optimizing rail lines to maximize train throughput.
The station-placement "minigame" in Transport Tycoon is very different than what's in Puzzle Pirates: you only place a station once per city, so it's an important but not frequent minigame. But it is a puzzle; it's not just "select a city and hit Build Station Here". You want to place a station that captures as much of the city as possible without razing any of the important buildings. You can be lackluster about it, but I think people that like the game like the challenge of optimizing their station placement. Likewise for building rails around mountains and rivers; you could just slap it down. What makes the game fun isn't "I finshed the mission!" but rather "Isn't my rail line awesome? Do you see how cleverly this station is placed? Look at this rail line! All those trains, isn't it grand?" It's like raising kids: see what my kid did?
Settlers 6 just seems to happen by itself. I wasn't particularly clever about placement. I built a wall around the town, but there was so goddamn much stone that the wall just... man, I could have built a wall twice as big. And there were random obstructions in the way, like this big boulder and a cliff face and a river, but I just kept building walls. Not particularly clever or interesting or expensive or tricky. It's just there. It's like clicking "Build a Wall Around This City" then standing back. You have to micromanage the wall, but you can't do it well. It's busy-work.
I think the main thing is that Transport Tycoon shows you how good of a job you did. Same for Settlers II, and Sim City. The good games invest the player in his decisions. I remember the decisions I made in Settlers II, and Transport Tycoon, and SimCity. In Settlers 6: meh. The buildings are just there.
Friday, July 11, 2008
Bridge Pattern vs Strategy Pattern
Short Form: both patterns are uses of inheritance to add flexibility. In both patterns, one class (the Container) has a reference to an Interface or base class, which is obviously intended to be subclassed.
In the Bridge pattern, the Container serves as an Adapter to the Interface, allowing Container's public interface to vary independently of the implementation in the subclasses. Bridge is a pattern that makes it easier to maintain code and add features.
In contrast, the Container's public interface isn't relevant to the Strategy pattern. The idea behind Strategy is to add flexibility to a class via the use of a contained object, instead of putting code directly in the Container and using a switch statement or whatever.
See also Builder Pattern vs Factory Pattern or Aggregation vs Composition.
--
I asked an interviewee about the Strategy Pattern yesterday, and it got me thinking about how best to explain the concept to someone. I'm of the belief that if you can't explain a concept then you don't really know it. There are a lot of concepts that one might have a fuzzy grasp of, but there's a wide gulf between that fuzzy grasp and being able to explain a concept to someone else. Explaining stuff is a great way to learn. That's one of the main reasons why I blog. :)
A pattern is a way of helping you abstract what your code is doing. It's a learning tool. We use a pattern name so that we can quickly explain what we're doing to others and so we can quickly implement new code. If I tell you that I'm using a Bridge in this one piece of code, and you know what a Bridge is, then I don't have to go through the trouble of explaining what all is going on. The word "Bridge" captures all of that info. If you only have a fuzzy grasp of the concept then we haven't really communicated. I said "bridge" but you heard "some sort of abstract connection thingy."
Patterns also help us categorize past experiences. I've implemented the Strategy pattern frequently and there's a few things I like to do the same way each time, like using an enum to specify which strategy to use. Following an existing pattern means not having to make up something from whole cloth.
The Bridge and Strategy patterns are structurally the same thing. They differ in intent. They're also similar to the State pattern and sometimes confused with the Template Method pattern, so I'll go over all four. Keep in mind that the purpose of using jargon is to communicate not just the fact that you're using inheritance somewhere, but why you're using it, and how the code is making use of it.
As I've said before, the best way to explain a concept is by using a few examples, including at least one negative example (to make sure you've communicated the limits of the concept). So let me give some examples of common usage.
A Strategy allows you to swap in different behaviors by using a base class or Interface. You'll have at least four classes in this model: the Container, the Base Class, and two (or more) Subclasses. Say you've got a game with creatures that do different behaviors, such as Guard or Patrol or Hunt. Your AI class for the creature (the Container) contains a base class pointer (the Interface), which is an instance of one of the various Subclasses. You could have just had a switch statement somewhere in your AI class; that would not be a Strategy. Moving the 'joint' into a new class and using various subclasses to implement the behavior is the Strategy pattern.
Or maybe you have a button in your UI, but that button could be drawn using a texture or by rendering text over a standard rounded-rectangle. Instead of implementing two different Button classes, you could create a new ButtonRenderer class to encapsulate how you draw the control. The Button class (the Container) contains a pointer to a ButtonRenderer (the Interface), which will be either TextureButtonRenderer or TextButtonRenderer.
Strategy example:
One can think of a Bridge is a combination of a Proxy (or Adapter) and a Strategy. Instead of just coding one base class and its subclasses, Bridge adds another object into the picture. This extra class provides the external interface, and maps that interface to the base class's interface. You can vary the interface (ie the extra class's public methods) separately from the implementation (ie the various subclasses).
You say "Strategy" when you want to vary behavior, and you do so not by writing different objects but by introducing a class heirarchy. You say "Bridge" when you expect that you will vary both the interface and the implementation. In both cases you're providing flexibility for a changing implementation; in a Bridge, you're also expecting the interface to change.
A Strategy is when one type of object implements some part of its behavior using another class. For example, a Button implements rendering (but not click-processing or message-sending) using a new class. A Bridge implies that you could have just used that class directly somewhere up the chain, but that you want to add in an Adapter or Proxy on top. The interface that a Bridge object exposes is usually similar to the base class; in a Strategy, the public interface of the container object is often completely different than the contained base class. A Strategy says that you are implementing part of the container's behavior using the base class.
The State pattern is similar to Strategy. Typically, a Strategy pattern means that you set an object's behavior at construction, like the Button example above. Buttons don't change from one appearance to another in the middle of a game! The AI example, though, is more like the State pattern: not only have you provided flexibility by adding a new base class and stuffing variation into new classes instead of using a switch statement or if statement, but you'll be changing out which subclass you use fairly frequently. "State" implies a Strategy that changes frequently over an object's lifetime. "State" also implies that you're trying to encapsulate some complex, dynamic portion of an object's behavior into a new class, where "Strategy" implies that, when the Container object is constructed, that its creator will tell the Container what approach to take for its entire lifetime.
The Template Method is really not similar to these, but sometimes people confuse it with one of the others. Say you've got an object's script in an XML file; in-game, you turn each one of the "commands" in the XML into a call into some other class. Say the XML script includes commands like Attack, Move, Find Target, Use Bandaid, etc. Different creatures could use the same script to do their thing, but they might do it in different ways -- Attack could be performed by casting Magic Missile, or firing a bow, or by swinging an axe -- the script is then a Template Method. It's an algorithm that can be implemented in different ways. A Template Method can be considered a sequence of different Strategy choices, and is often implemented that way.
Similar Posts:
Builder Pattern vs Factory Pattern
Aggregation vs Composition
See Also:
Bridge at Wikipedia or c2
Strategy at Wikipedia or c2
State at Wikipedia or c2
Adapter at Wikipedia or c2
Proxy at Wikipedia or c2
In the Bridge pattern, the Container serves as an Adapter to the Interface, allowing Container's public interface to vary independently of the implementation in the subclasses. Bridge is a pattern that makes it easier to maintain code and add features.
In contrast, the Container's public interface isn't relevant to the Strategy pattern. The idea behind Strategy is to add flexibility to a class via the use of a contained object, instead of putting code directly in the Container and using a switch statement or whatever.
See also Builder Pattern vs Factory Pattern or Aggregation vs Composition.
--
I asked an interviewee about the Strategy Pattern yesterday, and it got me thinking about how best to explain the concept to someone. I'm of the belief that if you can't explain a concept then you don't really know it. There are a lot of concepts that one might have a fuzzy grasp of, but there's a wide gulf between that fuzzy grasp and being able to explain a concept to someone else. Explaining stuff is a great way to learn. That's one of the main reasons why I blog. :)
A pattern is a way of helping you abstract what your code is doing. It's a learning tool. We use a pattern name so that we can quickly explain what we're doing to others and so we can quickly implement new code. If I tell you that I'm using a Bridge in this one piece of code, and you know what a Bridge is, then I don't have to go through the trouble of explaining what all is going on. The word "Bridge" captures all of that info. If you only have a fuzzy grasp of the concept then we haven't really communicated. I said "bridge" but you heard "some sort of abstract connection thingy."
Patterns also help us categorize past experiences. I've implemented the Strategy pattern frequently and there's a few things I like to do the same way each time, like using an enum to specify which strategy to use. Following an existing pattern means not having to make up something from whole cloth.
The Bridge and Strategy patterns are structurally the same thing. They differ in intent. They're also similar to the State pattern and sometimes confused with the Template Method pattern, so I'll go over all four. Keep in mind that the purpose of using jargon is to communicate not just the fact that you're using inheritance somewhere, but why you're using it, and how the code is making use of it.
A Bridge is a pattern that allows you to vary the interface and implementation separately.You might be thinking, "Huh?"
A Strategy is the parameterized variation of behavior.
The State pattern allows the dynamic variation of behavior.
A Template Method allows the variation of implementation without changing the algorithm.
As I've said before, the best way to explain a concept is by using a few examples, including at least one negative example (to make sure you've communicated the limits of the concept). So let me give some examples of common usage.
A Strategy allows you to swap in different behaviors by using a base class or Interface. You'll have at least four classes in this model: the Container, the Base Class, and two (or more) Subclasses. Say you've got a game with creatures that do different behaviors, such as Guard or Patrol or Hunt. Your AI class for the creature (the Container) contains a base class pointer (the Interface), which is an instance of one of the various Subclasses. You could have just had a switch statement somewhere in your AI class; that would not be a Strategy. Moving the 'joint' into a new class and using various subclasses to implement the behavior is the Strategy pattern.
Or maybe you have a button in your UI, but that button could be drawn using a texture or by rendering text over a standard rounded-rectangle. Instead of implementing two different Button classes, you could create a new ButtonRenderer class to encapsulate how you draw the control. The Button class (the Container) contains a pointer to a ButtonRenderer (the Interface), which will be either TextureButtonRenderer or TextButtonRenderer.
Strategy example:
class ButtonA Bridge is when you want to vary the implementation and interface separately. Say you've got a data access layer. The layer talks to an underlying database; you might want to change the type of database that you connect to. This could range from changing the connection string (to switch from a development DB to the production DB) to changing the database type (from SQL to Access to a stored XML file). But this layer also exposes an interface to the next higher layer (the business logic layer). A data access layer is, essentially, a Bridge: it separates the public interface of a class (Business Logic -> DAL) from its implementation (DAL -> Database).
{
private ButtonRenderer _renderer;
public Button( ButtonTypeEnum visualAppearance )
{
if (visualAppearance==ButtonTypeEnum.TexturedButton)
_renderer = TexturedButtonRenderer;
else
_renderer = TextButtonRenderer;
}
...
}
One can think of a Bridge is a combination of a Proxy (or Adapter) and a Strategy. Instead of just coding one base class and its subclasses, Bridge adds another object into the picture. This extra class provides the external interface, and maps that interface to the base class's interface. You can vary the interface (ie the extra class's public methods) separately from the implementation (ie the various subclasses).
You say "Strategy" when you want to vary behavior, and you do so not by writing different objects but by introducing a class heirarchy. You say "Bridge" when you expect that you will vary both the interface and the implementation. In both cases you're providing flexibility for a changing implementation; in a Bridge, you're also expecting the interface to change.
A Strategy is when one type of object implements some part of its behavior using another class. For example, a Button implements rendering (but not click-processing or message-sending) using a new class. A Bridge implies that you could have just used that class directly somewhere up the chain, but that you want to add in an Adapter or Proxy on top. The interface that a Bridge object exposes is usually similar to the base class; in a Strategy, the public interface of the container object is often completely different than the contained base class. A Strategy says that you are implementing part of the container's behavior using the base class.
The State pattern is similar to Strategy. Typically, a Strategy pattern means that you set an object's behavior at construction, like the Button example above. Buttons don't change from one appearance to another in the middle of a game! The AI example, though, is more like the State pattern: not only have you provided flexibility by adding a new base class and stuffing variation into new classes instead of using a switch statement or if statement, but you'll be changing out which subclass you use fairly frequently. "State" implies a Strategy that changes frequently over an object's lifetime. "State" also implies that you're trying to encapsulate some complex, dynamic portion of an object's behavior into a new class, where "Strategy" implies that, when the Container object is constructed, that its creator will tell the Container what approach to take for its entire lifetime.
The Template Method is really not similar to these, but sometimes people confuse it with one of the others. Say you've got an object's script in an XML file; in-game, you turn each one of the "commands" in the XML into a call into some other class. Say the XML script includes commands like Attack, Move, Find Target, Use Bandaid, etc. Different creatures could use the same script to do their thing, but they might do it in different ways -- Attack could be performed by casting Magic Missile, or firing a bow, or by swinging an axe -- the script is then a Template Method. It's an algorithm that can be implemented in different ways. A Template Method can be considered a sequence of different Strategy choices, and is often implemented that way.
Similar Posts:
Builder Pattern vs Factory Pattern
Aggregation vs Composition
See Also:
Bridge at Wikipedia or c2
Strategy at Wikipedia or c2
State at Wikipedia or c2
Adapter at Wikipedia or c2
Proxy at Wikipedia or c2
Game State Management : Finite State Machines
I've added a subsequent post on state management in game menus. My previous post on game state covered high-level game state management. I next tried writing this post, but felt that covering feature creep was first up. I'll explain that first.
The whole trick to writing a game state management system is figuring out where you need flexibility. A system that's too complex winds up being buggy and a pain to use. Stable, easy-to-use systems generally allow you to add more richness to a project, say by extending the system, and that's something that doesn't happen when you have buggy or painful code. Simple systems lead to power.
Game state systems are used to implement game AI or mechanics. For example, a building in an RTS might start in a Construction state, then transition into an Idle state, then move into a Production state then back to Idle. A Creature AI might use states like Patrol, Guard, Hunt, Attack, Move, or Sleep. Programmers usually implement these systems using finite state machines, and that's what I'll be talking about here.
Finite State Machines (FSMs) are easy to code. The major element is the State object; everything else is optional. That else includes Transitions & Transition Conditions, Events, and Actions.
So what's a state? Take the RTS example above. When a building is in the Construction state, it might cycle through several different stages, ie have several different images (for a 2D game) or models (for a 3D game) that represents that partial construction. Maybe the phase is one long animation; maybe it's a set of several different animations. Even for a 2D, non-animated game, you might display a progress bar or particle effect or something else indicating construction progress. Is each 'step' along that progress a different State?
And that's the decision to make. Why are you storing the state? I mentioned several different states for a building in an RTS, and these suggest the state that the building is considered to be in for the purposes of gameplay, not for animation. It doesn't matter how far along construction is, the player only has two choices: either leave it alone to continue construction, or cancel the construction. This is a good level to model the state. Leave the problem of animating the building to some other system; a useful state management system in this game will deal with "Under Construction" as one entire state. A building might have four states: Construction, Idle, Production, and Under Attack (a building under attack can't be repaired or start production).
Do you need a class to store this state? Another option is to store the state as an enum. Every game tick, you tell the building to draw itself, and it can switch depending on that enum, just as easily as looking at a state class. So why would you have a State class?
One reason would be to implement the Strategy pattern. The building object itself could hold a State object, where State is an abstract base class. Subclasses would implement virtual functions, which could be Events (User_Requested_Production, User_Cancels_Construction, etc) or queries (Can_Start_Production) or maybe even a Tick or Render function. This means creating new subclasses not just for each state that buildings could share (like Idle) but also per building and per game object. The question is, what behavior do different buildings share in their Idle states, and would different game objects (like Buildings and Infantry and Missiles) all have Production or Under Attack states? What's the shared code?
This is putting the cart before the horse. Don't be led into thinking that you need to implement a Finite State Machine class because lots of games use finite state machines. I recommend implementing (say) one game object (like Buildings) first, and one Building before the rest, and then see where you can pull common code out. Implement some simple method using a bunch of switch statements and enums and see, for your game genre and design, where you need flexibility. When you're writing the code for a particular building, you might wind up writing a bunch of switch statements, and when you see yourself doing that, that is a good time to decide to implement some kind of FSM abstraction into the code.
Do all game objects render themselves? Do all game objects share a common base class (maybe they don't!)? Maybe there's common code to render a game object. Maybe all Buildings share rendering code among themselves that isn't used by other game objects. Most likely, you're not going to want custom Render methods for each individual building, or worse, each state that each building can be in.
Let's go back to the Building interface. Other gameplay objects don't really care how buildings render themselves, or really even what state the building is in. They have specific questions: can you start production right now? Should I be displaying a Cancel button? Is the building damaged? There's lots of other state I'm skipping over, too, like how many hit points the building has. I reckon there's some OO nutball out there that thinks that hit points should be encapsulated into a state object, but you and me can laugh at him. My god, man, no way. Hit points are 'state', but there's no reason to have a state object there. An int is fine. Hit points are such a primary concept in a game like an RTS that your base Game Object (or Building) class should have an accessor for that value.
So the external interface that a Building object exposes doesn't contain any State-like abstract object. A State object might be useful for a Building to manage itself internally, but it's not something it tells its friends about.
The place to put flexibility in your code is where there's a lot of traffic. Buildings don't get a lot of traffic. There's not much that can be done to them -- they get attacked, they get repaired -- but they don't usually observe their environment. Buildings don't behave different when their hitpoints get low, or when an enemy comes into range, or if they see a friendly unit nearby. Maybe yours do, but at least they're far more "stable" when compared to other units (like infantry). A complex state management system with transitions and events getting fired and scriptable transition conditionals and substates and enter actions and exit actions and all that... not that useful for game objects that don't do a lot of those things.
Mobile AI units, like infantry in an RTS or mobs in a real-time RPG or enemies in a FPS, will do a lot of those things. A fancy state management system makes more sense for those kinds of AI units, and I'll cover them in more depth next time.
The whole trick to writing a game state management system is figuring out where you need flexibility. A system that's too complex winds up being buggy and a pain to use. Stable, easy-to-use systems generally allow you to add more richness to a project, say by extending the system, and that's something that doesn't happen when you have buggy or painful code. Simple systems lead to power.
Game state systems are used to implement game AI or mechanics. For example, a building in an RTS might start in a Construction state, then transition into an Idle state, then move into a Production state then back to Idle. A Creature AI might use states like Patrol, Guard, Hunt, Attack, Move, or Sleep. Programmers usually implement these systems using finite state machines, and that's what I'll be talking about here.
Finite State Machines (FSMs) are easy to code. The major element is the State object; everything else is optional. That else includes Transitions & Transition Conditions, Events, and Actions.
So what's a state? Take the RTS example above. When a building is in the Construction state, it might cycle through several different stages, ie have several different images (for a 2D game) or models (for a 3D game) that represents that partial construction. Maybe the phase is one long animation; maybe it's a set of several different animations. Even for a 2D, non-animated game, you might display a progress bar or particle effect or something else indicating construction progress. Is each 'step' along that progress a different State?
And that's the decision to make. Why are you storing the state? I mentioned several different states for a building in an RTS, and these suggest the state that the building is considered to be in for the purposes of gameplay, not for animation. It doesn't matter how far along construction is, the player only has two choices: either leave it alone to continue construction, or cancel the construction. This is a good level to model the state. Leave the problem of animating the building to some other system; a useful state management system in this game will deal with "Under Construction" as one entire state. A building might have four states: Construction, Idle, Production, and Under Attack (a building under attack can't be repaired or start production).
Do you need a class to store this state? Another option is to store the state as an enum. Every game tick, you tell the building to draw itself, and it can switch depending on that enum, just as easily as looking at a state class. So why would you have a State class?
One reason would be to implement the Strategy pattern. The building object itself could hold a State object, where State is an abstract base class. Subclasses would implement virtual functions, which could be Events (User_Requested_Production, User_Cancels_Construction, etc) or queries (Can_Start_Production) or maybe even a Tick or Render function. This means creating new subclasses not just for each state that buildings could share (like Idle) but also per building and per game object. The question is, what behavior do different buildings share in their Idle states, and would different game objects (like Buildings and Infantry and Missiles) all have Production or Under Attack states? What's the shared code?
This is putting the cart before the horse. Don't be led into thinking that you need to implement a Finite State Machine class because lots of games use finite state machines. I recommend implementing (say) one game object (like Buildings) first, and one Building before the rest, and then see where you can pull common code out. Implement some simple method using a bunch of switch statements and enums and see, for your game genre and design, where you need flexibility. When you're writing the code for a particular building, you might wind up writing a bunch of switch statements, and when you see yourself doing that, that is a good time to decide to implement some kind of FSM abstraction into the code.
Do all game objects render themselves? Do all game objects share a common base class (maybe they don't!)? Maybe there's common code to render a game object. Maybe all Buildings share rendering code among themselves that isn't used by other game objects. Most likely, you're not going to want custom Render methods for each individual building, or worse, each state that each building can be in.
Let's go back to the Building interface. Other gameplay objects don't really care how buildings render themselves, or really even what state the building is in. They have specific questions: can you start production right now? Should I be displaying a Cancel button? Is the building damaged? There's lots of other state I'm skipping over, too, like how many hit points the building has. I reckon there's some OO nutball out there that thinks that hit points should be encapsulated into a state object, but you and me can laugh at him. My god, man, no way. Hit points are 'state', but there's no reason to have a state object there. An int is fine. Hit points are such a primary concept in a game like an RTS that your base Game Object (or Building) class should have an accessor for that value.
So the external interface that a Building object exposes doesn't contain any State-like abstract object. A State object might be useful for a Building to manage itself internally, but it's not something it tells its friends about.
The place to put flexibility in your code is where there's a lot of traffic. Buildings don't get a lot of traffic. There's not much that can be done to them -- they get attacked, they get repaired -- but they don't usually observe their environment. Buildings don't behave different when their hitpoints get low, or when an enemy comes into range, or if they see a friendly unit nearby. Maybe yours do, but at least they're far more "stable" when compared to other units (like infantry). A complex state management system with transitions and events getting fired and scriptable transition conditionals and substates and enter actions and exit actions and all that... not that useful for game objects that don't do a lot of those things.
Mobile AI units, like infantry in an RTS or mobs in a real-time RPG or enemies in a FPS, will do a lot of those things. A fancy state management system makes more sense for those kinds of AI units, and I'll cover them in more depth next time.
Monday, July 7, 2008
Gameplay and Irony
What you spend your time doing in a game isn't necessarily what you think the game is about.
One of my favorite game genres is sims; games like Railroad Tycoon or Settlers. These games are ostensibly economy-building games, but that's not what one spends their time doing in the game.
Take The Settlers. I remember building up settlements from next-to-nothing. Once you build a structure it runs on its own. In an hour-long play session, I might only build 20 or so structures. That's one structure every three minutes. So that's not really what one spends time in-game doing. What do you do for the rest of those three minutes?
I was optimizing the pathways to speed up production -- to eliminate transport bottlenecks, to get manufactured goods from one step in the production chain to the next, and make sure my favored buildings were getting their requirements. I was micro-managing my prospectors, finding optimal locations for new buildings, and assessing stockpiles and production rates.
An so that was the gameplay: micromanaging transport routes, placing buildings carefully, and figuring out what the settlement needed for the next stage of production.
Transport Tycoon was very similar. The game is loosely about building new rail lines and improving service at existing stations. I've spent more time thinking about the game, and I know that at its heart it is those two things. Building new rail lines is a combination of two mini-games: a tetris-like problem of finding the optimal place to put a station in a city, and the task of building a line around a mountain and over hills that allows a train to move quickly (without having to spend a lot on rail construction).
Both of those tasks were defined by the game's square grid. Without that grid, both tasks would be both simpler and less interesting. Deciding to build a rail line, or to place a station, is easy. Placing it is the puzzle. Games that try to get rid of the "old-school" square grid also get rid of that puzzle.
When you think of a game that you really enjoyed, it's important to remember both the highlights as well as the details. The highlights of Diablo are killing boss creatures or finding great new loot, but the details -- what you spend minute-to-minute doing -- is the click-fest of combat. MMOs like WoW have highlights like finally buying your (epic) (flying) mount, downing raid bosses, or finishing a gear set, but the details are in the combat system. Doom III has some scary-moment highlights, but you spend most of your time creeping around corners and trying to pick off enemies from afar.
If the details sucked, then the highlights are likely to just be a rationalization for playing. I've talked to people that really enjoyed the socialization in EverQuest and in Asheron's Call, and the way they describe it really makes clear that the details -- the minute-to-minute gameplay -- in both games was boring and grindy. ATITD has intriguing highlights: finishing obelisks, tackling newly opened tests, giant group efforts to finish massive structures. But the gameplay sucked. ATITD's three major gameplay elements are running around (i.e. long runs), waiting, and mindlessly clicking.
Dave Sirlin on occasion points out that bad gameplay elements, no matter how they appear to shape the rest of a game, aren't good things. Your game would be better without them. In ATITD, the timesinks seem to be something to give the player to do (since the rest of the game is so barren). WoW took similar ideas but vastly improved on them. Fishing is a great example. In ATITD, you stand near water, hit the 'fish' button, and wait 5 seconds. WoW asks you to stare at a bobble and click on it when it moves, somewhere between 3 and 20 seconds after you cast it. The WoW approach is much slower, but it forces the player to pay attention.
Is WoW fishing bad? It's not boring; you have to pay attention. It's kinda distracting, because you can't really dedicate yourself 100% to some chat conversation, or browsing your recipe book, or watching the TV out of the corner of your eye -- you need to be ready to click on that bobble within a second of it moving. It's not horribly complicated; there's no tricks involved at all.
ATITD has some much better minigames, such as charcoal production. Getting a good batch of charcoal is a skill-based tradeskill. After loading an oven up with wood, you have a few controls to tweak -- adding more wood, opening or closing the vents, or even throwing a bit of water in the oven to get a raging fire back under control. If only the rest of the tasks were as interesting...
Transport Tycoon is an empire-building game and Settlers is an econ-building game, but in both of them the economics serve as a framework for what's really going on. Like saving up for a mount in WoW, they're the goals, but it's not the game. However interesting and motivating your game's end-points, the process is what players spend their time doing and should be what they enjoy.
One of my favorite game genres is sims; games like Railroad Tycoon or Settlers. These games are ostensibly economy-building games, but that's not what one spends their time doing in the game.
Take The Settlers. I remember building up settlements from next-to-nothing. Once you build a structure it runs on its own. In an hour-long play session, I might only build 20 or so structures. That's one structure every three minutes. So that's not really what one spends time in-game doing. What do you do for the rest of those three minutes?
I was optimizing the pathways to speed up production -- to eliminate transport bottlenecks, to get manufactured goods from one step in the production chain to the next, and make sure my favored buildings were getting their requirements. I was micro-managing my prospectors, finding optimal locations for new buildings, and assessing stockpiles and production rates.
An so that was the gameplay: micromanaging transport routes, placing buildings carefully, and figuring out what the settlement needed for the next stage of production.
Transport Tycoon was very similar. The game is loosely about building new rail lines and improving service at existing stations. I've spent more time thinking about the game, and I know that at its heart it is those two things. Building new rail lines is a combination of two mini-games: a tetris-like problem of finding the optimal place to put a station in a city, and the task of building a line around a mountain and over hills that allows a train to move quickly (without having to spend a lot on rail construction).
Both of those tasks were defined by the game's square grid. Without that grid, both tasks would be both simpler and less interesting. Deciding to build a rail line, or to place a station, is easy. Placing it is the puzzle. Games that try to get rid of the "old-school" square grid also get rid of that puzzle.
When you think of a game that you really enjoyed, it's important to remember both the highlights as well as the details. The highlights of Diablo are killing boss creatures or finding great new loot, but the details -- what you spend minute-to-minute doing -- is the click-fest of combat. MMOs like WoW have highlights like finally buying your (epic) (flying) mount, downing raid bosses, or finishing a gear set, but the details are in the combat system. Doom III has some scary-moment highlights, but you spend most of your time creeping around corners and trying to pick off enemies from afar.
If the details sucked, then the highlights are likely to just be a rationalization for playing. I've talked to people that really enjoyed the socialization in EverQuest and in Asheron's Call, and the way they describe it really makes clear that the details -- the minute-to-minute gameplay -- in both games was boring and grindy. ATITD has intriguing highlights: finishing obelisks, tackling newly opened tests, giant group efforts to finish massive structures. But the gameplay sucked. ATITD's three major gameplay elements are running around (i.e. long runs), waiting, and mindlessly clicking.
Dave Sirlin on occasion points out that bad gameplay elements, no matter how they appear to shape the rest of a game, aren't good things. Your game would be better without them. In ATITD, the timesinks seem to be something to give the player to do (since the rest of the game is so barren). WoW took similar ideas but vastly improved on them. Fishing is a great example. In ATITD, you stand near water, hit the 'fish' button, and wait 5 seconds. WoW asks you to stare at a bobble and click on it when it moves, somewhere between 3 and 20 seconds after you cast it. The WoW approach is much slower, but it forces the player to pay attention.
Is WoW fishing bad? It's not boring; you have to pay attention. It's kinda distracting, because you can't really dedicate yourself 100% to some chat conversation, or browsing your recipe book, or watching the TV out of the corner of your eye -- you need to be ready to click on that bobble within a second of it moving. It's not horribly complicated; there's no tricks involved at all.
ATITD has some much better minigames, such as charcoal production. Getting a good batch of charcoal is a skill-based tradeskill. After loading an oven up with wood, you have a few controls to tweak -- adding more wood, opening or closing the vents, or even throwing a bit of water in the oven to get a raging fire back under control. If only the rest of the tasks were as interesting...
Transport Tycoon is an empire-building game and Settlers is an econ-building game, but in both of them the economics serve as a framework for what's really going on. Like saving up for a mount in WoW, they're the goals, but it's not the game. However interesting and motivating your game's end-points, the process is what players spend their time doing and should be what they enjoy.
Subscribe to:
Posts (Atom)