So as I look out, bleary-eyed, at the huge puffs of steam being vented past our window by the building’s boiler, I’m kind of sorry that moving to a proper office has meant that I can’t just stay at home in the nice warm flat and work from there on frosty days like these. Still, the office itself is warm enough, it’s just the trip to it that means I have to brave the icy conditions.

Just read an interesting article here on longer term planning with the Scrum methodology. Good stuff, but there’s still the big chasm of “how do we get the publisher to sign up to this”. Until the people paying the money are okay with the less detailed milestone definitions that come along with agile planning, there will continue to be issues. It’s all very well running teams on agile internally, but until there is a solid contractual way of satisfying the publisher’s need for security with the developer’s need for flexibility, there will still be problems. At the moment the milestones are defined fully at the start, but it’s a naive producer that doesn’t expect the content of those milestones to change. It’s at the developer’s disadvantage though – the contract states that they are bound to deliver what’s in the milestone list, and if they don’t the publisher is within their rights to cancel the project at their discretion. They generally won’t, but it’s a quick get out if they want it. Even if the publisher and the developer both know that the milestones have become meaningless, when they’re written into the contract it means that there needs to be a re-negotiation to fix them again.

Personally I think it’s far better to start out with a high level statement of intent – that the developer will be working on a particular title for the publisher, and that they will use their best efforts to deliver builds of acceptable quality. The regular delivery of those builds is part of the process, and the method of arbitration as to what is ‘acceptable’ is written into the contract as well. That way the publisher still retains the majority of the power (control over what they deem acceptable), but they can’t use that control to avoid their responsibilities to allow the developer reasonable time to deliver something acceptable.

Okay, so we have had our Jobs page up for a while now, but ever since we started I’ve had a continual stream of emailed applications from potential employees. Some are impressive, some are not, but this post isn’t directed at any of them in particular. It’s intended as a guide to anyone else who is thinking of applying, so I’ll put a link to it on the right hand side.

First off, one of the biggest positive factors for a prospective employee is to show enthusiasm, both for developing games and for our company. We have this web-site and blog – it’s always been there, it’s fairly open. You could readily skim over everything on it in 5 minutes. So if your application clearly shows that you haven’t put in that small amount of effort, expect it to be either binned outright, or at least given short shrift. I make an effort to write a personal reply to every application, but the ones that annoy me get very little attention.

That point is at the core of why most applications that turn up in my in-box will fail, but I can sum the rest up in bullet points (most of which represent actual applications).

1. DO understand that you’re applying for a games job, not just a ‘software’ or ‘IT’ job. Those who end up at games companies are primarily those who have a real passion for games, and that comes through readily in a good application.
2. DON’T show ignorance of who we are and what we do. There are two of us, and we primarily do custom software development for other games studios. And yet we get applications which:
   1. talk about things like meshing with our organisation and looking forward to working in a large team.
   2. ask about jobs on our QA team
   3. are an impersonal email, even though the applicant worked with Pete and/or I at VIS
3. DON’T send a generic “please I would like a job at your company” email. This includes:
   1. not mentioning our company at all
   2. not making sure the cover letter is appropriate to our company,
   3. the worst sin of all: sending the exact same email to every games developer in Scotland, and leaving all of those email addresses clearly visible in the To: line of the email!
4. DO make sure your email and CV are free of spelling and grammar mistakes. Bad spelling and grammar says to me: “I’m so slack that I can’t be bothered to spend the 15 minutes it would take to look them over properly, despite the fact that I’m applying for a job that might be hugely important to the next few years of my life”. Frankly that’s not a person I’m necessarily keen to employ.

Paying attention to these details take a very short amount of time. There aren’t so many games companies out there that you can’t do them for every place you apply to. Personally I think for the potential reward (i.e. getting a job), they’re worth it. I’m sure more bad examples will appear in the future, so I’ll be keeping this post up to date.

One of the good things about my new, doctor ordered, walk to the office in the morning is that it gives me 20 minutes or so of un-interrupted thinking time. I can’t do anything, no-one is asking me anything, so my mind is free to wander. This last week we’ve been brain-storming development ideas for our own games, finally. Engine and tools work is all very nice and satisfying, but without a clear end-goal, it’s not so productive.

So Pete and I had a proper idea generating session last week, and settled on a plan for making a small game as a first step. Well, second step really – as an intermediate step we’re making Pong, on the grounds that if the engine can do Pong, then it has all the components necessary to prototype game-play for our real first title.

The walk to work this morning though was about coming up with the concept for the real game though – we had some good game-play ideas, but nothing to tie them together into a game. I’m very much in favour of the few-short-paragraphs-of-exposition-then-into-the-game approach (think Super Mario Brothers), but we still need that exposition to give us something to focus the game style around. And a name for our protagonist always helps to coalesce ideas around as well.