small teams
by: akbar A.(syedali011@earthlink.net)
Well today, i am deciding to take a short break from reading more about the stencil buffer (if you really must now, i am working on casting the shadows of moveable objects but with a mirror projecting all what is happening) and tell you what i think about small team game houses, and the relation with todays' games.
Small teams are not a good idea for large scale commercial games. Sure back in the early 90's and even up till the mid 90's it was possible to do, but now days it is totally ludicrous.
Customers are getting more and more anxious about there games, and they want to see them. The time it is taking to make games is just getting longer and longer due to a few reasons. But here is the part which is kind of interesting. I guess when you start your project for the first few months it is good to keep the team rather small. {4-6 programmers}, at least until you architect the way the game is going to be handled by the software code. I would say designing the *engine* but that word is being overused way to much and i feel like it is becoming into the y2k word.
Once you have the basic architecture laid out, it is time to increase the size on the staff. Although it may seem to cost more in the long run, with more programmers on the team you will get the game completed quicker and polished (consumers like polish. just take a look at ut for a fps) much more then you would with 4 to 5 programmers.


Another plus factor is, since you are going to be shipping sooner, your initial technology bracket will be lower. You are not going to have to architect with a certain 'X' feature involved cause it's time slot is way ahead of your launch time.
Also by completing the game quicker, you will have lesser chances of the team getting frustrated with everyone else at the company and deciding to quit. ala` ionstorm. although that was not the only cause.
peace,
akbar A.