While it''s probably very unlikely that an up-and-coming 1, 2, or 3-man team (or so) will produce sleeper computer game or video game hits from the start, is it impossible to see a group of this size creating respectable programs? My theory would project a much larger development cycle, but could pitbull-sized determination and perseverance produce good games like this? The concept does not seem impossible - the surgical team concept was a serious consideration in terms of solving the systems software development problem, wasn''t it? (the surgical team was a concept involving an industry-recognized small group of people - 7 to 10 at most - designing operating system software, doing the work of 10 to 100 times their number in terms of employees and people-hours.) In one corner... The software developers of yesteryear, going at it alone or in very small groups, producing software titles out of their garages. The era of the gold box (SSI role players will remember that phrase). In the other... Big-business software companies, dozens of cubicles strong. Entire floors / departments dedicated to mere portions of program design. Multi-million dollar budgets. With the right technology, could the surgical team concept work for game development, or is it impossible, benchmarked by the space-shuttle-sized effort it takes to produce a game today? Comments VERY much appreciated... -slippers2k Attack life''s problems like a Subaru... with all four wheels

Look at Croteam and Serious Sam for your answer. They started out as a tiny garage developer and as I understand it they were still a very small, young, independent team when Serious Sam was finished over a period of many years.

I would like to think so. If you can create a fun game, people will like it, no matter how many people it took to develop.

Spectre Software - RPGs, strategy, puzzle games, programming

It would seem to me that if you are talking about developing a single game, the small team could be just as efficient as a big company.

A big company, however, has the obvious advantage of being able to work on more titles simultaneously. This has the (not as obvious) advantage of being able to make more efficient use of their staff, if managed well.

For example, a group of 8 people making a game, let''s suggest that there are 3 programmers, 3 artists, and 1 music/sound technician and one lead designer.

The first thought that comes to mind is that the music/sound engineer will not be used for the entire 1-2 years of development normal for an average-sized game. A big company could use this person on several projects during that time frame, making better use of their time.

Having said all that, there are always creative ways to manage this kind of situation. However, from my experience, you wind up with several people on a small team that have to wear a number of hats (sound, testing, and tools programming, for example) - this can lead to conflict of interest, difficult time-management problems and consequent due-date slippages.

I haven''t worked with a big game shop, so I''m not sure how well this theory applies in the game industry, but in other software development, I have seen it myself. I''ve worked in both environments, big and small, and have found that, in general, the small team is more responsive to changes and can put out deliverables at a faster rate, but the big team/company allows for economies of scale that the small team can''t employ.

My $0.02. :-)

Cheers,
Russ

Check out this game called SCH (bizzare name). It''s the work of one developer working in his free time since 99'' and it''s in beta now. It''s pretty stinking cool.

I think your hypothetical surgical team can produce an AAA-quality game *engine*. Even in large projects, there aren''t a lot of people working on the core engine.

What they can''t do is create an RPG with 80+ hours of AAA-quality gameplay, or an RTS with hundreds of unique, interesting unit types. I don''t mean to focus on these particular genres... my point is that the surgical team simply can''t produce the amount of content seen in some commercial games. There''s too much art & sound, too much scripting, and too much testing.

So, I think the best you can do is come up with a game design that minimizes content requirements. Multiplayer-only deathmatch games and racing games are two genres that come to mind.

I think the problem with "large corporations" is that the project gets broken up into so many small, manageable pieces that the developers never really get attached to their code/project. It isn''t so much a labour of love for them as it is just "another job."

This doesn''t just refer to game programming either. In my job (writing custom corporate software for clients) the more people on the team the less I enjoy the work. It is strange thing really.

Dire Wolf
www.digitalfiends.com