The most cost effective thing to do would be to start on a new project immediately after the previous, because you have to pay for employees, business expenses, and other things every day. Also, if you are only working on one project, than after the concept artists and designers and composers and artists have done their work, and the programmers are fixing the last bugs before the game is sent to the publisher for disk pressing, they are essentially getting paid for nothing. You can't just make them go home and not pay them, and you can't have them sitting there. Some studios have their team start on DLC before the game actually is released, and some just start a whole new project entirely, and then there are some like 38 studios that get liquidated by Rhode Island after they finish a project.

I start planning the next one when the current one is in QA. Some team members are being phased out, and they could get started on the next one.

A game project's staff needs tend to start low in the pre-production phase, then ramp up to requiring a lot of people during production, and then wind down again towards the end of the project (e.g. when all the art and code features are done, and there's just weeks of bug-fixing left).

So the staffing needs of a project kinda look like a parabola when graphed against time.

As one project begins to wind down and you've got staff who have no work left to do, then it's time to start pre-production on the next project so that those people can hopefully do something productive.

At large companies, this doesn't always work out and I've sometimes seen people simply left with no work to do at the end of a project, who are just given training exercises, etc, while the company bleeds money while looking for their next project (in the case of work-for-hire studios).

I was just wondering, if you have a long term game development team, when do you start thinking about a game that you want after the one you're currently working on is complete?

Before the current one is even started usually!

The process usually begins with a list of potential titles and evaluations of popularity, development difficulties, competition, and other factors that can influence potential success of a title. Then the title that looks like it will be "most successful" is selected.

Later, usually about 2/3 of the way through development on a large project, when burnout from working on the same project for months occurs, I start rapid prototyping other titles.

Right now i'm about 1 year into my main project, with probably close to 6 months left to go. But I already have 3 other titles prototype'd and ready to be fleshed out.

But this approach requires a long view. Thinking in terms of developing a suite of products, not just one title at a time. Not always possible in the roller-coaster world of commercial game development. But doing so allows one to take maximum advantage of the reuse of technologies from one title to the next. Prototyping is reduced to "technology tests" for new features, and "proof of concept" for untried game play systems. Everything else, you've done before, and have sample code in your existing project(s).

Design then become an exercise in "kit-bashing": I'll use a modified ground engine from this title, i can use the AI techniques from that other project, and all the terrain graphics from that third project (well, at least the trees). Since you're assembling games mostly from existing components, about all that needs figuring out is the new stuff you've never done before.

When it comes to designing and building games, I've discovered that the most important thing to do is worry about what you don't know how to do. How to write code that will do this, finding a graphics tool that will do that, or finding a library that does the other thing. Everything else is old news, all you have to do is go through the motions.

The planning of the next project should usually start way before the current project is done. At the place I work, we usually have the next few projects already in a planning stage, with a very rough draft for the requirement specifications, an approximate release date and a general project outline. And while one project winds down you gradually define more and more of the next project.

I'd say at least one person (or more, depending on how that team works) needs to have an idea long before starting. Either you're trying to secure access to content under a licensor, brand material, etc or you're going to need to create a lot of background elements if you start from scratch. As this takes a lot of time, during which you're either negotiating with a client/third party or actually fleshing out a macro concept, its best to start early.

That way, when your actual game designers are no longer producing stuff but are mainly there to insure everyone has access to the info they need and problems are resolved down the road (things that weren't properly documented, cases that haven't been handled, etc) you have something for them to feed on. Same goes with artists as well.

That said, while this is a very 'workflow-oriented' approach (checks who is available to define when to start) you might consider also allocating at least one technical member of your team to these brainstorms/discussions. While they will still be swamped at that moment, finishing up with the game, their input will be invaluable in making this a success.

Wow I had been wondering this exact thing. The answer is fairly obvious, but I might not have arrived at it until long after it was too late. Thanks everyone!