Thursday, March 27, 2003
A quick note. Tensions seem to be running high on the programming team. I guess that means people got their reviews...
I'm beginning to see the trouble of closing out the project as more significant than I ever imagined. And I think the problem results from not bringing in QA and better process early -- resulting in lots of bugs and more being uncovered. And then a again, we lack documentation that might help with them validating the game. And lack tools to help automate testing. And...
So I'm beginning to play around with early dev team sizes and roles:
producer: schedule, motivation, triage, conflict resolution, upper management negotiation
lead designer: vision, balance, fun
lead artist: the look
lead programmer: the implementation
lead QA: testing and documentation
early key contacts:
I think the process starts with a designer (or two) coming up with the top level design.
Then I think you bring in the team core team. The tasks need to be clear from the start and concrete milestones (early and often.)
I expect a prototype, technology, and a clear direction for the art. Perhaps a few additional people need to come on board to help the design, art, programming teams. These people should be capable of being leads later.
Expect the full documentation when Technology tries to write it. My ideal is allowing teams to be flexible except on some key points.