Legacy:How To Recruit A Programmer

The original article was posted by James Walkoski in a forum thread in Atari's UT2003 coding forum.

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:

1. How much influence will they have on the product based on what they want to work on, and what are 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 do 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 (five 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 delusioned that we won't give them the time of day.)
   Also, all sorts of other information need 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, have you done already? If you have nothing or just some concept sketches don't bullshit 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. 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.

Examples

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. Soma Studios have a good example of what will interest a programmer. All of their information is cleanly laid out and freely available. Their design doc is also very well written and concise: http://www.soma-studios.com/mark/mark_documents/cd_revolve.pdf (notice that the gameplay and features are at the start of the doc and the story is at the end)
3. Flowcharts. They show organization and thought and will increase the workrate of your programmers. Here's an example of a frontend flowchart:

Related Topics

• Mychaeel/Mod Startups – Things you should think about before making a recruitment post.
• Programmer Typology – There are two different types of programmer. Take your pick.

Comments

EntropicLqd: Heh – not a bad idea for a page. My very summarised thoughts on the topic are:

• The design doc needs to be as specific as possible. I wouldn't put a limit on its length. It does need to be as specific as possible. I don't care how much stuff I have to read as long as I can get a good feel for the scope of what I'm being asked to build. This in turn allows me to make a good judgement on whether I can commit to that amount of effort or not.
• In terms of front-end design, a bullet-pointed list of well described options is normally sufficient rather than the flow chart above. If the front end has been split into pages already then a page schematic with a bulleted point description of the options on each of the pages is sufficient.

Mychaeel: As I personally find making the software design to be the most interesting and fun part of development, I prefer if somebody has a clear idea of what he/she wants to do and how to get there, but doesn't attempt to dictate my every step with an overly specific design document.

Chazums: Details, i like details. how far? how long? how high? Its more irritating to have to go and re-do do code because people weren't sure and say "you decide" amd then come back with a "not like that tho.."

Mychaeel: Bad luck on the designer's part then. Not specifying something means they have to live with whatever the coder came up with. One more reason I prefer taking part in creating a design document simply because it's all too easy to end up with ambiguities or subtle intra-design contradictions if the design is made by somebody who is not very closely acquainted with the code creation process.

Chazums: Indeed, although i think getting art guys to make any kind of solid descision is an art in itself :D

Dante: I remember when some members in the mod I'm working for went nuts as we planned to move on to UT2003. I was the only coder back then - and they "suprised" me with their ideas. Yes, it's actually cool to have aircrafts with transport capabilities - and yes, it's also nice to have bots to fly them around... But wait - who is going to code all those things again ? - ARGH! And, I don't want to hear that "it's easy to code" stuff from people who can only do copy&paste coding, or less, anymore.

Foxpaw: I think it's good to have as specific a design document as possible. I do all of my own programming but I still make a design document for myself, and when I do I like to include everything possible, up to how exactly things will work. It doesn't include the actual syntax, but it will include all of the classes I expect to use and all of their variables that may be accessed by other classes.. I find this helps a lot to avoid running into a situation where you need to access a value in a class that you didn't think of and isn't easily procured.

Haral: As far as design documents go, I think the option I like the most so far is to make one out of a forum. Make a post regarding every specific area of the design and be very, very detailed. Think always of what the people implementing it will need to know. Don't worry about being too limiting, because you just put in one disclaimer: It's a forum. If you have a thought, reply. What you want is a complete design so that even if everything isn't the best, there's still something there. You don't have to rely on anyone thinking things up later. Then, as things go on, people can easily put in "this sucks, we should change it." Just edit the original post as solid decisions get made. Don't expect your design to stay the same either, as unless it's exceedingly simple, it'll cripple the lasting value of your mod.

MikeY: Hi lads, just wondering what prog you made the flow diag. in? I want to make one of these, I find it hard in photoshop, but thats probably to do with the fact i suck at it :) Thx.

Csimbi: Looks like a Visio drawing to me.

MythOpus: You could do it in word too :)

MikeY: Cheers, i installed visio, but i can't seem to get the connectors curved on the corners and i cant split the connecter, anyone can help?