Note: This topic has been re-named to aid discovery through search, as it contains some valuable information. The original title was "So you're a programmer?"

-----------------------------------------------------------

A question out to all the code-heads out there. I'd like to get a sense for what you as a programmer like to see out of designers to spend a few dozen/hundred hours on writing code for free. I'd also like to ignore the topic of the game design idea, we all want to build the next great game idea but I want to know the elements aside from money and design idea that has drawn you to a project. This post focuses on when you're reading the classifieds you're looking for something out of a team or the individuals to instill a sense of commitment and components to indicate a unified design idea but what are those components. In a priority list what matters to you?

I'll do a little addition to this to keep the post from continuing down the abyss-like spiral of venting frustrations, I'm sure its very cathartic for you all but this isn't meant to be the point of the post. I'm looking for positive experiences, constructive re-constructions of moments where you as a programmer have looked at a free project (no monetary incentive at all, money is for suckers anyways) and decided to join the project and what it was about that project that drew you to it. What are the classified "hooks" that matter to you? Fancy art, clean sound&music, that backdrop of a good story, team structure, learning possibilities, % completion etc. I'd like to know what you personally have been drawn to and why.

There is a wealth of knowledge here that is drilled into designers to suit the needs of the industry this post doesn't need anymore of this info (its all over the site if you need it) I've gotten a few decent answers but I'd really like to hear more personal experiences of useful situations for designers to add to their own toolbox.

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

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

As a solo indie developer, I'd be happy for a good game designer working for me.
By game designer, I mean someone who knows how to design the mechanics of games in a scientific way.

I'd be happy to have a dedicated writer with a degree in writing, or else proof (published works?) that he's actually a writer. Not a person who happens to write something. (I make art, that doesn't make me an artist)
I'd be happy to have a dedicated musician, artist, 3D modeler, scripter, etc...

I'd be happy to have dedicated level editors and map makers... IF they actually understand the science behind it. ([size=2]Given two hallways, one poorly lit, and one brightly lit, most players will travel down the brightly lit one first. Thus, make your 'real path' brightly lit, and side-paths dimly lit, so less-exploratory players don't get lost. Given a choice between a left turn and a right turn, which is the average player more likely to take? Around which corner can he better defend himself? Science of level design)

I'm not saying there isn't intuition in artistry, but an artist who doesn't know the science behind his art is usually a bad artist. Intuition + Creativity + Knowledge (science) + Experience = Awesomeness in any skill set.

Game designer does not mean, "Person who comes up with ideas for other people to make".
Game designer means, "someone who understands the ramifications of each decision he makes before he makes them, comprehending the entire vast system of intricate interactions that is a game".

A dedicated game designer probably wouldn't be in charge of the story, or the characters, or the art style, or anything like that. The story would be for the writers, the art style for the artists, the music for the musicians, and the gameplay mechanics for the game designer.

I'd love for someone to adequately explain in detail why changing the reload time of the sniper rifle in Halo 3 from 0.5 seconds to 0.7 seconds was beneficial. That is a game designer. Someone who constantly has in the back of his mind that it takes exactly 2.4 seconds for the player to do a complete 180 degree turn around in whatever specific FPS he's working on, and the effect it has on competitive play. This is the science of game design. It should be called "gameplay mechanic engineer", IMO.

Everybody has ideas, and it's not bad that so many people are creative. If you want those ideas to become reality, you need to either hire people to make it for you, learn to make it for yourself, or convince them to help you for free. One possible way of doing this is by learning a different skillset (like art), and teaming up with a programmer - you make the art for his game, and he writes the code for your game, maybe.

An artist is hopefully creative. If he is, he probably has ideas for games he wants to make.
A musician is hopefully creative. If so, he too has his own dreams.
A writer, creative. He has games he wishes could become reality.
A programmer, also (hopefully) creative. He also has his own game ideas.

So if the only thing someone brings to the table is a game idea, and nothing (money or skill in some discipline) that can turn that game idea into reality, why should the artists/programmers/writers/composers/animators/modellors/level-designers put their life on hold to cater to someone who's offering them nothing in return, in exchange for wasting the next three years of their life making a game that isn't the game they want to make?

"Idea person" isn't a job title - it's the very nature of everyone in the game industry, from the janitor to the animator.
"Manager"/"Leadership" isn't a valid skill you can offer, unless you understand the science behind leadership and have actual experience in it.

Most people on the internet saying, "I'll manage/lead the project", actually mean "I'll control the project to make people do things my way, because it's my ideas, and my ideas are more important and better than their ideas... they can just make the art/code/music for my idea, and make my dreams a reality. To heck with their dreams!"
Ofcourse, it sounds alot less selfish and silly in their head.

So, yes, I'm a programmer. One who bothered to learn a very real skillset, and invested time to study to acquire knowledge (science) in that skillset (programming). I became a programmer to make the games I want to make.
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?

If I, as the programmer, know more about "game design" then the game designer, I'll kick him off the team and do both the game design and the programming... which I'm already doing anyway (along with the writing, more than half the art, and the scripting and half the level layout and world design).
A game designer must bring real value to the table, otherwise he's just using me to make his project for him, and giving nothing in exchange.

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.

@AlterofScience I guess you'll never know. Not that I disagree on the whole but not exactly the pre-flight list I was looking for.

@jbadams Big list of stuff you don't want and plenty of "be good at you're job" but I think you missed the question's mark. I'm trying to get a clear picture of what you like to see from designers to achieve this list of expectations you've shared. Clearly a lot of what you're asking is entirely reasonable but when someone is posting an offer what sort prep work do you prefer to see before they post? What's enough to get you hooked and coding that day? Certainly don't sweat the length, I appreciate the detail. This is a post that should matter to a lot of devs that come to this site IMO. (On that note, I probably should have named it better...;)

