The lunch theme this week has been "so what was it like working in the games industry?"
Good and bad. Unstable. Underpaid.
Good and Bad
It's easy to guess the good parts: at the end of a day, you can point to a sprite, or a combat screen, or some AI, or a really cool-looking model and say "I did that!" It's great. But there's a lot of other great benefits, too. The office graffiti is professionally done. There's a Robotron machine in the breakroom. Your boss won't yell at you for having an action figure on your monitor. Or, heck, an army of action figures around your desk. In fact, he's got that 5000-piece Lego Star Destroyer taking up his.
Every job is a job. Some jobs have fun bits, but if it's all fun, they're probably not paying you. Sometimes you just don't feel like going to work, or working on something annoying, or having to do something embarrassing. There's going to be bad parts to any job. Some bosses suck, some coworkers are crazy, sometimes the deadlines will eat your soul.
Unstable
In Hollywood, everyone knows that they're out of a job when the project wraps. In the games industry, sometimes you know and sometimes you don't. Game development is very clearly project-based, but yet employment is mostly full-time. Sometimes your boss tells you that they'll keep things going but then he changes his mind and you're off looking for a new work when the publisher decides not to renew a contract. It's tough to predict that stuff, even on the inside.
Underpaid
There's a ton of people that want in the games industry. A good number of them are willing to put in the effort to get hired, too. And then, once in the industry, they get paid slave wages. Profit structures are generally set up that unless a game wildly exceeds expectations, there's no royalties to hand out. You're not going to get a bonus. At Microsoft, the secretaries became millionaires when the company went big. Maybe I'm wrong, but I have a feeling that most of the grunts at Blizzard got nice bonuses and a salary bump when WoW shipped, but I don't think they're all millionaires.
Game companies want young, single people that are willing to work 80 hours a week. You'll be on salary, of course, and exempt from overtime.
The Good, Part II
Making games is hella fun. It's full of intriguing puzzles. As long as you're not stuck churning out shovelware for some marketing tie-in, chances are you're developing a brand-new game from scratch. The "real world" pays a lot better, but money can't buy happiness. I have a much easier time getting out of bed on the weekends because I know I'll be working on my game project. Plus, I know that I will keep the profits if it does well. I'm working for myself and happy as a pre-colony-collapse-disorder bee.
Friday, May 30, 2008
Thursday, May 29, 2008
Programmers as Designers
First let me point out that there are many game-building tasks that are given to a designer. The designer might come up with a world history, write character dialog, design levels, tweak game mechanics, design game mechanics, name classes or skills, come up with crafting recipes, write game-item scripts, and on and on.
Here, I'm talking about the high level stuff -- mechanics, and the other stuff insofar as it is relevant to the feel of the gameplay experience. The gestalt of (say) level design, rather than the craft of it.
--
Programmers, by the nature of their job, have a great body of experience to draw from; a rich source upon which they can draw insight into the game design process.
Let's say you want dynamically flowing water in your mostly-2D city building game. You can ask a programmer about it, and work with the programmer. But what works, the caveats, etc are all things discovered by the programmer. Having someone else (a separate designer) stare over his shoulder just wastes his time -- unless you think it's important to prevent that programmer from working without adult supervision. :P
Some programmers are eggheads. Total geeks. Socially inept, clumsy, absent-minded, the works. These guys might be good at algorithms, but you don't want to let them near your design. My argument isn't that being socially inept makes someone a game designer. Quite the reverse. My argument is that a rational mind is critical for the task.
A good designer needs to understand [1] how algorithms will impact gameplay; [2] what drives players, what they think of as fun, and what makes games compelling; and [3] how the mechanics he's built into the game will alter and steer player behavior.
Algorithms
I've met some designers that are great at level design. True artists. But their levels were sometimes awkward and unbalanced. I wouldn't want to ask them to come up with game mechanics, other than to contribute some creative suggestions. They were no better at designing game mechanics than dozens of the egghead programmers I've worked with, but the engineers understood Big O, searching, sorting, curves, graphs, charts, A*, inheritance, and/or state machines.
Compelling Gameplay
A good designer needs to understand how people think. Coming up with cool ideas isn't useful if you're the only one that thinks they're cool. I've said before (and this might well be a recurring them) that most players have no idea of why they like a game. It's easy to take something and criticize it. When you don't actually have to implement anything, it's also easy to suggest solutions. I'm reminded of suggestion threads on popular-game bulletin boards. There's a ton of people with theories for making the game more awesome or less sucky, and a ton of theories that just won't work.
This isn't something that a programmer would be better at than an artist or level builder, generally, except that I think a programmer is closer to learning about this stuff, because good programmers are good at analysis. They understand the scientific method, and how to test their own theories on player behavior. Some designers spend a lot of time studying game mechanics; some programmers do too; either one might also spend time studying psychology.
Incentives
Game designers get to play Economics Czar, but people are bad economists. Politicians will tell you "we're doing this for the children" and wind up with a plan that stabs them in the back. A game design sets up incentives, which players will quickly discover and play to. Learning to look for and see incentives before they're implemented in a game isn't something that happens after reading one blog page. A book might help.
As with creating compelling gameplay, I think this is one of those areas that programmers are often not any more competent than anyone else in a game studio, but yet an area where their mindset and experience with code (and scripting) can give them a head start in learning it.
The Biggest Barrier
I think the biggest hindrance to creating great game mechanics, for non-programmers, is not knowing what's possible to do in code. I'm an agile developer, and I think one of the key life lessons that's pushed me in that direction is learning that you find out far more about a problem by trying to implement it than you ever could be staring at it while it's on a piece of paper. When I was in college (and for years afterwards) I thought the most important thing a programmer should do is plan out his development path in excruciating detail. Implementation turns that detail to excrement. For years my plans never turned out the way I thought, and, like a politician addicted to money, thought the solution was to throw ever more at the problem.
But the lesson isn't to not plan; it's to acknowledge that you need to jump in and get your feet wet, to find out if the rock you see underneath those rippling waves is as sturdy as you think it is. Staring and planning and measuring from the streambed will give you a better idea, but not the answer.
Programmers are the ones charged with finding away across that stream. I think the experience of doing the grunt work gives the grunt a great perspective for planning the next one. It's up to the programmer to put that experience to work.
Here, I'm talking about the high level stuff -- mechanics, and the other stuff insofar as it is relevant to the feel of the gameplay experience. The gestalt of (say) level design, rather than the craft of it.
--
Programmers, by the nature of their job, have a great body of experience to draw from; a rich source upon which they can draw insight into the game design process.
Let's say you want dynamically flowing water in your mostly-2D city building game. You can ask a programmer about it, and work with the programmer. But what works, the caveats, etc are all things discovered by the programmer. Having someone else (a separate designer) stare over his shoulder just wastes his time -- unless you think it's important to prevent that programmer from working without adult supervision. :P
Some programmers are eggheads. Total geeks. Socially inept, clumsy, absent-minded, the works. These guys might be good at algorithms, but you don't want to let them near your design. My argument isn't that being socially inept makes someone a game designer. Quite the reverse. My argument is that a rational mind is critical for the task.
A good designer needs to understand [1] how algorithms will impact gameplay; [2] what drives players, what they think of as fun, and what makes games compelling; and [3] how the mechanics he's built into the game will alter and steer player behavior.
Algorithms
I've met some designers that are great at level design. True artists. But their levels were sometimes awkward and unbalanced. I wouldn't want to ask them to come up with game mechanics, other than to contribute some creative suggestions. They were no better at designing game mechanics than dozens of the egghead programmers I've worked with, but the engineers understood Big O, searching, sorting, curves, graphs, charts, A*, inheritance, and/or state machines.
Compelling Gameplay
A good designer needs to understand how people think. Coming up with cool ideas isn't useful if you're the only one that thinks they're cool. I've said before (and this might well be a recurring them) that most players have no idea of why they like a game. It's easy to take something and criticize it. When you don't actually have to implement anything, it's also easy to suggest solutions. I'm reminded of suggestion threads on popular-game bulletin boards. There's a ton of people with theories for making the game more awesome or less sucky, and a ton of theories that just won't work.
This isn't something that a programmer would be better at than an artist or level builder, generally, except that I think a programmer is closer to learning about this stuff, because good programmers are good at analysis. They understand the scientific method, and how to test their own theories on player behavior. Some designers spend a lot of time studying game mechanics; some programmers do too; either one might also spend time studying psychology.
Incentives
Game designers get to play Economics Czar, but people are bad economists. Politicians will tell you "we're doing this for the children" and wind up with a plan that stabs them in the back. A game design sets up incentives, which players will quickly discover and play to. Learning to look for and see incentives before they're implemented in a game isn't something that happens after reading one blog page. A book might help.
As with creating compelling gameplay, I think this is one of those areas that programmers are often not any more competent than anyone else in a game studio, but yet an area where their mindset and experience with code (and scripting) can give them a head start in learning it.
The Biggest Barrier
I think the biggest hindrance to creating great game mechanics, for non-programmers, is not knowing what's possible to do in code. I'm an agile developer, and I think one of the key life lessons that's pushed me in that direction is learning that you find out far more about a problem by trying to implement it than you ever could be staring at it while it's on a piece of paper. When I was in college (and for years afterwards) I thought the most important thing a programmer should do is plan out his development path in excruciating detail. Implementation turns that detail to excrement. For years my plans never turned out the way I thought, and, like a politician addicted to money, thought the solution was to throw ever more at the problem.
But the lesson isn't to not plan; it's to acknowledge that you need to jump in and get your feet wet, to find out if the rock you see underneath those rippling waves is as sturdy as you think it is. Staring and planning and measuring from the streambed will give you a better idea, but not the answer.
Programmers are the ones charged with finding away across that stream. I think the experience of doing the grunt work gives the grunt a great perspective for planning the next one. It's up to the programmer to put that experience to work.
Wednesday, May 28, 2008
Linear Gameplay vs Open Worlds
Continuing a thread from yesterday.
I'm fine with linear gameplay. Being shoved into a corner sucks, but if a game is good and fun, chances are you don't notice it. On some recent Lost episode, Locke told Hurley to take off (by himself) and head back to the beach. Hurley thought about it and decided it was a bad idea. Ben, perceiving that result as intentional by Locke, told him (paraphrasing) "well done, now he thinks it was his idea to stay."
If your player wants to go the same direction that you want to send him, linearity isn't that big of a deal. HL2 is linear, but was awesomeness anyway. Ditto for Portal. I thought HL2's linearity was, in some places, too linear. It dig bug me. But I got over it.
I think Sirlin would say "no annoying mechanic is worth keeping." (He, and this catchphrase, has been my ghost the past week. Maybe he wouldn't say that, but I'll save that for another day.)
It's not really that hard to add varied paths into a game. Two door and two hallways; complete three goals, but in any order that the player wants. Don't send him to find the silver key then the gold key--let him find either first. Variation has to be planned around; HL2 went through a ton of tuning, and having multiple completion paths can throw testing and tuning time through the roof. Depending on the implementation!
If the player is running in fear (the player, mind, not the character), he's less likely to notice that he only had one real option. If it looks like he had several options, he might later go back and look, on his next playthrough. People don't like thinking they have unexplored options. There is a thing as too much choice. The trick is giving players real choices (because they are going to go back and check on you), but not to make them feel like they missed something. One trick for solving this dilemma is choosing when to give choice and when to take it away.
When you put cool stuff in the nooks and crannies, some players will want to check every single flippin cranny in the entire game. For games like Doom and Quake, that works. For a narrative-heavy game like Half-Life, I think it's a detriment.
Build up a pattern language. Advertise the big stuff, so that the player is focused on an objective that you have control over. If you want to hide something, show it to the player first. That is, show them the object, but hide the path to it. Give them time to explore nooks and crannies when they're not under pressure. When the heat is on, make the path clear. Players love thinking that they're smart, so make it obvious what they should be doing. The fact that they have choice is enough. It's a bit like the Forer effect; in this case, show a player two choices, where one is obviously better, and he'll choose the better one and feel happy about it.
I think this is a good thing. It's a survival trait. Show someone a snake-filled pit and a banana on table, and he'll go for the banana and be happy that he avoided the snake. The 'danger' is almost illusory! But almost. It is real danger. People look for patterns. When there's a blank in the puzzle, their active imaginations will fill it in. Players like using their imagination. Give them a chance to.
I'm fine with linear gameplay. Being shoved into a corner sucks, but if a game is good and fun, chances are you don't notice it. On some recent Lost episode, Locke told Hurley to take off (by himself) and head back to the beach. Hurley thought about it and decided it was a bad idea. Ben, perceiving that result as intentional by Locke, told him (paraphrasing) "well done, now he thinks it was his idea to stay."
If your player wants to go the same direction that you want to send him, linearity isn't that big of a deal. HL2 is linear, but was awesomeness anyway. Ditto for Portal. I thought HL2's linearity was, in some places, too linear. It dig bug me. But I got over it.
I think Sirlin would say "no annoying mechanic is worth keeping." (He, and this catchphrase, has been my ghost the past week. Maybe he wouldn't say that, but I'll save that for another day.)
It's not really that hard to add varied paths into a game. Two door and two hallways; complete three goals, but in any order that the player wants. Don't send him to find the silver key then the gold key--let him find either first. Variation has to be planned around; HL2 went through a ton of tuning, and having multiple completion paths can throw testing and tuning time through the roof. Depending on the implementation!
If the player is running in fear (the player, mind, not the character), he's less likely to notice that he only had one real option. If it looks like he had several options, he might later go back and look, on his next playthrough. People don't like thinking they have unexplored options. There is a thing as too much choice. The trick is giving players real choices (because they are going to go back and check on you), but not to make them feel like they missed something. One trick for solving this dilemma is choosing when to give choice and when to take it away.
When you put cool stuff in the nooks and crannies, some players will want to check every single flippin cranny in the entire game. For games like Doom and Quake, that works. For a narrative-heavy game like Half-Life, I think it's a detriment.
Build up a pattern language. Advertise the big stuff, so that the player is focused on an objective that you have control over. If you want to hide something, show it to the player first. That is, show them the object, but hide the path to it. Give them time to explore nooks and crannies when they're not under pressure. When the heat is on, make the path clear. Players love thinking that they're smart, so make it obvious what they should be doing. The fact that they have choice is enough. It's a bit like the Forer effect; in this case, show a player two choices, where one is obviously better, and he'll choose the better one and feel happy about it.
I think this is a good thing. It's a survival trait. Show someone a snake-filled pit and a banana on table, and he'll go for the banana and be happy that he avoided the snake. The 'danger' is almost illusory! But almost. It is real danger. People look for patterns. When there's a blank in the puzzle, their active imaginations will fill it in. Players like using their imagination. Give them a chance to.
Boring Combat
I've been thinking about open worlds, still. The 'great' Ultimas (4-7) let you go anywhere in the outerworld right from the start. Only the dungeons were restrictive. I loved the exploration aspect of the game, and I remember (back when I was a kid and probably before I knew better) not hating the combat.
Yet it's strange to me that so many people played without companions, skipping through combat. If combat wasn't fun, then wouldn't the games have been better without it at all? In the earliest Ultimas, combat was really lame, and unpleasantly unbalanced. Food was also a major distraction. Why have these mechanics at all?
Ultima would have been an adventure series without combat. Without combat, there's no reason to level your character up. And, regardless, getting some of the best weapons reduced combat to an easy win -- which was generally considered a good thing, so that the players could just skip it that much more quickly.
That sounds very broken to me. Is tactical combat fun? X-Com was critically well-received. WoW has engaging combat. Diablo sold cubic assloads of copies. Combat can be fun, right? Hmm.
Usually the first few combat encounters are a chance to get used to the combat system; to figure out what's what, how you attack, where your hitpoint meter is, stuff like that. Then, hopefully, it starts getting more intricate. I think what happened with Ultima is that it never got more intricate. You could cast more spells, but the basics of combat were the same, and almost ... robotic. Attack, move into the right spot to attack, attack again. The end.
WoW is addictive more because of item rewards than because of its combat. Combat in Diablo wasn't challenging or deep but it wasn't boring. Toon Town combat was fun in its goofy, co-op way. Tank-healer-mage is a powerful design combo because it adds a lot of depth to combat (that isn't there in the Ultimas). WoW combat is often forgettably easy, but it could also be very challenging: hamstring this guy cuz he likes to run when he's low on health, burst through the last 20% of this other guy's health because he enrages, get ready to interrupt this other guy's healing spell or else the fight takes twice as long. These are simple mechanics and simple choices, but they're much more complex than "should I use the wimpy sling or the magic bow?", or even the non-choice of "should I step left so that I can attack that guy, or should I stay here and do nothing?"
The failure is obvious, but I'm not sure the solution is easy. Diablo and WoW both have very, very long level grinds. I don't think the random-drop-magic-item mechanic fits well in a 15-hour game. The lesson is that there needs to be more than two options in combat (Move and Default attack). I'm not sure how to do that tho. I don't really want to go with the JRPG solution. There's some richness in Ultima with the variety of spells but ... it feels like standard melee combat is just broken.
Yet it's strange to me that so many people played without companions, skipping through combat. If combat wasn't fun, then wouldn't the games have been better without it at all? In the earliest Ultimas, combat was really lame, and unpleasantly unbalanced. Food was also a major distraction. Why have these mechanics at all?
Ultima would have been an adventure series without combat. Without combat, there's no reason to level your character up. And, regardless, getting some of the best weapons reduced combat to an easy win -- which was generally considered a good thing, so that the players could just skip it that much more quickly.
That sounds very broken to me. Is tactical combat fun? X-Com was critically well-received. WoW has engaging combat. Diablo sold cubic assloads of copies. Combat can be fun, right? Hmm.
Usually the first few combat encounters are a chance to get used to the combat system; to figure out what's what, how you attack, where your hitpoint meter is, stuff like that. Then, hopefully, it starts getting more intricate. I think what happened with Ultima is that it never got more intricate. You could cast more spells, but the basics of combat were the same, and almost ... robotic. Attack, move into the right spot to attack, attack again. The end.
WoW is addictive more because of item rewards than because of its combat. Combat in Diablo wasn't challenging or deep but it wasn't boring. Toon Town combat was fun in its goofy, co-op way. Tank-healer-mage is a powerful design combo because it adds a lot of depth to combat (that isn't there in the Ultimas). WoW combat is often forgettably easy, but it could also be very challenging: hamstring this guy cuz he likes to run when he's low on health, burst through the last 20% of this other guy's health because he enrages, get ready to interrupt this other guy's healing spell or else the fight takes twice as long. These are simple mechanics and simple choices, but they're much more complex than "should I use the wimpy sling or the magic bow?", or even the non-choice of "should I step left so that I can attack that guy, or should I stay here and do nothing?"
The failure is obvious, but I'm not sure the solution is easy. Diablo and WoW both have very, very long level grinds. I don't think the random-drop-magic-item mechanic fits well in a 15-hour game. The lesson is that there needs to be more than two options in combat (Move and Default attack). I'm not sure how to do that tho. I don't really want to go with the JRPG solution. There's some richness in Ultima with the variety of spells but ... it feels like standard melee combat is just broken.
Monday, May 26, 2008
Skill-based vs Level-based
I presume you, the reader, are somewhat familiar with this discussion.
To me, the basic problem with skill-based systems is that they require you to do boring stuff to get a skill that you consider useful. Want to learn lockpicking? Hunt around for hours finding locks. Ugh! Also, while hunting for locks, don't accidentally find yourself in combat, because then you might swing your sword or block with your shield, thereby gaining levels in them, nerfing your ability to learn lockpicking.
Levelling up, instead, says "thou hast gained a level! Dost they wish to get better at what you've been doing, or is there a skill you didn't use but would dearly love to be better at?"
I think my bias is clear.
Skill-based systems seem to be driven by a desire to be realistic, which is totally not in keeping with fantasy games. "Realistic" means slippery slope. An injury to your arm hurts your sword-swinging skills, leading to more wounds, and then (like the black knight) you're just a stump on the ground taunting your attacker. Slippery slopes are not fun. You can stick your realism where the sun don't shine.
Hit points are an approximation. A gloss. As are levels. As is combat. As is the fact that your character never needs a latrine, nor needs to sleep, and the fact that days go by in an hour or less, and that magic works... Immersion > Realism. Immersion makes players happy.
Anyone who's ever worked any time of service or retail knows that customers are idiots. And yet, we are all customers often. The problem is generally one of communication, expectation, and repetition. Although any given customer might only rarely have expectations mismatched with reality, the fact that the service employee encounters hundreds of customers means that he frequently sees that mismatch.
My point is that players are like customers. If you ask them what they like about a game, they might mention the realism -- which made them feel like the game world was real. Which is actually immersion. It's sad when a designer can't figure this out. What are we paying you for again?
You can't get emotion from a player without suspension of disbelief. If your game is too complex, the player doesn't figure it out, says wtf, and spends time thinking about game mechanics rather than enjoying the fantasy of being his character. And it's not strictly complexity that does this, but how much complexity you throw at the player at once.
Which is one reason why platformers like to gradually introduce the player to mechanics. Having the player do something complex is easy if you train him up to it. It's like learning to speak a foreign language, drive a car, play WoW, or use a programming API. Learn a little bit, internalize it until it becomes second nature, then add another layer on top. These topics can seem daunting at first, but everyone still learns to do them.
Take Dwarf Fortress. It's scary. You get thrown into the deep end of that particular pool. Once you learn your way around, the complexity turns into richness and becomes very engrossing. I think a lot of players will be turned off by its steep learning curve, which kills any player's sense of immersion.
--
ok, sidetrack over. Topic: skill-based. My basic point is that a good skill-based system isn't one based upon practice, but open. No, it's not realistic. The player might say "that's unrealistic" and hate you, but I think that happens more when the game isn't fun. WoW is grossly unrealistic in a lot of ways, but players rarely complain about those aspects. (In part because they're bitching about how Locks are OP, instead.) Give the player a chance to do what he wants to do, and I expect he'll forgive heaps of minor sins.
The whole point of classes, to me, is to give players a clear role. "You are a mage. Act like one! Go shoot fireballs at orcs!" Some players thrive in this sort of restriction; the direction gives them purpose. It sets their expectations in a way that allows them to mentally frame the coming game experience. I think this is much more mass-market because it doesn't require that your player have played your sort of game many times before.
A skill-based system is more open, allowing a player to change his mind, or to mix-and-match skills a bit more loosely, creating a particular playing style that he particularly likes. One downside common to many skill-based systems is gimping: the player is "free" to choose crappy combinations of skills, or to put hard-earned skill points into those gimicky "flavor" skills your drunk designer threw in one weekend. And now that player can't kill any creatures or complete any quests because his character is underpowerd. Yay for you, you taught that player a lesson! The players that like that kind of stuff -- and there's some out there that really enjoy that kind of challenge -- won't keep bread on your table, much less meat, much less food for your wife and kids.
Whatever system you (or I) choose, the most important thing to do is to let the player know ahead of time what's coming up.
To me, the basic problem with skill-based systems is that they require you to do boring stuff to get a skill that you consider useful. Want to learn lockpicking? Hunt around for hours finding locks. Ugh! Also, while hunting for locks, don't accidentally find yourself in combat, because then you might swing your sword or block with your shield, thereby gaining levels in them, nerfing your ability to learn lockpicking.
Levelling up, instead, says "thou hast gained a level! Dost they wish to get better at what you've been doing, or is there a skill you didn't use but would dearly love to be better at?"
I think my bias is clear.
Skill-based systems seem to be driven by a desire to be realistic, which is totally not in keeping with fantasy games. "Realistic" means slippery slope. An injury to your arm hurts your sword-swinging skills, leading to more wounds, and then (like the black knight) you're just a stump on the ground taunting your attacker. Slippery slopes are not fun. You can stick your realism where the sun don't shine.
Hit points are an approximation. A gloss. As are levels. As is combat. As is the fact that your character never needs a latrine, nor needs to sleep, and the fact that days go by in an hour or less, and that magic works... Immersion > Realism. Immersion makes players happy.
Anyone who's ever worked any time of service or retail knows that customers are idiots. And yet, we are all customers often. The problem is generally one of communication, expectation, and repetition. Although any given customer might only rarely have expectations mismatched with reality, the fact that the service employee encounters hundreds of customers means that he frequently sees that mismatch.
My point is that players are like customers. If you ask them what they like about a game, they might mention the realism -- which made them feel like the game world was real. Which is actually immersion. It's sad when a designer can't figure this out. What are we paying you for again?
You can't get emotion from a player without suspension of disbelief. If your game is too complex, the player doesn't figure it out, says wtf, and spends time thinking about game mechanics rather than enjoying the fantasy of being his character. And it's not strictly complexity that does this, but how much complexity you throw at the player at once.
Which is one reason why platformers like to gradually introduce the player to mechanics. Having the player do something complex is easy if you train him up to it. It's like learning to speak a foreign language, drive a car, play WoW, or use a programming API. Learn a little bit, internalize it until it becomes second nature, then add another layer on top. These topics can seem daunting at first, but everyone still learns to do them.
Take Dwarf Fortress. It's scary. You get thrown into the deep end of that particular pool. Once you learn your way around, the complexity turns into richness and becomes very engrossing. I think a lot of players will be turned off by its steep learning curve, which kills any player's sense of immersion.
--
ok, sidetrack over. Topic: skill-based. My basic point is that a good skill-based system isn't one based upon practice, but open. No, it's not realistic. The player might say "that's unrealistic" and hate you, but I think that happens more when the game isn't fun. WoW is grossly unrealistic in a lot of ways, but players rarely complain about those aspects. (In part because they're bitching about how Locks are OP, instead.) Give the player a chance to do what he wants to do, and I expect he'll forgive heaps of minor sins.
The whole point of classes, to me, is to give players a clear role. "You are a mage. Act like one! Go shoot fireballs at orcs!" Some players thrive in this sort of restriction; the direction gives them purpose. It sets their expectations in a way that allows them to mentally frame the coming game experience. I think this is much more mass-market because it doesn't require that your player have played your sort of game many times before.
A skill-based system is more open, allowing a player to change his mind, or to mix-and-match skills a bit more loosely, creating a particular playing style that he particularly likes. One downside common to many skill-based systems is gimping: the player is "free" to choose crappy combinations of skills, or to put hard-earned skill points into those gimicky "flavor" skills your drunk designer threw in one weekend. And now that player can't kill any creatures or complete any quests because his character is underpowerd. Yay for you, you taught that player a lesson! The players that like that kind of stuff -- and there's some out there that really enjoy that kind of challenge -- won't keep bread on your table, much less meat, much less food for your wife and kids.
Whatever system you (or I) choose, the most important thing to do is to let the player know ahead of time what's coming up.
Sunday, May 25, 2008
Game Design
My inspiration for this RPG project is Ultima IV, so I've spent some time hunting around reading what others have said about the game.
Looking at all the Ultimas, what seems most striking to me is (1) world interactivity, (2) open-endedness, and (3) consequences.
[1] Most 3D games have woefully static worlds. Simple things, like moving chairs around a room, are cake in a tile-based 2D game but become nightmares in 3D, where the designers probably want a physics engine to handle it. The thing is, we (humans) have a lot of flexibility when interacting with objects, whereas in a game the UI usually limits us to uni-directional pressure. We have not just 'pushing' but variable pressure and torque.
But then there's simple things like turning candles on and off, flipping switches, or even lowering drawbridges. I think all of these things add greatly to immersion, and thereby to enjoyment and fun. They're what I want to do in a 2D environment.
[2] I have a harder-time accepting open-endedness. I think many people don't know why they enjoy something. Many times when I've asked people what they liked about a game, I get one memorable instance. Memorable is very different from fun. Memorable moments happen rarely, but fun games have dozens of hours that aren't very memorable. Good combat is intense and non-trivial, but ultimately good intensity means that it isn't memorable. If everything is memorable ... uh, I don't think that's possible. I think we would be overwhelmed with that much emotion. Memorable events are memorable because they're so exceptional!
I don't think making every waking moment exceptional is even really possible, for more than maybe an hour. The time to create content is dwarfed by the time to consume it. Nowadays, those $5M single-player console games are consumed in a couple dozen hours or less. That's something like a five-thousand-to-one ratio. Every hour of amusement takes five thousand hours for the creators to develop. Maybe I can improve that ratio a lot, but then I wind up entertaining a niche market only.
My point: I'm not sure how important open-endedness is. I think linearity, especially when it becomes grossly apparent, is frustrating. When the player wants to do X but is prevent to by the structures of the plot, that sucks. But is all linearity necessarily bad? It definitely makes it easier to make a single plot. Highly narrated games require that linearity.
Hmm, I guess my point is really: what is it about "open-endedness" that is attractive, if anything? I'm not going to believe it just because people say so -- in part because it's difficult to reach a decision on how much open-endedness to add if I don't understand why. I think this is a big enough issue that I'll write about it later.
[3] Consequences. A good linear game might convince the player that his choices were meaningful if the player was satisfied with his choices. If the player feels forced in his decisions, he'll be unhappy. But if his decision was effectively irrelevant but the player feels like he had a meaningful decision to make, then he'll be happy with those consequences.
But saying "consequences make the game fun" really means that it is possible, upon play-through, to change the way the game comes out. Does it matter what class you choose? All the way down to -- does it matter what spells you use in combat? It seems to me that early Ultimas suffered from pointless combat, because no matter what spells or weapons you had, all that really mattered was your net damage output. It seems that you have to almost cheat at these games -- using ships cannons, or grossly over-powered weapons, or invisibility rings, or letting party members die and adventuring solo thru the whole thing -- to make any meaningful difference in combat. In other words, no combat decisions were meaningful. Cast spell A or B? Who cares? Whichever one gets the combat over with faster.
Modern MMOs are combat games at their heart, which means players spend hundreds
of hours in combat. The combat system is intricate enough to make those hundreds of hours different. What spell you use in combat matters, at least in terms of whether you win a fight quickly or slowly. What's strange, to me, is the huge amount of variance in player skill -- some players suck at their classes, and ... god, it amazes me. I can't think that they don't want to get better, but... ! I think they get stuck on "total damage" and fail to realize things like damage-per-second and stuns are also useful.
Anyway. Consequence. Yeah. So, combat choices should be meaningful. Dungeons should give loot relative to their difficulty and/or time to completion.
I went to see some panel discussion in Austin once and I remember Garriot making the point that MMOs had lost the "fun". I want to say that a long, challenge-free dungeon (or trek) should have a reward matching the time investment, but I'm reminded of David Sirlin's comments about WoW rewarding time spent, which he considers the wrong thing to reward. I agree with his point. I think the answer, really, is that you shouldn't have a long, challenge-free dungeon. There's not really much point in making a really long, empty hallway in a single-player game. If the game needs to be longer, adding boring parts isn't really what you want to do.
Combat choices need to have consequences. Time spent in a dungeon or on a quest should have consequences. Game-wide choices, such as for character class, or whether you help the Empire or the Rebellion, should (at least appear to) have an impact on the game.
The thing is, again, content takes time to develop. Say, halfway thru a game, the player shifts a war to one side or the other. And the game is open-ended (cuz, well, we'll just take this on faith atm). So every character and environment in the game needs to be rendered one way or the other: either that city has been destroyed and is populated by dispirited survivors and the enemy oppressors, or it's still intact and populated by cheerful victors. The environment is different, the quests are different, heck, it's two different worlds.
So, ah, no. I also think making content that half of your playerbase won't see is a poor investment. (It adds some replayability though.) There's plusses and minuses here, but I don't want to let open-endedness spiral out of control.
I'm much happier giving characters different dialog. Different quests, fine. But I think art resources take a lot more time than design resources.
Looking at all the Ultimas, what seems most striking to me is (1) world interactivity, (2) open-endedness, and (3) consequences.
[1] Most 3D games have woefully static worlds. Simple things, like moving chairs around a room, are cake in a tile-based 2D game but become nightmares in 3D, where the designers probably want a physics engine to handle it. The thing is, we (humans) have a lot of flexibility when interacting with objects, whereas in a game the UI usually limits us to uni-directional pressure. We have not just 'pushing' but variable pressure and torque.
But then there's simple things like turning candles on and off, flipping switches, or even lowering drawbridges. I think all of these things add greatly to immersion, and thereby to enjoyment and fun. They're what I want to do in a 2D environment.
[2] I have a harder-time accepting open-endedness. I think many people don't know why they enjoy something. Many times when I've asked people what they liked about a game, I get one memorable instance. Memorable is very different from fun. Memorable moments happen rarely, but fun games have dozens of hours that aren't very memorable. Good combat is intense and non-trivial, but ultimately good intensity means that it isn't memorable. If everything is memorable ... uh, I don't think that's possible. I think we would be overwhelmed with that much emotion. Memorable events are memorable because they're so exceptional!
I don't think making every waking moment exceptional is even really possible, for more than maybe an hour. The time to create content is dwarfed by the time to consume it. Nowadays, those $5M single-player console games are consumed in a couple dozen hours or less. That's something like a five-thousand-to-one ratio. Every hour of amusement takes five thousand hours for the creators to develop. Maybe I can improve that ratio a lot, but then I wind up entertaining a niche market only.
My point: I'm not sure how important open-endedness is. I think linearity, especially when it becomes grossly apparent, is frustrating. When the player wants to do X but is prevent to by the structures of the plot, that sucks. But is all linearity necessarily bad? It definitely makes it easier to make a single plot. Highly narrated games require that linearity.
Hmm, I guess my point is really: what is it about "open-endedness" that is attractive, if anything? I'm not going to believe it just because people say so -- in part because it's difficult to reach a decision on how much open-endedness to add if I don't understand why. I think this is a big enough issue that I'll write about it later.
[3] Consequences. A good linear game might convince the player that his choices were meaningful if the player was satisfied with his choices. If the player feels forced in his decisions, he'll be unhappy. But if his decision was effectively irrelevant but the player feels like he had a meaningful decision to make, then he'll be happy with those consequences.
But saying "consequences make the game fun" really means that it is possible, upon play-through, to change the way the game comes out. Does it matter what class you choose? All the way down to -- does it matter what spells you use in combat? It seems to me that early Ultimas suffered from pointless combat, because no matter what spells or weapons you had, all that really mattered was your net damage output. It seems that you have to almost cheat at these games -- using ships cannons, or grossly over-powered weapons, or invisibility rings, or letting party members die and adventuring solo thru the whole thing -- to make any meaningful difference in combat. In other words, no combat decisions were meaningful. Cast spell A or B? Who cares? Whichever one gets the combat over with faster.
Modern MMOs are combat games at their heart, which means players spend hundreds
of hours in combat. The combat system is intricate enough to make those hundreds of hours different. What spell you use in combat matters, at least in terms of whether you win a fight quickly or slowly. What's strange, to me, is the huge amount of variance in player skill -- some players suck at their classes, and ... god, it amazes me. I can't think that they don't want to get better, but... ! I think they get stuck on "total damage" and fail to realize things like damage-per-second and stuns are also useful.
Anyway. Consequence. Yeah. So, combat choices should be meaningful. Dungeons should give loot relative to their difficulty and/or time to completion.
I went to see some panel discussion in Austin once and I remember Garriot making the point that MMOs had lost the "fun". I want to say that a long, challenge-free dungeon (or trek) should have a reward matching the time investment, but I'm reminded of David Sirlin's comments about WoW rewarding time spent, which he considers the wrong thing to reward. I agree with his point. I think the answer, really, is that you shouldn't have a long, challenge-free dungeon. There's not really much point in making a really long, empty hallway in a single-player game. If the game needs to be longer, adding boring parts isn't really what you want to do.
Combat choices need to have consequences. Time spent in a dungeon or on a quest should have consequences. Game-wide choices, such as for character class, or whether you help the Empire or the Rebellion, should (at least appear to) have an impact on the game.
The thing is, again, content takes time to develop. Say, halfway thru a game, the player shifts a war to one side or the other. And the game is open-ended (cuz, well, we'll just take this on faith atm). So every character and environment in the game needs to be rendered one way or the other: either that city has been destroyed and is populated by dispirited survivors and the enemy oppressors, or it's still intact and populated by cheerful victors. The environment is different, the quests are different, heck, it's two different worlds.
So, ah, no. I also think making content that half of your playerbase won't see is a poor investment. (It adds some replayability though.) There's plusses and minuses here, but I don't want to let open-endedness spiral out of control.
I'm much happier giving characters different dialog. Different quests, fine. But I think art resources take a lot more time than design resources.
Wednesday, May 21, 2008
In-Game Editors
I spent about four hours today working on my current project, code-named RPG4. (It started as a Ultima IV knockoff, hence, "the U4-like RPG project", aka RPG4.)
I think in-game editors are a bad idea. In the past, they've made my game code ugly. Objects that would otherwise be constant and have no modifiers suddenly become mutable. Usually it's easier/faster/cleaner to keep a list of objects in a container optimized for game code, but that container isn't good for editing. Editing and playing are two different worlds and trying to do both just consigns your code to not be well-suited to either one.
This is different than an engine that can be used in a custom-built editor. I'm fine with that, and encourage it (where making an exporter for 3DS or Maya isn't a better choice). An engine is a library, though, and most of your custom-created editors are going to be for gameplay data, not graphics.
An in-game editor mode is tempting. It helps out in development, cuz you can just change stuff using the editor commands. It doesn't require a separate package. This arrangement means there's no chance that the editor and game get out of sync. The resource pipeline in shorter, and hence simpler. But I don't think the savings are as great as they appear. If making an editor is easy, then there isn't much to "save" by bundling the editor into the game executable. In-game editors are more useful the uglier your code is, and if you've got crappy dev tools. If poking around in your code and seeing what's going on is tough, then yeah, an in-game editor can help you debug faster. What you really need is good debug tools, though. I hate Microsoft, but their tools are great. (Maybe I've just been hitting myself with a hammer for a couple years; my previous job was all text-mode *nix development for an embedded platform with minimalistic debugging tools.)
I used to build editors by hand, in part a legacy habit from building game-engine UIs, working with old frameworks, and, to some degree, the amount of manual construction necessary a decade ago. Tools have moved on, and now for us Win-centric developers, it's cake. Cake cake and cake. There's no reason to have an in-game editor. I think having a separate tool adds a lot to development.
With good tools, developing a separate data-file editor is easy. I've always felt that a strong description of your data format is a good thing; it defines gameplay, to some extent; what can be edited, what their ranges are, and what combinations are verboten. If you have one person working on the editor and another working on the game code, and they have a well-specified data format to share, then they're both less likely to err. They can refer to the documentation and learn about the format at their own pace, without interrupting another developer with noob questions. If your data format is in a shared place (Wiki > code repository for this), then a new-hire junior guy can jump right in and start working on his own. And when he finds out that the documentation sucks, he can fix the documentation. Right then, right there. Plus, he doesn't need to know how both the engine and the editor work, so he can't bork the code in a way that cripples either game performance or editor features. And then you can give the documentation to the designers! But that's a different rant.
I love WinForms. I spent about three hours today putting together a tileset editor. All it's good for is moving tiles from one .bmp/.png/.jpg to another, but it should save me some time -- I plan on mostly using public-domain images for this title. It's great to be able to go into the designer and mock up an interface really quickly. Better yet, that mockup is your interface. It's not MVC, but I've seen MVC debated. MVC is not my holy grail. Working, maintainable code > appeasing the design gods.
I figured it'd be cool to add a checkbox to control whether or not the source icon auto-advanced after every Grab operation. So I threw a checkbox in the form. I didn't have to connect it to anything; no magic CASE connector ribbons to stream around. Edit the label, give the checkbox a useful name, and blammo. It's in there. Rather than figuring out where to put some bool so that both the UI and the code can get at it, the code already has access to the checkbox, so it can just query state.
That was for a control that determines editor behavior, though, and isn't saved in the data format. Having controls that go both ways (ie populate from the data store, and then save their values back into that data store) can be done with data binding, but I'm not a data binding guru yet. Maybe next week.
And even further I'm learning a useful job skill. I use data binding, a bit of WinForms, and a ton of C# in my day job. My hobby and my day job are feeding off each other, and that's cool.
I'm still a WinForms noob, though. I've got a decent book that I'm reading through, but the first few chapters are even more noobish than me and that's slowed my progress cuz I know it all already. :) I haven't yet read through the meaty middle chapters. Having Intellisense (when it doesn't fall into a fey mood) plus online help makes it easy to just do what I want to do and not mess with other features. I rilly rilly need to build some custom controls. My main editor has seven tabs, and right now all of the handling functions for every sub-editor is there in the main form code. Holy Blobs, Batman.
I know it's easy to fix. Heck, I could probably find out how to get custom controls working in design-time in less time than it took to write this sentence, but ... well I guess things aren't so bad yet. I'm learning, I'm getting stuff done, and I know I'll get to those chapters in a few days, so I'd rather read through everything than skip around. I have a feeling if I got custom controls working fine, I'd drop the WinForms book and run straight to...
XNA
... which is what the game engine will be built in. I'm looking forward to that, too. My last few engines have been OpenGL, but I've been ignoring the games industry for a couple years while working a day job. Vista sucks, still, and so I haven't dabbled with DX10, and I was playing with DX9 back then, so it seems mostly that graphics cards haven't passed me by. Cool graphics features await in the pristine Vista future (*cough*), I know, but I'm not shooting for triple-A titles right off the bat. As I said in a previous blog, my goal is to GET IT DONE. Finish the game; ship it.
I think in-game editors are a bad idea. In the past, they've made my game code ugly. Objects that would otherwise be constant and have no modifiers suddenly become mutable. Usually it's easier/faster/cleaner to keep a list of objects in a container optimized for game code, but that container isn't good for editing. Editing and playing are two different worlds and trying to do both just consigns your code to not be well-suited to either one.
This is different than an engine that can be used in a custom-built editor. I'm fine with that, and encourage it (where making an exporter for 3DS or Maya isn't a better choice). An engine is a library, though, and most of your custom-created editors are going to be for gameplay data, not graphics.
An in-game editor mode is tempting. It helps out in development, cuz you can just change stuff using the editor commands. It doesn't require a separate package. This arrangement means there's no chance that the editor and game get out of sync. The resource pipeline in shorter, and hence simpler. But I don't think the savings are as great as they appear. If making an editor is easy, then there isn't much to "save" by bundling the editor into the game executable. In-game editors are more useful the uglier your code is, and if you've got crappy dev tools. If poking around in your code and seeing what's going on is tough, then yeah, an in-game editor can help you debug faster. What you really need is good debug tools, though. I hate Microsoft, but their tools are great. (Maybe I've just been hitting myself with a hammer for a couple years; my previous job was all text-mode *nix development for an embedded platform with minimalistic debugging tools.)
I used to build editors by hand, in part a legacy habit from building game-engine UIs, working with old frameworks, and, to some degree, the amount of manual construction necessary a decade ago. Tools have moved on, and now for us Win-centric developers, it's cake. Cake cake and cake. There's no reason to have an in-game editor. I think having a separate tool adds a lot to development.
With good tools, developing a separate data-file editor is easy. I've always felt that a strong description of your data format is a good thing; it defines gameplay, to some extent; what can be edited, what their ranges are, and what combinations are verboten. If you have one person working on the editor and another working on the game code, and they have a well-specified data format to share, then they're both less likely to err. They can refer to the documentation and learn about the format at their own pace, without interrupting another developer with noob questions. If your data format is in a shared place (Wiki > code repository for this), then a new-hire junior guy can jump right in and start working on his own. And when he finds out that the documentation sucks, he can fix the documentation. Right then, right there. Plus, he doesn't need to know how both the engine and the editor work, so he can't bork the code in a way that cripples either game performance or editor features. And then you can give the documentation to the designers! But that's a different rant.
I love WinForms. I spent about three hours today putting together a tileset editor. All it's good for is moving tiles from one .bmp/.png/.jpg to another, but it should save me some time -- I plan on mostly using public-domain images for this title. It's great to be able to go into the designer and mock up an interface really quickly. Better yet, that mockup is your interface. It's not MVC, but I've seen MVC debated. MVC is not my holy grail. Working, maintainable code > appeasing the design gods.
I figured it'd be cool to add a checkbox to control whether or not the source icon auto-advanced after every Grab operation. So I threw a checkbox in the form. I didn't have to connect it to anything; no magic CASE connector ribbons to stream around. Edit the label, give the checkbox a useful name, and blammo. It's in there. Rather than figuring out where to put some bool so that both the UI and the code can get at it, the code already has access to the checkbox, so it can just query state.
That was for a control that determines editor behavior, though, and isn't saved in the data format. Having controls that go both ways (ie populate from the data store, and then save their values back into that data store) can be done with data binding, but I'm not a data binding guru yet. Maybe next week.
And even further I'm learning a useful job skill. I use data binding, a bit of WinForms, and a ton of C# in my day job. My hobby and my day job are feeding off each other, and that's cool.
I'm still a WinForms noob, though. I've got a decent book that I'm reading through, but the first few chapters are even more noobish than me and that's slowed my progress cuz I know it all already. :) I haven't yet read through the meaty middle chapters. Having Intellisense (when it doesn't fall into a fey mood) plus online help makes it easy to just do what I want to do and not mess with other features. I rilly rilly need to build some custom controls. My main editor has seven tabs, and right now all of the handling functions for every sub-editor is there in the main form code. Holy Blobs, Batman.
I know it's easy to fix. Heck, I could probably find out how to get custom controls working in design-time in less time than it took to write this sentence, but ... well I guess things aren't so bad yet. I'm learning, I'm getting stuff done, and I know I'll get to those chapters in a few days, so I'd rather read through everything than skip around. I have a feeling if I got custom controls working fine, I'd drop the WinForms book and run straight to...
XNA
... which is what the game engine will be built in. I'm looking forward to that, too. My last few engines have been OpenGL, but I've been ignoring the games industry for a couple years while working a day job. Vista sucks, still, and so I haven't dabbled with DX10, and I was playing with DX9 back then, so it seems mostly that graphics cards haven't passed me by. Cool graphics features await in the pristine Vista future (*cough*), I know, but I'm not shooting for triple-A titles right off the bat. As I said in a previous blog, my goal is to GET IT DONE. Finish the game; ship it.
Tuesday, May 20, 2008
Grinding
Grinding sucks. Why do games have grinding?
Because without it, players would zoom through content. Something has to slow them down! Grinding is one way of doing it. Want that sword of +10 uber? Go kill mobs until you get enough faction with the right people and they'll sell it to you.
If a player could finish the final bossfight with a new, level 1 character -- then what's the point of the intervening content, even if it is fun?
There's a lot of places in WoW where the fun way to get faction requires being in the right guild and clearing the right instance. If you're not in that guild, then you're stuck with the slow way, which is boring. At this point you have two options: give up on your goal, or grind. This is obviously why some of the slow, boring ways don't give rep after a certain point -- the designers want you to go do something else. The designers know their solution sucks, and they're hoping you try some of the other stuff and have more fun along the way.
Now the problem has turned into a group-size constraint. Some content is hidden behind having 24 friends, a competent leader, and a schedule that allows all of you to be online for the same two or three contiguous hours. What if that's not your style?
What if the optimal grind path -- one that asks you to spend no more than an hour a day -- isn't fast enough for you? The presence of a repeatable quest that you can do for the other 23 hours of a day means that some players will feel compelled to do that unfun grinding.
Making everything fun doesn't always work. What's fun in one guise can become unfun in another; removing that mechanic altogether gets rid of some fun. Choosing only perfect fun mechanics isn't really possible in any large game. Lowbies often enjoy their lowbie quests to kill ten wimpy skeletons, but then they're done. They could continue to kill skeletons until they become grey, but they have better options. And yet the game still presents the player with that unfun advancement option; luckily, it's not an efficient or optimal one.
Here's the heart of grinding: when the most efficient path of advancement is doing something repetitive or boring. This phrasing suggests its own solution: provide a more efficient path that is fun. The trick, of course, is content.
MMOs provide thousands of hours of gameplay; the standard console game, ten to twenty. Can you imagine making the content equivalent of a hundred console games? That's a pretty huge budget. Something's gotta repeat.
I think there's two answers: (1) your game should be short enough that there's no boring stretches, and (2) procedural content generation. (Multiplayer often fills in for that second solution.)
Because without it, players would zoom through content. Something has to slow them down! Grinding is one way of doing it. Want that sword of +10 uber? Go kill mobs until you get enough faction with the right people and they'll sell it to you.
If a player could finish the final bossfight with a new, level 1 character -- then what's the point of the intervening content, even if it is fun?
There's a lot of places in WoW where the fun way to get faction requires being in the right guild and clearing the right instance. If you're not in that guild, then you're stuck with the slow way, which is boring. At this point you have two options: give up on your goal, or grind. This is obviously why some of the slow, boring ways don't give rep after a certain point -- the designers want you to go do something else. The designers know their solution sucks, and they're hoping you try some of the other stuff and have more fun along the way.
Now the problem has turned into a group-size constraint. Some content is hidden behind having 24 friends, a competent leader, and a schedule that allows all of you to be online for the same two or three contiguous hours. What if that's not your style?
What if the optimal grind path -- one that asks you to spend no more than an hour a day -- isn't fast enough for you? The presence of a repeatable quest that you can do for the other 23 hours of a day means that some players will feel compelled to do that unfun grinding.
Making everything fun doesn't always work. What's fun in one guise can become unfun in another; removing that mechanic altogether gets rid of some fun. Choosing only perfect fun mechanics isn't really possible in any large game. Lowbies often enjoy their lowbie quests to kill ten wimpy skeletons, but then they're done. They could continue to kill skeletons until they become grey, but they have better options. And yet the game still presents the player with that unfun advancement option; luckily, it's not an efficient or optimal one.
Here's the heart of grinding: when the most efficient path of advancement is doing something repetitive or boring. This phrasing suggests its own solution: provide a more efficient path that is fun. The trick, of course, is content.
MMOs provide thousands of hours of gameplay; the standard console game, ten to twenty. Can you imagine making the content equivalent of a hundred console games? That's a pretty huge budget. Something's gotta repeat.
I think there's two answers: (1) your game should be short enough that there's no boring stretches, and (2) procedural content generation. (Multiplayer often fills in for that second solution.)
Monday, May 19, 2008
Focus
What's the purpose of my current game development project? Do I have a clear focus, or is it more like the focus of a lightbulb? What's my feature list -- don't I want every feature imaginable?
I recently started work on a long-standing RPG side project. While working on it, I've done "research" into other indie RPGs, and played some roguelikes.
Roguelikes are great indie game developer fodder. The devs can release a new version whenever they want without worrying about people currently in the middle of a play-through. The major branches (NetHack, Rogue, Moria, Angband) and the vast majority of their derivatives (excepting the elephantine Diablo) are open source, so the dev can see what everyone else is doing. And the standard UI--a text-based console display--is trivially simple to code for.
One consequence is that any roguelike can borrow code from any other roguelike. (Mostly.)
So let's say you're developing a tile-based RPG with a simple UI and simple combat, but not random levels or permadeath. Or let's say that I'm developing one. What features do I include?
In the major roguelike branches, development is never finished. There's always new creatures, new weapons, new dungeon generation algorithms, new player races and classes, new skills, and on and on. But that's not me. My goal is to finish a game and push it out the door. My game has a story, which would kill a roguelike. Imagine playing through Tetris and having to listen to the unfolding of some complicated plot. After a few games, the early bits of the story would get horribly boring. After a few days, you'll want to turn it off. After a few weeks, you'll stop playing the game because that story (no matter how well-written) has become impossibly repetitive.
But story isn't the only reason to reign in features. I want to release the game and have it be done; I don't want to endlessly add new features to it. Bugfixes are fine, but new features go into the sequel. My goal with this project is more to release a finished RPG than almost anything else. I've never finished this "project", though it has changed forms and been restarted so many times that it no longer resembles the idea I had back in high school.
Do roguelikes require focus? I don't think it's necessary. They're a very different product. Does a word processor need focus? Not really; Office has grown so gargantuan that it does everything now. You can imbed spreadsheets, graphs, images, links, columns, whatever... It doesn't have a fixed feature set. Like an arcade game, it's used in small sessions, almost constantly. I've read of many novellists who use some arcane word processing machine or application on a historic old PC because they like it and they're used to it, but for the rest of us -- we can install the latest Word and get right to a new session. No focus here; who cares? There's no single feature that's a unique selling point for the product.
Focus isn't just a feature for small products. World of Warcraft has a focus (i.e. combat), and that's a huge game. Most console games have a very clear ending that serves as the focus for the player. I think the best games have a focus that helps them provide an entertaining experience without taking forever to develop. To me, the worst games¹ are those that try to do too many things. Sometimes that means trying to do just two things, like being both an RTS and an FPS, but doing neither well.
Focus is what lets me push off some cool feature til the sequel. Its what keeps me from spending another day searching the web for cool background graphics. Its what tells me to stop when I try adding more features to the combat system.
--
1: actually the games I hate the most are those where I can't express myself because of some dodgy UI design, whether it's sloshy controls or control lag or a useless camera. I don't care how awesome your mechanics are, if the controls frustrate me I'm just gonna throw the disc away.
Related reading:
Andrew Doull's post on the Game Development Arms Race
I recently started work on a long-standing RPG side project. While working on it, I've done "research" into other indie RPGs, and played some roguelikes.
Roguelikes are great indie game developer fodder. The devs can release a new version whenever they want without worrying about people currently in the middle of a play-through. The major branches (NetHack, Rogue, Moria, Angband) and the vast majority of their derivatives (excepting the elephantine Diablo) are open source, so the dev can see what everyone else is doing. And the standard UI--a text-based console display--is trivially simple to code for.
One consequence is that any roguelike can borrow code from any other roguelike. (Mostly.)
So let's say you're developing a tile-based RPG with a simple UI and simple combat, but not random levels or permadeath. Or let's say that I'm developing one. What features do I include?
In the major roguelike branches, development is never finished. There's always new creatures, new weapons, new dungeon generation algorithms, new player races and classes, new skills, and on and on. But that's not me. My goal is to finish a game and push it out the door. My game has a story, which would kill a roguelike. Imagine playing through Tetris and having to listen to the unfolding of some complicated plot. After a few games, the early bits of the story would get horribly boring. After a few days, you'll want to turn it off. After a few weeks, you'll stop playing the game because that story (no matter how well-written) has become impossibly repetitive.
But story isn't the only reason to reign in features. I want to release the game and have it be done; I don't want to endlessly add new features to it. Bugfixes are fine, but new features go into the sequel. My goal with this project is more to release a finished RPG than almost anything else. I've never finished this "project", though it has changed forms and been restarted so many times that it no longer resembles the idea I had back in high school.
Do roguelikes require focus? I don't think it's necessary. They're a very different product. Does a word processor need focus? Not really; Office has grown so gargantuan that it does everything now. You can imbed spreadsheets, graphs, images, links, columns, whatever... It doesn't have a fixed feature set. Like an arcade game, it's used in small sessions, almost constantly. I've read of many novellists who use some arcane word processing machine or application on a historic old PC because they like it and they're used to it, but for the rest of us -- we can install the latest Word and get right to a new session. No focus here; who cares? There's no single feature that's a unique selling point for the product.
Focus isn't just a feature for small products. World of Warcraft has a focus (i.e. combat), and that's a huge game. Most console games have a very clear ending that serves as the focus for the player. I think the best games have a focus that helps them provide an entertaining experience without taking forever to develop. To me, the worst games¹ are those that try to do too many things. Sometimes that means trying to do just two things, like being both an RTS and an FPS, but doing neither well.
Focus is what lets me push off some cool feature til the sequel. Its what keeps me from spending another day searching the web for cool background graphics. Its what tells me to stop when I try adding more features to the combat system.
--
1: actually the games I hate the most are those where I can't express myself because of some dodgy UI design, whether it's sloshy controls or control lag or a useless camera. I don't care how awesome your mechanics are, if the controls frustrate me I'm just gonna throw the disc away.
Related reading:
Andrew Doull's post on the Game Development Arms Race
Subscribe to:
Posts (Atom)