At the time of this writing, open-source game projects stereotypically have a surplus of programmers, and a painful lack of artists. This has a strong negative effect on the community; many of our games are embarrassing to show off, and are attractive only to the small subset of the gaming public which doesn't care about art.

There's a certain "sour grapes" stance in the open-source and indie community that good visuals are a hallmark of bad commercial games; this sometimes is taken to the point of mild hostility towards good graphics. This article isn't a soapbox for the necessity of graphics; it's a scientific fact that most people are visually oriented and need good graphics to be able to comprehend and enjoy a game - if you're not willing to accept that, you're deliberately limiting yourself to a tiny ghetto of people. I can't help you with that - this article assumes you want your game to be enjoyed by as wide an audience as possible.

It is true that many commercial games have great art layered on top of bad gameplay, but this is due to strict deadlines, a limited budget, and a lack of 'natural selection' to weed out games that aren't fun to play - many companies pump cash and art into games which they only discover are difficult to enjoy, after having already dedicated enormous resources to them. They usually finish it without fixing it, because they can't afford to refactor their design, or are afraid of discarding assets they've already paid for that would be unused in such a change. The great news is that Open Source is immune to this by default; the very nature of open-source means that an open-source game will almost never gain popularity unless it actually is fun to play. Because of this, people will generally only spend time making art for fun games. Open-source also not only has no fixed timeline or budget, so it is at leisure to refactor whatever is necessary to make the game fun; in fact the necessity of being fun in order to get art generally means you won't be throwing away art assets until after you've finished all your refactoring and established a fun set of game mechanics.



The key to attracting artists is to get a lot of players, and advertise that you're open to contribution. Statistically, a certain fraction of your players will be artists. It's possible that if your game is aimed at certain subcultures, they'll have disproportionately higher numbers of people interested in art (this may, for example, include the fantasy/sci-fi community). In order to keep artists, you need to keep them motivated. Your artists are not being paid, so motivation is the only thing keeping them around. The moment it stops being fun or rewarding, they're usually out the door.

Make a fun game:
To get lots of players, and in turn, artists, make a really fun game. This is difficult, and entire books could be written about it - it is by far the most important thing.

Use common file formats:
Another important factor is to make your game use as open of formats as possible. I don't mean open in terms of the open-source community, I mean open in terms of "formats people actually have programs to work with"; these are often the same, but not always. The thing that matters is that people have to ability to completely prepare art for your game without using any special tools, and are able to pop it into the game and see it in action without any of your help. Generally, this means using formats like OGG and PNG, instead of using some sort of homebrewed custom format like most games did in the 90s. If you roll your own MOD-like music format, or your own custom way of storing bitmaps, no one will have the tools to directly make art for your game. They'll have to go through you to do it, and this will drive away a large percentage of contributors, because most people dip their toes into making art by just messing around with their own copy of the game.

By extension, most artists interested in making games actually have a certain amount of data-modding skill. You need your engine to be moddable; they need to be able to make their own levels, creatures, and characters - storytelling is usually the very part of game making that artists enjoy most. You can do this either by having a great editor, or by having accessible text-based files storing the stuff (many game artists are computer-savvy enough to edit text-based data files). Editors are better and can be used by almost everyone, but they're time consuming to make (especially for rarely-edited content types), and one danger in trying to pursue the holy-grail of having a GUI editor for everything is that some parts of game content are isometric to programming no matter how you present them, and are best left as programming. If you try to gui-ify them, you will at best end up with a graphical programming language, but will likely just create a disaster.

Instant Gratification is your friend:
Making the barrier-to-entry for contribution as casual as possible is really important, because it's usually only after they've tried making art for you, that a person will realize they love doing it. In most life activities, people don't decide they're going to do X, and then decide to like it. People try X casually, like it, and then decide they're going to continue doing it. If they don't have a chance to casually dabble in it, they don't get started. This is exactly the way most game-modders get started - frivolous dabbling with the included editors, which they find to be fun, and which snowballs into further work. This is probably the same factor that got everyone reading this article started on programming - you wrote something trivial in some friendlier programming environment, it worked, and the joy of creation kept you coming back for more. Instant gratification is really important - it creates momentum and motivation.

