How Long Does it Take Anyways?
posted by Scott Hsu-Storaker at 1:24 PM
I've been reading with interest a discussion being had over at the Freegamer blog and related forums about making a centralized project for the creation of a library of free game art -- kind of like what we do here, but multiplied by n. I would love to see something like that take off. There has always been a tough balance to strike around here with our project. We want our project and our team to grow because with growth comes excitement, momentum, and a sense of doing something greater than ourselves. But, there is also the urge to keep it small, because with smallness comes friendships, independence, and a sense of working on something as close to our passions as we can get in public. I've probably said it a thousand times in this space, but I'll say it again. There is a point at which there will be enough free game art in this community that a developer could get a long way towards reaching the first goal in creating a whole game -- a kind of critical mass if you will. I've always gone for a thousand as an even number. A thousand generic environment models plus one great developer plus one great artist to create custom artwork can put together a valid demo/beta/prototype. And if someone else out there is going to help lead a community effort to bring it all together, then, well... yeehaww! Go to it!
Which brings me here. I got to thinking about these things together -- time accounting and a large community effort. So, I am going to throw numbers at you. Yes, even in some detail. I hope I don't lose many of you, because I often get bored when people start spewing numbers, but I do think there is some sort of point at the end of this, my thoughts on how something larger than we have here now could possibly be run. It might make sense to apply some of this thinking to our own projects here, even. Up to this point our group, and our output has grown and changed very organically over time. For any artist coming along offering help, my one main direction has always been, "Just start working on stuff". This works great for a while, but without my constant attention, the organic growth tends towards being fallow. It is something akin to a gardener standing in the garden with a hose, watering the seedlings and saying out loud, "Grow". Things do grow and in some quite extraordinary ways. But as the team matures and the list of projects grows and production of art goes in all sorts of wild directions, it does get out of control. Sometimes this is good -- projects like this attract the type of people who inspire and create beautiful art. Sometimes it is not -- projects like this tend to drive away hardworking and productive people who would keep projects on track and spirits high as everyone sees the results of all their work coming together. Any project massive enough to say it can organize one community (artists eager to donate art) and supply another (developers looking for quality free art) needs to think about how teams need to be structured and a big part of understanding team structure is understanding how things get done, who does those things, and how long these things actually take to get done. And I am going to talk a little bit about what I have learned over the past two years, working with a flexible team of 20 artists, supplying models to over 5000 developers, wrangling over 200 models and helping the flow of over 500 man-hours.
So, here come the numbers.
I looked at the Gilman Street project that we completed last year. It was in many ways the easiest to examine since I was involved with all steps of the process and did about 50% of the work myself on it. So, accounting for time was a matter of looking over my Thousander Club records and extrapolating other artists' time based on forum postings. Here are some basic numbers:
42 complete models
320 total man-hours
Given that I edited out a few at the end, I am going to go with a rough number for the following:
7 hours per complete model
How does that break down?
1.5 hours -- Modelling and unwrapping
3 hours -- Texturing
1 hour -- Exporting and file wrangling
1.5 hours -- Man. & Misc., includes project management, team communication, finding source material, recruiting, anything else miscellaneous.
I've broken it out this way to coincide with each of the discreet steps at which files can be passed from one team member to another in a manner that feels complete. It also works out that each handoff point matches pretty well with standard skillsets of modeller, texture artist, technical artist, and management.
My next step is to then apply this accounting to formulating a proposal for what would be an ideal team structure for creating a massive library of models. At some point I may actually finish an article I have been exploring for the past year about Brooks' Law and how it applies to the sort of virtual game art teams similar to this coop. For now, in short, my conclusion is that small teams are best for creating work in the way that we have done here in the coop. My calculations say that anything over seven team members working on any one project starts to produce a state in which each person added makes the team less productive. Five may actually be a more ideal number, but given that real life has a way of knocking people out (see my last ten posts), I say seven would be a better starting point.
So, let's try this out for size. Let's make a project team that consists of the following members:
2 Modellers for modelling and unwrapping
3 Texture Artists for texturing
1 Technical Artist for exporting and delivery of files
1 Team Facilitator to handle all the team management
1 Floater to help the team facilitator and to fill in the gaps on the team
How does that sound? What does this team accomplish? Well, if each person on the team works five hours a week, that will net a content pack with 50 models in a period of 10 weeks. If each person works 2-3 hours per week on the project, a content pack will be done in under 6 months.
For a team like ours, if we get larger than we have been, it might or might not make sense to split out in teams like this. For the Gilman project, which tooks 18 months to complete, I filled more than one of these roles. I was, in effect, 1 modeller, 1 texture artist, the technical artist, the team facilitator, and the floater. Maybe for a team like ours, which is small by its very nature, this sort of flexibility is better suited to us than grafting on a layer of structure. For contemplating a massive project like a community media project, though, with potentially thousands of elements, I think it makes a lot of sense. Expecting a crowd of people, each one an artist with a unique style and a partial skillset, to just drop off whatever they have made in their spare time with little oversight is an invitation to chaos. At best, with the efforts of a few dedicated facilitators, the mass of work can be wrangled into some sort of coherency. But, having been one of these central faciliators in the past (a whole separate story), I know that the sort of effort needed to rein it all in is taxing, unappreciated, and is often met with resistance and spin. In short, it is not a position to stay in for long and any lapse in the continuity of the main facilitators' presence results in a strong blow to the project.
I propose, either for project like a large community media project or for the coop if we grow that large, that an approach of creating multiple small teams brings the best of both worlds. The team dynamic can help create work that is better than the work that any one person can accomplish, yet a small team is ideal for creating work that is cohesive and focussed.
I say we all throw a party when we reach a milestone of 1000 original models for the community!
Stay free
~shs~
I've been thinking about time recently. Partially, it is natural -- time plays a big part in my day job. I keep projects on deadline and I estimate how long projects should take. That sort of thing. But I've taken a much greater interest in understanding how all the little grains of time add up over the day, how all the little bits of sand become the massive waves of dunes. I think what sparked my renewed passion in this myopic accounting of seconds and minutes is a project I worked on recently. There was this certain task that had to be done on a regular basis, a fairly mindless task but it needed to be done with enough concentration so as to avoid stupid mistakes. Basically it amounted to an hour of design work and five hours of copying and renaming files. Naturally my mind started to wander and I started calculating how long each keystroke, each renaming, each click was taking. I ended up figuring out a solution that cuts out over four hours from the process and that sort of success has gotten me to start thinking about how long tasks in other parts of my life take.
I've been reading with interest a discussion being had over at the Freegamer blog and related forums about making a centralized project for the creation of a library of free game art -- kind of like what we do here, but multiplied by n. I would love to see something like that take off. There has always been a tough balance to strike around here with our project. We want our project and our team to grow because with growth comes excitement, momentum, and a sense of doing something greater than ourselves. But, there is also the urge to keep it small, because with smallness comes friendships, independence, and a sense of working on something as close to our passions as we can get in public. I've probably said it a thousand times in this space, but I'll say it again. There is a point at which there will be enough free game art in this community that a developer could get a long way towards reaching the first goal in creating a whole game -- a kind of critical mass if you will. I've always gone for a thousand as an even number. A thousand generic environment models plus one great developer plus one great artist to create custom artwork can put together a valid demo/beta/prototype. And if someone else out there is going to help lead a community effort to bring it all together, then, well... yeehaww! Go to it!
Which brings me here. I got to thinking about these things together -- time accounting and a large community effort. So, I am going to throw numbers at you. Yes, even in some detail. I hope I don't lose many of you, because I often get bored when people start spewing numbers, but I do think there is some sort of point at the end of this, my thoughts on how something larger than we have here now could possibly be run. It might make sense to apply some of this thinking to our own projects here, even. Up to this point our group, and our output has grown and changed very organically over time. For any artist coming along offering help, my one main direction has always been, "Just start working on stuff". This works great for a while, but without my constant attention, the organic growth tends towards being fallow. It is something akin to a gardener standing in the garden with a hose, watering the seedlings and saying out loud, "Grow". Things do grow and in some quite extraordinary ways. But as the team matures and the list of projects grows and production of art goes in all sorts of wild directions, it does get out of control. Sometimes this is good -- projects like this attract the type of people who inspire and create beautiful art. Sometimes it is not -- projects like this tend to drive away hardworking and productive people who would keep projects on track and spirits high as everyone sees the results of all their work coming together. Any project massive enough to say it can organize one community (artists eager to donate art) and supply another (developers looking for quality free art) needs to think about how teams need to be structured and a big part of understanding team structure is understanding how things get done, who does those things, and how long these things actually take to get done. And I am going to talk a little bit about what I have learned over the past two years, working with a flexible team of 20 artists, supplying models to over 5000 developers, wrangling over 200 models and helping the flow of over 500 man-hours.
So, here come the numbers.
I looked at the Gilman Street project that we completed last year. It was in many ways the easiest to examine since I was involved with all steps of the process and did about 50% of the work myself on it. So, accounting for time was a matter of looking over my Thousander Club records and extrapolating other artists' time based on forum postings. Here are some basic numbers:
42 complete models
320 total man-hours
Given that I edited out a few at the end, I am going to go with a rough number for the following:
7 hours per complete model
How does that break down?
1.5 hours -- Modelling and unwrapping
3 hours -- Texturing
1 hour -- Exporting and file wrangling
1.5 hours -- Man. & Misc., includes project management, team communication, finding source material, recruiting, anything else miscellaneous.
I've broken it out this way to coincide with each of the discreet steps at which files can be passed from one team member to another in a manner that feels complete. It also works out that each handoff point matches pretty well with standard skillsets of modeller, texture artist, technical artist, and management.
My next step is to then apply this accounting to formulating a proposal for what would be an ideal team structure for creating a massive library of models. At some point I may actually finish an article I have been exploring for the past year about Brooks' Law and how it applies to the sort of virtual game art teams similar to this coop. For now, in short, my conclusion is that small teams are best for creating work in the way that we have done here in the coop. My calculations say that anything over seven team members working on any one project starts to produce a state in which each person added makes the team less productive. Five may actually be a more ideal number, but given that real life has a way of knocking people out (see my last ten posts), I say seven would be a better starting point.
So, let's try this out for size. Let's make a project team that consists of the following members:
2 Modellers for modelling and unwrapping
3 Texture Artists for texturing
1 Technical Artist for exporting and delivery of files
1 Team Facilitator to handle all the team management
1 Floater to help the team facilitator and to fill in the gaps on the team
How does that sound? What does this team accomplish? Well, if each person on the team works five hours a week, that will net a content pack with 50 models in a period of 10 weeks. If each person works 2-3 hours per week on the project, a content pack will be done in under 6 months.
For a team like ours, if we get larger than we have been, it might or might not make sense to split out in teams like this. For the Gilman project, which tooks 18 months to complete, I filled more than one of these roles. I was, in effect, 1 modeller, 1 texture artist, the technical artist, the team facilitator, and the floater. Maybe for a team like ours, which is small by its very nature, this sort of flexibility is better suited to us than grafting on a layer of structure. For contemplating a massive project like a community media project, though, with potentially thousands of elements, I think it makes a lot of sense. Expecting a crowd of people, each one an artist with a unique style and a partial skillset, to just drop off whatever they have made in their spare time with little oversight is an invitation to chaos. At best, with the efforts of a few dedicated facilitators, the mass of work can be wrangled into some sort of coherency. But, having been one of these central faciliators in the past (a whole separate story), I know that the sort of effort needed to rein it all in is taxing, unappreciated, and is often met with resistance and spin. In short, it is not a position to stay in for long and any lapse in the continuity of the main facilitators' presence results in a strong blow to the project.
I propose, either for project like a large community media project or for the coop if we grow that large, that an approach of creating multiple small teams brings the best of both worlds. The team dynamic can help create work that is better than the work that any one person can accomplish, yet a small team is ideal for creating work that is cohesive and focussed.
I say we all throw a party when we reach a milestone of 1000 original models for the community!
Stay free
~shs~
posted by Scott Hsu-Storaker at 1:24 PM
2 Comments:
Good post Scott.
Working together on the net is very difficult. I haven't seen a team work efficiently on a forum alone.
A wiki might help, but it takes many hours to setup, as would any efficient system!
I always seem to place a lot of importance on the system by which we work, I guess I think that if its set up properly, new members can easily see exactly what needs doing, and where the project is heading.
Anyway, I'm sure the solution will present itself.
3:03 AM
As an add-on to the above numbers, I thought that since there may be new readers here, I should make it clear as to what specs we used in creating these items. Things we did not do, like normal maps, rigging and animation, tend to be huge time sucks. The goal for us was to deliver a solid set of simple but useful environment props.
Polycount -- 300-600 tris.
Texture -- 1 diffuse color texture, png format at 512 x 512, usually created at 1024 x 1024 and sized down.
Basic file formats -- .blend is the master format, with additional common formats of .obj and .3ds.
UV Map -- all files were unwrapped and the 2d file, png format, was included.
Game engine format -- files set up and exported to .dts format for use in Torque -- other formats are in the works but not included in this accounting.
Terry, maybe now is the time we actually get something set up. I'll look into it based on the recommenedations you've given in the past.
Scott
12:01 PM
Post a Comment
Links to this post:
Create a Link
<< Home