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
Saturday, October 20, 2007
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)
"Always do right--this will gratify some and astonish the rest."Mark Twain
"A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." Antoine de Saint-Exup'ery
"Not everything that can be counted counts, and not everything that counts can be counted." Albert Einstein
"Make everything as simple as possible, but not simpler." Albert Einstein