Instant gratification is necessary to keep artists motivated. If an artist starts making a kind of asset for you, it's important for you to get it into the game and visible to them as soon as possible. It's very exciting to get that kind of approval of seeing it in the official build of the game, and vice-versa, it's very damning not to have one's work put to use. Artists rarely understand how difficult programming is, and will usually assume that you're not putting their art in because it's not welcome. It's also agnostic to either art or code, that they are not you; if you've put it on your mental checklist to take care of in a few weeks time, they're not aware of that. If you're not immediately working with a contributor of code/art/music, they usually will stop making more. This is fine for an one-off bugfix patch, but this is a death knell for someone who sending you the first in what might be an entire game's worth of models or sprites. You must follow up, you must work with them and keep them engaged. Almost all contributors who might contribute a whole game's worth of art will be lost if you don't get back to them in the space of a week - preferably a few days. This strongly speaks in favor of a RERO (release early, release often) policy.

Artists can't compile:
A related part of this is that artists can't compile your game. If official releases are more than a month or two apart, you must supply them with releases; they can't be stuck in a ghetto of outdated versions, because they'd be excluded from anything new that's going on. They're a part of the core team, and they need to see how their stuff works with new changes as well. It's also mandatory that you have releases for their platform; I know that linux programmers usually won't have a way to make a mac binary (for one example). But if someone comes offering art, they'd better get one damn fast, because if they can't play your game, they're not interested in helping you. In fact you generally need to have mac and windows builds of your game publicly available, period; if you don't, the entire 99% of the rest of the computing world will not play your game, and will not be interested in making art for it. (Macs in particular are important to target because like the Amiga platform in its heyday, macs have a disproportionate number of artists and musicians.)

Prove your game will succeed:
Artists are usually gunshy of hotshot "sky is the limit" game plans. They're a dime a dozen. Most videogame projects (open-source or commercial) are unfinished failures, and most artists who have an interest in doing videogame art will have tried contributing to at least one project, and will have been burned by the project's collapse. All of their work went to waste. The problem for them is that most artists have no means to judge the skill of a fellow programmer. Most programmers can quickly look at a project and judge whether the codebase is tenable or doomed, but most artists have only word of mouth to go on. They have no clue if you've got what it takes. The only way they can know is if you've basically finished the core of gameplay. Like in "return of the jedi", the death star doesn't need to be finished, but it needs to be "fully functional."

