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?
#2
About what you said, you have alot of "He", I don't know how many woman we have but lets not lose them.
Apart from that sounds fair enough. But were to draw the line on those topics like "the least gameplay features possible". Much like judging ones self?
10/09/2003 (10:15 pm)
Yeah two threads to me wouldn't work, because it would create confussion about who said what and which thread it was in.About what you said, you have alot of "He", I don't know how many woman we have but lets not lose them.
Apart from that sounds fair enough. But were to draw the line on those topics like "the least gameplay features possible". Much like judging ones self?
#3
This is where the "minimalism" comes into effect. Give the developers a skeleton of an outline, and see how they perceive and execute it. Its quite amazing. Although it may be wildly different than what I anticipated, its refreshing to see (or hear) something so new.
10/09/2003 (10:47 pm)
Well, for me and my previous teams, this is relatively true. I don't have time to micromanage, so I bring people into the team that can take the ball and run. As I respect their expertise, they have the final word on their portion of the project. I can tell you that I have never been disappointed in their performance. Maybe i have just been lucky.This is where the "minimalism" comes into effect. Give the developers a skeleton of an outline, and see how they perceive and execute it. Its quite amazing. Although it may be wildly different than what I anticipated, its refreshing to see (or hear) something so new.
#4
But neither of you may be the best at managing the PROJECT - which is making sure resources get created as they are needed, etc.
As far as the specialization factor --- I dunno. In my experience, the smaller your team, the more you have to wear multiple hats. If everyone's being extremely competent and professional, your job is easy... but even the best of professionals aren't perfect. Your artist has some really cool effects that would be PERFECT for the game, give it the "punch" it really needs... but your programmer doesn't really "get it". Everyone's going to have to learn enough about each other's discipline to at least communicate with each other --- and whoever's wearing the management hat is going to have to be something of a jack-of-all-trades to be able to make sure everyone's happy and isn't stuck waiting on someone else.
Besides, circumstances ALWAYS come up that don't fall into neat categories of discipline. Special effects are a notorious example. These typically require a combination of programming, art, and sound. Who drives this?
I do agree that you want to restrict micromanagement as much as possible - nobody likes to feel that someone is watching over their shoulder as they work (though it's a basic tenet of Extreme Programming... go figger). And especially with games, you really MUST give people their creative freedome --- within reason. That'll often make the difference between a great game and a lackluster one. But this too must be kept in check, or you'll end up with a runaway project that collapses under its own creative weight.
10/09/2003 (11:25 pm)
One thing to bear in mind - the designer isn't necessarily the manager. While this can be the case, managing the game and managing people are often two different things. But if you have a small team of, say, four guys working on several different titles consecutively, there's a good chance that you are going to execute on different people's ideas over time. While today you might be working on your game, six months from now it's going to be your lead artist's chance to be "keeper of the vision".But neither of you may be the best at managing the PROJECT - which is making sure resources get created as they are needed, etc.
As far as the specialization factor --- I dunno. In my experience, the smaller your team, the more you have to wear multiple hats. If everyone's being extremely competent and professional, your job is easy... but even the best of professionals aren't perfect. Your artist has some really cool effects that would be PERFECT for the game, give it the "punch" it really needs... but your programmer doesn't really "get it". Everyone's going to have to learn enough about each other's discipline to at least communicate with each other --- and whoever's wearing the management hat is going to have to be something of a jack-of-all-trades to be able to make sure everyone's happy and isn't stuck waiting on someone else.
Besides, circumstances ALWAYS come up that don't fall into neat categories of discipline. Special effects are a notorious example. These typically require a combination of programming, art, and sound. Who drives this?
I do agree that you want to restrict micromanagement as much as possible - nobody likes to feel that someone is watching over their shoulder as they work (though it's a basic tenet of Extreme Programming... go figger). And especially with games, you really MUST give people their creative freedome --- within reason. That'll often make the difference between a great game and a lackluster one. But this too must be kept in check, or you'll end up with a runaway project that collapses under its own creative weight.
#5
Edward, I use the word "he" when referring to a generic person. This is correct english when referring to an unknown person of an unknown sex. The word "he", like many other words, has multiple meanings - including reference to a generic person. So when I use the word "he" in the context of general reference, it is implicit and correct that I also mean "she" when applicable.
You bring up a good question about limiting one's gameplay features. Where does one draw the line? I believe in limiting the gameplay features to as absolutely few as possible to express the original gameplay intent. Anything else could be considered bloat. Of course, a bit of bloat can be good when it meets 2 requirements - that the gameplay feature bloat is important / necessary for creating variety in gameplay, and is implemented only when the previous game play feature is properly implemented.
Also, I feel you should only add one extra gameplay feature at a time to keep from breaking the design upon its failure. Gameplay bloat must also be done only in the event that there is development time left after the last gameplay feature was implemented. Gameplay bloat must also be modular, and separable from the original gameplay intent and other gameplay features to enable the designer to remove or change it if it turns out unworkable.
So, you must take all your game design ideas (as well as the ones you develop along the way), modularize them into categories of single intent (that is, one cohesive expression of player interaction [AKA gameplay feature]), and implement each feature one at a time in the iterative process.
If you implement, say, 3 features at a time that all rely on each other to work, but one of them fails, then you have failed not once, but thrice! Of course, there can be the case where this is unavoidable, but the point is to minimize this where possible. Decoupling design features is as important as decoupling objects in C++, and done with the same philosophy in mind. It allows you to fail only once at a time, and iterative process allows you to fail early. I guess it could be called a hypothesy of fault-tolerant development :)
Finally, some design intents have contradictory rules, which means that one MUST be chosen over the other unless a compromise can be found. Otherwise, design could be broken. If this occurs, the failure should make itself apparent in the testing phase of the iterative process, so you must remove or modify one of the features to fix the gameplay design.
So, that's what I believe at this point... Any critiques are certainly welcome! :)
10/10/2003 (12:04 pm)
Heh, my internet connection was screwing up, so I accidentally posted twice.Edward, I use the word "he" when referring to a generic person. This is correct english when referring to an unknown person of an unknown sex. The word "he", like many other words, has multiple meanings - including reference to a generic person. So when I use the word "he" in the context of general reference, it is implicit and correct that I also mean "she" when applicable.
You bring up a good question about limiting one's gameplay features. Where does one draw the line? I believe in limiting the gameplay features to as absolutely few as possible to express the original gameplay intent. Anything else could be considered bloat. Of course, a bit of bloat can be good when it meets 2 requirements - that the gameplay feature bloat is important / necessary for creating variety in gameplay, and is implemented only when the previous game play feature is properly implemented.
Also, I feel you should only add one extra gameplay feature at a time to keep from breaking the design upon its failure. Gameplay bloat must also be done only in the event that there is development time left after the last gameplay feature was implemented. Gameplay bloat must also be modular, and separable from the original gameplay intent and other gameplay features to enable the designer to remove or change it if it turns out unworkable.
So, you must take all your game design ideas (as well as the ones you develop along the way), modularize them into categories of single intent (that is, one cohesive expression of player interaction [AKA gameplay feature]), and implement each feature one at a time in the iterative process.
If you implement, say, 3 features at a time that all rely on each other to work, but one of them fails, then you have failed not once, but thrice! Of course, there can be the case where this is unavoidable, but the point is to minimize this where possible. Decoupling design features is as important as decoupling objects in C++, and done with the same philosophy in mind. It allows you to fail only once at a time, and iterative process allows you to fail early. I guess it could be called a hypothesy of fault-tolerant development :)
Finally, some design intents have contradictory rules, which means that one MUST be chosen over the other unless a compromise can be found. Otherwise, design could be broken. If this occurs, the failure should make itself apparent in the testing phase of the iterative process, so you must remove or modify one of the features to fix the gameplay design.
So, that's what I believe at this point... Any critiques are certainly welcome! :)
#6
We've had a similar discussion about Pen & Paper RPGS... Is it better to have a large, complex system that is extremely streamlined and has a great internal consistency and a depth that comes from all the pieces interrelating with each other? Or is it better to have an extremely modular system where you can give or take any of the pieces and they wouldn't be missed by the system (but you can consequently add new pieces without knocking the whole system out of whack)?
My best answer is you need a balance between the two. Go too far in the complex direction, and you end up with a monolithic beast that is difficult to balance, maintain, or expand. Go too far in the modular direction, and you end up with a gameplay that quickly comes up to feeling bland and shallow, where the total is really no more (and often less) than the sum of its parts.
Knowing how to balance the two (and all the other factors of game design) --- that is what makes it art.
10/10/2003 (3:09 pm)
Reminds me of the old RISC vs. CISC discussions.We've had a similar discussion about Pen & Paper RPGS... Is it better to have a large, complex system that is extremely streamlined and has a great internal consistency and a depth that comes from all the pieces interrelating with each other? Or is it better to have an extremely modular system where you can give or take any of the pieces and they wouldn't be missed by the system (but you can consequently add new pieces without knocking the whole system out of whack)?
My best answer is you need a balance between the two. Go too far in the complex direction, and you end up with a monolithic beast that is difficult to balance, maintain, or expand. Go too far in the modular direction, and you end up with a gameplay that quickly comes up to feeling bland and shallow, where the total is really no more (and often less) than the sum of its parts.
Knowing how to balance the two (and all the other factors of game design) --- that is what makes it art.
#7
So how do we define the "balance"? I think we could agree that the balance is found by minimizing feature-coupling where it is not necessary or when it is detrimental, while tolerating feature-coupling cautiously when it is necessary or beneficial.
Good call! :)
10/10/2003 (3:31 pm)
This is true - not all gameplay features can be modularized and decoupled.So how do we define the "balance"? I think we could agree that the balance is found by minimizing feature-coupling where it is not necessary or when it is detrimental, while tolerating feature-coupling cautiously when it is necessary or beneficial.
Good call! :)
#8
Also, should you "hire" more people than you need since the turnover in indie gamedev is so high? Should you keep redundant teammates so that one can continue the work if the other leaves?
Finally, should you have teammates agree to leave their work in your possession if they decide to quit? Could this agreement be abused by the team leader if he wants to force teammates to quit in order to avoid paying them when the game ships?
I bet there's a bunch of little, difficult principles to follow in game dev management... I may be acting insecure, but I would like to be well prepared before asking anyone to join a team.
10/11/2003 (8:22 pm)
Here's a question (or 12) - when do you decide to kick a member off your team? Could you do so democratically, and if so, wouldn't that introduce a lot of politics into the team (ick)? Also, should you "hire" more people than you need since the turnover in indie gamedev is so high? Should you keep redundant teammates so that one can continue the work if the other leaves?
Finally, should you have teammates agree to leave their work in your possession if they decide to quit? Could this agreement be abused by the team leader if he wants to force teammates to quit in order to avoid paying them when the game ships?
I bet there's a bunch of little, difficult principles to follow in game dev management... I may be acting insecure, but I would like to be well prepared before asking anyone to join a team.
#9
I wouldn't bring more people into the project than are necessary- its pointless and would actually introduce MORE problems. If you are insecure with a 4 people on the team, I imagine you would be twice as insecure with 8 people on the team.
When I get rid of a teammember, they are free to take all the work they created. They own it, I don't want it, and I won't use it anyway. (This is actually outlined in the contract) This is very fair and may make you rethink firing a dev, especially if you are very close to launching. Just understand that there will be conflicts occasionally, and not everyone needs to be "best friends"- they only need to be professional and get the work done.
Luckily, I have only had to fire people within a week or two after bringing them onboard, so they really hadn't contributed anything of significance.
10/11/2003 (9:20 pm)
Give the team member a few warnings, and each time, make sure you outline EXACTLY what you expect, and why their behavior is not tolerable. If they can't handle that, shitcan them. Screw the democratics, its far too many politics than are necessary- if you hired, you can fire.I wouldn't bring more people into the project than are necessary- its pointless and would actually introduce MORE problems. If you are insecure with a 4 people on the team, I imagine you would be twice as insecure with 8 people on the team.
When I get rid of a teammember, they are free to take all the work they created. They own it, I don't want it, and I won't use it anyway. (This is actually outlined in the contract) This is very fair and may make you rethink firing a dev, especially if you are very close to launching. Just understand that there will be conflicts occasionally, and not everyone needs to be "best friends"- they only need to be professional and get the work done.
Luckily, I have only had to fire people within a week or two after bringing them onboard, so they really hadn't contributed anything of significance.
#10
Let's say I have a monster designer who has designed 5 or 6 monsters which have been integrated into the game, and are all ready to go. What happens if they just disappear? Must I rip apart the game and find someone to put new monsters in - and surgically reconstruct the whole thing? Sure, modular design could eliminate some of the mess, but once you have a working build, ripping out and replacing big chunks could potentially introduce huge bugs and mutilate program stability. It comes to a point where the project becomes dependant on their work, and the loss of their work could tremendously hurt the entire production. Even worse, what if a progammer quits? I would have to recode all his modules, and all of my code that interact with his will be broken. And worst of all, sometimes people simply evaporate, leaving you with no clue whether they'll ever return - leaving you with no idea whether you can use their work or have to hire someone else to redo it!
But on one hand, it doesn't seem fair to demand ownership of an artist's work if they quit the project or whatever. They certainly deserve compensation for their work even if they quit. Plus, demanding that I get all work regardless gives me too much leverage over the worker. On the other hand, though, I can't just rip out big chunks of work in the case that a person disappears - not knowing if they'll ever return.
Perhaps I should return to the hypothesy of fault-tolerant development (or FTD [hey, I think I coined an acronym - God knows we need another one of those]). How about this for a compromise - the contributor trades each individual asset (say, 1 completed, skinned, animated monster) for a guranteed percentage of the game's profit. This would seem to do 2 things - 1) it allows the contributor to quit the group cleanly if they really must, but also see compensation for the work. Sometimes there ARE good reasons to quit, and that's no reason that the worker should not see compensation. 2) It encourages the worker to be a productive as HE can possibly be - to get his biggest piece of the pie.
So, it's like I'm contracting out each asset in exchange for guaranteed percentage of revenue (with there being no gurantee that there will be any revenue, unfortunately). It sounds like a fair exchange where neither participant has any undue leverage over the other.
This model, though, brings up one more concern - the issue of asset maintenence. The initial exchange (percentage of profit for each asset) is an immediate, one-time transaction. But what happens if there is a problem with the asset after the exchange is made? This problem must be corrected, but since the asset belongs to the producer (AKA manager), the artist has no incentive to fix the problem since it is no longer his property. But, *someone* needs to fix the problem, and the producer must find someone other than himself to do it - preferably the artist who initially made the asset. Thus, someone must be contracted out to "maintain" the asset as well - preferably the person who made it. This maintenence must take on a slightly different transaction process - mainly that the exchange of %profit for "maintenence" cannot be made until the game is published in its final x.x.x version.
So, for every asset, there are 2 exchanges - one for the initial transfer of ownership, and one for the maintenence of the asset until the final version (bug-fixes included).
Anyone see any problems so far?
10/11/2003 (11:04 pm)
I'm not really worried about firing people and losing their work - I am worried about the people who just "disappear" after creating some work for the game. Let's say I have a monster designer who has designed 5 or 6 monsters which have been integrated into the game, and are all ready to go. What happens if they just disappear? Must I rip apart the game and find someone to put new monsters in - and surgically reconstruct the whole thing? Sure, modular design could eliminate some of the mess, but once you have a working build, ripping out and replacing big chunks could potentially introduce huge bugs and mutilate program stability. It comes to a point where the project becomes dependant on their work, and the loss of their work could tremendously hurt the entire production. Even worse, what if a progammer quits? I would have to recode all his modules, and all of my code that interact with his will be broken. And worst of all, sometimes people simply evaporate, leaving you with no clue whether they'll ever return - leaving you with no idea whether you can use their work or have to hire someone else to redo it!
But on one hand, it doesn't seem fair to demand ownership of an artist's work if they quit the project or whatever. They certainly deserve compensation for their work even if they quit. Plus, demanding that I get all work regardless gives me too much leverage over the worker. On the other hand, though, I can't just rip out big chunks of work in the case that a person disappears - not knowing if they'll ever return.
Perhaps I should return to the hypothesy of fault-tolerant development (or FTD [hey, I think I coined an acronym - God knows we need another one of those]). How about this for a compromise - the contributor trades each individual asset (say, 1 completed, skinned, animated monster) for a guranteed percentage of the game's profit. This would seem to do 2 things - 1) it allows the contributor to quit the group cleanly if they really must, but also see compensation for the work. Sometimes there ARE good reasons to quit, and that's no reason that the worker should not see compensation. 2) It encourages the worker to be a productive as HE can possibly be - to get his biggest piece of the pie.
So, it's like I'm contracting out each asset in exchange for guaranteed percentage of revenue (with there being no gurantee that there will be any revenue, unfortunately). It sounds like a fair exchange where neither participant has any undue leverage over the other.
This model, though, brings up one more concern - the issue of asset maintenence. The initial exchange (percentage of profit for each asset) is an immediate, one-time transaction. But what happens if there is a problem with the asset after the exchange is made? This problem must be corrected, but since the asset belongs to the producer (AKA manager), the artist has no incentive to fix the problem since it is no longer his property. But, *someone* needs to fix the problem, and the producer must find someone other than himself to do it - preferably the artist who initially made the asset. Thus, someone must be contracted out to "maintain" the asset as well - preferably the person who made it. This maintenence must take on a slightly different transaction process - mainly that the exchange of %profit for "maintenence" cannot be made until the game is published in its final x.x.x version.
So, for every asset, there are 2 exchanges - one for the initial transfer of ownership, and one for the maintenence of the asset until the final version (bug-fixes included).
Anyone see any problems so far?
#12
The assets do NOT become the property of the producer, but rights to use the asset in the specified game are granted to the producer in exchange for a specified % of the profit. This way, the producer never gets ownership of the work, but retains rights to use it in the specified game. This protects both the artist and the producer.
Does this resolve any problems? Without specific feedback, I am having a hard time resolving your concerns. I feel the contractual model has a lot of promise, but also comes with its own host of problems to deal with. I'll post here as I figure out more things to fix.
10/12/2003 (11:17 am)
Firstly, there are many things I would like to change.The assets do NOT become the property of the producer, but rights to use the asset in the specified game are granted to the producer in exchange for a specified % of the profit. This way, the producer never gets ownership of the work, but retains rights to use it in the specified game. This protects both the artist and the producer.
Does this resolve any problems? Without specific feedback, I am having a hard time resolving your concerns. I feel the contractual model has a lot of promise, but also comes with its own host of problems to deal with. I'll post here as I figure out more things to fix.
#13
It sounds like you are acting more as a people manager than a project manager. I prefer to bring people on board that are self motivated, self managing and respectful. They can be the most brilliant and talented person on the planet, but if they don't have those traits, I don't want them. In fact, I spend very little time analyzing their portfolio.
I can't even begin to imagine the amount of paperwork involved in managing those assets. Who can dictate the value of one model vs. one code feature vs. one song? The amount of time involved has NOTHING to do with anything, so you can't even use that as a base. What you end up doing is gicing certain priority to certain parts. Lets take an explosion for example. The basic parts are the code to render the explosions, the graphics to display the pretty explosion and the accompanying sound effect that rocks the world. Take any one of those parts out, and you have a lackluster explosion, yet none is more important than the other.
Your asset model also dictates that you need a very strict design document to account for everything in advance. Suppose you give 1% per model- you'll quickly run out of percentages when you add in 1% per feature, per song, per... whatever. So maybe you decide .5% per model is adequate- 20 models (which isn't much) is still 10%. keep slicing that pie- I think you'll start getting a headache, much like the one I have right now just thinking about it. Remember, you also have to account for the percentages taken for marketing, selling, etc.
I suspect that you would want to finish this project sometime in the next decade.
I personally would NEVER work based on a scale like that. Its not much of a motivator for me to work-per-component. Basically, I can stop whenever I want and I don't need to see the project through. You are almost guaranteed to have people quit then.
In my projects, each dev owns the specific rights of the work they produced. Why is this so? Because nobody on the team has the financials to purchase the content outright, and the dev is working for royalties, not a salary. I prefer to work this way- I never want a salary. Keep in mind that I am a full-time indie developer for the past 2 years.
The amount of time involved in game production also plays a huge role. the longer the game is in production, the more likely you are going to lose a dev in the process. A lot can change in our lives, in a years time. This is why we need to take time out of our day just to chit-chat. We don't have coffee breaks, we don't have lunch rooms, we don't have a water cooler. So we need to recreate these opportunities for chit-chat in a virtual world. This will help bond the team and develop true friendships, rather than a stagnant work releationship.
What kind of timeline are we talking about here? The longer the game is in development, the more likely serious problems will arise. So its in the best interest of all to keep the timeline as short as possible. This doesn't necessarily meean "add more people to the team", especially if you are already having problems trusting that the team will stick together. This also doesn't mean to "rush a buggy pile of crap" to market, just to get it done.
(continued...)
10/12/2003 (12:43 pm)
Well, it really depends on a couple things.It sounds like you are acting more as a people manager than a project manager. I prefer to bring people on board that are self motivated, self managing and respectful. They can be the most brilliant and talented person on the planet, but if they don't have those traits, I don't want them. In fact, I spend very little time analyzing their portfolio.
I can't even begin to imagine the amount of paperwork involved in managing those assets. Who can dictate the value of one model vs. one code feature vs. one song? The amount of time involved has NOTHING to do with anything, so you can't even use that as a base. What you end up doing is gicing certain priority to certain parts. Lets take an explosion for example. The basic parts are the code to render the explosions, the graphics to display the pretty explosion and the accompanying sound effect that rocks the world. Take any one of those parts out, and you have a lackluster explosion, yet none is more important than the other.
Your asset model also dictates that you need a very strict design document to account for everything in advance. Suppose you give 1% per model- you'll quickly run out of percentages when you add in 1% per feature, per song, per... whatever. So maybe you decide .5% per model is adequate- 20 models (which isn't much) is still 10%. keep slicing that pie- I think you'll start getting a headache, much like the one I have right now just thinking about it. Remember, you also have to account for the percentages taken for marketing, selling, etc.
I suspect that you would want to finish this project sometime in the next decade.
I personally would NEVER work based on a scale like that. Its not much of a motivator for me to work-per-component. Basically, I can stop whenever I want and I don't need to see the project through. You are almost guaranteed to have people quit then.
In my projects, each dev owns the specific rights of the work they produced. Why is this so? Because nobody on the team has the financials to purchase the content outright, and the dev is working for royalties, not a salary. I prefer to work this way- I never want a salary. Keep in mind that I am a full-time indie developer for the past 2 years.
The amount of time involved in game production also plays a huge role. the longer the game is in production, the more likely you are going to lose a dev in the process. A lot can change in our lives, in a years time. This is why we need to take time out of our day just to chit-chat. We don't have coffee breaks, we don't have lunch rooms, we don't have a water cooler. So we need to recreate these opportunities for chit-chat in a virtual world. This will help bond the team and develop true friendships, rather than a stagnant work releationship.
What kind of timeline are we talking about here? The longer the game is in development, the more likely serious problems will arise. So its in the best interest of all to keep the timeline as short as possible. This doesn't necessarily meean "add more people to the team", especially if you are already having problems trusting that the team will stick together. This also doesn't mean to "rush a buggy pile of crap" to market, just to get it done.
(continued...)
#14
It also sounds like your team may be fairly large. I always use 2 designated artists, 1 designated audio technician, and 1 designated coder. I prefer to assign a single person to each department, rather than using the jack-of-all trades to span several departments. I can code, write music, create special effects, and models. Does this mean that I NEED to do all these? Hell no. I much prefer to focus on the artwork and leave those tasks to the specialists (who can probably do the job much better and more efficient than me, at least that is why they were hired)
Keep in mind that everything I displayed here is null and void when applied to an in-house project. It simply doesn't apply, because they are completely different worlds. Some devs can't even function or comprehend a working environment like this. But for us, it has been the one that is most rewarding.
10/12/2003 (12:43 pm)
People have problems in their everyday lives- we simply can't get around it. I have found that people are far more apt to discuss their problems through IM (or chatroom), simply because the emotional aspect is removed. As long as those lines of communication are open, people will stick around.It also sounds like your team may be fairly large. I always use 2 designated artists, 1 designated audio technician, and 1 designated coder. I prefer to assign a single person to each department, rather than using the jack-of-all trades to span several departments. I can code, write music, create special effects, and models. Does this mean that I NEED to do all these? Hell no. I much prefer to focus on the artwork and leave those tasks to the specialists (who can probably do the job much better and more efficient than me, at least that is why they were hired)
Keep in mind that everything I displayed here is null and void when applied to an in-house project. It simply doesn't apply, because they are completely different worlds. Some devs can't even function or comprehend a working environment like this. But for us, it has been the one that is most rewarding.
#15
Well, if you don't like it now, you may not like this addition - but I guess I'll throw all ideas out on the table -
What one must realize is that a game designer / programmer who is also taking on the role of manager is limited to how many people he can manage - prolly about 3 or 4 max. Having established the contractual model for asset acquirage, I wonder if I could take the hypothesy one step further - I wonder if I could encourage each of the 3 or 4 people who I hired to sub-contract people to work under them in the case that they need help. This contract-sub-contract model seems to allow more people to work on the game, and allow team size to dynamically expand and shrink without the manager needing to be involved with anything other than the 3-4 people he is directly contracting. Here's how it might work - I, the overworked (and underlaid) manager contract 3 to 4 brilliant, self-sufficient people to create assets for each area of the game. In my case, I would hire a Stage artist, a Monster artist, a Character artist, and another Programmer. In the case that the Monster artist is unable to create all the monsters necessary for the game, he can sub-contract that responsibility out to another person, and give that person the percentage of revenue of his that he is willing to give for the asset. The management of the sub-contractee will take place between the lead Monster artist and the sub-contractee - leaving me out of the equation to get my programming done. This gives the lead Monster artist a lot of flexibility in how to get his work done. He could do all the work himself, or he could possibly contract out all the work to various other people, and take a shaving of the revenue percentages off the top for his time and energy spent recruiting. He could expand or shrink his "department" dynamically as he sees fit, all with only a small amount of hindrence of and from me. Of course, I would still have to talk to each new sub-contractee (to make sure contractee who hired them isn't ripping them off), but I wouldn't have to manage or supervise them.
10/12/2003 (1:40 pm)
It seems to me that I would be more of an asset manager than a people manager. I want to avoid managing people, actually. I would like to keep the dev time limited to 1 year, and have only about 3-4 people directly helping me.Well, if you don't like it now, you may not like this addition - but I guess I'll throw all ideas out on the table -
What one must realize is that a game designer / programmer who is also taking on the role of manager is limited to how many people he can manage - prolly about 3 or 4 max. Having established the contractual model for asset acquirage, I wonder if I could take the hypothesy one step further - I wonder if I could encourage each of the 3 or 4 people who I hired to sub-contract people to work under them in the case that they need help. This contract-sub-contract model seems to allow more people to work on the game, and allow team size to dynamically expand and shrink without the manager needing to be involved with anything other than the 3-4 people he is directly contracting. Here's how it might work - I, the overworked (and underlaid) manager contract 3 to 4 brilliant, self-sufficient people to create assets for each area of the game. In my case, I would hire a Stage artist, a Monster artist, a Character artist, and another Programmer. In the case that the Monster artist is unable to create all the monsters necessary for the game, he can sub-contract that responsibility out to another person, and give that person the percentage of revenue of his that he is willing to give for the asset. The management of the sub-contractee will take place between the lead Monster artist and the sub-contractee - leaving me out of the equation to get my programming done. This gives the lead Monster artist a lot of flexibility in how to get his work done. He could do all the work himself, or he could possibly contract out all the work to various other people, and take a shaving of the revenue percentages off the top for his time and energy spent recruiting. He could expand or shrink his "department" dynamically as he sees fit, all with only a small amount of hindrence of and from me. Of course, I would still have to talk to each new sub-contractee (to make sure contractee who hired them isn't ripping them off), but I wouldn't have to manage or supervise them.
#16
lol... UNDERLAID. A freudian slip?
Actually, that model might work. Assuming that their percentage is significant to begin with.
I have seen numerous projects that dole out the full 100% of the revenue to the team, leaving no further percentages to expand, or accomodate further expenses (marketing, etc.) One such contract was so lopsided with The 2 coders receiving 30% each, a pseudo-marketer/financial backer receives 30%, the artists receiving 9% and the audio technician receiving 1%. That is just plain assinine, and shows that these dorks have no clue.
Needless to say, their game is selling miserably, although it is a VERY GOOD and polished game. The people in control really have no idea what they are doing, and left no further monies to hire a competent marketing person.
There are two points that I would like to make, and these are the single most important:
1) LAUNCH THE GAME. This sounds stupid, but unless the game actually launches, nothing else matters. How many projects have you people worked on that never launched or saw the light of day? Many, I bet.
2) MARKETING. You can have the best and funnest game in the world. But people will not naturally flock to play the game. They have to be coerced into playing it in the first place. I think its an illusion that many developers assume all they have to do is create a killer game and it will succeed. That is not the case.
10/12/2003 (2:31 pm)
QUOTE: I, the overworked (and underlaid) manager contract 3 to 4 brilliant...lol... UNDERLAID. A freudian slip?
Actually, that model might work. Assuming that their percentage is significant to begin with.
I have seen numerous projects that dole out the full 100% of the revenue to the team, leaving no further percentages to expand, or accomodate further expenses (marketing, etc.) One such contract was so lopsided with The 2 coders receiving 30% each, a pseudo-marketer/financial backer receives 30%, the artists receiving 9% and the audio technician receiving 1%. That is just plain assinine, and shows that these dorks have no clue.
Needless to say, their game is selling miserably, although it is a VERY GOOD and polished game. The people in control really have no idea what they are doing, and left no further monies to hire a competent marketing person.
There are two points that I would like to make, and these are the single most important:
1) LAUNCH THE GAME. This sounds stupid, but unless the game actually launches, nothing else matters. How many projects have you people worked on that never launched or saw the light of day? Many, I bet.
2) MARKETING. You can have the best and funnest game in the world. But people will not naturally flock to play the game. They have to be coerced into playing it in the first place. I think its an illusion that many developers assume all they have to do is create a killer game and it will succeed. That is not the case.
#17
10/12/2003 (3:25 pm)
You can always do an advance against royalties in the contract. Actually advance might technically be wrong, i should say just money against royalties on completion of the contract. The person that creates some assets gets to keep them, but then the producer gets to use it (as said earlier). You can agree to pay some money on completion of contract against royalties, if they don't finish the contract, you still get to use the assets, they just don't get paid because they failed on their commitment.
#18
I've just started reading this post, and so I'm responding to an old post. Maybe someone else commented on it, but I'm still reading down the thread....
This is a good way to think about it, but from the context of the conversation I gathered that you would use this method to decide on feature implementation priority. 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?
10/12/2003 (11:07 pm)
@BryanI've just started reading this post, and so I'm responding to an old post. Maybe someone else commented on it, but I'm still reading down the thread....
Quote:So how do we define the "balance"?(between modularized and decouple gameplay features) I think we could agree that the balance is found by minimizing feature-coupling where it is not necessary or when it is detrimental, while tolerating feature-coupling cautiously when it is necessary or beneficial.
This is a good way to think about it, but from the context of the conversation I gathered that you would use this method to decide on feature implementation priority. 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?
#19
Recently I was reading through patent and copyright law because I was trying to get a copyright for something. I don't know where I read it although if anyone wants I can hunt it down. Anyway...
I read that any time that an artist is hired for work, then the work is naturally owned by the person hiring. All that is needed is a work for hire contract. Exchanging work for percentage points or cash should both fall under the title of work for hire.
I thought about this in the context of my work with games and various issues I've come across during my time in games. What this means for me, is that if you work out an agreement with someone to work on your project and they produce something usable and then flake, then you have all the rights to use that art for your project as long as the artist is compensated as agreed upon. I think the problem only arises when the work for hire contract is poorly written. I think the best kind of contract is the kind of contract that gives the artist the right to flake if he wants without hurting himself or the project. Let's assume this is a work for percentage situation since work for cash is pretty clearly always an objective oriented exchange thing.
The contract model that has worked best for me is using a percentage of "productive hours" worked per person over total productive project hours put in by everyone. This will allow for you to bring in partners who can contribute as much as they want to, although they'll probably contribute more the more you inspire them.
(Minor developers are the developers who come into the project at a later time in development under a percentage by hour contract. They don't get as much a percentage as the one's who started it assuming they all work the same number of productive hours per week till the end of the project. Call it percentage Senority.)
There's another wrinkle you can add to make it easier to dole out percentages to people with varying skills.
When you hire someone, you can go through a probationary period where the prospective developer has to produce a usable asset for the project. They don't get anything if they fail, but they shouldn't get anything if they fail and they'll still get the experience of trying.
Now, if they do produce a usable asset, then as project manager you should assign them an hourly productivity constant. Assuming that the average indie is a 1.0 and you would probably consider yourself an average developer, then you could give really talented (better than you) people 1+ values, etc...This means that really talented people get to accumulate share of the royalties %50 faster than an average developer.)
10/12/2003 (11:50 pm)
@Randall and BryanRecently I was reading through patent and copyright law because I was trying to get a copyright for something. I don't know where I read it although if anyone wants I can hunt it down. Anyway...
I read that any time that an artist is hired for work, then the work is naturally owned by the person hiring. All that is needed is a work for hire contract. Exchanging work for percentage points or cash should both fall under the title of work for hire.
I thought about this in the context of my work with games and various issues I've come across during my time in games. What this means for me, is that if you work out an agreement with someone to work on your project and they produce something usable and then flake, then you have all the rights to use that art for your project as long as the artist is compensated as agreed upon. I think the problem only arises when the work for hire contract is poorly written. I think the best kind of contract is the kind of contract that gives the artist the right to flake if he wants without hurting himself or the project. Let's assume this is a work for percentage situation since work for cash is pretty clearly always an objective oriented exchange thing.
The contract model that has worked best for me is using a percentage of "productive hours" worked per person over total productive project hours put in by everyone. This will allow for you to bring in partners who can contribute as much as they want to, although they'll probably contribute more the more you inspire them.
(Minor developers are the developers who come into the project at a later time in development under a percentage by hour contract. They don't get as much a percentage as the one's who started it assuming they all work the same number of productive hours per week till the end of the project. Call it percentage Senority.)
There's another wrinkle you can add to make it easier to dole out percentages to people with varying skills.
When you hire someone, you can go through a probationary period where the prospective developer has to produce a usable asset for the project. They don't get anything if they fail, but they shouldn't get anything if they fail and they'll still get the experience of trying.
Now, if they do produce a usable asset, then as project manager you should assign them an hourly productivity constant. Assuming that the average indie is a 1.0 and you would probably consider yourself an average developer, then you could give really talented (better than you) people 1+ values, etc...This means that really talented people get to accumulate share of the royalties %50 faster than an average developer.)
#20
I think the most important thing here is to use a system that is fair, explainable, rational, and defendable. People always want more percentage for work they do, and everyone probably understands the genius behind their work more than anyone else, but if you can create a system that everyone can buy into then you'll be able to deal with flaky people as easily as you can dedicated people without worry of there being disputes over assets. You should hold regular reviews of people's work and their production skill to adjust productivity values over time. You have to build up credibility in your process to assign productivity values, but that'll probably be a different process for everyone. You can track an entire project's progress with developer percentage contribution using standard query emails and an excel spreadsheet.
If you can work all this contractual stuff out with your people, then you can create a management structure separately. There's a lot of value added when someone manages people well, so having a model, like you hinted at, where 3-4 talented managers/developers (>1'ers) manage 3-4 talented(>1) and beginner artists(<1) could lead to a productive development system where everyone gets a fair shair of the pot.
I kind of ran my last project like this, although crudely. The artistic director didn't come on until the beginning of summer. We had already been working heavily on the project since the end of January. Projected completion was Sept 1st. So it turns out that if the Artistic Director worked on the game as much as we typically did up to release, then he should have half as much a percentage as us cause he'll have worked on it half as long...which works out to 40-40-20. Those numbers looks harsh at first glance, but it really was the only way that I could find a way for everyone to be happy.
10/12/2003 (11:50 pm)
You can bring beginners onto the team and assign them values less than 1.0 so that everyone else doesn't get jealous. You don't have to make the values public, although if your team demands it and you can explain why certain people were given non-average values then everyone should be able to deal with it.I think the most important thing here is to use a system that is fair, explainable, rational, and defendable. People always want more percentage for work they do, and everyone probably understands the genius behind their work more than anyone else, but if you can create a system that everyone can buy into then you'll be able to deal with flaky people as easily as you can dedicated people without worry of there being disputes over assets. You should hold regular reviews of people's work and their production skill to adjust productivity values over time. You have to build up credibility in your process to assign productivity values, but that'll probably be a different process for everyone. You can track an entire project's progress with developer percentage contribution using standard query emails and an excel spreadsheet.
If you can work all this contractual stuff out with your people, then you can create a management structure separately. There's a lot of value added when someone manages people well, so having a model, like you hinted at, where 3-4 talented managers/developers (>1'ers) manage 3-4 talented(>1) and beginner artists(<1) could lead to a productive development system where everyone gets a fair shair of the pot.
I kind of ran my last project like this, although crudely. The artistic director didn't come on until the beginning of summer. We had already been working heavily on the project since the end of January. Projected completion was Sept 1st. So it turns out that if the Artistic Director worked on the game as much as we typically did up to release, then he should have half as much a percentage as us cause he'll have worked on it half as long...which works out to 40-40-20. Those numbers looks harsh at first glance, but it really was the only way that I could find a way for everyone to be happy.
Torque 3D Owner Eric Forhan
-Eric