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.
Friday, July 18, 2008
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)