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.


Money

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.


The idea

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.


Reasonable expectations

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.

Art, documentation, pre-recorded audio, etc?

Good presentation of whatever you do have is very important, and it should be obvious that you are capable and committed to the project.

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 next week", where x is concept art, a video, a website, or whatever. Wait till next week and post with x included.

...wow, that ended up quite long, I hope it's helpful! Perhaps I should clean this up into an article at some point...

Sorry Mratthew for taking this a little offtopic (I'm not a programmer, or at least not mainly), but I really have to answer to this.

A designer who can either do art well or code well. Otherwise what good are they?

I can't really agree with that.
Yes, art and code are important for a game, but they're not everything. Content-wise, the most important things to add would be music and writing, followed by world-/leveldesign (two different things) and mechanics. Actually worlddesign and mechanics are also damn important, but yes I know, we've got more than enough of them.

But that's not what I'm aiming at. When you're asking what good they are, you're most likely referring to the guys who run around yelling "I've got the best idea ever, who wants to make it for me?" and then refer to themselves as gamedesigners because they've had some basic ideas in worlddesign and/or mechanics. But even though gamedesigners usually take care of the worlddesign, mechanics and sometimes also the writing, that's not what being a designer is about.
A good designer is neither good enough an artist to take the art-lead, nor is he good enough at coding to be lead-programmer. Instead he has intermediate skills in both of the fields as well as in any other field that even might play a part during the project. This basic understanding allows them the help out where needed, but way more importantly, it allows them to communicate with the whole team. Not just talking and exchanging images until the others somewhat get what you might have wanted to say, but actual, efficient communication. That is important, because designers are the people who coordinate the team and get everybody to work together instead of against each other.
The second task of a designer is evaluation and quality assurance. Not of (for example) the art itself of course, the artist is way more suited to do that. But what good are great art and great music if they just don't fit together and none of them goes with the mechanics at all? It's the designer's job to assure the quality not only of the individual elements, but of the whole project and to see as soon as possible if such conflicts should arise. And yes, he's also most likely to be the first one who notices someone seriously slacking of, but anyone on the project would have the right to give such a person a talk, should the situation arise.
And while I'm using large-scale-vocabulary all the time, the effects good designers have already take place in such small groups as four or five people, especially if those people should not know each other personally.

So, what good are they? Communication, Moderation and Evaluation, that's what good they are. (If they are designers that is, and not one of those vague-idea-guys)


Now that that's been said, I should mention that I'm studying design (not gamedesign, but interactiondesign). However, I would kindly ask you to not read that as me being biased (or at least not mainly), but as me knowing what I'm learning on my way to become a designer and what designers are actually good for.

bw,
Tobl

What do I want from a game designer? I want someone equally passionate and equally creative, if not more so, who actually took the time to learn the very real skillset of engineering gameplay mechanics, and the science behind it. I've put in my 7 years learning programming in-depth, where's his 7-years of studying player behavior and psychology, and the interactions of objects in a simulation?

(Emphasis mine.)

Agreed completely, but I just wanted to add that playing games is not the same as studying games and player behaviour. Beyond the fact that it shows your passion for the medium (which is an important quality), the fact that you've played video games for 10 years (or whatever particular number is mentioned) is not something a programmer will care about. Would-be team-leaders often tout some large number of years they've been playing video games as if it's an impressive figure, but honestly I wouldn't bother -- or at the least would recommend not making a big deal of it -- because it simply isn't really useful or relevant.

If you've actually studied these things as opposed to simply playing games then you should have something to show for it -- perhaps a blog with detailed entries on different mechanics, a paper outlining your findings from a survey, or even a relevant degree or other formal education.

Hrm, ok, I'm seeing two distinct questions there:

1. What preparation should a would-be team leader do before they try recruiting, and...
   
2. What, specifically, should they include in a recruiting post to best attract attention from the right people.
   

Preparation -- what you should do before recruiting

The short and general answer is "as much as possible". Set about the task of creating your game, and progress as much as possible until you can no longer continue without help.

You should have a firm grasp of your idea, and you should have it documented in some way -- often a design document -- so that you are able to show it to a potential programmer. This can still be high-level details rather than the nitty-gritty details of every skill, but it should give a clearly communicate the concept in a specific way; more detailed than "a shooter, but with x". If you've just thought of your idea, or only had it a couple of days ago, then you almost certainly aren't ready for a team yet. Take the time to refine and detail it.


If you have the skills to start your game by yourself in any way then you should do so. For some people this might mean starting to code, while others might start creating concept art or in-game assets. Once you begin recruiting, you'll use this stuff to show that you're useful, and that you have the drive the work on your project. If you've done a good job you'll be able to set yourself apart from the "idea guy".

If your skill is design you should mock-up your game, and if at all possible build one or more playable demos for different features of the game using software such as Game Maker, Construct 2, or engines such as Unity3d.


What you should not do before recruiting

Don'tmake meaningless technology choices that you don't properly understand. In some cases there's an unusual feature you need to have, but most of the time any number of different engines or libraries can offer you the same functionality. Don't limit yourself to looking for "a C++ programmer who is able to use C4 Engine" if it's possible that a Python programmer using Panda3d could do the job just as well. Just look for a programmer, and let them make those choices based upon your needs. The exception to this is of course if you're going to start programming the game yourself.


What should be in a recruiting post?

A recruiting post should be well written and neatly formatted. It should be free of spelling and grammatical errors and should be properly punctuated. You should use any formatting options available to help lay out your post.

Get the broad details out of the way quickly and clearly -- what broad genre(s) does your game belong to, what are the target platforms, and are you paying? Lead with an "elevator pitch" that quickly details the type of game you're trying to make and the unique selling points or unusual features that set it apart. Briefly touch on your own skills an involvement during your pitch: "I'm an %YOUR SKILL HERE% with %x% years of experience, and..." Don't drag on the part about yourself, and be honest about it. This whole thing should be two-to-three paragraphs at most.

Next it would be absolutely fantastic to share a link to a playable demo, great to embed (or link to if embedding is not possible) a game-play video, or good to share some media from the project. Only do one of these, and make it the best one available to you. Videos should be embedded if possible, and images should be embedded as thumbnails that can be viewed at a larger size if possible. If you're linking to a playable demo, provide a prominent direct link (and clearly state that's what it is), include at least one screen-shot and any brief instructions needed, and be sure to specify any requirements to run the demo.


