What Game Designers Actually Do
A very short prologue: I've been very lousy about actually posting game-related topics since I first set up philomathgames.com. The site also needs a better skin. Largely, I don't say much about games because I've always felt that the volume that I'm learning still dwarfs what I already "know". But I've realized 1) this will probably always be the case; 2) some of this stuff, it's been pointed out to me, might actually be helpful for others. So I'm going to try to post about it a bit more.
So, most of the people I know actually have next to no idea what it is I do by 'day' (and sometimes night). The short answer is "it's complicated". Whereas most people have a general notion of what a carpenter does, or even a computer programmer, there is no established archetype for something still perceived to be as "new" as game design. Most people assume I am either a programmer or a graphic designer (I get "so do you use Photoshop?" a lot. I do, but not in the way they think, which also confuses things.). I don't think that game design is new at all -- but what possibly is new is there being enough people trying to make a living practicing it that they have to start sorting out what they do in common. And that's the other difficult part about explaining game design: like writing, it can be approached from a number of different directions to comparably valuable levels of success -- but also like writing, a given game designer is likely to think their way is the ONLY WAY. The reality about both professions (and recognize my bias in the fact that I even compare game design to writing -- a lot of people don't) is that the craft is so complex that most people who do it don't really have a solid notion of why what they do works -- so they often take a very regimented approach with their own methods and theory so as not to lose what they've got. But the truth, and most designers that I've talked to agree on this, is that many roads can lead to the broader field of game design, while at the same time there are certain anchors -- among them mathematics, psychology, and traditional 'design' -- without a basic mastery of which a game designer is going to be in serious trouble eventually, the same way a writer is going to be in hot water pretty quickly without a grasp of grammar and storytelling archetype. Every craft has its tools.
I'm fortunate in tackling this question in that Phil O'Connor from Codemasters wrote an article for Gamasutra on "how to hire game designers" back in October that gives me some good points to reiterate and others to argue with. Mostly, the article is very good, and he's tackling a very difficult concept, which is how to quantify the instinctive way in which one game designer can often recognize another game designer. I remember talking to Jay Minn about this at last year's ION conference (now "LOGIN") -- within about five minutes of conversation one game designer can often recognize another. I don't know why this is, precisely -- and I vehemently do not think that any person with sufficient drive cannot become a competent game designer -- but there are certain focal points that certainly lend to the notion that "game designer" is a "type", beyond the vague ways they're often described -- "jack of all trades", "wide interests", "multitaskers" -- though all of these things often have to be true as well.
A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects."
-- Lazarus Long, Time Enough For Love, Robert Heinlein
This quote seems to be a favorite among designers that I know. I certainly found it pretty young and latched onto it.
The major criticism, from the comments, levied at Paul's article is the apparent contradiction between his assertion that a good game designer should be effectively obsessed with games and also have broad interests and know a lot about many different aspects of the world. I also agree that this seems to fundamentally contradict, but I also understand the spirit with which it was expressed.
I think the safe way to navigate this problem is to say that for game designers, and generally for game developers as a whole, passion is a problem. It's a really persistent, really fulfilling problem. I personally do deep down feel that games are at the heart of everything, being, as Elliot Avedon says (in what I think is one of the most important books for game designers (and there aren't many), though out of print -- The Study of Games), "encapsulated systems" of nearly anything that exists in the world. You can make a game out of anything. You can write a book about anything. Some subjects lend themselves better to game mechanics than others, but there is no genre that games have not or cannot permeate and absorb.
So while a good game designer generally does approach life with a deep passion for what a game is and means and can mean -- the same way, hopefully, any craftsperson approaches their profession, deeply analyzing how it fits into the world even when they're not on the clock -- I don't think that means a good game designer has to be playing games at every spare moment. It is a contradiction to say that they should be worldly and game-obsessed at the same time. At one time it may have been possible to know every game there was, but it's simply not possible anymore -- some filtering is necessary. And Paul covers some of the pitfalls of existing only in games with his section on the difference between a game fan(boy) and a game designer. Game critics, I think, and game analysts and historians, have a much greater burden to be exhaustive and encyclopedic in their knowledge of games. At a certain point such things may actually hurt a designer, though they should never resist exposure to different types of games. So these are the natural tensions that exist and are exacerbated by the sheer breadth and depth that games as a field have become. Games, anthropologically, have historically grown in complexity when society grows in complexity. Kurzweil's Law, anyone? Aka, making games in today's market is damn hard, and sometimes requires some forceful reductionism to keep the "play" objective in mind.
So what do you do?
Right.
The nuts and bolts of the design process aren't all that different from architecture, only instead of planning a building we're planning an experience. It starts with "pre-production", the "core" design phase, where a project is concepted out and assessed for its place in the market. This isn't the farting of ideas, keep in mind -- it involves, or should, intense analysis of the market, how the game will be communicated to that market, and how it will be placed in the marching timestream of game releases to be relevant and appreciated. You will make a fantastic, beautiful document that in all likelihood no one will actually deeply read (but you'll know it back and front, and had better have a bulletproof notion of what the game's identity is -- and something that, in most publication situations, you'll be contractually obligated to fulfill).
This is, mostly, documentation, though it can also, and probably should also, involve prototyping. The core skills here are concise, communication-oriented writing (learn to love bullet-point lists), flow-charting, and research. (If you want to know more about the pitch process, I have a chapter on it in Professional Techniques for Video Game Writers, which also contains several very excellent offerings by folk like rdansky.) Most gamers probably think of this when they think of game design.
But this is where design begins, not where it ends. The concept document and larger game design document should establish core vision and be a reference guide throughout the development process, but it must also be flexible, and it IS going to change. If it were chess, this is the opening -- killer important, but really only the first less-than-a-third of the whole process.
The Middle Game
Aha, so now this blog post has morphed flexibly into a chess model. The middle portion of the design process is involved but less purely creative and cognitive -- this is where the sausage factory begins (and no, I'm not referring to gender ratios, tempting as that might be). Communication is at the forefront here -- and, frankly, a lot of personality management, both overcoming one's own personal limitations (I used to be very shy) and adapting to the collective personality of the team. Things like cultivating personal relationships can go a long way toward pulling this phase of the project together, and so you start getting into the "five dysfunctions of a team" management-type territory. But this is real game development.
The middle phase is the longest, and is also where the game is liable to change the most. I say that communication is important, and by that I mean the designer needs to be aware of where the project is on its trajectory (is it ahead, behind? what needs to be cut, what can be added?), and checking in with the various parts of the team to ensure that the actual implementation is staying consistent with design, or, if it's not, making sure that the documentation is updated for new directions. Very few game projects run top-down, which is one reason why Scrum has grown so popular -- great games come when every member of a team is engaging with the project and making it into a game, not just a collection of features.
The last note about the middle section is that your whole opening game, to a certain extent, doesn't matter here. People -- not just the team, but the producer and the publisher -- are going to read your documents, but realistically only in a cursory fashion. Hopefully they're going to refer back to them when they have questions -- but more likely they're going to call you over or talk to you in a morning meeting about how a particular aspect of the game should go. If you're not an effective and confident communicator, you risk not only losing control of the direction of the project, but instilling doubt and lack of confidence in your team. If a team doesn't have confidence in its designer, or if it thinks one part of the team is going in a different direction, and these difficulties aren't hashed out, bad things happen, and this is where the problems Paul talks about when it comes to designer credibility tend to rear up -- especially if you're dealing with developers (or publishers) who think that they're designers. (And they're really, really not.)
The Endgame
The final phases of a project are by far the most difficult and stressful, even in the most optimal of projects. In less optimal projects, this is where things become brutal. The role of design in this phase is polish, and often becomes hands-on, if it hasn't been already, which is where and why you hear that game designers should know a bit about how to program and how to create art and sound, depending on the size of the team (on smaller teams, everyone does a bit of everything, usually). If you don't, you'll learn, or you'll be out of a job.
In this phase design also switches over to domains more familiar to sociology -- game testing. If there is any formal testing, and even in informal testing, the designer's primary function is to be present and observe intensely how new players interact with the game. What confuses them? What parts do they really enjoy? And then the polish process shifts toward magnifying those uniquely compelling elements and smoothing over confusing UI or gameplay sequences. This part can be harrowing, because people are wild cards, but it's also where you get to see whether unbiased people think your baby is ugly or not. Easy, right? Especially if it's a project you've been working on for 8+ months in a stretch, as many projects these days are. So this phase is about analysis, polish, and prioritization -- because there are going to be about a thousand things you WANT to do and only a small percentage of them will make it through to the end. You have to know when to cut the cord, particularly since, as deadlines approach and pressure increases, further tampering runs a great risk of damaging a product.
Oh, and the endgame is where a game ultimately lives or dies. No pressure!
Whew, this thing is getting long. So, that's the game development process. That's what you do, or at least that's what I've experienced, and I'm sure it isn't all of it.
Lastly, on a few things I agree with Paul completely, and must emphasize--
Game designers must be marketers. They absolutely must. This includes "selling" the game to one's internal team in order to keep he project going in the right direction, "selling" the game to the publisher continuously (if you have one) so they don't cancel it, and, finally, selling the game to the people who will actually play it. And, as Russ Carroll said very eloquently in his 2007 Independent Game Summit presentation, if you're waiting until the game is done to market it, you're dead. It didn't work out so well for Van Gogh, not being appreciated in his time, and it doesn't work out so well for underappreciated games and their designers, either. A game can't just be dropped into the rolling ocean of the game market -- if it's going to succeed, meaning get played and appreciated and make you fabulously wealthy, it needs to be constructed from its core to surf that ocean, to be aware of the world and respond to it, and to respond to what the gaming community wants at a particular time.
And here's the thing: it's entirely possible to be a phenomenal designer and have the full gamut of one's skill not matter a damn bit. If you have incredible design vision and are doing everything exactly right from the purest sense of what "game design" can be defined to mean, you can still get royally fucked if you don't know a lot about project management and marketing. And while most game designers, like writers or creative people in general, on some level often deeply hate these things, the bottom line is that great games don't get made by design alone. They come through a long, grueling, iterative process, and if you make it to the finish line, there's a lot involved, including a good measure of dumb luck. This is not to say that you can be unskilled and make it -- you probably can't -- but if you focus exclusively on the High Art that is Game Design in all its hallowed splendor, you run the serious risk of making crap games, unless you're working alone on a project that can be completed by a single person.
So that's my brain spew on game design. It's really more a quick-and-dirty explanation of the process than it is an explanation of what game design actually is, but that's the peculiar thing about it: the practical application of game design, what game design is as a profession, differs greatly from what game design is as an art. One can, on a good day, pay your bills -- the other you don't need to be a professional game designer at all to practice and achieve great things with. And game design's separate identity -- ie, everything included here -- as a profession is what makes developers and publishers leery about investing in someone who hasn't proven they can make it through the complex gauntlet of the development process. Sure, games need new ideas -- but they also need to make it out the door, and that doesn't always happen even given a great team and a great design. Proving that you can overcome the personal challenges involved in shipping product is the dimension that can't be taught in school, at least not yet, and so students find themselves in the difficult position of seeking one of very few entry-level design-assistant positions, where a senior designer can guide them through the learning process.
We'll see when I gather the energy for an explanation of what game design is, if my own would be actually relevant.
(And did you see how sure of myself I sounded up there? That's game design, too -- the part of it that's perception management, which is marketing.)
So, most of the people I know actually have next to no idea what it is I do by 'day' (and sometimes night). The short answer is "it's complicated". Whereas most people have a general notion of what a carpenter does, or even a computer programmer, there is no established archetype for something still perceived to be as "new" as game design. Most people assume I am either a programmer or a graphic designer (I get "so do you use Photoshop?" a lot. I do, but not in the way they think, which also confuses things.). I don't think that game design is new at all -- but what possibly is new is there being enough people trying to make a living practicing it that they have to start sorting out what they do in common. And that's the other difficult part about explaining game design: like writing, it can be approached from a number of different directions to comparably valuable levels of success -- but also like writing, a given game designer is likely to think their way is the ONLY WAY. The reality about both professions (and recognize my bias in the fact that I even compare game design to writing -- a lot of people don't) is that the craft is so complex that most people who do it don't really have a solid notion of why what they do works -- so they often take a very regimented approach with their own methods and theory so as not to lose what they've got. But the truth, and most designers that I've talked to agree on this, is that many roads can lead to the broader field of game design, while at the same time there are certain anchors -- among them mathematics, psychology, and traditional 'design' -- without a basic mastery of which a game designer is going to be in serious trouble eventually, the same way a writer is going to be in hot water pretty quickly without a grasp of grammar and storytelling archetype. Every craft has its tools.
I'm fortunate in tackling this question in that Phil O'Connor from Codemasters wrote an article for Gamasutra on "how to hire game designers" back in October that gives me some good points to reiterate and others to argue with. Mostly, the article is very good, and he's tackling a very difficult concept, which is how to quantify the instinctive way in which one game designer can often recognize another game designer. I remember talking to Jay Minn about this at last year's ION conference (now "LOGIN") -- within about five minutes of conversation one game designer can often recognize another. I don't know why this is, precisely -- and I vehemently do not think that any person with sufficient drive cannot become a competent game designer -- but there are certain focal points that certainly lend to the notion that "game designer" is a "type", beyond the vague ways they're often described -- "jack of all trades", "wide interests", "multitaskers" -- though all of these things often have to be true as well.
A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects."
-- Lazarus Long, Time Enough For Love, Robert Heinlein
This quote seems to be a favorite among designers that I know. I certainly found it pretty young and latched onto it.
The major criticism, from the comments, levied at Paul's article is the apparent contradiction between his assertion that a good game designer should be effectively obsessed with games and also have broad interests and know a lot about many different aspects of the world. I also agree that this seems to fundamentally contradict, but I also understand the spirit with which it was expressed.
I think the safe way to navigate this problem is to say that for game designers, and generally for game developers as a whole, passion is a problem. It's a really persistent, really fulfilling problem. I personally do deep down feel that games are at the heart of everything, being, as Elliot Avedon says (in what I think is one of the most important books for game designers (and there aren't many), though out of print -- The Study of Games), "encapsulated systems" of nearly anything that exists in the world. You can make a game out of anything. You can write a book about anything. Some subjects lend themselves better to game mechanics than others, but there is no genre that games have not or cannot permeate and absorb.
So while a good game designer generally does approach life with a deep passion for what a game is and means and can mean -- the same way, hopefully, any craftsperson approaches their profession, deeply analyzing how it fits into the world even when they're not on the clock -- I don't think that means a good game designer has to be playing games at every spare moment. It is a contradiction to say that they should be worldly and game-obsessed at the same time. At one time it may have been possible to know every game there was, but it's simply not possible anymore -- some filtering is necessary. And Paul covers some of the pitfalls of existing only in games with his section on the difference between a game fan(boy) and a game designer. Game critics, I think, and game analysts and historians, have a much greater burden to be exhaustive and encyclopedic in their knowledge of games. At a certain point such things may actually hurt a designer, though they should never resist exposure to different types of games. So these are the natural tensions that exist and are exacerbated by the sheer breadth and depth that games as a field have become. Games, anthropologically, have historically grown in complexity when society grows in complexity. Kurzweil's Law, anyone? Aka, making games in today's market is damn hard, and sometimes requires some forceful reductionism to keep the "play" objective in mind.
So what do you do?
Right.
The nuts and bolts of the design process aren't all that different from architecture, only instead of planning a building we're planning an experience. It starts with "pre-production", the "core" design phase, where a project is concepted out and assessed for its place in the market. This isn't the farting of ideas, keep in mind -- it involves, or should, intense analysis of the market, how the game will be communicated to that market, and how it will be placed in the marching timestream of game releases to be relevant and appreciated. You will make a fantastic, beautiful document that in all likelihood no one will actually deeply read (but you'll know it back and front, and had better have a bulletproof notion of what the game's identity is -- and something that, in most publication situations, you'll be contractually obligated to fulfill).
This is, mostly, documentation, though it can also, and probably should also, involve prototyping. The core skills here are concise, communication-oriented writing (learn to love bullet-point lists), flow-charting, and research. (If you want to know more about the pitch process, I have a chapter on it in Professional Techniques for Video Game Writers, which also contains several very excellent offerings by folk like rdansky.) Most gamers probably think of this when they think of game design.
But this is where design begins, not where it ends. The concept document and larger game design document should establish core vision and be a reference guide throughout the development process, but it must also be flexible, and it IS going to change. If it were chess, this is the opening -- killer important, but really only the first less-than-a-third of the whole process.
The Middle Game
Aha, so now this blog post has morphed flexibly into a chess model. The middle portion of the design process is involved but less purely creative and cognitive -- this is where the sausage factory begins (and no, I'm not referring to gender ratios, tempting as that might be). Communication is at the forefront here -- and, frankly, a lot of personality management, both overcoming one's own personal limitations (I used to be very shy) and adapting to the collective personality of the team. Things like cultivating personal relationships can go a long way toward pulling this phase of the project together, and so you start getting into the "five dysfunctions of a team" management-type territory. But this is real game development.
The middle phase is the longest, and is also where the game is liable to change the most. I say that communication is important, and by that I mean the designer needs to be aware of where the project is on its trajectory (is it ahead, behind? what needs to be cut, what can be added?), and checking in with the various parts of the team to ensure that the actual implementation is staying consistent with design, or, if it's not, making sure that the documentation is updated for new directions. Very few game projects run top-down, which is one reason why Scrum has grown so popular -- great games come when every member of a team is engaging with the project and making it into a game, not just a collection of features.
The last note about the middle section is that your whole opening game, to a certain extent, doesn't matter here. People -- not just the team, but the producer and the publisher -- are going to read your documents, but realistically only in a cursory fashion. Hopefully they're going to refer back to them when they have questions -- but more likely they're going to call you over or talk to you in a morning meeting about how a particular aspect of the game should go. If you're not an effective and confident communicator, you risk not only losing control of the direction of the project, but instilling doubt and lack of confidence in your team. If a team doesn't have confidence in its designer, or if it thinks one part of the team is going in a different direction, and these difficulties aren't hashed out, bad things happen, and this is where the problems Paul talks about when it comes to designer credibility tend to rear up -- especially if you're dealing with developers (or publishers) who think that they're designers. (And they're really, really not.)
The Endgame
The final phases of a project are by far the most difficult and stressful, even in the most optimal of projects. In less optimal projects, this is where things become brutal. The role of design in this phase is polish, and often becomes hands-on, if it hasn't been already, which is where and why you hear that game designers should know a bit about how to program and how to create art and sound, depending on the size of the team (on smaller teams, everyone does a bit of everything, usually). If you don't, you'll learn, or you'll be out of a job.
In this phase design also switches over to domains more familiar to sociology -- game testing. If there is any formal testing, and even in informal testing, the designer's primary function is to be present and observe intensely how new players interact with the game. What confuses them? What parts do they really enjoy? And then the polish process shifts toward magnifying those uniquely compelling elements and smoothing over confusing UI or gameplay sequences. This part can be harrowing, because people are wild cards, but it's also where you get to see whether unbiased people think your baby is ugly or not. Easy, right? Especially if it's a project you've been working on for 8+ months in a stretch, as many projects these days are. So this phase is about analysis, polish, and prioritization -- because there are going to be about a thousand things you WANT to do and only a small percentage of them will make it through to the end. You have to know when to cut the cord, particularly since, as deadlines approach and pressure increases, further tampering runs a great risk of damaging a product.
Oh, and the endgame is where a game ultimately lives or dies. No pressure!
Whew, this thing is getting long. So, that's the game development process. That's what you do, or at least that's what I've experienced, and I'm sure it isn't all of it.
Lastly, on a few things I agree with Paul completely, and must emphasize--
Game designers must be marketers. They absolutely must. This includes "selling" the game to one's internal team in order to keep he project going in the right direction, "selling" the game to the publisher continuously (if you have one) so they don't cancel it, and, finally, selling the game to the people who will actually play it. And, as Russ Carroll said very eloquently in his 2007 Independent Game Summit presentation, if you're waiting until the game is done to market it, you're dead. It didn't work out so well for Van Gogh, not being appreciated in his time, and it doesn't work out so well for underappreciated games and their designers, either. A game can't just be dropped into the rolling ocean of the game market -- if it's going to succeed, meaning get played and appreciated and make you fabulously wealthy, it needs to be constructed from its core to surf that ocean, to be aware of the world and respond to it, and to respond to what the gaming community wants at a particular time.
And here's the thing: it's entirely possible to be a phenomenal designer and have the full gamut of one's skill not matter a damn bit. If you have incredible design vision and are doing everything exactly right from the purest sense of what "game design" can be defined to mean, you can still get royally fucked if you don't know a lot about project management and marketing. And while most game designers, like writers or creative people in general, on some level often deeply hate these things, the bottom line is that great games don't get made by design alone. They come through a long, grueling, iterative process, and if you make it to the finish line, there's a lot involved, including a good measure of dumb luck. This is not to say that you can be unskilled and make it -- you probably can't -- but if you focus exclusively on the High Art that is Game Design in all its hallowed splendor, you run the serious risk of making crap games, unless you're working alone on a project that can be completed by a single person.
So that's my brain spew on game design. It's really more a quick-and-dirty explanation of the process than it is an explanation of what game design actually is, but that's the peculiar thing about it: the practical application of game design, what game design is as a profession, differs greatly from what game design is as an art. One can, on a good day, pay your bills -- the other you don't need to be a professional game designer at all to practice and achieve great things with. And game design's separate identity -- ie, everything included here -- as a profession is what makes developers and publishers leery about investing in someone who hasn't proven they can make it through the complex gauntlet of the development process. Sure, games need new ideas -- but they also need to make it out the door, and that doesn't always happen even given a great team and a great design. Proving that you can overcome the personal challenges involved in shipping product is the dimension that can't be taught in school, at least not yet, and so students find themselves in the difficult position of seeking one of very few entry-level design-assistant positions, where a senior designer can guide them through the learning process.
We'll see when I gather the energy for an explanation of what game design is, if my own would be actually relevant.
(And did you see how sure of myself I sounded up there? That's game design, too -- the part of it that's perception management, which is marketing.)