@Tobl I agree, designers definitely need to know how to properly coordinate the talent to achieve the design whole and this skill is an incredible juggling job once the crew is in the thick of it but I'm going to try and steer us back on course a bit. You as a designer know you're design, but you don't know what the talent needs to appreciate the design and want to add to it (other then piles money and a brand new game genre that uses the latest in mind reading peripherals). The trick to creating a "perfect reveal" is an art I'm curious about here and I'd like to hear from programmers mostly because they speak with the machine directly and the project doesn't happen without that. Many programmers are a bit primadonna because of this (who can blame them?) and understanding their expectations (beyond the complaints) is very important to anyone fighting to see a game come to life. Even other programmers.

@Servant of the Lord Great naming convention change, I couldn't agree more that everyone likes to work with someone that knows their job. But I'm really trying to dig up the first stage of all those expectations of a designer. I don't think people should waste time on good ideas unless they're willing to work to make something better out of it. But "the reveal" is the key ingredient in the freeware world (especially on these jaded forums). I'm glad you bothered to gather some skills and I'm glad you're proud of them but they don't do anyone here any good unless that person can get you're attention and that's my aim in this post.

To give a bit of background on this question, I'm a character animator. I can bring anything to life with a chunk of free time (this isn't my own horn, I do a technical process that anyone can learn and should, game animation is always brutal) but if I want anyone to do anything but stare and react at what I create I need a programmer. So I'm eager to figure out how to get programmers to ignore the dollar signs and explore ideas. I know programmers have plenty of their own design ideas and have all dealt with unreliable devs on dozens of free projects that have gone no where. But like all of us here, they too keep coming back for more (though I think the reputation growth helps too). So I'd like to figure out upfront what they need because otherwise that's the stage I'll be at forever (unless I stumble upon a steady stream of hefty passive income it seems).

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.

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?

In that case, it depends whether the game-person-who-is-not-a-designer is wanting me to join his project, or whether they are wanting to join mine.
In either case, they must have some real skill other than an idea (as we've already covered), so I'm assuming this is so.

Regardless of whether they want to join me, or want me to join them:

• Passion and/or dedication. Either one or both.
  
• Good grammar, good spelling, if English is their native tongue.
  
• Not manipulative or controlling ([size=2]I'm personally not that manipulative, but I do have control issues trying to micro-manage things - this is something I try to change in myself, and something I don't want to encounter when working with others)
  
• Not whiny or complainy or overly argumentative.
  
• Not silently failing to speak up if they have a real opinion about something.
  
• After chatting once or twice via email, or PMs, or instant messengers: I want to get a good feeling about the person, and feel I can get along with them for the long-haul that a project requires.
  
• Openness and honesty.
  
• I don't care about their age, as long as they act maturer than their age.
  
  
  (Note: The above all have to do with the person's character)
  
  What I require, if they want to join me:
  
  
  • Solid examples of their non-idea skills. It needs to be good, but doesn't have to be professional.
    
  • Full understanding that I'm taking the lead on the project, and so have the final say.
    
  • Understanding that I do want their feedback on the project, even in areas not directly related to their skill, and am willing to listen to their suggestions and debate about it.
    
  • It doesn't matter whether they can only contribute 10 hours a week or 50, but 10 is minimum (I don't want to go long periods of time without hearing from them, and not knowing what's going on).
    
    
    What I require, if they want me to join them:
    
    
    • Solid examples of their non-idea skills. It needs to be good, but doesn't have to be professional.
      
    • Preferably multiple different categories of skills already present in the project (Art + Music, or Music + Map makers, etc...)
      
    • A solid concept, but it doesn't have to be completed down to the super fine details.
      
    • Overall goals and milestones need to be set, but the sub-goals and steps towards the milestones don't need to be figured out yet.
      
    • The project must have already been going for at least half a year (preferably a whole year or more), and have something tangible to show (lots of music if a composer, lots of art if an artist, lots of story if a writer) apart from the idea. ([size=2]This is to show that they aren't recruiting and expecting others to do all the work, but that they themselves have been doing loads of work even before recruiting)
      
      
      Requirements for the leader of the project I'd be joining: (Important enough that it needs it's own list)
      
      
      • The leader must not dramatically change direction too many times. He can't be overly indecisive either.
        
      • Polite, and willing to listen, but with enough boldness to make final decisions and veto my own and other teammates' suggestions when needed.
        
      • Must be putting in a minimum of 25 hours a week into the project, and preferably over 40.
        
      • He should be charismatic enough to hold the team together and keep them motivated, or else one of the other teammates should fill that role of the encourager... this doesn't necessarily have to be present at the time I'm recruited though.
        
      • He should be reachable at almost any time by instant messenger, or at the very least getting a solid response back within 24 hours on the private developer forums or email.
        
      • The willingness to trust that I know what I'm doing in my field of expertise, and to let me do my work... unless there are others on the team also in the same field of expertise (multiple programmers, for example), and they raise complaints about my work - then the leader needs to be able to sort out the facts from the fiction and remedy the situation.
        
      • He must be able to resolve disputes between team members, and keep team members focused and coordinated (the focus and coordination can be delegated to another person if the team is larger).
        
        
        I care more about the personalities and maturity of the people I work with than their skills, though I do require that they bring value, otherwise my time is wasted trying to get them up to speed instead of working on the game. They should bring equal or greater value than I myself bring, in whatever skillset. If I am not a musician but can make better music then them, forget it. If I'm not an artist but can make better art then them, no thanks. Ideally, they should be as good or better at their specific skills, as I am at my specific skills, but even if they are merely 'competent', I'd be satisfied. Incompetence because of laziness or false representation of their skill levels costs me more than it gains for me. A completed project should be a net gain for everyone involved, not a net loss.

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.