Game development 101?

Start with 1 experienced network coder and 1 experienced AI programmer, preferably MMO experience, and hire out of their Rolodexes.

That number is impossible to even guestimate, it depends 100% on the skillset (and codebase in their head from prior projects) your coders arrive with.

The "Business behind Everquest" article in game developer recommends that an MMORPG be limited to less than 10 people for the first year or so of development, primarily engineers, so that the technology side of things can get worked out for the most part and the content pipeline set up right, then worry about artists and content later, if it even survives that long that is.

Quote:

Original post by DrEvil The "Business behind Everquest" article in game developer recommends that an MMORPG be limited to less than 10 people for the first year or so of development, primarily engineers, so that the technology side of things can get worked out for the most part and the content pipeline set up right, then worry about artists and content later, if it even survives that long that is.

Boy, such positive thoughts :p

Thanks that helps, actually both posts help, it will give me a rough estimation of what we can be looking at in the near future.

The size of teams for current tripple A titles range from around 30 up to 100. Exactly how many will depend on the scope of the project, when it needs to be finished and what amount of slippage protection you include in the plan. You should start with a small team to get the core tech done then ramp up to the full team.

[Edited by - Obscure on June 23, 2004 6:39:38 AM]

To start out, 5 is plenty based on my experience. That gets a tech demo which less experienced coders can be given bits to work on and flesh out. This way the original few all know exactly how the project hangs together. And I agree with no artists until that point (maybe one for placeholding stuff I guess).

There isn't really ever a black and white answer to this kind of question. So, so much depends on the particular game, the platforms its released on, the timescale, whether you're looking to build a long lasting company out of this, whether you're going to be using traditional publishing & distribution, the structure and amount of your initial funding etc... my thoughts about how you should go about doing things:

1) Initially you'll want to have a "INITIAL PROTOTYPING/SCOPING PHASE" with just the leads and nobody else; lead programmer, lead artist and (possibly, depending on the game and how much consistency/continuity needs building in from the outset) a lead designer.

a. From the few details you've posted, technology is probably your biggest unknown (assuming the "new" parts of the design contribute to something your target market will actually enjoy playing).

b. Because technology will be such a key here, hiring a good lead programmer will be essential. If I were in your position I'd be looking for someone:

- with 10-15 years or more professional experience in the games industry (with 5+ shipped titles, at least one in the past few years on your target platform [PC?]).

- with exceptional networking knowledge (possibly an ex-network programmer who's moved up to lead status, possibly someone who used to work for an ISP or similar writing protocol level stuff). They should know the hardware side (dealing with NATs etc), the protocol side (including dealing with firewalls and such), and general network architecture design.

- with at least one shipped product that had a significant networking component.

- experience as a lead on at least one *shipped* product.

- good all round experience with strong 3d & mathematics.

c. A programmer of that calibre won't come cheap! - take a look at the jobs section here on GameDev; at the IGDA/Gamasutra salary survey; and at adverts from games industry recruiters for an idea of the ballpark salary they'll want.

d. Of course, whether someone of that calibre is willing to risk stability for the fun of a startup is another matter entirely (someone of that calibre is in their 30s or older so probably has a family & mortgage).

e. Initially the lead programmer should be prototyping the core networking architechture. In particular they're going to need to determine which parts of the big design idea will actually work in practice; it's quite common for designers to dream up ideas that simply aren't at all possible with the technology available today.

f. It might be the case for that the FPS aspect of your "big idea" wouldn't work with the massively multiplayer aspect in terms of lag - or may have to be trimmed down in scope.
If you're intending to be the CEO *AND* designer, then *PLEASE* do trust the experience your lead - that's what you hired them for - you MUST be prepared to make sacrifices in the design to make it all work.

g. Since the networking aspect underpins your whole game, in the initial prototyping phase the lead programmer shouldn't be doing anything on the GUI, the 3D engine etc. In fact, all the program code they write should be thrown away or only used for reference after the prototyping stage. The prototype should be to evaluate ways of doing things, to identify core risks.
It would be wise for the lead to evaluate the networking middleware on the market at this time too - it will cost you, but gives you a head-start, takes out some implementation risks, shifts technical/compatibility issues onto another company etc.

h. During this prototyping phase the lead artist should be gathering reference material and working on defining an overall "style". Additionally they should be evaluating tools and identifying tools that might need to be written. They might also be doing high quality "concept" sketches and renders now.

i. A good lead artist should have clear vision, but also be a good technical artist, understanding the tools and the technology. If your game is going to be released on console platforms the lead artist should definately have shipped product on a console before (NTSC/PAL & RF do horrible things to colours and lines that PC/Mac monitors don't - the lead artist must intuitively know when something will look ok and when it won't).

j. A lead artist will be cheaper than the lead programmer and doesn't need as much specialist experience (though if you're doing something with characters, a former animator or character artist would be desirable). However you're still going to have to shell out some $$ to attract the right person.

