Tuesday, November 8, 2011

[CRAZY IDEA] Asynchronous Game Development

There is a very good chance that this blog post exists because I am reverting to old college habits in pursuit of NaNoWriMo... namely I am somehow avoiding something I "need" to do by doing that same thing to no purpose.

I don't know anything about developing a video game but...

So, I have never completed any programming project that took more then 6 months to develop. The occasions where I did complete projects weren't games anyway. So, while I may not be knowledgeable about making video games I know quite a bit about failing to complete video game projects.

I'm sure someone else has thought of this but...

There are many times when I have an idea and it later turns out that someone is already doing it or has proved it to be crazy and abandoned it. That said, I like writing down my ideas because it helps me "hone" them.

So I've heard there's this problem...

There are a number of examples I have seen of games getting to a certain point and being scrapped or taking so long to develop that by the time they are released they look dated or perform less well then recent games.  This comes because the engine and the assets and the game itself are essentially built, and tested, at the same time.

Now, this style of concurrent development makes a lot of sense because you can have everyone in the company working on the same project and deliver it and move on. You can also ensure that the graphics and engine and interface and play mesh seamlessly because there will be constant back and forth between the sections of the team.

All that said, here's what I think someone should do...

First, this would only really work well with a large development team working on a long project; preferably multiple concurrent projects.

Stage One would be game design, concept art, maybe get the development team in to do some mechanics demos to get an idea how the whole thing should work... block out the whole project from scratch, figure out what's essential to the release, what's modular and the timeline/roadmap for the project.  Everyone from every team working together for maybe 10% of the total development of the game.

Stage Two the story guys and game play guys and the art guys break down what assets are needed and then the art guys make those assets... but target them to work on an engine that they expect to be up to date at the end of the project.

When the art guys have figured out when their part of the project is going to be done the designers start working on an existing engine using existing assets and build a working example of the game play mechanics and further block out the needs from the final engine so that they finish around the same time as the art guys.

Stage Three the art guys and the designer guys go off and work on something different while the engine guys build the engine that will support the existing assets and game play. They may need to bug the art and design guys to make sure they are getting things right but for the most part, if it was designed and planned well it shouldn't be a problem.

Stage Four, everyone gets back together and makes sure the game works as it is, looks good, plays well, doesn't break etc... and essentially the rest of the project is bug fixes until release.

So...

Does that make sense? Am I solving a problem that doesn't exist or making an existing problem worse? I don't know but it seems to me that it would be a lot more rewarding at every stage of the process for those involved and it would result in significantly less waste on the "more expensive" aspects of the project.