« Lucky | Main | TDD »

May 17, 2006

Comments

Liam Hislop

That's not too bad of a theory. It is similar to something I read some time ago (blast my memory for not remembering anymore).
How much time you can expect/schedule people for (on average):

Contract work - 100% of their time. If they are there, they should be working or you're losing $$
Non-management employees - 80% of their time. This takes into account meetings and stuff. Basically, what you're saying, that they will do other stuff than work during the day, so .75 isn't that far off.
Management - 50% of their time scheduled. They will have more fires and meetings and stuff, so to schedule them for an entire week will probably end in disaster.

SO I do think Fristom's Law has some merit to it. As you said, there are other factors involved, but it's not too bad for a rough estimate. I may have to try this one out in secret and see what happens...

Jay Barnson

A big part of it depends upon the length of time involved. While the productivity may average out to that formula, in the short term it is often worse, because of the "spool up time" required for a new team member to get up to speed and be productive.

I haven't read Brooks' book, but I suspect that's a big part of the "making it later." For the first 1-4 weeks, the new team member may be more of a productivity sink as he pulls other team members away from their tasks to help train him on what he should be doing, processes, how the code is organized, etc.

Sean Barrett

Huh, levels? "Number of Levels" isn't going to be at all correlated with the amount of programming effort on the project, only the amount of design (and maybe art) effort.

Jamie Fristrom

Well, although Brooks is talking about just programming effort, I'm talking about the whole shebang. Artists & designers are just as impacted by communication overhead as coders are. And number of levels IS *correlated* with amount of programming effort on the project - because number of programmers is usually correlated with the size of the rest of the staff. Granted, there's no causation.
Finally, I did say it was just a "feel" thing.

Nathan McKenzie

"Artists & designers are just as impacted by communication overhead as coders are."

I hear this as wild crazy talk.

I'm not going to claim that artists, specifically, operate in a communication vaccuum, per se, but my experience has definitely been that most artists, once they understand art style and technical constraints and engine features and tools (and yeah - all of that can take a non-trivial amount of time) can work pretty decoupled from each other. Doubling the amount of artists _can_ double, say, the number of textures that are produced. It slows, too, if there are complex specialist interdependencies (animations that rely on tweaks to animation systems and specifics in level architecture, for example).

I don't think artists scale anywhere near as terribly as programmers do in the wild.

Designers probably are about as bad, though, or at least have the potential to be, depending on what it is they're designing.

Jamie Fristrom

Easy for a non-artist to say. Even with texture artists, the most likely art position to be able to make into galley-slaves, you've got "Is this texture good enough?", "Does it match the concept art?", "Does it fit the color key?", "You forget to make it double-sided, alpha, not-alpha, this shader, that shader." At Treyarch, the texture artists also would do the texture mapping and refine the terrain meshes so their textures looked good, so you'd get, "Hey, when you added this little ridge here you made it so Spider-Man couldn't crawl over."
Also, rule-of-thumb, folks! I agree that you *can* double work when you double manpower, as in, it's *possible* - but that's not the way to plan.

Nathan McKenzie

Feh!

I do have production artwork in shipped games, actually - it's all particle system stuff and related source art. And as other effects artists made new effects, they had nearly no chance of breaking or mucking up my stuff. Effects (and textures and sounds and music and models) aren't totally decoupled from other disciplines - as you say, texture choices can drastically affect gameplay - and they're not decoupled from each other - it is important that textures all fit the art style. But in my experience, they still are far more decoupled than code tends to be. Isn't this part of the reason for all the current interest in data-driven approaches - they can be scaled up more successfully (if, often, more generically)?

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been posted. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment

Your Information

(Name is required. Email address will not be displayed with the comment.)

Jamie's Bragging Rights

  • Spider-Man 2
    The best superhero games of all time Game Informer
    Top five games of all time Yahtzee Croshaw
    Top five superhero games of all time MSNBC
    Top 100 PS2 games of all time Official Playstation 2 Magazine
    1001 Games You Must Play Before You Die Nomination for Excellence in Gameplay Engineering Academy of Interactive Arts & Sciences
  • Schizoid
    Penny Arcade PAX 10 Award
    Nominated for XBLA Best Original Game
    Nominated for XBLA Best Co-Op Game