k. Starting with a core team of 2-3 should save quite a lot of your budget while you get the technical and artistic aspects of the game designed and the risks identified. If you identify a lot of risks or things that will prevent the game from working, after prototyping is the time to can the project or change scope.


2) Once things are designed and prototyping has eliminated/identified all major risks, the overall artistic style decided, design scope adjusted and consistent, you can move into the "initial pre-production" phase.

a. Your next hire will be the [lead] engine programmer who will develop things like the renderer (or evaluate rendering middleware). The networking design will likely affect the way the renderer does certain things which is why the lead will have already worked out that stuff before the engine person comes on board. They'll also be working a lot with the lead artist to decide what will and won't be possible in art terms (maximum bone counts, maximum poly counts, effects/materials that the engine will do etc). If game consoles are amongst your target platforms, then a good engine programmer will cost you more because of their specialist console knowledge (PS2 in particular - some PS2 engine programmers can command lead level salaries).

b. Around the same time as the engine programmer you'll want to get a tools programmer; they should have decent 3d programming experience as well as application development experience (preferably .NET these days I'd say). Network programming experience would be a bonus too. This is often an entry level job that a talented graduate who's made a game in their spare time would be ideal for. Initially in this pre-production phase they'll be working with all members of the team on things such as file formats, exporters, test tools, and the start of the world editor (object placement, behaviour assignment etc).

c. This core team of 4-5 people should be enough to get a rough prototype/experimental version of a single level/area the game running without AI and with placeholder graphics. This will be the first time everything would have come together and people can actually see the direction the game will go for real etc. This is also where bad decisions, bad design, and bad prototyping/R&D should be exposed.


3) The next stage is full pre-production where you start fleshing out the content to see the overall size and scope of the game. At this stage the artists will be making untextured levels, building objects, building characters etc. The aim of this is to ensure that there isn't any problem with the scope or any particular level element - the game isn't necessarily properly playable as a whole at this stage. At the end of this stage is when you'll be making demos that look good to obtain that extra investment and/or publisher support. You'll probably *gradually* hire:

a. AI programmer

b. Additional network programmer (possibly a server-side guy, likely a UNIX guru).

c. Maybe an additional engine programmer (say for effects and the like).

d. Additional gameplay programmer(s) depending on how much special case stuff you'll have that can't be done in level design/script.

e. Character artist(s) and animator(s)

f. Level/scenery/prop artists

g. Texture artists

h. A sound guy.


4) Once pre-production is nearly done you can move into full production and ramp up team size to almost full capacity. The kinds of people you'll be hiring:

a. Any remaining staff from above.

b. Level designers/builders/scripters.

c. Front end artist.

d. QA/testers (in the latter half of production) - both gameplay people and technical network people to try different hardware configurations etc.


5) In summary + time guesstimates:

a. 3-6 months, 2-3 staff, prototyping

b. 2-6 months, 4-5 staff, pre-production foundations/R&D

c. 6+ months, 8-35 staff, pre-production

d. 8-12 months, 12-100 staff, production



Of course, that's not necessarily the right way or wrong way to do things - just the way *I* would do things (in an ideal world) [smile].

I'd love to be able to follow that plan Simon - if only I had the cash to start a company! Although it would be strange hiring leads with WAY more knowledge than me as I'd want to be the designer and do some code too.

Quote:

Original post by d000hg I'd love to be able to follow that plan Simon - if only I had the cash to start a company! Although it would be strange hiring leads with WAY more knowledge than me as I'd want to be the designer and do some code too.

It's normal to hire people with more experience, its impossible to know everything.