My Travian game is coming to a close, ie nearing its one-year mark. I've been poking around at other browser games to assess the competition, thinking about switching, and it reminded me of one of the lessons of game design that I picked up long ago.
I remember playing Warcraft 2 and thinking, "you know, this game would be even better if it had even more upgrades and building types and everything."
A few years later, while playing Kohan, I realized that I was very wrong. WC2 was so awesome because it wasn't any more complex. Kohan (another real-time strategy game) had a different, but relatively straightforward, combat model. It didn't add more building types, or more troop types, or more upgrades -- it just configured armies differently than WC2.
Complexity is great for World of Warcraft because people play that game for thousands of hours. Yet at the lower levels, the game starts out very simple. Starcraft, currently enjoying years of professional play in Korea, isn't any more complicated than Warcraft 2. Chess is much simpler than both.
What makes a game fun is the interplay of choices. With a ton of choices, sometimes randomness sets in and dominates play. "Is unit A better than unit Z732? What about Z731, or Q986? Gah there's so many, forget it! Just build unit A!?" It's difficult to figure out a good strategy (or to be happy with the strategy you chose) when combinations start spiraling up.
Warcraft 2 and Kohan and Starcraft all found a balance with a small number of troops and buildings. Even then, they gradually added all their options in over the course of the game. They don't throw new players into the deep end (the full game); they work up to it over 30 hours or more.
It's like getting decent at chess and thinking, "ok, now that I've learned how all these pieces move, what I need now is more pieces! A larger board!" What makes chess interesting isn't those new pieces; instead, the game changes. The focus shifts to strategy and positional play, thinking ahead and mind games, learning the books and the endgames.
Part of Travian's appeal is its simplicity. If the game got too much more complex -- twice the number of buildings, more complex combat, etc -- then it would be a much harder game to get into. Part of its appeal is its chess-like simplicity. Even in that simplicity there is a lot of interplay, since so much of the game works on an exponential curve.
Good designs are simple designs. Let the fun be in the interplay of a handful of archetypes, not in the mindless proliferation of abilities and powers and resources and buildings and technologies...
Thursday, April 30, 2009
Monday, April 27, 2009
Tips on Hiring Agile Programmers
We're looking to hire another couple programmers here, and while I was talking about it with the coding crew, we had some thoughts, there was a rant or two, so now I'm here.
First, What is Agile Programming?
It's not a buzzword. Agile programming is a methodology, which is just a $10 way of saying it's a set of methods. What brings those methods together is that it makes programmers and the code they write more agile. As in flexible. Bendable. Responsive, dextrous, nimble. Agile programmers should be able to adapt the code they write to changing requirements. That's really the whole point. There's a subthread in discussions about "what is agile?" that basically says you won't understand a problem until you try to solve it, and so changing requirements are a natural outcome of exploring the solution domain until you understand it -- but that's not really my point here. We can argue that later.
Using interfaces and patterns is nice, but that's not agile programming. Interfaces and objects are just a part of object-oriented programming, and patterns appear in any programming language (although most well-known patterns are OO patterns).
One part of being agile is avoiding tight coupling. If there's a one-to-one relationship between two class hierarchies, then any time you add a class to one branch, to have to make a similar change to the other branch. This ties those two trees together; they're now tightly bound. One agile approach would be to use smaller bits, like methods (or delegates, in C#) instead. Or to embed the behavior of the second class in the first. Or to get rid of whatever it is that requires you to have two trees with all of the same class types in them.
Being agile means being responsive to change. Writing all your code through interfaces is nice in theory, but whenever you need a client to pull more information out of a subclass of that interface, you're stuck with a problem -- throw in a using clause, or what? Is the interface providing something specific? If there's a 1:1 mapping between interfaces and implementations, ie one interface class for every implementation class, then you haven't done jack. There's already a way to hide implementation from a client, and it's the fucking private keyword, you moron. If the client is going to break through the interface anyway, then get rid of it, it's not actually hiding anything. You should only write code once; there should only be one class exposed to your client. (A 'using' clause etc winds up exposing two classes.) This is the principle of Once And Only Once. If you've got an interface, there better be a reason for it other than "my teacher told me to." If you're doing something and you don't know why, then you better need to do it to get something to work. If you can skip a step that someone told you was required, and your code works just fine without that step, then you've got smaller, more nimble code. That is what Agile means. (And that your guru is full of it.)
Which gets me to the rant: some programmers do things just because they're supposed to. Like adding interfaces for everything, even if there's no hierarchy there. Or using patterns everywhere. I write patterns all the time, but I don't obsess over it. It just happens. If you have to scan through Gang of Four to figure out what pattern to use, then you're not yet a jedi. That's OK, but it's also not the best way to program. Understanding patterns is better than throwing patterns at a project. That's like throwing bailout money everywhere.
Likewise, you don't need a factory for every object. The constructor works just fine! Just call the constructor! I've seen this problem in programmers that have misunderstood the factory pattern. A builder is a class (or method) that assists with complex construction code; a factory is a class (or method) that can build one of several different objects, and returns them through a common base class (which might be an interface). Again, if a factory only builds one type of object, then why do you have the factory? If a class only has one constructor and construction is simple, then why do you have a builder? Both add to code bloat and complexity, and thereby inhibit the ability of future programmers to add new features or fix bugs. Or even understand what the hell you were doing. And here again is the benefit of agile programming: if your code is small and nimble, you can change it more easily.
Wait, I thought you were talking about hiring programmers?
Many academic programmers heed rules that they don't understand. You want the guys that have figured things out for themselves. There's a lot of clues here to figure out how to tell the first group from the second.
In general, the best way to hire programmers is to get them to do the job they're about to do. Give them a written test before the interview, or stand them in front of a whiteboard and ask them to pop out a design.
Not just a function; a design. The stuff that matters, for agile, is design -- not algorithms. (Algorithms are important, but ultimately agile isn't about algorithms. Test algorithm knowledge, sure, but that's not why you're reading this.) Good programmers have a sense not only of algorithms but also data structures. Good OO programmers can think in module-sized units (as well as class-sized units, method-sized units, or statement-sized units). Ask your candidates to express some designs. If you're interviewing a senior candidate, then he should understand framework-sized units. Ask him to sketch a framework for handling a large, complex data set and a wide variety of operations, probably something related to your personal problem domain. You don't really want a correct answer so much as strong thinking. (Don't judge a candidate by how closely they parrot your personal favorite design, or the one that your office has chosen. That's not what you're looking for here.)
For juniors, start with the simple stuff: persistance and streaming, three-tiered architecture stuff, de novo object creation, parsing. And ask them to get specific; where are the interfaces? What patterns do you use here?
And the money question: why?
The thing to look for is not their answer so much as how they answer. Is the candidate trying to think up a good reason for their answer, or are they just struggling to translate their understanding into words? The faster you can get a candidate to talk, the less rationalization goes on. It's ok if they're stumbling around their words or gesturing a lot with their hands, or just drawing circles on a white board and using too many pronouns -- this suggests that they're thinking of objects, not trying to reconstruct some quiz question a prof gave them once.
Object-oriented designs are inherently visual. They're visual creations. This is why whiteboards are a must in interviews, and why it's very difficult to assess a programmer over the phone.
Getting a candidate to explain what agile means is less important than hiring a candidate that inherently does agile things. And the way to test that is not to get him to talk, but to get him to do.
First, What is Agile Programming?
It's not a buzzword. Agile programming is a methodology, which is just a $10 way of saying it's a set of methods. What brings those methods together is that it makes programmers and the code they write more agile. As in flexible. Bendable. Responsive, dextrous, nimble. Agile programmers should be able to adapt the code they write to changing requirements. That's really the whole point. There's a subthread in discussions about "what is agile?" that basically says you won't understand a problem until you try to solve it, and so changing requirements are a natural outcome of exploring the solution domain until you understand it -- but that's not really my point here. We can argue that later.
Using interfaces and patterns is nice, but that's not agile programming. Interfaces and objects are just a part of object-oriented programming, and patterns appear in any programming language (although most well-known patterns are OO patterns).
One part of being agile is avoiding tight coupling. If there's a one-to-one relationship between two class hierarchies, then any time you add a class to one branch, to have to make a similar change to the other branch. This ties those two trees together; they're now tightly bound. One agile approach would be to use smaller bits, like methods (or delegates, in C#) instead. Or to embed the behavior of the second class in the first. Or to get rid of whatever it is that requires you to have two trees with all of the same class types in them.
Being agile means being responsive to change. Writing all your code through interfaces is nice in theory, but whenever you need a client to pull more information out of a subclass of that interface, you're stuck with a problem -- throw in a using clause, or what? Is the interface providing something specific? If there's a 1:1 mapping between interfaces and implementations, ie one interface class for every implementation class, then you haven't done jack. There's already a way to hide implementation from a client, and it's the fucking private keyword, you moron. If the client is going to break through the interface anyway, then get rid of it, it's not actually hiding anything. You should only write code once; there should only be one class exposed to your client. (A 'using' clause etc winds up exposing two classes.) This is the principle of Once And Only Once. If you've got an interface, there better be a reason for it other than "my teacher told me to." If you're doing something and you don't know why, then you better need to do it to get something to work. If you can skip a step that someone told you was required, and your code works just fine without that step, then you've got smaller, more nimble code. That is what Agile means. (And that your guru is full of it.)
Which gets me to the rant: some programmers do things just because they're supposed to. Like adding interfaces for everything, even if there's no hierarchy there. Or using patterns everywhere. I write patterns all the time, but I don't obsess over it. It just happens. If you have to scan through Gang of Four to figure out what pattern to use, then you're not yet a jedi. That's OK, but it's also not the best way to program. Understanding patterns is better than throwing patterns at a project. That's like throwing bailout money everywhere.
Likewise, you don't need a factory for every object. The constructor works just fine! Just call the constructor! I've seen this problem in programmers that have misunderstood the factory pattern. A builder is a class (or method) that assists with complex construction code; a factory is a class (or method) that can build one of several different objects, and returns them through a common base class (which might be an interface). Again, if a factory only builds one type of object, then why do you have the factory? If a class only has one constructor and construction is simple, then why do you have a builder? Both add to code bloat and complexity, and thereby inhibit the ability of future programmers to add new features or fix bugs. Or even understand what the hell you were doing. And here again is the benefit of agile programming: if your code is small and nimble, you can change it more easily.
Wait, I thought you were talking about hiring programmers?
Many academic programmers heed rules that they don't understand. You want the guys that have figured things out for themselves. There's a lot of clues here to figure out how to tell the first group from the second.
In general, the best way to hire programmers is to get them to do the job they're about to do. Give them a written test before the interview, or stand them in front of a whiteboard and ask them to pop out a design.
Not just a function; a design. The stuff that matters, for agile, is design -- not algorithms. (Algorithms are important, but ultimately agile isn't about algorithms. Test algorithm knowledge, sure, but that's not why you're reading this.) Good programmers have a sense not only of algorithms but also data structures. Good OO programmers can think in module-sized units (as well as class-sized units, method-sized units, or statement-sized units). Ask your candidates to express some designs. If you're interviewing a senior candidate, then he should understand framework-sized units. Ask him to sketch a framework for handling a large, complex data set and a wide variety of operations, probably something related to your personal problem domain. You don't really want a correct answer so much as strong thinking. (Don't judge a candidate by how closely they parrot your personal favorite design, or the one that your office has chosen. That's not what you're looking for here.)
For juniors, start with the simple stuff: persistance and streaming, three-tiered architecture stuff, de novo object creation, parsing. And ask them to get specific; where are the interfaces? What patterns do you use here?
And the money question: why?
The thing to look for is not their answer so much as how they answer. Is the candidate trying to think up a good reason for their answer, or are they just struggling to translate their understanding into words? The faster you can get a candidate to talk, the less rationalization goes on. It's ok if they're stumbling around their words or gesturing a lot with their hands, or just drawing circles on a white board and using too many pronouns -- this suggests that they're thinking of objects, not trying to reconstruct some quiz question a prof gave them once.
Object-oriented designs are inherently visual. They're visual creations. This is why whiteboards are a must in interviews, and why it's very difficult to assess a programmer over the phone.
Getting a candidate to explain what agile means is less important than hiring a candidate that inherently does agile things. And the way to test that is not to get him to talk, but to get him to do.
Friday, April 10, 2009
Noobs and Information
Many games have large noob populations, and they suck. Dealing with noobs is a pain. They don't know what they're doing, they don't know what to ask, and they're asking all the wrong people in the wrong places.
I think the same thing happens in many domains, not just in online games.
The problem is that the noobs have no information. Games with strong documentation and community features reduce their noob load; games where information is spread out among third-party sources and where game mechanics are not explained by the developer have much higher noob loads.
Warcraft has extensive online documentation, but they still have a high noob load. 'Preventing' noobs requires addressing the needs of the noobs, not the needs of the marketing department. Keeping players interested, getting them to come back, giving them something to look forward to -- these are all great. But it's not what noobs need.
Travian has crappy documentation. There's a lot of different info sites, but many of them are paltry. They focus on a few of the major concepts in the game, and although often broad and deep, are broad and deep in the wrong places.
Single-player games tend to not have noobs. Single-player games tend to require that they explain themselves to new players or else players just stop playing. I've played a number of 'innovative' single-player console and PC games that just didn't make sense. Although these games hint at depth and complexity and something fun, they hide it. And if I can't find it, the game gets returned and I don't recommend it. And I expect they get bad reviews, too.
What noobs need is direction. They need to know how the game scores them. They want to know the roles that they are expected to take. They want to know the consquences of their actions, before they take them. They want a place to go for this information, plus a forum lively enough where they can ask obscure questions.
Direction
Single-player games tend to have scores or mission directives that communicate to players what it is that they're trying to accomplish. Warcraft is fairly open, yet there are a few major goals: get to the level cap (80), accumulate gear, and work through the hardest dungeons. A more subtle point is the things that they should look out for along the way; some guidance on which goals are worthwhile. Many mid-level players worry about gear, spending hours and days getting just the right piece. Then they out-level it a few days later.
Travian takes pride in its opaqueness, supposedly because it gives players 'freedom' to choose their own path. Yet there are a few paths that are extremely useful to the over-arching goal of winning the game. Winning the game is something that's done by an alliance, not by a solo player, or one player that happens to be in an alliance with some friends. It requires the cooperation of dozens, if not hundreds, of players. There are a few strong roles that players can take, as well as some rules for how to be most effective. Yet the publishers don't do any of that; they leave it up to players to discover all of that on their own.
The discovery process can be fun, but there's two important concepts that limit where a game designer should put discovery: consequence (see below) and direction. If a player first has to figure out where he's going, then he's not discovering the game world, or developing strategy; he's figuring out what the user manual would look like, if the user manual had something more constructive than a simple list of all the units in the game and their cost.
Roles
Role is related to Direction. Whereas Direction shows the player what they have to do to win (what obstacles they have to overcome), Role is the set of tools that the player has available to do it.
A Priest in World of Warcraft knows about the spells that he can cast, but a good role is a bit more than "cast these three spells over and over." In a raid, a healer can stay focused on one target, heal several targets, look over a whole bunch of people and top them off -- or stick to some of the utility spells that they have.
Over a career levelling a priest, that player might go Holy (and heal in groups), Shadow (and focus on damage and mana generation), or Discipline (for... PvP?). Ignoring the accuracy of those descriptions, these are ways of telling new players: if you choose this class, you will have these roles that you fit into.
In Travian, roles could be as a Defender, Hammer, or Feeder; one might work solo or in a group. There's an infinite variety of combinations, obviously -- yet there are no general guidelines. Travian noobs wonder what they should be focused on. They try to do all things, without picking a role. They want to be offensive, but don't know how that plays out over a year. It's very frustrating to spend a lot of time on a game building a character (as in WoW) or a bunch of villages (as in Travian) to find out that you made fundamental mistakes early on, and that your current effectiveness is gimped because of it.
Giving new players guidance on the Role that they'll play can help players get started on the road to contributing during a game, rather than observing. Links to discussions will help them understand how other players feel about that role, letting new players find their sweet spot that much faster.
Score
Score defines direction. Score tells players how they win. It gives them feedback, and it's through feedback that players learn to play better. I don't like mashing buttons; winning for random reasons is not an achievement. Score tells me if I mashed the right buttons, so that I can see patterns in the game, start developing a strategy, start discovering the game world, meeting new people, and then killing them.
Open games sometimes have visible 'score' charts that measure inconsequential things. Statistics can be fun to browse; some people like that. I often do. But if you give everybody a useless metric (but one easy to manipulate), many will shoot to maximize that metric, even if it is a detriment to their play experience. If you put up a score-board but that score-board only applies to some players, or is completely irrelevant to the rest, you misdirect your players.
Travian shows village population for all the players. This is the major score rank in the game, since it's something that everyone has and it's relatively easy to see. Yet it, ultimately, isn't a strong measure of performance. But that's a problem with team games; how do you measure 'performance' when so much of the contribution one makes is building social networks, establishing trust, etc?
For vague, open games like travian, maybe the best way to communicate 'score' to players is to give them an overview of previous rounds. Show them the target, and how they measure progress, and then what last round's measuring stick looked like. They might choose a different metric, but at least with this kind of guidance they can make an informed assessment about how well they are proceeding.
Consquences
This was one big problem in many MMORPGs: players were 'free' to destroy their characters, spending hundreds of hours building a character that was sub-par. I remember putting points into Charisma in Dark Age of Camelot. As a Cleric. It did nothing for my character; they were wasted points. The 'freedom' to distribute points as I felt wasn't backed with enough information to make a good choice (unless I had been playing the game through to the end-game already, which didn't even exist when the game first shipped). Further, my choice was hard-locked; it could never be changed. This was a combination of asking players to make choices without sufficient information and then penalizing them, for the rest of their online career, for the wrong choices.
I think the same thing happens in many domains, not just in online games.
The problem is that the noobs have no information. Games with strong documentation and community features reduce their noob load; games where information is spread out among third-party sources and where game mechanics are not explained by the developer have much higher noob loads.
Warcraft has extensive online documentation, but they still have a high noob load. 'Preventing' noobs requires addressing the needs of the noobs, not the needs of the marketing department. Keeping players interested, getting them to come back, giving them something to look forward to -- these are all great. But it's not what noobs need.
Travian has crappy documentation. There's a lot of different info sites, but many of them are paltry. They focus on a few of the major concepts in the game, and although often broad and deep, are broad and deep in the wrong places.
Single-player games tend to not have noobs. Single-player games tend to require that they explain themselves to new players or else players just stop playing. I've played a number of 'innovative' single-player console and PC games that just didn't make sense. Although these games hint at depth and complexity and something fun, they hide it. And if I can't find it, the game gets returned and I don't recommend it. And I expect they get bad reviews, too.
What noobs need is direction. They need to know how the game scores them. They want to know the roles that they are expected to take. They want to know the consquences of their actions, before they take them. They want a place to go for this information, plus a forum lively enough where they can ask obscure questions.
Direction
Single-player games tend to have scores or mission directives that communicate to players what it is that they're trying to accomplish. Warcraft is fairly open, yet there are a few major goals: get to the level cap (80), accumulate gear, and work through the hardest dungeons. A more subtle point is the things that they should look out for along the way; some guidance on which goals are worthwhile. Many mid-level players worry about gear, spending hours and days getting just the right piece. Then they out-level it a few days later.
Travian takes pride in its opaqueness, supposedly because it gives players 'freedom' to choose their own path. Yet there are a few paths that are extremely useful to the over-arching goal of winning the game. Winning the game is something that's done by an alliance, not by a solo player, or one player that happens to be in an alliance with some friends. It requires the cooperation of dozens, if not hundreds, of players. There are a few strong roles that players can take, as well as some rules for how to be most effective. Yet the publishers don't do any of that; they leave it up to players to discover all of that on their own.
The discovery process can be fun, but there's two important concepts that limit where a game designer should put discovery: consequence (see below) and direction. If a player first has to figure out where he's going, then he's not discovering the game world, or developing strategy; he's figuring out what the user manual would look like, if the user manual had something more constructive than a simple list of all the units in the game and their cost.
Roles
Role is related to Direction. Whereas Direction shows the player what they have to do to win (what obstacles they have to overcome), Role is the set of tools that the player has available to do it.
A Priest in World of Warcraft knows about the spells that he can cast, but a good role is a bit more than "cast these three spells over and over." In a raid, a healer can stay focused on one target, heal several targets, look over a whole bunch of people and top them off -- or stick to some of the utility spells that they have.
Over a career levelling a priest, that player might go Holy (and heal in groups), Shadow (and focus on damage and mana generation), or Discipline (for... PvP?). Ignoring the accuracy of those descriptions, these are ways of telling new players: if you choose this class, you will have these roles that you fit into.
In Travian, roles could be as a Defender, Hammer, or Feeder; one might work solo or in a group. There's an infinite variety of combinations, obviously -- yet there are no general guidelines. Travian noobs wonder what they should be focused on. They try to do all things, without picking a role. They want to be offensive, but don't know how that plays out over a year. It's very frustrating to spend a lot of time on a game building a character (as in WoW) or a bunch of villages (as in Travian) to find out that you made fundamental mistakes early on, and that your current effectiveness is gimped because of it.
Giving new players guidance on the Role that they'll play can help players get started on the road to contributing during a game, rather than observing. Links to discussions will help them understand how other players feel about that role, letting new players find their sweet spot that much faster.
Score
Score defines direction. Score tells players how they win. It gives them feedback, and it's through feedback that players learn to play better. I don't like mashing buttons; winning for random reasons is not an achievement. Score tells me if I mashed the right buttons, so that I can see patterns in the game, start developing a strategy, start discovering the game world, meeting new people, and then killing them.
Open games sometimes have visible 'score' charts that measure inconsequential things. Statistics can be fun to browse; some people like that. I often do. But if you give everybody a useless metric (but one easy to manipulate), many will shoot to maximize that metric, even if it is a detriment to their play experience. If you put up a score-board but that score-board only applies to some players, or is completely irrelevant to the rest, you misdirect your players.
Travian shows village population for all the players. This is the major score rank in the game, since it's something that everyone has and it's relatively easy to see. Yet it, ultimately, isn't a strong measure of performance. But that's a problem with team games; how do you measure 'performance' when so much of the contribution one makes is building social networks, establishing trust, etc?
For vague, open games like travian, maybe the best way to communicate 'score' to players is to give them an overview of previous rounds. Show them the target, and how they measure progress, and then what last round's measuring stick looked like. They might choose a different metric, but at least with this kind of guidance they can make an informed assessment about how well they are proceeding.
Consquences
This was one big problem in many MMORPGs: players were 'free' to destroy their characters, spending hundreds of hours building a character that was sub-par. I remember putting points into Charisma in Dark Age of Camelot. As a Cleric. It did nothing for my character; they were wasted points. The 'freedom' to distribute points as I felt wasn't backed with enough information to make a good choice (unless I had been playing the game through to the end-game already, which didn't even exist when the game first shipped). Further, my choice was hard-locked; it could never be changed. This was a combination of asking players to make choices without sufficient information and then penalizing them, for the rest of their online career, for the wrong choices.
Subscribe to:
Posts (Atom)