Attracting and keeping artists on an OSS game project

Attracting and keeping artists on an OSS game project

Postby Danimal » 29 Apr 2014, 21:20

I saw this article in OGa and though to share it here: ... ment-28455

by Jetrel ... &sk=t&sd=a

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. ... 00018.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.

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.
User avatar
OD Moderator
Posts: 1322
Joined: 23 Nov 2010, 13:50

Re: Attracting and keeping artists on an OSS game project

Postby Wuzzy » 22 Sep 2016, 14:41

Woah, thanks a lot for sharing. I will keep this in mind should I ever start a serious (!) game project on my own. :)

Some general questions (to everyone here):
Do you have practical experience in working together with artists as a programmer, or vice-versa? I would am interested to hear your stories. Successes and failures alke. :) Especially if you have worked together with many people.

Can you confirm the points brought up in the post? Or doesn't it match your experience?

In other words: Do these recommendations made in the post actually work, based on experience? ;)

Also, final question: What can I do when an artist pops up and presents some of his/her work but later doesn't agree to license the work on a libre license (meaning it cannot be used legally in the project)? Is there any chance to convince the artist otherwise?
Got too many bitcoins? I gladly take them: 17fsUywHxeMHKG41UFfu34F1rAxZcrVoqH :-)
User avatar
Posts: 622
Joined: 28 May 2012, 23:13

Re: Attracting and keeping artists on an OSS game project

Postby Roots » 23 Sep 2016, 00:17

Wuzzy {l Wrote}:Do you have practical experience in working together with artists as a programmer, or vice-versa? I would am interested to hear your stories. Successes and failures alke. :) Especially if you have worked together with many people.

I've worked with artists on Hero of Allacrost for many years. Attracting artists to free projects is always difficult, as in my experience artists are much less willing to work for free than programmers, musicians, etc. are. One of the big mistakes we made in the beginning was setting our art requirements too high, which led to some unproductive efforts being made (best example: we tried to create different versions of sprites for the different modes of play). Often you'll see very young artists join free projects and their lack of maturity can cause some issues. For example, one young artist left after throwing a fit when he made a sprite, and another artists made alterations to improve it (totally missing the point of this being a collaborative effort).

I also think we took too long to realize that we couldn't make all the art on our own. We've been using more and more freely licensed assets from sites like for us to get by. FOSS projects share code, and shouldn't be shy about sharing artwork either.

Wuzzy {l Wrote}:Can you confirm the points brought up in the post? Or doesn't it match your experience? In other words: Do these recommendations made in the post actually work, based on experience? ;)

Absolutely everything is true. And I've worked with Jetrel personally, so I know that he knows what he's talking about.

Wuzzy {l Wrote}:Also, final question: What can I do when an artist pops up and presents some of his/her work but later doesn't agree to license the work on a libre license (meaning it cannot be used legally in the project)? Is there any chance to convince the artist otherwise?

Perhaps you should explain to them what the license means? We make it clear upfront to all artists on our project that they retain the full rights to their work and can do whatever they want with them. The only thing they agree to is to allow us to use it in the game under the terms of that license, with the understanding that other projects may also use it if they follow that license.

But if you've got an artist that is absolutely insistent about not licensing their work under a libre format, tell them thanks but no thanks. There's not much room for compromise here, and why would you want an artist who only creates proprietary work anyway? I doubt you'll ever encounter this situation though.
Posts: 96
Joined: 04 Mar 2010, 21:54

Re: Attracting and keeping artists on an OSS game project

Postby Julius » 23 Sep 2016, 10:35

Roots {l Wrote}:But if you've got an artist that is absolutely insistent about not licensing their work under a libre format, tell them thanks but no thanks. There's not much room for compromise here, and why would you want an artist who only creates proprietary work anyway? I doubt you'll ever encounter this situation though.

Sadly this is more common than you would think, but I agree, this is one of the things where as a project lead I would not compromise. Yes it is a hard decision to turn away great assets over licensing questions, but in the long run you will greatly benefit from it.

Otherwise, nice resurrection of the topic, kind of strange it never got much attention here when it was originally posted.

I have one more advise to share:
Insist that even "incomplete" models/art are shared from time to time under the final license. Too often I have seen artists posting nice screen-captures of their work and promising that there are just a few things left to fix and they will share it, just to never show up again. This is both bad from a community management point of view, as they will be asking when this great model that was showcased a few months ago will finally show up in the game, and also wastes a lot of effort as you start over from scratch too often. Yes, often a new artist will not want to touch another persons half-finished model over style and quality disagreements ("urggh, that edge-flow.... how can you work like that???") but this is not always the case and for example animations can be quite feasibly added by another artist later on. So insists and insist to share progress as actual source files as often as possible, as artists often do not know when something is "good enough" and will try to polish it until they loose motivation and then might forget to share it (especially those that mainly do the work as pictures for their Portfolio as preparation to get hired by a company).
“You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete” - Buckminster Fuller
User avatar
Community Moderator
Posts: 2172
Joined: 06 Dec 2009, 14:02

Re: Attracting and keeping artists on an OSS game project

Postby Lyberta » 25 Sep 2016, 14:54

It is also crucial to share *all* source files to qualify for Free Cultural Work.
Mental health warning.
User avatar
Posts: 388
Joined: 19 Jun 2013, 10:45

Re: Attracting and keeping artists on an OSS game project

Postby farcodev » 31 Oct 2016, 19:34

I worked only two times with artists for FAR Colony. I never really teamed up with them, they were punctual and specifics contributions, so I'm not much relevant here but anyway.

They were two success;
- the first one made many background pictures, with logos and all. It was even him who had an idea to use F.A.R. Colony :)
I never told him any specifications, excepted for one logo, because he asked me. In the end he let me license his work.
- the second one made some icons for the resources spots, I gave hime some spec on how I wanted the pictures and he made it.
I had no problem to license his work under a Creative Common too.

That's about all. The rest of assets are either fully made by me (I do badly 3D beside dev) or come from many free/opensourced sources like OGA and SolCommand, and modified by me, when necessary.

Beside licensing, one of the hardest thing for us the status-poor open-sourcers is to keep visual assets coherents between each others for a same project. That's one of the main problem when you use ones coming from multiples sources and inspiration and not specifically made for your game.
Also there are obligatory limitations for pictures and such; you can find a good picture to make for ex. a banner, but if you need 10 different of them you are screwed up and can only put placeholders and/or let it blank, as I do in some parts of the game...
Posts: 163
Joined: 09 Feb 2011, 02:52

Who is online

Users browsing this forum: No registered users and 1 guest