Principles of Game Dev Management
by Bryan Edds · in General Discussion · 10/09/2003 (9:47 pm) · 36 replies
I'm attempting to hammer out some general principles for managing the development of a game (in my case, online). Here's one issue that I'm currently dealing with, and what I believe is the correct principle at this point.
I'm starting to come of the mind that the game designer's most important trait is that of being an absolute minimalist. He must minimize the decisions he makes about art, about story, and about the actual engineering. He must also design a game with the least gameplay features possible to fulfill the design goal - any extra gameplay features will naturally come into existence in the iterative process if there is time. The game designer's only role is to design a fun core play engine - and leave everything else to everyone else. Of course, on a small team such as mine, the game designer must wear more than one hat - in this case, I am the game designer, programmer and system designer, director, and an artist for the minimal amount of art needed for a demo to attract artists to work on my game. But the point is to minimalize each developer's scope of responsibilities as much as possible in order to give each developer as much freedom as possible to create and fulfill their vision within their own scope of responsibility. I think this is especially true of the game designer since he has the greatest tendency to usurp creativity and micromanage since he is usually at the top of the dev hierarchy. Has anyone else found this to ring true, or otherwise false?
I'm starting to come of the mind that the game designer's most important trait is that of being an absolute minimalist. He must minimize the decisions he makes about art, about story, and about the actual engineering. He must also design a game with the least gameplay features possible to fulfill the design goal - any extra gameplay features will naturally come into existence in the iterative process if there is time. The game designer's only role is to design a fun core play engine - and leave everything else to everyone else. Of course, on a small team such as mine, the game designer must wear more than one hat - in this case, I am the game designer, programmer and system designer, director, and an artist for the minimal amount of art needed for a demo to attract artists to work on my game. But the point is to minimalize each developer's scope of responsibilities as much as possible in order to give each developer as much freedom as possible to create and fulfill their vision within their own scope of responsibility. I think this is especially true of the game designer since he has the greatest tendency to usurp creativity and micromanage since he is usually at the top of the dev hierarchy. Has anyone else found this to ring true, or otherwise false?
#22
@ Keith Weatherby II - you are right that I could avoid compensating people if they fail to see the project through, but I don't see this as fair. Sometimes, there are very valid reasons to quit, and not all potential hirees can stick with a long project. So, not compensating those who do not see the project all the way through is, IMO, bad in 2 ways - 1) it seems only fair to compensate one's contributors no matter how little work is done (as long as SOME usable work is done) and 2) this discourages people from helping me if they know that they may not be able to stay on until the end. And since many projects get extended beyond their projected time, some people may have to quit because they were only able to work for the projected period of time. Also, punishing people for not seeing the project through may encourage people to stay on, but I don't believe that doing so is necessary to keep people interested. People know that if the project doesn't get finished, they won't see ANY money since the game won't get published. This, I think, is reason enough for people to do their best to contribute as much as they personally can in order to see the project through.
Well, with iterative development, one does not try to predict any gameplay features before development other than the core gameplay concept / intent. I think that trying to predict all gameplay features is against the iterative way. Trying to predict such things, which to me seems impossible) would fall more under the style of waterfall development. With iterative development, you only make one feature addition at a time (if you have time). And since you have no idea whether you'll have time to do any additional features beyond the current one, you must choose to develop only the most "fun", effective feature. In other words, treat each gameplay feature as your last - because it may be all you have time for. That decision to include a certain feature over all others is the only decision you can anticipate because you have no idea whether you'll have enough time to include yet another feature. With fault-tolerant development (I love that!), you can't theoretically make these sort of predictions - so you don't really try :)
Now, the exception is when you need to develop multiple features at a time because they all depend on one another AND there is no way to decouple them. In this case, you develop the desired coupled features all at once, and hope that you are able to get them all done and get them all to work before you run out of time. If you do not successfully implement the desired coupled features before the project time is over, you must either extend the project dev time, or drop the unfinished coupled features since the addition is broken in its incomplete form. Since developing 2 coupled features theoretically takes twice as much time as developing one stand-alone feature, you can see how developing coupled features can present a greater risk of not getting finished or prolonging the project. Of course, not all features take the same amount of time to develop, and that adds some variance in you decision of what feature to include next. And, if you are running out of time in your project, you may have to develop the easiest-to-implement feature instead of the most fun-to-play one in order to to stay on schedule. Actually, there's a lot of variance in that decision, but the important point is to know that you can only make one feature addition decision at a time - and you should treat it as your last.
10/13/2003 (8:04 am)
Thanks for all of your great insight, everyone!@ Keith Weatherby II - you are right that I could avoid compensating people if they fail to see the project through, but I don't see this as fair. Sometimes, there are very valid reasons to quit, and not all potential hirees can stick with a long project. So, not compensating those who do not see the project all the way through is, IMO, bad in 2 ways - 1) it seems only fair to compensate one's contributors no matter how little work is done (as long as SOME usable work is done) and 2) this discourages people from helping me if they know that they may not be able to stay on until the end. And since many projects get extended beyond their projected time, some people may have to quit because they were only able to work for the projected period of time. Also, punishing people for not seeing the project through may encourage people to stay on, but I don't believe that doing so is necessary to keep people interested. People know that if the project doesn't get finished, they won't see ANY money since the game won't get published. This, I think, is reason enough for people to do their best to contribute as much as they personally can in order to see the project through.
Quote:Shayne Guiliano said -
But how can you make these analyses before you implement the features? I believe that it is possible to make projections as to what could be detrimental and what is beneficial, but how do you do it without hindsight? Is it possible to predict all divergent effects before the feature is implemented?
Well, with iterative development, one does not try to predict any gameplay features before development other than the core gameplay concept / intent. I think that trying to predict all gameplay features is against the iterative way. Trying to predict such things, which to me seems impossible) would fall more under the style of waterfall development. With iterative development, you only make one feature addition at a time (if you have time). And since you have no idea whether you'll have time to do any additional features beyond the current one, you must choose to develop only the most "fun", effective feature. In other words, treat each gameplay feature as your last - because it may be all you have time for. That decision to include a certain feature over all others is the only decision you can anticipate because you have no idea whether you'll have enough time to include yet another feature. With fault-tolerant development (I love that!), you can't theoretically make these sort of predictions - so you don't really try :)
Now, the exception is when you need to develop multiple features at a time because they all depend on one another AND there is no way to decouple them. In this case, you develop the desired coupled features all at once, and hope that you are able to get them all done and get them all to work before you run out of time. If you do not successfully implement the desired coupled features before the project time is over, you must either extend the project dev time, or drop the unfinished coupled features since the addition is broken in its incomplete form. Since developing 2 coupled features theoretically takes twice as much time as developing one stand-alone feature, you can see how developing coupled features can present a greater risk of not getting finished or prolonging the project. Of course, not all features take the same amount of time to develop, and that adds some variance in you decision of what feature to include next. And, if you are running out of time in your project, you may have to develop the easiest-to-implement feature instead of the most fun-to-play one in order to to stay on schedule. Actually, there's a lot of variance in that decision, but the important point is to know that you can only make one feature addition decision at a time - and you should treat it as your last.
#23
And I agree that each developer should minimalize their respective oversight of the game as a whole because they are experts in their one field and shouldnt be concerned with everything else. The designer on the other hand is a broad-view developer and needs to stay that way. The Designer is a jack of all trades and ace of none. He's supposed to know a little bit about everything so he can tell the experts what he expects of them. He has to have a broad view otherwise there is no one keeping the overall vision on track.
10/13/2003 (8:41 am)
I didn't wanna read all the posts, but in regards to the first one: That's called "Feature Creep" or "Scope Creep". If the designer doesn't design every aspect of the game that he wants, then the scope is not clearly defined, and you'll have other developers trying to come up with a cool idea that will "only take a few weeks to put in". But if it doesn't fit the scope, then it may cause the game as a whole to not blend well, and focus on the things that may be more important is lost.And I agree that each developer should minimalize their respective oversight of the game as a whole because they are experts in their one field and shouldnt be concerned with everything else. The designer on the other hand is a broad-view developer and needs to stay that way. The Designer is a jack of all trades and ace of none. He's supposed to know a little bit about everything so he can tell the experts what he expects of them. He has to have a broad view otherwise there is no one keeping the overall vision on track.
#24
IF you are paid a regular salary, then anything you produce during that time period is owned by the company you work for. Normally, this applies even for works produced during non-working hours. So professional devs that are working on an indie game on the side try to keep it pretty quiet.
I actually saw an incident where an artist created artwork for an indie game, and his company SUED for the rights to that content.
As independent developers, I think it is VERY important for everyone to know that they do NOT have to abide by contracts and rules that are the norm for published games. Basically, we can write our own ticket without losing our asses, and without selling our soul. I ALWAYS retain the rights and ownership of the content that I provide. If I produce works for another dev, they are basically licensing the right to use that work and pay me in royalties. They do not have the right to modify that work without my consent, and they cannot create a PART2 without my consent.
Keep in mind, if you are working with devs from outside the US, that their laws and protections may be applicable. So it pays to be well versed and knowledgable about international copyright law.
10/13/2003 (8:45 am)
Regarding copyright, I am pretty well knowledgable about this.IF you are paid a regular salary, then anything you produce during that time period is owned by the company you work for. Normally, this applies even for works produced during non-working hours. So professional devs that are working on an indie game on the side try to keep it pretty quiet.
I actually saw an incident where an artist created artwork for an indie game, and his company SUED for the rights to that content.
As independent developers, I think it is VERY important for everyone to know that they do NOT have to abide by contracts and rules that are the norm for published games. Basically, we can write our own ticket without losing our asses, and without selling our soul. I ALWAYS retain the rights and ownership of the content that I provide. If I produce works for another dev, they are basically licensing the right to use that work and pay me in royalties. They do not have the right to modify that work without my consent, and they cannot create a PART2 without my consent.
Keep in mind, if you are working with devs from outside the US, that their laws and protections may be applicable. So it pays to be well versed and knowledgable about international copyright law.
#25
I also believe that there is a difference between iterative feature dev and feature creep. Iterative feature dev is simply the process of making game features modular (if possible), and implementing as few features as possible at a time. You see, the iterative process does allow you to develop many features at a time if they are dependant on one another, but also allows you to modularize features dev where possible or necessary. Feature creep does not allow multiple features to be developed at the same time, and this is the major thing that separates the two processes in my mind.
10/13/2003 (8:49 am)
@Jeremy - Feature creep can be both good and bad. If the producer decides to let incohesive, out-of-scope, and ill-blended features to be added in, then he'll have bad results. But if he only lets good, cohesive, properly scoped, and well-blended features to added in, then he'll have good results. If the results aren't good, then the testing phase of the iterative process will reveal this, and the feature will be nixed. Feature creep is not necessarily scope creep, IMO. And the success of an added feature comes down to the producer's call. I think one must separate the concept of feature creep from the concept of scope creep in order to see the potential value of the former.I also believe that there is a difference between iterative feature dev and feature creep. Iterative feature dev is simply the process of making game features modular (if possible), and implementing as few features as possible at a time. You see, the iterative process does allow you to develop many features at a time if they are dependant on one another, but also allows you to modularize features dev where possible or necessary. Feature creep does not allow multiple features to be developed at the same time, and this is the major thing that separates the two processes in my mind.
#26
Talk about a contradiction. Anyone have any ideas of how to fix this?
10/13/2003 (9:25 am)
My biggest problem with my current model is that asset prediction is in complete contradiction with the iterative process. One has no idea what the game will turn out to be with iterative dev, but in order to delegate assets by percentages, one has to have a good idea how many of each asset will be used in the game.Talk about a contradiction. Anyone have any ideas of how to fix this?
#27
Explosions are worthless without the graphics, sound and code to back it up. How do you break THAT asset up into its smallest components?
When we hire someone, we describe the scope of the game, the responsibilities of the dev, and how their work is instrumental to the overall gameplay. Based on that, we tell them their percentage of royalites.
No dev on our team makes more than double the lowest paid team member. So if the lowest paid team member recieves 5%, no other dev can make over 10%. We are never at a shortage of bringing people on board, regardless of their massive experience.
10/13/2003 (9:37 am)
We just establish a flat rate to each dev, regardless. Splitting hairs about how many assets and which are the most impoportant is futile. When you start breaking the game into "assets" you are losing focus of the big picture. Gameplay is the single most important aspect, and it is based on the sum of its parts.Explosions are worthless without the graphics, sound and code to back it up. How do you break THAT asset up into its smallest components?
When we hire someone, we describe the scope of the game, the responsibilities of the dev, and how their work is instrumental to the overall gameplay. Based on that, we tell them their percentage of royalites.
No dev on our team makes more than double the lowest paid team member. So if the lowest paid team member recieves 5%, no other dev can make over 10%. We are never at a shortage of bringing people on board, regardless of their massive experience.
#28
What I have seen in practice is that most game development teams are pretty creative people - your artists, sound people, and yes... even your engineers. Most of them are probably doing games because they love games, and feel they could contribute to the creative endeavor. And many of them could be a great designer on their own, but their other skills are in greater demand.
Most game designers (myself included) are not God's gift to gaming. The good ones understand that, and even refer to themselves as "middlemen". The good ones (that I've had the pleasure of getting to know, at least) act as a the "keeper of the vision," soliciting contributions from the group. The trick is that they also act as a filter - working with the producer in making sure the game is released on time and with the appropriate level of quality. So they may discard far more ideas than they integrate.
If they don't do this, in fact, you are going to see your development team grow disgruntled. They realize that instead of being involved in a creative endeavor, they are being treated as assembly workers. This is going to reduce productivity, as they lose their personal investment in the product.
10/13/2003 (10:37 am)
Quote:And I agree that each developer should minimalize their respective oversight of the game as a whole because they are experts in their one field and shouldnt be concerned with everything else.We used to refer to this as the "ivory tower" or "widget factory" approach to game development. It's most often espoused by Miyamoto-wannabe game designers with inflated opinions of their own genius (think John Romero during his rock star days screaming "design is law!"), or guys in suits who want DESPERATELY to believe that the waterfall development model actually works and the creative endeavor of game-building can be reduced to an assembly-line process.
What I have seen in practice is that most game development teams are pretty creative people - your artists, sound people, and yes... even your engineers. Most of them are probably doing games because they love games, and feel they could contribute to the creative endeavor. And many of them could be a great designer on their own, but their other skills are in greater demand.
Most game designers (myself included) are not God's gift to gaming. The good ones understand that, and even refer to themselves as "middlemen". The good ones (that I've had the pleasure of getting to know, at least) act as a the "keeper of the vision," soliciting contributions from the group. The trick is that they also act as a filter - working with the producer in making sure the game is released on time and with the appropriate level of quality. So they may discard far more ideas than they integrate.
If they don't do this, in fact, you are going to see your development team grow disgruntled. They realize that instead of being involved in a creative endeavor, they are being treated as assembly workers. This is going to reduce productivity, as they lose their personal investment in the product.
#29
10/13/2003 (11:01 am)
Kind of an addendum: The gameplay and game design are not atomic elements of the game. It's atomic if there are no other dependencies - and it's pretty obvious that any design you come up with in a computer game are dependent upon software, artwork, sound, testing, etc. in order to be implemented. Because of this, the role of the "designer" in, in my mind, a managerial one, where you are directing the efforts of others to achieve a desired result. These efforts are creative as well as mechanical. A designer who, for example, ignores the suggestion of his testers because they disagree with his Magnum Opus design document is crippling the game.
#30
I have seen devs that were overly concerned with everyone else' job, and started to interfere with the project. A developer that I will call "Gaymax" suddenly decided that we should abort our current game and work on something more simplistic like "3D Teris". I am not lying. He even went so far as to contact the rest of the team to project his "new idea".
Luckily, everyone else ignored him. After a few threats to fire him if his disruptive behavior continued, I finally shitcanned him. This was the guy that was hired as a texture artist, but he suddenly decided that he didn't like the in-game music that our brilliant audio technician created, so "Gaymax" decided to submit his own techno-crap. When the audio technician and I both contacted him to tell him the music would not be used, he persisted by contacting the coder and the marketing person to state his case.
When that wasn't enough, he submitted several models, which were unusable because he has no idea what the hell he was doing. "Whats UVW?" "Whats LOD?" So during the week he spent producing these crap-models, he produced ZERO textures, a resource that we needed immediately.
When he decided to start messing with the coder to introduce "brilliant new features", that was the last straw.
While suggestions and ideas are appreciated, there comes a time when it must be stopped, especially when they start overriding another persons position, and become inneffective in their own position.
10/13/2003 (11:08 am)
I think that quote was a bit broad. Nobody can expect you to create a game component, without a basic understanding of how that is integrated, and the fundamental concept behind it. I don't think that was the intent of the quote.I have seen devs that were overly concerned with everyone else' job, and started to interfere with the project. A developer that I will call "Gaymax" suddenly decided that we should abort our current game and work on something more simplistic like "3D Teris". I am not lying. He even went so far as to contact the rest of the team to project his "new idea".
Luckily, everyone else ignored him. After a few threats to fire him if his disruptive behavior continued, I finally shitcanned him. This was the guy that was hired as a texture artist, but he suddenly decided that he didn't like the in-game music that our brilliant audio technician created, so "Gaymax" decided to submit his own techno-crap. When the audio technician and I both contacted him to tell him the music would not be used, he persisted by contacting the coder and the marketing person to state his case.
When that wasn't enough, he submitted several models, which were unusable because he has no idea what the hell he was doing. "Whats UVW?" "Whats LOD?" So during the week he spent producing these crap-models, he produced ZERO textures, a resource that we needed immediately.
When he decided to start messing with the coder to introduce "brilliant new features", that was the last straw.
While suggestions and ideas are appreciated, there comes a time when it must be stopped, especially when they start overriding another persons position, and become inneffective in their own position.
#31
Thus my contention that a designer is a role akin to a creative manager. Which I guess is something akin to what Bryan has been talking about here.
Case in point: We had an artist / modeler who was something of a loose cannon. He was a little hard to keep on-task as a manager. However, if you have him some room to run, he could come up with some AMAZING stuff that would take a player's breath away. And he'd challenge the designers and programmers to punch up their work a notch. Now, you do NOT want a guy like that to get out of control - he'll be your feature-creep demon and he'll possibly water down your game with features that don't match the core vision. However, he can also help you punch up your game to be all it can be.
While he was an extreme example, I think what applies to him can apply to everyone else on your team. Ultimately, the designer and producer have to keep in close communication, and evaluate proposals in a "bang-for-the-buck" fashion. Will the three days' delay that this additional feature cost you pay for itself in the long run? Will it save time in other development areas (I love it when the answer is affirmative to this one)? Will it give your game the graphical punch or gameplay depth that will generate more sales or more interest in your company's full product line? Is the individual responsible for this feature addition have a few spare cycles to spend on it, or is he in the critical path with other people waiting on him to finish his current tasks? If the latter, can we delay the binding on this decision until later when we have a clearer measure of the schedule? Does this feature require support from the other developers?
10/13/2003 (12:52 pm)
Agreed. Complete anarchy can be worse than tyranny. I certainly wouldn't take things to that extreme. Although it sounds like you were suffering more from someone with a complete lack of professionalism rather than anything else.Thus my contention that a designer is a role akin to a creative manager. Which I guess is something akin to what Bryan has been talking about here.
Case in point: We had an artist / modeler who was something of a loose cannon. He was a little hard to keep on-task as a manager. However, if you have him some room to run, he could come up with some AMAZING stuff that would take a player's breath away. And he'd challenge the designers and programmers to punch up their work a notch. Now, you do NOT want a guy like that to get out of control - he'll be your feature-creep demon and he'll possibly water down your game with features that don't match the core vision. However, he can also help you punch up your game to be all it can be.
While he was an extreme example, I think what applies to him can apply to everyone else on your team. Ultimately, the designer and producer have to keep in close communication, and evaluate proposals in a "bang-for-the-buck" fashion. Will the three days' delay that this additional feature cost you pay for itself in the long run? Will it save time in other development areas (I love it when the answer is affirmative to this one)? Will it give your game the graphical punch or gameplay depth that will generate more sales or more interest in your company's full product line? Is the individual responsible for this feature addition have a few spare cycles to spend on it, or is he in the critical path with other people waiting on him to finish his current tasks? If the latter, can we delay the binding on this decision until later when we have a clearer measure of the schedule? Does this feature require support from the other developers?
#32
It's a common misunderstanding to say that Designers think of themselves as "Godly". I'm from a programming background that has an interest in professional Design. People may all the sudden think that a Jack of all Trades is better than an Ace of One, but the fact of the matter is that both are good and both are necessary for their own purposes. I know there are a lot of engineers and artists out there that would argue that a Designer has no true purpose to game development and that because game development is a creative venture it should be left to creative people, but if you have all these people spouting their ideas, the game isn't being made. You need one person with the game vision that guides everyone else with a solid design. As soon as you just say to a group of artists and engineers "Make me a game about fishing and you got 2 years". You will have the most ad hoc and hectic work environment ever. There needs to be someone who holds the vision. This isn't to say that ideas shouldn't be allowed, ideas should be openly welcomed, but they should also be compared to the vision otherwise you will have features that dont match the rest of the game.
10/13/2003 (7:28 pm)
@JayIt's a common misunderstanding to say that Designers think of themselves as "Godly". I'm from a programming background that has an interest in professional Design. People may all the sudden think that a Jack of all Trades is better than an Ace of One, but the fact of the matter is that both are good and both are necessary for their own purposes. I know there are a lot of engineers and artists out there that would argue that a Designer has no true purpose to game development and that because game development is a creative venture it should be left to creative people, but if you have all these people spouting their ideas, the game isn't being made. You need one person with the game vision that guides everyone else with a solid design. As soon as you just say to a group of artists and engineers "Make me a game about fishing and you got 2 years". You will have the most ad hoc and hectic work environment ever. There needs to be someone who holds the vision. This isn't to say that ideas shouldn't be allowed, ideas should be openly welcomed, but they should also be compared to the vision otherwise you will have features that dont match the rest of the game.
#33
Early failure, yet another great feature of fault-tolerant development :)
So now, I've got to think of something else to resolve the problems of normal indie development. Failing that, I would have to recognize that there is no way to solve our current problems and find a way to live with them. Wish me luck! :)
10/13/2003 (8:49 pm)
Yeah, I've come to the conclusion that assets for % of profits is an unworkable idea. This is mainly because predicting assets is impossible in non-waterfall development methods... It sucks to realize it, but it would be even worse to have tried it and failed.Early failure, yet another great feature of fault-tolerant development :)
So now, I've got to think of something else to resolve the problems of normal indie development. Failing that, I would have to recognize that there is no way to solve our current problems and find a way to live with them. Wish me luck! :)
#34
10/13/2003 (9:19 pm)
Quote:There needs to be someone who holds the vision. This isn't to say that ideas shouldn't be allowed, ideas should be openly welcomed, but they should also be compared to the vision otherwise you will have features that dont match the rest of the game.That's pretty much what I was saying. What I was arguing against was the concept that one designer does game design from his ivory tower, and that everyone else stays out of it.
#35
10/13/2003 (9:36 pm)
Yeah, I agree. Hideo Kojima is my hero. One thing he does is have every developer write in a book daily any ideas they have for the game, and he collects them all at the end of the day, reviews them, and writes comments on all of them and gives them back the next morning. My bad Jay, I misunderstood you.
#36
* The Designer provides concept leadership
* The designer should encourage the rest of the team members to contribute supporting details
* HOWEVER, the designer should set aside "concept-breaker" ideas. (In other words, he acts as the creative "filter" for ideas)
* The designer should promote expertise professionalism (Don't let the programmers tell the artists how to do their jobs, etc.)
* Much of the time, the designer is a glorified data-entry clerk.
Some other suggestions:
* The designer controls the design through the design document.
* The design doc should document all tasks.
* The design document does not necessarily contain all details. It is NOT a substitute for interpersonal interaction. In fact, it should promote consultation between the developers and designers.
(I vaguely remember - though maybe I only imagined it - him mentioning even including the text, "Talk to the designer for details" inside the document to meet this point).
* The design document must be organized for team convenience.
Anyway, I don't know if these suggestions help at all, but these have helped me through my (probably less-than-competent) game design efforts.
10/13/2003 (9:52 pm)
Appealing to Hal Barwood (who just left LucasArts last week, after years working there) in one of his game design seminars at GDC a few years ago on game design (I DID take notes, and still have 'em handy...) Here's some salient bits I'm trying to decypher from my chicken-scratch:* The Designer provides concept leadership
* The designer should encourage the rest of the team members to contribute supporting details
* HOWEVER, the designer should set aside "concept-breaker" ideas. (In other words, he acts as the creative "filter" for ideas)
* The designer should promote expertise professionalism (Don't let the programmers tell the artists how to do their jobs, etc.)
* Much of the time, the designer is a glorified data-entry clerk.
Some other suggestions:
* The designer controls the design through the design document.
* The design doc should document all tasks.
* The design document does not necessarily contain all details. It is NOT a substitute for interpersonal interaction. In fact, it should promote consultation between the developers and designers.
(I vaguely remember - though maybe I only imagined it - him mentioning even including the text, "Talk to the designer for details" inside the document to meet this point).
* The design document must be organized for team convenience.
Anyway, I don't know if these suggestions help at all, but these have helped me through my (probably less-than-competent) game design efforts.
Torque Owner Randall
If we calculate by hours, we end up with the lopsided logic that the audio technician deserves 1% of the royalties. That is absurd. Just because a songwriter is genius enough to complete his work in a much shorter time period does not mean his work is worth LESS to the overall project.
In the end, its often the sound and music that can break or make the game experience, because THAT is the part of the game that recieves the least attention. Many devs fail to recognise this, and their projects are often lacking.
We can also see that some people are just plain inefficient in their work- suppose a coder keeps "trying new things" in an attempt to bring something groundbreaking to the game realm. Even if they fail, those hours are alloted to experimentation. Experimentation should be explored. However those hours can't be tacked on, especially when they have no bearing on the end result. But if you DON'T add those hours in, there is no incentive to explore. Its a double edged sword, and the whole structure begins to fall apart.
Along with talent, a certain amount of skill is required. So is it better to work with an artist that is extremely talented, but requires a longer lead time to learn the tools and techniques. Or is it better to work with an artist that is extremely skilled in all tools and efficient, but the work is sorta ho-hum. These are opposite ends of the spectrum, and neither fits well into the point system.
Whether its fair or not, the core devs that started the project (normally the first two people to brainstorm) don't get "a fair share of the pot". It just doesn't work out that way. I assume many devs are like me, and they have tossed around a game concept for years (maybe several). Where exactly does this fit into the point system? It doesn't- and our projects are a labour of love.
Although I started our current project, did all the hiring, and continue to act as the project manager AND lead artist, I am not the highest paid member of the team. In fact, I am somewhere in the middle.