GameDevMike

In a recent discussion at GameDev.net regarding art content in indie development, I was quite surprised at the number of people advocating getting the art into the game as soon as possible. I’m guessing most of the posters in that thread haven’t carried a major indie project through to completion yet, but it still brings to light what I perceive as a misunderstanding of the development process. Hence this tip.

Some people prototype their games, some don’t. I don’t advocate one approach or the other. A prototype obviously will not use the final production art. But even after the prototype, or if you skip it, you shouldn’t be relying on production art early in your development of the game. I could probably come up with a list of several reasons why I think placeholder art is a great idea, but instead I’ll give you the two that I believe are most important.

1) Placeholder art allows you to focus on gameplay. This may sound silly on the surface, but it really is true. When you start off with quality art from the beginning, there will always be an urge in the back of your head to implement more eye candy. You’ll constantly be distracted by ideas of how to make the appearance of your game shinier. I have found that placeholder art doesn’t distract in such a way. You are able to devote the majority of your focus on gameplay features and not the visual ga-ga factor. Awkward moments may arise when you can’t judge the full impact of a feature because you don’t have the proper animation yet, but that’s sort of the point. If the game mechanics work with garbage art content, then you know you’re on to something. Getting the core gameplay down is very important.

2) Placeholder art decouples the programmer’s schedule from that of the artist(s). This seems like a no-brainer. I mean, it’s a pretty dumb thing to hold up the early development of your game just because your artist hasn’t gotten some of the content finished yet, right? As ridiculous as it sounds, some people do just that. “I can’t implement my inventory system yet because the UI artist hasn’t finished the item icons!”. Placeholder art allows you to avoid situations like this. It doesn’t matter if the icons aren’t completed yet because you are using bitmaps with multicolored backgrounds and labels such as “sword”, “potion” and such. This allows you to implement you inventory system, the merchant interface, and everything else you need item icons for in your Kick Ass RPG, no matter what the artist is working on. Ultimately, the schedules will need to converge as the game nears release. At that point, any incomplete content could very well hold things up. But you can always squash bugs in the meantime.

If you agree that placeholder art is a good thing, then comes the question of what to use. The answer to that is… anything you want. Placeholder art is expendable, so it doesn’t matter what you use. For a 2D game, or for 2D elements of a 3D game, I think labelled, solid color bitmaps are handy. These can be knocked up in a graphics program in no time (yes, by you). In the UI example I gave above, all potion icons could be labelled “potion” and the background color coded for potion type: red for healing, blue for mana, green for poision, or whatever makes sense for you. In a 3D game, terrain textures could be solid color bitmaps (green for grass, brown for dirt, yellow for sand, white for snow) and the characters could be basic geometric shapes - like boxes. Or you could use free textures from the net, implement an alternative model loader for MD2s, or another format, and use those. GarageGames sells several content packs that are intended to be used as placeholder art for Torque-based games.

Eventually, the artist(s) will start handing you the finalized art that you, at some point, approved. You have to decide to add it in immediately or wait until later. For best results, I think this is something that should be specifically allotted for as part of a milestone, preferably near the end of the project. The goal is to get the core gameplay and support systems as feature complete as you can before adding the art in. Then, go through each system and add it all in bit-by-bit, tweaking each system as you go. For example, after you add character models you will need to look for anomalies in the rendering, animation, and collision systems. You may get lucky and find none, but chances are that there will be border cases which you couldn’t catch with your placeholder art. Once you get the characters in, then move on to game objects, or UI components. The point is to work on one system at a time and not move on to the next one until it is complete. After growing accustomed to ugly placeholder art, it’s an amazing feeling to see your game world gradually transform into the final product.

The standard disclaimer applies, of course. This process may not be best for every developer, particularly in larger teams where artists are readily available and consistently pumping out art. But for small teams, or solo developers, who have to contract out one or more artists online, I think this a sensible and efficient approach. Adding the art in as you get it can be a distraction, particularly if it takes you away from something complex you might be working on (like AI), so having it scheduled as part of a specific milestone allows you to use your time as efficiently as possible. If you aren’t scheduling milestones during development… well, that’s another post for another day.

Technorati Tags: game development, indies, GarageGames, GameDev, game programming