Follow that up with your specific needs. Who are you trying to recruit, what skills do they need, and how will they be involved in the project? What will you be expecting of them? If there are any other team members you'll want to briefly detail who they are and what their roles are as well.


Next, detail what you've already done, and explain what you will be doing as the project continues. This is an excellent place to include some more media and/or additional links, but don't over-do it. Try to give a rough outline of how you hope the project to go -- when you would like to have a playable beta, when you might be able to release, a brief overview of how the game will be released and marketed, etc.


After that, other details on the game. This is where you might include excerpts of a design document and explain some of your unique selling points in more detail. You might include a short story excerpt. Be concise, but try to choose compelling content -- link to more detailed information, or attach it, depending on the functionality provided.

Finish up with some final media. In-game or concept art is great to put here, and if possible you should also link to a gallery and/or blog showing images from the game and detailing your progress.



Does that help?

Know the difference between your and you're. When you make mistakes involving contractions, you're painting yourself in a really negative light; It's not just a simple spelling error.

So if you program, what is it that catches your eye on a project, sexy screenshots of zbrushed models that belong in the next Gears game, my latest 18 000 x 18 000 pixel photoshop masterpiece, a library of tombs detailing item by item spec info with multipage skill trees and archetypes to match each branch, the next LOTR but screen written by Joss Whedon, John William's latest sit down with Ben Burtt, etc. I'm curious what elements (aside from money and along side a design idea that is worth posting) matter to you when a designer is posting in the classifieds.

I wouldn't really care for any of those.

Given enough time, anyone can create a show piece that "belongs" in a AAA title. Similarly, some great "photoshop masterpiece" is not a very good indicator of your overall ability to produce art for an actual game. As for a library of tombs/specs/skill trees: It all looks great on paper, but when you actually test the first implementation, it seldom plays that well. In other words: it's not that important, because it's typically work that can only be done after the base engine is up and running.

Story is completely irrelevant, from my perspective; gameplay should be the primary concern in the beginning.

I think many programmers would look for a core gameplay idea, which is well defined, but also flexible, along with completed art assets; they don't have to be "production quality", but they should be good enough to make people think: "... Ok, I believe that he could polish this into something market worthy.".

You could also try making screenshots: You don't have the game, but you can paint a screenshot of what you have in mind for the final product. Or, even better: Make a 10 second animation that clearly shows the basics of gameplay.