Friday, August 19, 2011

How to get programmers to build your game aid

I was spurred to write this post dealing with a common issue when I read that Alexis over the Tao of D&D has a problem. He wants programmers to build him things but they just don't do it the way he wants. This he see's as a flaw among all graphic designers and programmers.


Now, this strikes me as an odd thing to try to pull off to an RPG crowd as both programmers and visual artists are quite heavily represented among RPG players. But the crux comes down to a problem I see all the time as a contract programmer. Best summed up by two contradicting statements:

SHUT THE FUCK UP ABOUT HOW YOU THINK IT SHOULD WORK. In this particular case, given that you don't know a fucking thing about what I'd like to do with this environment, just make it work like I want it to work.



Did you catch the problem?

When you get a musician to play a song you wrote. You have to write it as sheet music.

You can't hand a musician something like the following:

Yet.. this is what programmers tend to get. Sheet music contains a ton of technical detail about how EXACTLY you want the musician to perform the music. You don't write "A really high note" or a "really low note" or "really fast". You put specific notes, specific timing. You specify exactly what you want within the allowable framework (ie, no making up new notes).

If a musician tries to play along and perform a scribbled napkin of noise and poorly communicated gibberish, it will end up as Alexis is forced to deal with:


It won't work; it won't be like you envisioned (if its even possible at all), and it will be garbage.

Like sheet music for a musician there are specifications for code and applications you can provide to a developer. Learn them or learn to trust their interpretation of what you want. If they don't do what you want it may not be that they don't understand, it may be that you don't understand what you are asking for cannot be done in that manner.

But you may ask, why should I learn to write their technical specs? If you want to design a system and have others build it for you, you must. This is no different then learning to write sheet music if you want to write a song for others to perform.

I mention this because, given my history in the gaming industry, I am often asked for advice (or help) in building gaming applications. If you are serious about building a piece of gaming software you must learn one of three things:

i) How to write software (most difficult and most control over work)
ii) How to write technical specs (middle of both)
iii) How to deal with a developer's interpretation of your idea (easiest but most frustrating).

When you are looking to hire a developer you have two choices:

A) Gaming developers as a hobby (Grab bag of competence/passion and limited to no control)
B) Professional developer who probably doesn't care about gaming (able to select competence VS price ratio, and contractually obligated control). Note that option 2 is expensive. If someone provides better service than what you can get for free (which could be quite high in quality), they charge out the nose. They will almost certainly charge more per hour than you earn (statistically) and are unlikely to cut you any slack.

This information I imagine is useful to any trades person you are seeking (including Illustrators I would imagine, but any readers who do graphic work can correct me or write their own post for how to choose an illustrator, I will link it here).

I highly recommend you think about this before starting the next Obsidian Portal. This something that comes up a lot, not just in RPG circles but in anything creative (not just artistic, but new business ventures as well). This is something you need to understand before you invest money in development work.

And yes, I will build your game aide for you. I will do so as option B. If I am willing to work as option A, I will find you and offer to work on your awesome idea (and that does happen). Please don't assume an entire trade is incompetent, that is almost never the case and definitely not for one that needs results for pay.


  1. "But, just make the magic box do what I said..."

    I have worked too many times in shops where our customers (usually an internal to the company shop) had just the same attitude.

    I don't anymore...for the most part none of their competent programmers do.

  2. Great post.

    There have been times when I've outsourced a project and got back something that wasn't what I wanted -- but I had to pay off because looking at the spec I had written, it was *exactly* what I asked for.

    What you ask for and what you want had better be the same thing -- if they're not, don't blame the programmer.


  3. Amen brother. I can't tell you how many times I've gotten the napkin notes and then been chided that I didn't create something "exactly like I asked"

    select * from employers where clue > 0
    [0 rows returned]

  4. Alexis sounds like a joy to work with.

    One fruitful middle ground between ii and iii can be get a developer who's versed in iterative development, and be prepared to spend a lot of time guiding the project through its iterations. It may cost more time and money, but you're more likely to end up with exactly what you want without having to learn the skill of writing bulletproof specs, and you will probably get software that does at least something useful sooner. And whether it actually costs more depends on whether you compare just the initial budgets or the inevitable rework when your specs weren't as bulletproof as you thought, or your needs or understanding of them changed as the project developed.

  5. Heh - I've given musicians directions something very like what you listed above - it used to drive our classically trained keyboard player nuts sometimes - but, and this is the most important caveat here (and what supports what you are saying, actually), we were co-creating the music, not just handing someone something and then saying "you lackey, make the vision that is in my head" and then when it doesn't turn out exactly as you envisioned it, getting upset that the other person "doesn't get it" somehow. In the collaborative songwriting process, it was very rare that a song came together "exactly as I heard it in my head." As soon as you involve another person in a vision of any kind, you introduce variables and interpretations that have to be worked out. Why is that hard to understand?