Disclaimer: I'm probably going to write as if I'm speaking on behalf of many (or all) programmers, because I feel it is the style in which I am best able to express these ideas, but the following is all based upon my own personal opinions and experiences. Other programmers may disagree with some or all of my points of view.
I know you wanted to look beyond them, but before putting them aside I'd like to expand a little bit on money and on the idea.
Obviously, it can really help your recruiting efforts if you're able to pay your programmer. We put hundreds (even thousands) of hours into learning our skill, and we have limited time available in which to use that skill. If you're able to pay for that time it's more likely a programmer will be interested in spending time to work on your project. However, not all projects can afford to spend much -- if anything -- and programmers are sometimes willing to work for discounted rates or even for free.
For a project to be considered without pay, it still needs to satisfy a couple of other money-related conditions:
- It needs to be fair. If you're not paying us then you shouldn't be getting paid either, or if there is pay involved you shouldn't be offering your programmer some small amount whilst others -- especially yourself -- get much more.
- Even if you're not paying for it, it needs to be obvious that you understand and respect that our time is valuable. You might be able to find a programmer who would be willing to work for free or at a discount, but they would be unlikely to do so for a project where people think programming isn't worth paying for.
- Beyond compensating people for their time, money also goes towards showing commitment to and belief in the project. If you're not paying your team -- programmers and otherwise -- then you damn well better show your commitment and belief in the project in other ways.
- You need to show that you're sensible and -- even if you're not an expert -- have a bit of basic business sense. If you're aiming for a commercial product then profit sharing is a nice thing to do, but you should be realistic about the fact that this doesn't count as paying your staff; they might not get anything out of such a deal for a variety of reasons including not completing the project, poor sales/conversions, or even running into legal problems either before or after release.
- By not paying your team members you're asking them to volunteer their valuable time to the project. You should be making a similar -- if not greater -- contribution of your own time. Skilled programmers will not work for the dreaded "idea guy", and as essential as an idea is, you should not expect us to attach more than a small amount of value to your idea; you need to be contributing some value beyond that.
You might also show both your commitment, belief in the project, and good business sense by saving up your own money in order to pay other costs such as licencing fees for tools and engines, website or repository hosting, etc.
In addition to grabbing the programmer's interest, the idea needs to be specific, detailed, and well thought-out. If you just have a general, high-level concept then you're probably going to have difficulty finding a programmer -- they have general, high-level concepts (and probably even more detailed ideas) of their own.
However, you shouldn't be expecting to simply hand over a design document and have it treated as The Word of God™ to be followed exactly to the letter so that the One True Game™ will result; that's code-monkey work, and you have no choice but to pay for it to be done. Any experienced programmer will be expecting that a successful game will be the result of an iterative process.
You need to be willing to share the idea. No skilled programmer is going to waste time privately contacting you on the chance that your idea might be good, you need to provide the idea -- or at least a substantial part thereof -- up-front to be assessed and hopefully gain interest. Don't suffer from "stupid paranoia", and don't be one of those foolish people who thinks every facet of their latest idea is truly unique.
So... what else are we looking for...
Clear communication (and good presentation)
For both designers and project leaders, one of the most important skills is communication, and our first impression of this is your recruiting advert and any documentation you choose to attach. You need to put your best foot forward:
- Take the time to use proper spelling, grammar, and punctuation. Don't use "1337" or "txt" speak, or unnecessary abbreviations.
- Don't just ramble. Take the time to properly structure both your advert and any responses. Use formatting options, and white-space including paragraphs, indentation, etc.
- Test any links you include to make sure they work correctly and take the time to fix them if they're broken.
Your contribution (you need to be useful!)
I covered this to an extent in the section on money, but your idea is not enough. If you're just providing an idea that you want made you're going to have to pay someone.
Otherwise you need to provide useful skills, and you need to be contributing as much time and effort to the project yourself as you expect from others. It does not count to say you've already finished your contribution by writing up the idea.
You might also be contributing to marketing, sales, etc., and that's a great skill to have that will really help a final product, but again it isn't enough: you need to be contributing something during the project whilst the programmer is also working on it.
Ideally, you might produce some or all of the art and/or audio for the game, or might be doing an equal share of the programming yourself. If you're claiming to have design skills that will be used throughout the project -- and again, having created the idea up-front does not count -- you'll need to be able to clearly explain what those skills are, and you'll need something (previous projects, demo games made with Game Maker, board games, card games, etc.) that demonstrates you're actually capable with those skills.
Understanding of the industry/market/processes
Programmers want to be confident that you understand the realities of the industry and market, and that you have some idea of the process that goes into creating a game.
Gaps in your knowledge are fine if you're both up front and honest about them and are willing to learn -- even better if you're obviously pro-active about it -- from others, but no one wants to work with someone who is completely ignorant or misinformed about how things really work. This is especially true if you stubbornly stick to your guns when provided with evidence to the contrary; it's fine to want to try an unusual approach, but you need to at least acknowledge it as such, and should never simply stick your head in the sand and refuse to change an incorrect belief.
You don't need to be an expert at everything -- you wouldn't need us if you were! -- but you should have at least a general idea of the entire process.
If you're not paying your programmers, you can't expect us to treat your project like a proper job. It's probably going to take longer than you might have liked, and you'll have to gracefully accept the occasional interruptions due to real-life issues or the opportunity for paying work.
You should also not be expecting to make a super smash hit game of AAA quality with hour upon hour of intricate storyline.
You should expect to face difficulties and to have to work really hard to see your project through to completion.
Honesty and integrity
We're more comfortable working with someone who is open and honest. Don't misrepresent yourself or the project, and don't try to rip people off, or no programmer will want to work with you, and you almost certainly will be caught out eventually.
A sensibly sized (i.e. small) team
AAA games are made by huge teams with massive budgets, and they have a lot of management and official policy -- as well as the incentive of proper pay -- to make that happen properly.
Successful indie and hobbyist games are usually the product of much smaller teams, often ranging from only two people up to a handful. Larger long-term open-sourced projects might have more contributors over time, but even then usually have a smaller active "core" team working at any one time; they also begin with either an individual or a much smaller team, and only end up with those larger numbers of contributors once substantial progress has been made.
If you're looking to recruit large numbers of people to an unpaid project, most skilled programmers will expect you to fail like many projects before and won't consider you. Trying to do this probably indicates unreasonable goals and expectations, and is in most cases indicative of an overly ambitious project.
Good presentation of whatever you do have is very important, and it should be obvious that you are capable and committed to the project.
Art, documentation, pre-recorded audio, etc?
The working demo or video of a semi-functional game is great to see.
Concept art that was specifically created for your project is good. Completed (or nearly complete work-in-progress) art is much better. Concept art that you simply collected from existing sources might help to explain your project to artists, but often isn't ideal and can sometimes be indicative of a lack of commitment; why not simply delay and save up to get your own?
Audio usually seems premature unless your project is to the stage of having a working demo or game-play video.
Detailed documentation is good, bearing in mind the notes above about iterative design and the understanding that your idea (and any design documents containing it) are not the be-all and end-all, and will not be acceptable as your only contribution.
Oh, and don't bother with "I'll have
...wow, that ended up quite long, I hope it's helpful! Perhaps I should clean this up into an article at some point...
: Fixed formatting after it was trashed during an edit.