I posted this in another tread and someone suggested that it be reposted to become a sticky. Given the number of recruitment posts in the last few days I figured I should get to that.
The absolute first thing that enters into a coder's head when they see a recruiting post is: "Why should I work for this guy?" It is not "Wow that is a cool idea" or "I wish there was a game like that I could play". Rather, "Wow, that sounds like a lot of work".
Before someone who knows what they are doing is going to sign up you need to provide them with some very important information like:
1) How much influence they will have on the product based on what they want to work on and also the technology limitations. We can do anything on computers nowadays. The question is always whether or not it is a good idea.
2) What skills you have aside from 'designer'. Anyone can have game ideas. If your only task for a project is to design it you had better have a design doc (5 pages or less) written and available and we'd better not have to email you for it. (Like someone said above, inherently lazy and anyone who thinks they have an original idea worth protecting is so delusional that we won't give them the time of day)
Also, all sorts of other information needs to be documented as well. Weapon sheets and descriptions, game and front end flowcharts, etc. Otherwise the programmers will be waiting on you for stuff and the last thing you want to do with their valuable time is squander it.
3) What, exactly, you have done already. If you have nothing or just some concept sketches don’t bull**** us. We will know. In fact, before you go searching for programmers it would be a good idea to have placeholder packages made with temporary art that is named correctly. I could go on for a few pages about how important that stuff is to us. Suffice to say, as far as your programmers will be concerned placeholder art is more important than the final art.
I know that may sound odd or confusing but just trust me on it.
Ok, enough of the vague concepts of what to do here are some specific examples to help you out:
1) Spell and grammar check your post. These kind of errors are easy to catch, but immediately discount you.
2) A website with all of the information that is easy to read, cleanly laid out, and freely available. The gameplay and features should be at the start of the doc and the story at the end.
3) Flowcharts. They show organization and thought and will increase the work rate of your programmers. Diagrams of interface screens are also quite helpful.
The absolute first thing that enters into a coder's head when they see a recruiting post is: "Why should I work for this guy?" It is not "Wow that is a cool idea" or "I wish there was a game like that I could play". Rather, "Wow, that sounds like a lot of work".
Before someone who knows what they are doing is going to sign up you need to provide them with some very important information like:
1) How much influence they will have on the product based on what they want to work on and also the technology limitations. We can do anything on computers nowadays. The question is always whether or not it is a good idea.
2) What skills you have aside from 'designer'. Anyone can have game ideas. If your only task for a project is to design it you had better have a design doc (5 pages or less) written and available and we'd better not have to email you for it. (Like someone said above, inherently lazy and anyone who thinks they have an original idea worth protecting is so delusional that we won't give them the time of day)
Also, all sorts of other information needs to be documented as well. Weapon sheets and descriptions, game and front end flowcharts, etc. Otherwise the programmers will be waiting on you for stuff and the last thing you want to do with their valuable time is squander it.
3) What, exactly, you have done already. If you have nothing or just some concept sketches don’t bull**** us. We will know. In fact, before you go searching for programmers it would be a good idea to have placeholder packages made with temporary art that is named correctly. I could go on for a few pages about how important that stuff is to us. Suffice to say, as far as your programmers will be concerned placeholder art is more important than the final art.
I know that may sound odd or confusing but just trust me on it.
Ok, enough of the vague concepts of what to do here are some specific examples to help you out:
1) Spell and grammar check your post. These kind of errors are easy to catch, but immediately discount you.
2) A website with all of the information that is easy to read, cleanly laid out, and freely available. The gameplay and features should be at the start of the doc and the story at the end.
3) Flowcharts. They show organization and thought and will increase the work rate of your programmers. Diagrams of interface screens are also quite helpful.
Comment