Wow!

Hey frob, please re-read my post because I gave plenty of exception and I feel that you took everything out of context. I don't have time to hit all the issues now, but I will cover one thing that makes everything that I said both happen in the real world "by preference" and is eventually available to every game developer.

The collection of software available to the leader of a game development company makes nearly everything practical, but only if the leader has the skills to use those software.

Taken in context, everything that I wrote is available and actually being done in the industry.

Dear all - thank you ever so much for the thorough and detail discussion of the different project methodologies, and the pros and the cons of each. I confess, I am pleasantly surprised by how active and to-the-point this community is!

Thanks a lot,

George

Personally I had a big pain in ass by balancing between these two apects in development of our games. First thing you should have is a concept, then it goes to design document and specification. Then go sketches, to determine how the things will look like. Believe me, if you don't have sketches approved before you start the development - you're screwed. Like I did.

On early stage programmers can work without any art. Code don't require it. And when the code is done, they will need art to setup the game.

So in your plan take it into account, that the art should be done before programmer will finish his coding part. Because there will be gaps that you can't fill out during the process.

Balance is art. You'll never learn it until you do couple of games with a team.

Well, what comes first is the artwork - It's because without the art work you can't move forward with the code. You can say artwork is the idea in which you will be going to write down the code for.

Well, what comes first is the artwork - It's because without the art work you can't move forward with the code. You can say artwork is the idea in which you will be going to write down the code for.

Careful there. Starting with art could be a problem if you end up with all of the art produced but that it doesn't fit the programmer's expectations (asset sizes for example).

You need both teams to start and get them talking. This is why, oftentimes, its best to do in-house to minimize communication issues. By outsourcing to both (independent) parties, you are successfully cutting down costs, but make it that much more important to keep them synched, which will require (a lot of your) time.

In the development of many AAA popular game titles, the artists went to work first in creating concept art, sometimes in illustrated scene by scene fashion. If it is done very well, then some of those artworks can be used for attracting more investors and for advertising the game once it is done. The more experienced the game development organization, then generally the more feasible it becomes to have a choice in whether to commit to some art assets first or to begin coding. Both could begin literally on the same day, as well. A highly skilled single person Indy developer could likely start with a 3D model or start with assembling some game source code libraries with a bit of coding.

If the first 3D model is exported from the 3D software in one of the standard model file formats according what the game engine will use, then this likely is no problem. One could begin to create a game that is very art asset driven from the start. To get a "map" or "level" rendered by the game engine would be an early priority so all art and coding can build in relation to it.

However, if already existing code libraries are to be used, then it could be preferable to tie these libraries together as a game framework upon which art assets would later be imported. Next, further coding would be needed to make game functionality and gameplay features. It is not unusual for placeholder art to be used until all fundamental game source code is ready.

Some game development companies have been blasted by gamers for using almost the same game engine, game functionality, and similar game concept in consecutive releases from the company. Here is a case where a company feels desperate for improved development cost to sales ratio. In this case perhaps all the basic coding is done and used as placeholder while the company puts new art assets in to the framework and will later add coding as needed.

In my opinion, most beginners to game development should start with coding first and add art assets later. An exception might be the highly skilled 3D artists who needs to build on a level that he or she has made.

My conclusion is that what is made first (art or coding) depends on factors such as personal preference, skill set, available existing framework, and business pressures.

We are going to outsource the artwork and the development, most likely to two different parties to save costs.

I know I'm wasting my breath here, but waht you are trying to do is a suicide. Code and art are two critical components you need to have at least one as your core competence, it's a disaster otherwise.

Based on my research, it seems the first time after the GDD would be to ask the programmers to produce the code for the game using placeholder art - e.g., square boxes instead of real graphics.

Then the next step is to send this over to the artist and ask him/her to create the artwork to fit the placeholders.

Once the artwork is ready, it goes back to the developers who fit it to replace the placeholder graphics.

Nope, that's now how it's done. Coders will not "fit" any real placeholders (unless you can deal with wrong colourts conversion, inferior rescaling, etc) and artist can not be "sent over" the placeholders (also, you need concept art to show the artists).

BTW, placedholders can't be "empty boxes", it still needs some ugly art (forunatelly, coders draw them on their own in most cases). For example you can't code an animation without an actual picture of a human (with fifferent poses if we talk about 2D).

My advice would be ordering a finished game (corde+art+sound) and only do the marketing/publishing.