Bruce Shankle, when he spoke at my school in January '07 about breaking into the game industry, pointed out that even the most famous names are often not recognized by experienced gamers. How many know who Carmack and Romero, or Will Wright are? But mention their works (Doom and Quake, The Sims) and they're recognized. Sid Meier is recognized primarily because his name is part of some game names.
My students generally don't have a clue that I am a little bit famous--after all, I "don't do electronic games". I was amused one day at the game club when a student said he'd talked to a friend in Florida and told him his instructor had designed Britannia. The friend got excited and said something like "oh, that's my favorite game, he's famous". No. Hardly anyone in the game industry is famous. But many people worldwide recognize my name (which is fortunately nearly unique), or the game Britannia, or what I did with D&D and Diplomacy variants ages ago. Measured by that number of people, I'm likely the most famous (or better, least unfamous) person the students know, but they don't think in those terms.
I'm going to edit in a more recent story: Another student (Frank) told me that in his history class is an older man, who obviously knows the history instructors well, maybe working on another degree? He and some other folks have been working on an historical game for 10 years and are about to publish. Frank said, do you know the game Britannia? Yes. The designer of Britannia is teaching game design at Wake, you ought to talk to him, Frank says. The gent got quite excited. Though I haven't heard from him yet!
The "me" generation generally isn't impressed by anyone but themselves, of course. In a high school class I taught last year, about one quarter of the 20-some students thought they would be famous at some time. This is evidently a common "delusion" amongst the younger generation. (I say delusion because, barring extreme chance, you'd not have even one "famous" person come out of a group that small.)
So what can a teacher do about this? Nothing that I can think of. Sometimes only time/experience lets people shed illusions.
Wednesday, October 31, 2007
Number of people working on an "AAA list" game
I found this note highlighting the massive size of modern video games:
More than 70 people, including 20 programmers and 30 artists, worked on Madden NFL '07. Similarly, Maxime Beland, creative director at Ubisoft's Montreal studio, says that 150 people worked with him to create Rainbow Six Vegas.
More than 70 people, including 20 programmers and 30 artists, worked on Madden NFL '07. Similarly, Maxime Beland, creative director at Ubisoft's Montreal studio, says that 150 people worked with him to create Rainbow Six Vegas.
What students can do outside of class
In classes we made a list of what students can do outside of class to help prepare/qualify themselves to apply for a job in the video game industry. There is no particular priority here, for the most part.
IGDA free membership
Business card!
Use Printmaster or word processor, buy business card stock at office supply
Go to IGDA meetings
“Go to GDC”
Go to DGXpo
Go to Goldsboro cconvention (One-day)
Web sites to visit/monitor:
Gamasutra
Slashdot.org
Gamespot
Mobygames.com
IGN
Sloperama
Engadget
Joystiq
Boardgamegeek.com (for ideas)
Bgdf.com (board game designers’ forum)
And many others
Download and try engines (for programmers and designers), XNA, Torque, RPGMaker, Source, etc.
Application software:
Maya Personal Edition 8.5 (2008)
30 day 3D Studio Max
30 day Photoshop CS3
Blender
Gimp
MS Expression Graphic Designer
Resume
Your Web site
Geocities free
Freehostia free
Lunarpages <$100 / year (my host and package for pulsiphergames.com)
Portfolios (on the Web, and paper/CD/DVD)
Modding/make scenarios
Be a guest speaker (libraries, schools)
Write things (Gamasutra, many other Web sites, Game Developer Magazine)
Remember that many businesses do drug testing of prospective employees
Marwood Ellis came across some interesting networking advice about the Game Developers Conference (and possibly other events) that could be useful to students.
http://www.igda.org/articles/mmencher_networking05.php
Another article written
http://www.igda.org/articles/mmencher_networking06.php
a list of other articles written:
http://www.igda.org/Forums/showthread.php?s=9c6f2892ee6d8d60253a0e792da87a80&threadid=20528
IGDA free membership
Business card!
Use Printmaster or word processor, buy business card stock at office supply
Go to IGDA meetings
“Go to GDC”
Go to DGXpo
Go to Goldsboro cconvention (One-day)
Web sites to visit/monitor:
Gamasutra
Slashdot.org
Gamespot
Mobygames.com
IGN
Sloperama
Engadget
Joystiq
Boardgamegeek.com (for ideas)
Bgdf.com (board game designers’ forum)
And many others
Download and try engines (for programmers and designers), XNA, Torque, RPGMaker, Source, etc.
Application software:
Maya Personal Edition 8.5 (2008)
30 day 3D Studio Max
30 day Photoshop CS3
Blender
Gimp
MS Expression Graphic Designer
Resume
Your Web site
Geocities free
Freehostia free
Lunarpages <$100 / year (my host and package for pulsiphergames.com)
Portfolios (on the Web, and paper/CD/DVD)
Modding/make scenarios
Be a guest speaker (libraries, schools)
Write things (Gamasutra, many other Web sites, Game Developer Magazine)
Remember that many businesses do drug testing of prospective employees
Marwood Ellis came across some interesting networking advice about the Game Developers Conference (and possibly other events) that could be useful to students.
http://www.igda.org/articles/mmencher_networking05.php
Another article written
http://www.igda.org/articles/mmencher_networking06.php
a list of other articles written:
http://www.igda.org/Forums/showthread.php?s=9c6f2892ee6d8d60253a0e792da87a80&threadid=20528
Friday, October 26, 2007
Slides about size of modern electronic games
As a follow-up to posts about the sheer size of modern electronic games, I made a set of slides linked here.
Thursday, October 25, 2007
Playtesting is "Sovereign"
I've been known to say about game design that "Prototypes are sovereign", that you haven't really designed a game until you have a playable prototype. That's because, until the game is played, you just cannot really know what you've got. But I would be just as right to say "playtesting is sovereign".
When you design a game, you try to see in your "mind's eye" how the game is going to work, but until you play it, you simply cannot know what is going to work and what is not. The first few times you play, many things will change (provided, of course, that you're willing to make changes, which is a major requirement of a game designer).
Granted more experienced designers can foresee weaknesses and eliminate them before reaching the prototype stage. But we're interested here in teaching game design, so this is addressed to inexperienced designers.
Let's clarify something right now. I am talking about playtesting to improve gameplay, not testing to squash programming bugs. The latter is what is often meant by "testing" when people talk about electronic games, and this testing takes place late in the development cycle, when the gameplay and appearance are set in stone (because it's too late to make major changes). This bug testing ("Quality Assurance") is aimed at making sure the game works the way it is supposed to, not at whether the way it's supposed to work is good or not. "Bug testing" essentially does not exist in non-electronic games, although it is important (and often forgotten) to test the production version of a game, as converting the prototype into the published version can introduce its own set of problems. (For example, the boxes on Population Track on the FFG Britannia board are really too small for the purpose; this new version of the board evidently was not actually tested.)
So: here I'm talking about playtesting the gameplay and assorted details (such as user interface) that strongly affect gameplay.
There are three stages to playtesting: solo playtesting (also called "alpha"), local playtesting ("beta"), and "blind" playtesting (also part of the "beta" stage). (In electronic games, often the in-house testing is all called "alpha", and outside testing is called "beta".)
Few non-video games are meant to be played alone. Yet in solo playtesting, the designer plays the game solitaire, playing all the sides independently as best he can. At this stage the designer is trying to get the game to a state where other playtesters have a good likelihood of enjoying it, and of playing it through to the end. At solo stage the designer might try a portion of the game and then stop because something isn't working, or because he has a better idea. When asking other people to play a game I would never stop a game in the middle, or try something that might be so bad I'd want to stop, though I know of designers who think nothing of doing this.
Most video games can be played alone, and if there's a more-than-one-player component, it's usually impossible for the designer to play several sides by himself.
At the local playtesting stage, people are asked to play the game through, usually in the presence of the designer when it is a non-electronic game. Almost always, at the beginning of this beta testing I do not have a full set of rules, I just have notes about how to play, and some of the details are in my head. (This is a big reason why it is much quicker to design a non-electronic game. With an electronic game all the "rules" must be settled precisely before the programming of the prototype can be completed. The programming is the equivalent of the rules of the non-electronic game.) As local playtesting goes on, I make a rough set of rules, then finally write a full set of rules.
As the local playtests occur, I write down notes about what I see and hear, and especially about answers to questions that need to be incorporated into the full rules. By the time I have a full set of rules, I usually refer to the rules for detailed questions, to see if the rules cover that question and whether it is easy to find that information.
The third stage is "blind" testing, where someone is given the game and must play it without any intervention from the designer. This is a test of the rules, somewhat akin to "bug testing". Are the rules clear enough that people can play the game from the rules? What questions do the blind testers come up with, and how can the rules be improved as a result? Unfortunately, nowadays people are often poor rules-readers, so I advocate electronic tutorials to help people learn how to play a game.
I know from experience with published games, especially Britannia, that there will ALWAYS be people who misread rules, sometimes willfully. 99% clarity of detail is about the best you can get using the English language.
In a sense, electronic games can jump to "blind" testing quickly, because by their very nature these games hide the rules from the players, enforcing them through the programming. This is an advantage of electronic games over non-electronic, that no one needs to read and understand a set of rules.
Game design, when taken to completion, is highly interactive. Playtesting sets good games apart from bad, and playtesting is (or should be) interactive. In a separate post I list some of the things you must look for while doing beta testing.
There is no doubt that the last 20% of refinement of a game takes 80% of the designer's time. Playtesting is time-consuming, tweaking rules is time-consuming. In the non-electronic world, often a "developer", another person, does much of this testing and tweaking. I personally strongly prefer to do this myself, even though it is much less fun than creating new games, because I don't want someone else "screwing up" my game. (See http://www.pulsipher.net/gamedesign/developers.htm for some of my experiences.)
Even when you don't intend to change the rules, rewriting them introduces unintended consequences (as evidenced by the Britannia Second Edition rules rewrite by FFG--and apparently having no testing of the new version of the rules compounded the problem). When you rewrite to change a rule, the repercussions are often larger. So a remarkable amount of testing is needed.
In the electronic world it is difficult to quickly and cheaply make big changes in a prototype. This is one of the problems that all makers of electronic games face, and a major reason why some electronic games are not very good. By the time the development studio has a playable prototype, it is too late in the schedule to make the changes that playtesting reveals are necessary.
At some point during playtesting of a game, the designer must decide if "there's something in it" (as I put it): if the game is really good enough that people might play it, like it, and would buy the finished version of it. There's really two times when this should happen, once during solo playtests (alpha testing), the second time during playtesting by others (beta testing). The "something in it" point in solo playtesting is an indicator that it's about ready for others to play. The "something in it" point in beta testing comes when observing people playing the game and their reactions during and after playing.
Usually I need to tweak a game quite a bit from its state at the end of solo play, before I can reach the "something in it" stage of beta testing. Sometimes there doesn't seem to be anything in it during beta testing, and I set it aside for further thought. Sometimes I realize, from solo playing, that there isn't "something in it", at least not yet, so I set it aside at that point.
I strongly suspect that novice designers rarely understand these stages. Their egos become involved, and they assume that because they took the time to make the game, and it's their idea, there must be something in it. In extreme cases, the "designer" thinks he has "something in it" when all he has is an idea, that is, when he has virtually nothing at all. The number of people who think they've successfully designed a game, yet haven't playtested it at all, is remarkable. Playtesting is the meat of successful design, not the end. (I confess that I don't think of "development" as a process separate from design.)
So how do you recognize when there's "something in" a game? That's hard to say, unfortunately. Surveys or written feedback won't necessarily reveal it. In alpha testing, the "something in it" stage is a gradual realization, coming from observing my own thought processes as I play. My games are, almost without exception, strategy games. When I "see" myself thinking hard about the strategies, and liking the options, then I may think there's something in it.
In my case, in beta testing when spontaneously (without any urging) people say "I'd buy this game", I know I've got something. However, this is rare, and I don't remember anyone ever saying that about Britannia, or Dragon Rage, or Valley of the Four Winds, but they have all been quite popular. Perhaps better, if people want to play the game again, in this day of the "cult of the new" when hardly anyone plays a game twice in the same session, there may be "something in it".
I am very low-key in beta playtesting, preferring to watch reactions of people rather than try to solicit opinions, in part because people (being polite for the most part) won't say negative things even when asked. I also try not to play, as 1) the designer playing in a game tends to skew results and 2) when I play, I do a worse job of playing, and a worse job of evaluating the playtesting, than if I did either alone. As I'm that strange sort of person who enjoys watching games as much as playing, why play?
I do not "inflict" a game on players until I think it is good enough to be OK to play, that is, I've reached that first "something in it" stage. Evidently some other designers playtest with other people very early: not me. My playtesters play games to have fun, not as on obligation, and most are not hard-core boardgamers, so I do what I can to make sure the game MIGHT be fun before I ask them to play.
As I said, playtesters tend to be polite. It's hard to find out what they really think. I am skeptical that a feedback sheet will make a difference. Rather,
I sometimes try the "Six Hats" method (devised by Edward de Bono) when playtesting; specifically I'll ask players successively to put on their black hat (the judge), then the red hat (intuition and emotion) to see how they assess a game, and then the yellow hat (the positive side of assessing an idea) to see what they like about a game. With local playtesters I sometimes ask them to think of ways to make the game better (the green hat). Google "de Bono" or "Six Hats" for more information.
Also see the following article on Gamastutra: http://www.gamasutra.com/features/20050913/sigman_01.shtml
This includes tips on constructing prototypes.
When you design a game, you try to see in your "mind's eye" how the game is going to work, but until you play it, you simply cannot know what is going to work and what is not. The first few times you play, many things will change (provided, of course, that you're willing to make changes, which is a major requirement of a game designer).
Granted more experienced designers can foresee weaknesses and eliminate them before reaching the prototype stage. But we're interested here in teaching game design, so this is addressed to inexperienced designers.
Let's clarify something right now. I am talking about playtesting to improve gameplay, not testing to squash programming bugs. The latter is what is often meant by "testing" when people talk about electronic games, and this testing takes place late in the development cycle, when the gameplay and appearance are set in stone (because it's too late to make major changes). This bug testing ("Quality Assurance") is aimed at making sure the game works the way it is supposed to, not at whether the way it's supposed to work is good or not. "Bug testing" essentially does not exist in non-electronic games, although it is important (and often forgotten) to test the production version of a game, as converting the prototype into the published version can introduce its own set of problems. (For example, the boxes on Population Track on the FFG Britannia board are really too small for the purpose; this new version of the board evidently was not actually tested.)
So: here I'm talking about playtesting the gameplay and assorted details (such as user interface) that strongly affect gameplay.
There are three stages to playtesting: solo playtesting (also called "alpha"), local playtesting ("beta"), and "blind" playtesting (also part of the "beta" stage). (In electronic games, often the in-house testing is all called "alpha", and outside testing is called "beta".)
Few non-video games are meant to be played alone. Yet in solo playtesting, the designer plays the game solitaire, playing all the sides independently as best he can. At this stage the designer is trying to get the game to a state where other playtesters have a good likelihood of enjoying it, and of playing it through to the end. At solo stage the designer might try a portion of the game and then stop because something isn't working, or because he has a better idea. When asking other people to play a game I would never stop a game in the middle, or try something that might be so bad I'd want to stop, though I know of designers who think nothing of doing this.
Most video games can be played alone, and if there's a more-than-one-player component, it's usually impossible for the designer to play several sides by himself.
At the local playtesting stage, people are asked to play the game through, usually in the presence of the designer when it is a non-electronic game. Almost always, at the beginning of this beta testing I do not have a full set of rules, I just have notes about how to play, and some of the details are in my head. (This is a big reason why it is much quicker to design a non-electronic game. With an electronic game all the "rules" must be settled precisely before the programming of the prototype can be completed. The programming is the equivalent of the rules of the non-electronic game.) As local playtesting goes on, I make a rough set of rules, then finally write a full set of rules.
As the local playtests occur, I write down notes about what I see and hear, and especially about answers to questions that need to be incorporated into the full rules. By the time I have a full set of rules, I usually refer to the rules for detailed questions, to see if the rules cover that question and whether it is easy to find that information.
The third stage is "blind" testing, where someone is given the game and must play it without any intervention from the designer. This is a test of the rules, somewhat akin to "bug testing". Are the rules clear enough that people can play the game from the rules? What questions do the blind testers come up with, and how can the rules be improved as a result? Unfortunately, nowadays people are often poor rules-readers, so I advocate electronic tutorials to help people learn how to play a game.
I know from experience with published games, especially Britannia, that there will ALWAYS be people who misread rules, sometimes willfully. 99% clarity of detail is about the best you can get using the English language.
In a sense, electronic games can jump to "blind" testing quickly, because by their very nature these games hide the rules from the players, enforcing them through the programming. This is an advantage of electronic games over non-electronic, that no one needs to read and understand a set of rules.
Game design, when taken to completion, is highly interactive. Playtesting sets good games apart from bad, and playtesting is (or should be) interactive. In a separate post I list some of the things you must look for while doing beta testing.
There is no doubt that the last 20% of refinement of a game takes 80% of the designer's time. Playtesting is time-consuming, tweaking rules is time-consuming. In the non-electronic world, often a "developer", another person, does much of this testing and tweaking. I personally strongly prefer to do this myself, even though it is much less fun than creating new games, because I don't want someone else "screwing up" my game. (See http://www.pulsipher.net/gamedesign/developers.htm for some of my experiences.)
Even when you don't intend to change the rules, rewriting them introduces unintended consequences (as evidenced by the Britannia Second Edition rules rewrite by FFG--and apparently having no testing of the new version of the rules compounded the problem). When you rewrite to change a rule, the repercussions are often larger. So a remarkable amount of testing is needed.
In the electronic world it is difficult to quickly and cheaply make big changes in a prototype. This is one of the problems that all makers of electronic games face, and a major reason why some electronic games are not very good. By the time the development studio has a playable prototype, it is too late in the schedule to make the changes that playtesting reveals are necessary.
At some point during playtesting of a game, the designer must decide if "there's something in it" (as I put it): if the game is really good enough that people might play it, like it, and would buy the finished version of it. There's really two times when this should happen, once during solo playtests (alpha testing), the second time during playtesting by others (beta testing). The "something in it" point in solo playtesting is an indicator that it's about ready for others to play. The "something in it" point in beta testing comes when observing people playing the game and their reactions during and after playing.
Usually I need to tweak a game quite a bit from its state at the end of solo play, before I can reach the "something in it" stage of beta testing. Sometimes there doesn't seem to be anything in it during beta testing, and I set it aside for further thought. Sometimes I realize, from solo playing, that there isn't "something in it", at least not yet, so I set it aside at that point.
I strongly suspect that novice designers rarely understand these stages. Their egos become involved, and they assume that because they took the time to make the game, and it's their idea, there must be something in it. In extreme cases, the "designer" thinks he has "something in it" when all he has is an idea, that is, when he has virtually nothing at all. The number of people who think they've successfully designed a game, yet haven't playtested it at all, is remarkable. Playtesting is the meat of successful design, not the end. (I confess that I don't think of "development" as a process separate from design.)
So how do you recognize when there's "something in" a game? That's hard to say, unfortunately. Surveys or written feedback won't necessarily reveal it. In alpha testing, the "something in it" stage is a gradual realization, coming from observing my own thought processes as I play. My games are, almost without exception, strategy games. When I "see" myself thinking hard about the strategies, and liking the options, then I may think there's something in it.
In my case, in beta testing when spontaneously (without any urging) people say "I'd buy this game", I know I've got something. However, this is rare, and I don't remember anyone ever saying that about Britannia, or Dragon Rage, or Valley of the Four Winds, but they have all been quite popular. Perhaps better, if people want to play the game again, in this day of the "cult of the new" when hardly anyone plays a game twice in the same session, there may be "something in it".
I am very low-key in beta playtesting, preferring to watch reactions of people rather than try to solicit opinions, in part because people (being polite for the most part) won't say negative things even when asked. I also try not to play, as 1) the designer playing in a game tends to skew results and 2) when I play, I do a worse job of playing, and a worse job of evaluating the playtesting, than if I did either alone. As I'm that strange sort of person who enjoys watching games as much as playing, why play?
I do not "inflict" a game on players until I think it is good enough to be OK to play, that is, I've reached that first "something in it" stage. Evidently some other designers playtest with other people very early: not me. My playtesters play games to have fun, not as on obligation, and most are not hard-core boardgamers, so I do what I can to make sure the game MIGHT be fun before I ask them to play.
As I said, playtesters tend to be polite. It's hard to find out what they really think. I am skeptical that a feedback sheet will make a difference. Rather,
I sometimes try the "Six Hats" method (devised by Edward de Bono) when playtesting; specifically I'll ask players successively to put on their black hat (the judge), then the red hat (intuition and emotion) to see how they assess a game, and then the yellow hat (the positive side of assessing an idea) to see what they like about a game. With local playtesters I sometimes ask them to think of ways to make the game better (the green hat). Google "de Bono" or "Six Hats" for more information.
Also see the following article on Gamastutra: http://www.gamasutra.com/features/20050913/sigman_01.shtml
This includes tips on constructing prototypes.
Tuesday, October 23, 2007
Things to watch for when playtesting
Length. A game is always longer to new players, of course. But if it takes too long for new players, will they play again? Length is of course quite dependent on how much players enjoy what is happening in the game. The boardgame Civilization can take 8 to 12 hours, but those who love the game don't find that time weighs upon them.
Down time. Downtime is the time people must wait while someone else is taking a turn. This can be a problem even in a turn-based electronic game. Do people get bored waiting for their turn?
Is the game balanced. Even if the game is symmetric (all players start with identical situations), is there an advantage to playing first (or last). Chess is symmetric except for who moves first, but move-first is a big advantage.
Dominant Strategy. Look for any dominant strategy ("saddle point"). This is a strategy that is so good that a player who wants to win must pursue it; or a strategy so good that some will pursue it, yet that strategy renders the game less than entertaining. For example, in a Euro-style 4X game I've designed, one player found that by getting together a sufficiently large force, along with certain technology research, he could completely dominate other players who weren't pursuing the identical strategy. I want the game to offer a variety of ways to success, so I had to change the rules fairly extensively. This is why it is very important to have testers who are dynamite game players, so that they'll find these strategies during testing, rather than have someone find it after the game is published. I'm luck that I have one such player, and that I can be such a player myself when I put my mind to it.
Analysis paralysis. Are there too many things to watch for or keep track of, or too many choices, so players either freeze up or give up on figuring out what is the best thing to do? There are always "deliberate" (slow) players, the question is, is everyone slow or frustrated?
Rules difficult to grasp. What do the players find hard to grasp. (In my prototype Age of Exploration, players had trouble grasping the difference between movement of units and placement of units. I used the same distinction in an abstract stones-and-hexes prototype, and no one has a problem. Even if, after playing, players "get it", it might be necessary to change something. (In AoE I changed the rules extensively to recast/eliminate the distinction.)
What do players tend to forget? This isn't quite the same thing as what's difficult to grasp. Some rules just don't stick in people's minds. Is there anything you can do about it? Is there some play aid to help people remember?
What do players not bother to use? Some rules exist but no one uses them. If the threat of using them is not making a difference in the game, then perhaps you should eliminate the option. For example, in my hex-and-stones game Law and Chaos I originally allowed people to move a piece rather than place one. This happened rarely, as it was usually better to place another piece and increase the number on the board. So I eliminated the possibility, except as an "optional rule".
This was done in some haste, and I imagine I'll think of more.
Here are some items added from comments on boardgamegeek.
To see the discussion on boardgamegeek go to http://www.boardgamegeek.com/article/1810302#1810302
Adequate control. Do the players feel that they can exert a measure of control over what happens in the game? Remember, any (strategic) game is a series of challenges and actions in response to those challenges. (Harmony)
Horns of a Dilemma. On the other hand, are there enough plausible decisions in a play to make the players think, but not so many that "analysis paralysis" sets in. Even in a simple game, if a player can do only two of five possible actions in a turn, is there tension here or are the plays obvious? As one commenter put it, do the players sometimes feel "so much to do, so few actions"?
Player interaction. Do the players have to take the plays of other players into account? Yes, some games are virtually multi-player solitaire, and some players are happy with this. But most players want to be able to affect other players with their moves.
Taking it to the Max. Can extreme behavior within the rules break the game? Sure, if someone pursues a bad strategy, they'll lose. The question is, is there some extreme strategy that results in an unfair game?
Components and Play Aids. Do the physical parts of the game help play flow smoothly, or does something need to be changed? Is there too much record-keeping? How can it all be simplified?
Stages of play. You probably learn this in alpha/solo testing, if you do solo testing (which I strongly recommend). Are there identifiable stages in the game, especially ones where the typical run of play changes? E.g., in chess there is the early, middle, and end games. Pieces are deployed in the opening, mix it up in the midgame, and so forth. An exploration game has the expansion period followed by consolidation and then (usually) conflict. Etc.
Player interest/"fun". What part(s) of the game seem to be most interesting to the players? I'm not in favor of trying to figure out "fun", because fun comes from the people who are playing more than from the game design itself. And there are many games that I wouldn't call "fun" (including Britannia) that are nonetheless interesting and even fascinating.
Finally, remember Antoine de Saint-Exup'ery's maxim: “A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.”
Down time. Downtime is the time people must wait while someone else is taking a turn. This can be a problem even in a turn-based electronic game. Do people get bored waiting for their turn?
Is the game balanced. Even if the game is symmetric (all players start with identical situations), is there an advantage to playing first (or last). Chess is symmetric except for who moves first, but move-first is a big advantage.
Dominant Strategy. Look for any dominant strategy ("saddle point"). This is a strategy that is so good that a player who wants to win must pursue it; or a strategy so good that some will pursue it, yet that strategy renders the game less than entertaining. For example, in a Euro-style 4X game I've designed, one player found that by getting together a sufficiently large force, along with certain technology research, he could completely dominate other players who weren't pursuing the identical strategy. I want the game to offer a variety of ways to success, so I had to change the rules fairly extensively. This is why it is very important to have testers who are dynamite game players, so that they'll find these strategies during testing, rather than have someone find it after the game is published. I'm luck that I have one such player, and that I can be such a player myself when I put my mind to it.
Analysis paralysis. Are there too many things to watch for or keep track of, or too many choices, so players either freeze up or give up on figuring out what is the best thing to do? There are always "deliberate" (slow) players, the question is, is everyone slow or frustrated?
Rules difficult to grasp. What do the players find hard to grasp. (In my prototype Age of Exploration, players had trouble grasping the difference between movement of units and placement of units. I used the same distinction in an abstract stones-and-hexes prototype, and no one has a problem. Even if, after playing, players "get it", it might be necessary to change something. (In AoE I changed the rules extensively to recast/eliminate the distinction.)
What do players tend to forget? This isn't quite the same thing as what's difficult to grasp. Some rules just don't stick in people's minds. Is there anything you can do about it? Is there some play aid to help people remember?
What do players not bother to use? Some rules exist but no one uses them. If the threat of using them is not making a difference in the game, then perhaps you should eliminate the option. For example, in my hex-and-stones game Law and Chaos I originally allowed people to move a piece rather than place one. This happened rarely, as it was usually better to place another piece and increase the number on the board. So I eliminated the possibility, except as an "optional rule".
This was done in some haste, and I imagine I'll think of more.
Here are some items added from comments on boardgamegeek.
To see the discussion on boardgamegeek go to http://www.boardgamegeek.com/article/1810302#1810302
Adequate control. Do the players feel that they can exert a measure of control over what happens in the game? Remember, any (strategic) game is a series of challenges and actions in response to those challenges. (Harmony)
Horns of a Dilemma. On the other hand, are there enough plausible decisions in a play to make the players think, but not so many that "analysis paralysis" sets in. Even in a simple game, if a player can do only two of five possible actions in a turn, is there tension here or are the plays obvious? As one commenter put it, do the players sometimes feel "so much to do, so few actions"?
Player interaction. Do the players have to take the plays of other players into account? Yes, some games are virtually multi-player solitaire, and some players are happy with this. But most players want to be able to affect other players with their moves.
Taking it to the Max. Can extreme behavior within the rules break the game? Sure, if someone pursues a bad strategy, they'll lose. The question is, is there some extreme strategy that results in an unfair game?
Components and Play Aids. Do the physical parts of the game help play flow smoothly, or does something need to be changed? Is there too much record-keeping? How can it all be simplified?
Stages of play. You probably learn this in alpha/solo testing, if you do solo testing (which I strongly recommend). Are there identifiable stages in the game, especially ones where the typical run of play changes? E.g., in chess there is the early, middle, and end games. Pieces are deployed in the opening, mix it up in the midgame, and so forth. An exploration game has the expansion period followed by consolidation and then (usually) conflict. Etc.
Player interest/"fun". What part(s) of the game seem to be most interesting to the players? I'm not in favor of trying to figure out "fun", because fun comes from the people who are playing more than from the game design itself. And there are many games that I wouldn't call "fun" (including Britannia) that are nonetheless interesting and even fascinating.
Finally, remember Antoine de Saint-Exup'ery's maxim: “A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.”
Saturday, October 20, 2007
Sailors on the Seas of Fate
My title is a variation of a book title by Michael Moorcock (from the Elric of Melnibone series), a title that has always stuck in my mind.
I am a literal-minded person to an extreme, and as a result I am not good at making up analogies: I would rather discuss the reality than some comparison to that reality. However, I've come up with an analogy that might help students and teachers understand what's going on in many classes, so I'll explain it here.
We are all figuratively "cast upon the seas of fate" in a class, or in life as a whole. But we respond to that differently, in ways that are relatively easy to see in a class. Some are captains of sturdy sailing vessels, some are sailors on small boats, and some are castaways on makeshift rafts (or, like a message in a bottle, bobbing along on the waves without direction).
The Captains are guiding their ships, looking for the best winds and currents, keeping a "weather eye" at all times. They intend to do all they can to reach port. Some of the Captains have helpers (significant others, family, friends, mentors) providing support, some are "solo sailors". But all depend on themselves first of all to get where they need to go.
Their answer to the following two questions is to "disagree". "Luck plays a big part in what happens to me" and "When I'm required to do something (as at work or school) I do just enough to get by." They recognize that much of what happens to them is their doing, not someone else's fault.
Yes, these Captains can be thwarted by the "perfect storm", by circumstances (such as illness) that they truly cannot control. But they're doing their best to avoid those situations.
In terms of students, these are the ones who keep track of when work is due, who actually read textbooks (well, in the current generation, sometimes), who know what "study" means, who are trying to get an "A" rather than a B or C.
At the other extreme are the castaways, or the "message in a bottle", drifting along on the waves, hoping that they'll be carried to a good destination. Like a message in a bottle, they have little influence over where they're going. Like a castaway on a makeshift raft, they might have rigged up a sail, or they might have a paddle, but when things go wrong they often just throw up their hands and say "it's not my fault" instead of doing what they can to guide their fate. These are the folks who tend to blame everything that happens to them on someone or something else. They may indeed have difficult family circumstances, financial problems, and so on, but in the end it is usually a lack of WILL that will do them in.
Their answer to the two questions is to "agree". ("Luck plays a big part in what happens to me" and "When I'm required to do something (as at work or school) I do just enough to get by.") "It's not my fault" is their mantra. They may feel that the world "owes them something", but they find out that in the adult world that isn't true. The "world" is cruel and heartless. In classes, they are likely to fail, or to get really poor grades.
The third group, the sailors, are the "in-betweeners". They are looking to survive rather than to prosper. They try to guide their small boats, but often wish someone else was in charge, and sometimes aren't very diligent. Often they are looking for help. Sometimes they can get it, from family and friends and acquaintances (and teachers), sometimes not. In the end, in a class, you have to do it yourself, and sometimes they're up to it, sometimes not.
In classes they sometimes do what they need to do, sometimes not. They are often content with a C grade, or maybe a B. Their responses to the two questions are often in the middle, of course. They may learn better habits and become captains, or they may fall into the castaway category, or they may muddle along as sailors.
In a community college class you'll find a big proportion of sailors, quite a few castaways, and a variable number of captains. At Duke or UNC-CH you'll find a great many captains and few castaways, but still a goodly proportion of sailors. Many of the sailors will soon become captains, however.
Unfortunately, most K12 education is now designed to produce castaways far more often than captains. People are often told exactly what to memorize for the "end of class" test, regurgitate it, and go on to the next year, without having learned much, certainly without having learned good habits. What they do during the year in class doesn't matter much, what matters is the end of class test. Consequently the students are trained rather than educated. So in college, especially community college, we get many people who are ill-prepared to succeed in classes (or in life, unfortunately).
Where is the teacher in all this? The teacher is the Admiral, the Convoy Commander in wartime, trying to shepherd their fleet to the proper port(s) through dangerous waters. Unfortunately, the Admiral cannot sail every vessel; and when there's a straggler, the Admiral cannot stop (and endanger) the entire fleet for one member. The Admiral can only provide an example, and lead, and provide assistance when practical, and hope that all will follow.
So I say to students, imagine you are "cast upon the seas of fate". How are you going to react, what are you going to do about it?
Lew Pulsipher
I am a literal-minded person to an extreme, and as a result I am not good at making up analogies: I would rather discuss the reality than some comparison to that reality. However, I've come up with an analogy that might help students and teachers understand what's going on in many classes, so I'll explain it here.
We are all figuratively "cast upon the seas of fate" in a class, or in life as a whole. But we respond to that differently, in ways that are relatively easy to see in a class. Some are captains of sturdy sailing vessels, some are sailors on small boats, and some are castaways on makeshift rafts (or, like a message in a bottle, bobbing along on the waves without direction).
The Captains are guiding their ships, looking for the best winds and currents, keeping a "weather eye" at all times. They intend to do all they can to reach port. Some of the Captains have helpers (significant others, family, friends, mentors) providing support, some are "solo sailors". But all depend on themselves first of all to get where they need to go.
Their answer to the following two questions is to "disagree". "Luck plays a big part in what happens to me" and "When I'm required to do something (as at work or school) I do just enough to get by." They recognize that much of what happens to them is their doing, not someone else's fault.
Yes, these Captains can be thwarted by the "perfect storm", by circumstances (such as illness) that they truly cannot control. But they're doing their best to avoid those situations.
In terms of students, these are the ones who keep track of when work is due, who actually read textbooks (well, in the current generation, sometimes), who know what "study" means, who are trying to get an "A" rather than a B or C.
At the other extreme are the castaways, or the "message in a bottle", drifting along on the waves, hoping that they'll be carried to a good destination. Like a message in a bottle, they have little influence over where they're going. Like a castaway on a makeshift raft, they might have rigged up a sail, or they might have a paddle, but when things go wrong they often just throw up their hands and say "it's not my fault" instead of doing what they can to guide their fate. These are the folks who tend to blame everything that happens to them on someone or something else. They may indeed have difficult family circumstances, financial problems, and so on, but in the end it is usually a lack of WILL that will do them in.
Their answer to the two questions is to "agree". ("Luck plays a big part in what happens to me" and "When I'm required to do something (as at work or school) I do just enough to get by.") "It's not my fault" is their mantra. They may feel that the world "owes them something", but they find out that in the adult world that isn't true. The "world" is cruel and heartless. In classes, they are likely to fail, or to get really poor grades.
The third group, the sailors, are the "in-betweeners". They are looking to survive rather than to prosper. They try to guide their small boats, but often wish someone else was in charge, and sometimes aren't very diligent. Often they are looking for help. Sometimes they can get it, from family and friends and acquaintances (and teachers), sometimes not. In the end, in a class, you have to do it yourself, and sometimes they're up to it, sometimes not.
In classes they sometimes do what they need to do, sometimes not. They are often content with a C grade, or maybe a B. Their responses to the two questions are often in the middle, of course. They may learn better habits and become captains, or they may fall into the castaway category, or they may muddle along as sailors.
In a community college class you'll find a big proportion of sailors, quite a few castaways, and a variable number of captains. At Duke or UNC-CH you'll find a great many captains and few castaways, but still a goodly proportion of sailors. Many of the sailors will soon become captains, however.
Unfortunately, most K12 education is now designed to produce castaways far more often than captains. People are often told exactly what to memorize for the "end of class" test, regurgitate it, and go on to the next year, without having learned much, certainly without having learned good habits. What they do during the year in class doesn't matter much, what matters is the end of class test. Consequently the students are trained rather than educated. So in college, especially community college, we get many people who are ill-prepared to succeed in classes (or in life, unfortunately).
Where is the teacher in all this? The teacher is the Admiral, the Convoy Commander in wartime, trying to shepherd their fleet to the proper port(s) through dangerous waters. Unfortunately, the Admiral cannot sail every vessel; and when there's a straggler, the Admiral cannot stop (and endanger) the entire fleet for one member. The Admiral can only provide an example, and lead, and provide assistance when practical, and hope that all will follow.
So I say to students, imagine you are "cast upon the seas of fate". How are you going to react, what are you going to do about it?
Lew Pulsipher
Saturday, October 13, 2007
Inefficiency of big teams
Tyler Bello sent the following comment on size of games directly to me:
"I noticed your blog post's about team size/development time and wanted to add something. The business world ticks very slowly, this applies to big game studios. If you compare indy projects to big projects of the same caliber (regardless of sales/studio etc.) you will notice that the indy titles develop 10x faster than the ones from the big studios and with much smaller teams (or, at the same pace, with much smaller teams).
The first example that comes to mind is Project Offset. In only 1.5 years a team of 3 (1 programmer 2 artists) created an incredible engine. I would attribute this to the efficiency of small teams, the bigger the motor the less efficient it is with gas usage.
You can view the video under the downloads tab.
http://www.projectoffset.com/team.html
Another very small team company , whose games happen to sell wildly, is Introversion (Uplink 1 programmer, Darwinia/Defcon 2 programmers). They started with Uplink, which recieved mild sales but much praise. They then moved on to Darwinia which was a smash hit and now Defcon which went straight to Steam and is also very popular.
Minuscule teams can still make games that are just as good/beautiful/whatever as the big dudes, it's just not as common.
I just don't think that teams should be as big as they are and games don't have to take as long as they do to make. The process is drawn out by bureaucracy."
I've seen a few magazine ads for Darwinia, but of about 40 students I asked, only one had played Darwinia, and that only a demo (verdict: not so good). Evidently it isn't quite in the same category as Oblivion, Halo 3, Rainbow 6, and other very well-known games.
When a big publisher plans to publish a major game, they intend to spend a large sum on marketing. Introversion, as a smaller publisher selling games in less-than-top outlets, may not need to spend that kind of money.
Whenever large sums are at risk, companies will want to manage that risk, and monitor it. Managing risk is very important: if your project depends on very few people, then the risk that one or more of them will quit, or become incapacitated, or simply not be up to the task, is very significant. There's every incentive to spread the risk amongst more people, hence a larger group. There's also the notion that more people will finish faster, though this is sometimes regarded as a fallacy where programming is involved, generating a classic book (which I have not read, I must say) called The Mythical Man-Month. http://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959/ref=pd_bbs_sr_1/105-2718850-6987636?ie=UTF8&s=books&qid=1192314711&sr=8-1
Further, there will be more people whose job is to monitor and coordinate, because there are more programmers.
I have a saying: "The level of chaos increases with the square of the number of people involved. The level of chaos increases with the CUBE of the number of people IN CHARGE." And more chaos means less efficiency.
I'm also guessing that Introversion self-financed their games, that is, made the prototype and then found a publisher. If so, then Introversion assumed much of the risk, and could choose to risk depending on one or two programmers.
We need to remember also that in the "beautiful" games, there are many more artists than programmers involved.
"I noticed your blog post's about team size/development time and wanted to add something. The business world ticks very slowly, this applies to big game studios. If you compare indy projects to big projects of the same caliber (regardless of sales/studio etc.) you will notice that the indy titles develop 10x faster than the ones from the big studios and with much smaller teams (or, at the same pace, with much smaller teams).
The first example that comes to mind is Project Offset. In only 1.5 years a team of 3 (1 programmer 2 artists) created an incredible engine. I would attribute this to the efficiency of small teams, the bigger the motor the less efficient it is with gas usage.
You can view the video under the downloads tab.
http://www.projectoffset.com/team.html
Another very small team company , whose games happen to sell wildly, is Introversion (Uplink 1 programmer, Darwinia/Defcon 2 programmers). They started with Uplink, which recieved mild sales but much praise. They then moved on to Darwinia which was a smash hit and now Defcon which went straight to Steam and is also very popular.
Minuscule teams can still make games that are just as good/beautiful/whatever as the big dudes, it's just not as common.
I just don't think that teams should be as big as they are and games don't have to take as long as they do to make. The process is drawn out by bureaucracy."
I've seen a few magazine ads for Darwinia, but of about 40 students I asked, only one had played Darwinia, and that only a demo (verdict: not so good). Evidently it isn't quite in the same category as Oblivion, Halo 3, Rainbow 6, and other very well-known games.
When a big publisher plans to publish a major game, they intend to spend a large sum on marketing. Introversion, as a smaller publisher selling games in less-than-top outlets, may not need to spend that kind of money.
Whenever large sums are at risk, companies will want to manage that risk, and monitor it. Managing risk is very important: if your project depends on very few people, then the risk that one or more of them will quit, or become incapacitated, or simply not be up to the task, is very significant. There's every incentive to spread the risk amongst more people, hence a larger group. There's also the notion that more people will finish faster, though this is sometimes regarded as a fallacy where programming is involved, generating a classic book (which I have not read, I must say) called The Mythical Man-Month. http://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959/ref=pd_bbs_sr_1/105-2718850-6987636?ie=UTF8&s=books&qid=1192314711&sr=8-1
Further, there will be more people whose job is to monitor and coordinate, because there are more programmers.
I have a saying: "The level of chaos increases with the square of the number of people involved. The level of chaos increases with the CUBE of the number of people IN CHARGE." And more chaos means less efficiency.
I'm also guessing that Introversion self-financed their games, that is, made the prototype and then found a publisher. If so, then Introversion assumed much of the risk, and could choose to risk depending on one or two programmers.
We need to remember also that in the "beautiful" games, there are many more artists than programmers involved.
"You can lead a horse to water, but you can't make it drink."
The title above is an old saying that I'm reminded of this time of year, as some students are now stumbling toward either dropping out or flunking. Sometimes the problems are practical (finances, transportation), sometimes they come from being in too many classes (which can be solved by dropping out of one or more), but often they occur because the student is his or her own worst enemy. That is, the student has the brains and sufficient time (if managed properly) to succeed, but not the WILL.
One of the most disappointing things that can happen to a teacher is to lose students. However, a teacher can only provide suitable conditions for learning; no one can "make" someone learn in a democratic free society. So the teacher leads the student to the possibility of learning, but if the student won't do it, it won't happen.
Sometimes students just disappear, and sometimes I can see what's coming but no amount of talking or helping can make enough difference. The teacher cannot do the work for the student. Some of the students who lack the will come up with myriad excuses why they cannot do what they need to do, others just... don't do it.
In general there are three groups of students: those who do the required outside-of-class work on time, and usually do it well; those who don't do any required work, which almost guarantees failure; and a third in-between group, who may do some things and not others.
Roughly speaking, the first group also shows up to every class, the second group misses many classes, and the third in-between group is unpredictable in their attendance. (Remember, attendance is generally the best predictor of success in college classes.)
One of the most disappointing things that can happen to a teacher is to lose students. However, a teacher can only provide suitable conditions for learning; no one can "make" someone learn in a democratic free society. So the teacher leads the student to the possibility of learning, but if the student won't do it, it won't happen.
Sometimes students just disappear, and sometimes I can see what's coming but no amount of talking or helping can make enough difference. The teacher cannot do the work for the student. Some of the students who lack the will come up with myriad excuses why they cannot do what they need to do, others just... don't do it.
In general there are three groups of students: those who do the required outside-of-class work on time, and usually do it well; those who don't do any required work, which almost guarantees failure; and a third in-between group, who may do some things and not others.
Roughly speaking, the first group also shows up to every class, the second group misses many classes, and the third in-between group is unpredictable in their attendance. (Remember, attendance is generally the best predictor of success in college classes.)
Saturday, October 6, 2007
My "Advice about taking a test"
The following is advice I give to students. It encapsulates my philosophy about test-creation almost as much as about test-taking, so I'm including it here.
Advice About Taking a Test
L. Pulsipher
I am NOT trying to trick you with questions. Trick questions are pointless and serve no purpose. Poorly worded questions can always appear to be tricky, but I try hard to avoid that.
Answer the question. Simple advice, but sometimes people talk about this and that but not about the question! Some teachers tell people, “if you don’t know the answer, talk about something that’s close to the topic, and if you’re right I’ll give you some credit.” Not here. If you have a problem to solve at work and you know the solution to some other problem, it doesn’t help, does it? Nor will it on a test. Having said that, I’m infamous for giving half and even quarter credit for an answer.
If the question includes a comparison or contrast between two things, be sure to address both of them in your answer--don’t discuss one and assume we all know about the other, because the test grader can’t assume that.
Don’t beg the question--that is, don’t give as an answer a reworded version of the question. For example, if you’re asked why such-and-such is true, don’t answer that such-and-such is true (even using different wording): say WHY.
In most cases (other than multiple choice and true-false) use complete sentences, or at least complete phrases. On the other hand, if the question specifically asks you just to name three of something, listing those three will be good enough.
Finally, always remember that as I grade test I have no idea who is giving the answers. I may know, from talking with you, that you know such-and-such, but if it isn’t on paper (or in the computer), it doesn’t count.
Advice About Taking a Test
L. Pulsipher
I am NOT trying to trick you with questions. Trick questions are pointless and serve no purpose. Poorly worded questions can always appear to be tricky, but I try hard to avoid that.
Answer the question. Simple advice, but sometimes people talk about this and that but not about the question! Some teachers tell people, “if you don’t know the answer, talk about something that’s close to the topic, and if you’re right I’ll give you some credit.” Not here. If you have a problem to solve at work and you know the solution to some other problem, it doesn’t help, does it? Nor will it on a test. Having said that, I’m infamous for giving half and even quarter credit for an answer.
If the question includes a comparison or contrast between two things, be sure to address both of them in your answer--don’t discuss one and assume we all know about the other, because the test grader can’t assume that.
Don’t beg the question--that is, don’t give as an answer a reworded version of the question. For example, if you’re asked why such-and-such is true, don’t answer that such-and-such is true (even using different wording): say WHY.
In most cases (other than multiple choice and true-false) use complete sentences, or at least complete phrases. On the other hand, if the question specifically asks you just to name three of something, listing those three will be good enough.
Finally, always remember that as I grade test I have no idea who is giving the answers. I may know, from talking with you, that you know such-and-such, but if it isn’t on paper (or in the computer), it doesn’t count.
Thursday, October 4, 2007
Even little games take a lot of work
I've just read an article in PC Gamer that cites six months and six people to program a cell phone game, Orks & Elves 2, with a little help from famous game programmer John Carmack. They were limited to 300K (not M or G), though I'm not sure whether that was storage space or RAM.
Modern video games are incredibly large
A recent GameInformer magazine described the budget and related parameters for an "A list" console game (I cannot recall which game or platform.)
Budget:
10% marketing
8% testing
15% design
20% art
30% programming
etc.
(Sorry, it was a student's copy of the magazine, I didn't write it down at the time, and I could not access it online--so this is from memory.)
There were 1,767,000 line of code in the game. Let's get a handle on this. A single-spaced normal page has 54 lines of text. Let's round that down to 50 because some program lines will be longer than the width of the page. 100,000 lines, then, is 2,000 pages of text. A million lines is 20,000 pages.
So let's try a million lines. How long would it take a typist, typing 50 words a minute, to type 20,000 pages of text? A line is about 13 words. Let's call it 10 to account for short lines. Then each page would be 500 words, or 10 minutes. 20,000 pages is 200,000 minutes. That is 139 days of typing 24 hours a day.
Actually, 50 words a minute is optimistic; code is much harder to type than normal text, and must be completely without typos or it will not work.
Now consider that this code must actually be written (created) and tested, which takes immensely longer than mere typing. Nor can we have people working nonstop for 139 days. And this is only just more than half the entire game program, since we did only a million lines.
Now add in the time for creating the artwork. Generally, at least twice as many people work on art as on programming.
So now we've covered just half the budget!
In contrast, we have three hours of lab a week, times 16 weeks, or 48 hours (really less than that considering breaks). So what are the chances that we, in a one semester class, can even scratch the surface of creating an A-list video game? Nil, nought, nada, infinitesimal: none.
The days when one person could create a well-known video game ended around 1990. And even then, that person took much longer than both our game design classes combined, in an era when graphics were primitive and everything was much simpler.
There's a saying, "you can't get together nine newly-pregnant women and have a baby in a month." In other words, some things just take a long time, no matter how badly you want them to happen faster.
This is why I tell people, if you want to learn to create good games, you need to use non-video games, where you can get to a playable prototype in a short time, not in "forever". Until you have a playable prototype, you haven't done even 20% of the work.
Be sure to read Ian's comment to this post, as he has the full figures and makes an interesting comparison to numbers of semesters of work involved.
A related post explores the percentages of work done.
October 26: I have worked on this further and made a set of slides (a rarity). The file is linked here.
Budget:
10% marketing
8% testing
15% design
20% art
30% programming
etc.
(Sorry, it was a student's copy of the magazine, I didn't write it down at the time, and I could not access it online--so this is from memory.)
There were 1,767,000 line of code in the game. Let's get a handle on this. A single-spaced normal page has 54 lines of text. Let's round that down to 50 because some program lines will be longer than the width of the page. 100,000 lines, then, is 2,000 pages of text. A million lines is 20,000 pages.
So let's try a million lines. How long would it take a typist, typing 50 words a minute, to type 20,000 pages of text? A line is about 13 words. Let's call it 10 to account for short lines. Then each page would be 500 words, or 10 minutes. 20,000 pages is 200,000 minutes. That is 139 days of typing 24 hours a day.
Actually, 50 words a minute is optimistic; code is much harder to type than normal text, and must be completely without typos or it will not work.
Now consider that this code must actually be written (created) and tested, which takes immensely longer than mere typing. Nor can we have people working nonstop for 139 days. And this is only just more than half the entire game program, since we did only a million lines.
Now add in the time for creating the artwork. Generally, at least twice as many people work on art as on programming.
So now we've covered just half the budget!
In contrast, we have three hours of lab a week, times 16 weeks, or 48 hours (really less than that considering breaks). So what are the chances that we, in a one semester class, can even scratch the surface of creating an A-list video game? Nil, nought, nada, infinitesimal: none.
The days when one person could create a well-known video game ended around 1990. And even then, that person took much longer than both our game design classes combined, in an era when graphics were primitive and everything was much simpler.
There's a saying, "you can't get together nine newly-pregnant women and have a baby in a month." In other words, some things just take a long time, no matter how badly you want them to happen faster.
This is why I tell people, if you want to learn to create good games, you need to use non-video games, where you can get to a playable prototype in a short time, not in "forever". Until you have a playable prototype, you haven't done even 20% of the work.
Be sure to read Ian's comment to this post, as he has the full figures and makes an interesting comparison to numbers of semesters of work involved.
A related post explores the percentages of work done.
October 26: I have worked on this further and made a set of slides (a rarity). The file is linked here.
Percentage of time spent on various stages of a game
In a non-electronic game, the time spent by the designer and developer (this is sometimes two different people) is approximately:
10-15% Design
10-15% Prototype production and initial testing to arrive at a full set of rules that works. Most of this time is spent on the rules, not the physical prototype
75% Development: playtesting and revision
For an electronic game the percentages are different. I confess for electronic games I am "pulling these out of the air", they are estimates, and undoubtedly will vary greatly from one company to another.
10-15% Design
60% Production of a developmental prototype (this is very time-consuming)
15-20% Playtesting and revision of that prototype
10% Testing for programming bugs
This is "actual", not desirable. Blizzard works with no deadlines because they can easily self-fund projects. They can say "the game will be released when it is done". Most likely they spend more time on a game than the typical development studio, and a lot of that additional time is spent on playtesting and revision of the prototype. So their percentages would be different. This is the way the game ought to be made, but few companies have the track record of success and constant influx of royalties that Blizzard enjoys, so they can't afford to do it that way. This helps explain why so many newly-released games are seriously buggy.
We have to be careful about the word "prototype". Electronic game prototypes are often very limited versions of a game produced to get some idea of what it will actually be like, and are part of the design process; they are then discarded and work begins on the actual game, which ultimately arrives at a "developmental prototype" that can be turned into the game that will be sold.
10-15% Design
10-15% Prototype production and initial testing to arrive at a full set of rules that works. Most of this time is spent on the rules, not the physical prototype
75% Development: playtesting and revision
For an electronic game the percentages are different. I confess for electronic games I am "pulling these out of the air", they are estimates, and undoubtedly will vary greatly from one company to another.
10-15% Design
60% Production of a developmental prototype (this is very time-consuming)
15-20% Playtesting and revision of that prototype
10% Testing for programming bugs
This is "actual", not desirable. Blizzard works with no deadlines because they can easily self-fund projects. They can say "the game will be released when it is done". Most likely they spend more time on a game than the typical development studio, and a lot of that additional time is spent on playtesting and revision of the prototype. So their percentages would be different. This is the way the game ought to be made, but few companies have the track record of success and constant influx of royalties that Blizzard enjoys, so they can't afford to do it that way. This helps explain why so many newly-released games are seriously buggy.
We have to be careful about the word "prototype". Electronic game prototypes are often very limited versions of a game produced to get some idea of what it will actually be like, and are part of the design process; they are then discarded and work begins on the actual game, which ultimately arrives at a "developmental prototype" that can be turned into the game that will be sold.
Subscribe to:
Posts (Atom)