This is good game design practice anyways, doing rapid prototyping, and hammering out a functional core game as soon as possible. But it merits being said because I can't count the number of times I've seen game projects that are little more than a launchpad for Architecture Astronauts. If your primary focus is AI development, and you're not really serious about getting the game done, don't bait-and-switch potential contributors by saying you're a game project. If you're not serious about it, but claim you are, in the secret hope it will just magically come together, screw you - the people who are making art for you generally ARE serious (or they'd just be posting on an art gallery site like DeviantArt instead). Only advertise yourself as a game project if your primary goal is finishing a nice and polished game.

http://www.joelonsoftware.com/articles/fog0000000018.html

Artists need authority over art:
You may have very strong opinions about the visual look of your game. If you're not doing any of the work on the art, though, you need to shelve these opinions. Your artists will usually only enjoy their own style of art, and they're not being paid to make stuff for your game, they're only doing it because they enjoy it. Either you do it their way, or you don't get art. This is categorically different from commercial games. You're not their boss, you don't get to tell them what to do. Artists need to have complete carte-blanche over the art; in exactly the same way that you, the programmer, have complete authority over what language to use and what coding-style to employ. You'd be rightly incensed if they told you to change those, and any case of you telling them to alter their work for reasons of style is a violation of the things that make the work enjoyable. No enjoyment, means no artist.

The relationship on a game project is a short-term marriage. Like in a real marriage, you may need to avoid getting married to an artist who is doing something you hate. If you're making a videogame, and you have an artist trying to contribute in a style you personally can't stand (such as anime), you might need to turn them down. It's best to be forthcoming about that; the last thing you want is a ticking time-bomb. It's a tough choice; you might not get art if you turn that person away, but you'll need to make the choice, and be true to it. It might be worth it to tolerate something you only mildly dislike.


You need lead artists:
One obvious problem, though, is what do you do, when you have different artists who are pulling the game in different directions? You do exactly what is done with code; you pick the ones doing the most and best work (and who seem to have decent plans for getting the game done), and let them be dictators. If they're really doing the lion's share of the work, it's not a loss for them to drive away people who refuse to agree with them, and they'll ensure that everyone who is willing to contribute is contributing everything in a nice, uniform style and quality. In other words: you'll begin to look like a commercial game. This ownership and authority will also feedback into this artist's motivation; they'll usually feel driven to work harder and deserve being in charge of the art.

The best thing is when you snag someone who is as gung-ho about making your game as you are - but wants to do art instead of code. In other words - it becomes their game, as well.

It's important that if you get someone like this, that they have authority to actually remove pieces of poorly-done, or out-of-style art from the game. Yes, it feels wasteful, but commercial companies do it all the time; it's why their games look so nicely uniform in style. It's the same reason coders trim away stuff during a refactor. You only want to do this once they've proven that the net gain of their presence is creating more art than they'd want removed - but this is exactly as it would be with code. You don't just follow the orders of any coder who walks into your project and declares that the whole thing needs to be rewritten; they need to prove that they know what they're talking about, first.

You can have more than one lead artist - if your artwork is split into obvious categories that require different skillsets, then your artists will naturally form into different groups based on their skills. Many excellent illustrators are completely incapable at 3d-modelling (and vice-versa).


You don't need concept artists:
At least, not as a separate, distinct position. Concept artists are an artifact of commercial companies which throw money at the problem of "being creative". They're ultimately a form of leadership; they create concepts which other artists reinterpret as useable assets in the actual game. This level of specialization is usually quite wasteful, and robs many of the "follower" artists of the right to be creative on their own (which is fun, and which is why they'd want to contribute without pay to a free project). They put up with it on commercial projects because they're getting paid, but they usually don't like it - they're being forced to make exactly what the concept artist came up with, and they usually don't get to add their own flair to the design.

What you need are artists who are good at creating useable assets. Without these, you don't have a -game-; if all you have are concept artists, their art is just a bunch of pictures that can't actually be integrated into the game. The pictures are useless by themselves. What's nice, is that most artists who can create useable assets will have some level of ability at creating interesting concepts as well. This might take a little while for them to develop, but it's the most enjoyable part of developing as an artist, and practically all of them will grow into it over time. Also, a group of artists as a team will usually have enough creativity between them to provide most of the benefit of a real concept artist; certainly more than enough to float a decent game design.


Artists benefit from an environment of technical critiques:
There's a sizeable number of primadonna artists out there who consider art to be 'above' criticism. It's generally wise to identify and show those people the door as soon as possible. Even if they're good, they'll do more damage than good to your project; game projects are a marriage, and that needs to be bridged from both sides of the gap, the artist side included. What is true about art is that although there's a large amount of stuff in art that's a matter of subjective opinion and taste, there's also a large amount of stuff that can be judged on an absolute metric of quality. Art takes a lot of acquired skill to do well, and some people just suck.
http://www.paulgraham.com/goodart.html

Even those who are decent or good often make technical mistakes in their drawings. Limbs that are out of place. Poses that are awkward (because in reality they'd be impossible or uncomfortable). Perspective that would make Escher scream. These things weren't done as a matter of style or conveying the artist's message. They happened because the artist screwed up. They're the kind of thing that will make the work look stupid, even to that very artist who created it, once they realize what's wrong. People should keep their opinions on style out of things, but a healthy environment where it's okay to criticize actual mistakes is good for everyone. It will make your art better. It will allow your artist to improve. It will make your artist feel like he/she is being treated fairly. It encourages a healthy dialogue about the creation of the art for the project; rather than a stilted one-liner about how their latest piece is "nice".



In sum, treat artists (or sound designers) as your equal partners in the creative enterprise of game development, and you'll eventually pair up with at least one who is as gung-ho as you are. In order to do this effectively, you have to understand where they're coming from, and make special efforts to make your project accessible to them. You also have to embrace that once they start putting man-years of their effort into the game, it's as much theirs as it is yours.