It’s been a while since the last blog post though, so I’ve missed the opportunity to post this gem from back in December (and #HurricaneBawBag)

How to get poor reception

That is our back-yard neighbour’s TV and ham-radio antenna, trailing a big sheet of polythene. Note the mangled and bent spokes, as a result of the polythene catching the wind like a sail and whipping around for hours, very nearly pulling the poor man’s chimney stack over. Not that last months winds can hold a candle to today’s storm though. It seems Mother Nature is angry with us this winter.

To other news: we’ve picked up a new client for the new year which promises to be very interesting – a variety of code support work on PC/360/PS3. In addition to our existing clients, that’ll mean our own projects will have to be put to the side for a little while.

After yet another acquaintance saw fit to share their mobile app idea with me last night, I realised that what we’re short on isn’t ideas, it’s time. What with all of our client work and flitting back and forth, we very rarely get a chance to get heads-down, all-out concentrated on our own apps. There’s nobody to blame for that but me really, but we are rather at the mercy of the paying work. Tim’s been doing a bang-up job in December of bringing our latest creation up to a releasable standard, but I fear it’s not going to reach the quality bar before we have to put it back on the shelf and concentrate on our clients’ needs.

In an ideal world, we’d be able to take our time, concentrate fully on bringing our ideas to fruition, and the money made from releasing them would pay for the next round of product-making. In practice it’s not as simple as that; client work is money in our pockets now, but app sales are money in our pockets later, maybe. Of course, that’s a vicious circle, without taking a punt on our own apps, we’ll never have the opportunity to win big and break out of the work-for-hire mold. But in the meantime we take the work that keeps a roof over our heads.

We’re coming up on the end of our 7th year in business now, which is no mean feat these days. I’ve just updated our entry in SDI’s Gaming Brochure list of Scottish developers, and it’s heartening to see all the small and large companies in there. Here’s to a bright and positive 2012, and to the opportunities it brings.

Conflicting Interests

[clauses 10.1 through 10.3, and 14.1 through 14.8]

Oddly, as an independent games developer, we’re not really in competition with our peers in the industry. Rather, we tend to work with them, collaborating where possible to help game ideas come to life, and celebrating their successes. But like any creative industry, the value in a company is in both its ideas, and its team. As such, there are issues which can arise that may cripple a business. A dispute with an employee may arise, causing them to leave the team acrimoniously. Any employee will take with them knowledge of titles under development, they may also have a close working relationship with a third party like a publisher. Such information can be abused such that the company loses out on business, and a healthy development can quickly turn sour. It’s not unheard of for a senior team member to leave, set up a new studio of their own, and not only poach staff from their previous employer, but also use their pre-existing relationship with a publisher to pick up a development deal, while the original developer implodes due to the sudden loss of staff.

In practice, such a situation is rare, and such a drastic failing would only be possible if the situation inside the developer was already problematic. But even on a small scale, such an event can be enough to seriously damage a studio, and so these clauses attempt to make clear what is expected from the employee. To summarise, the employee must a) not be involved (or get involved) in a competitor business, at least without declaring it to the company, b) not interfere with any of the business’s existing business relationships (i.e. no poaching work), c) not attempt to coax any staff to leave the company (i.e. no poaching staff), d) not give away any confidential information that might harm the company and e) not pretend to be part of the company after they’ve left it.

These clauses are more generally referred to as non-compete clauses, and can be difficult to enforce, as it depends on a judgement on what is fair and reasonable to both parties. The final sub-clause (14.8) reflects this, and essentially says that while the contract is trying to be reasonable, if any single part of the contract is deemed to be slightly unreasonable, then rather than rendering the entire thing null and void, the next most reasonable interpretation should be enforced.

This is especially important because employees cannot and should not ever be prevented from working after they have left the employ of a business. For this it is crucial that companies not try to enforce these clauses without good cause, as a loose interpretation of “competing business” would include every other game developer out there, and it is entirely unreasonable to try to prevent an ex-employee from finding work elsewhere in the industry. These clauses are there to get the employee’s agreement that they will not actively pursue a course of action that will damage the company.

Confidentiality

[clause 12.1]

Lastly, it’s worth noting that the employee is bound not only to keep any internal confidential information a secret, but that they are also bound by any confidentiality agreements entered into by the company. That is usually things like platform confidentiality (no talking about closed platforms like Sony and Microsoft’s), as well as any business to business agreements (no announcing to your friends that your team has just landed the next instalment in MegaFranchise, before it’s even been announced to the press that a sequel is on the way). And of course these obligations exist even after the employee has left the company, and there is no limit on how long they must be kept for. It’s also worth noting that if information becomes public through other means, the employee can talk about that – so when MegaFranchise 2 is announced to all and sundry, the employee doesn’t have to pretend they know nothing about it.

Summary

I hope this series has been useful, both to other small developers and to games industry employees alike. I found that, when we started out, all of this information was lacking, and we would have to hire lawyers to get set up. Even then, there are few games industry specific lawyers, so any information you can get for a reasonable price is usually from places which have no idea of the nuances of games development.

Lastly, if you are put off by the legalese in the document as is, you can go here for my rather irreverent but much more succinct summation of each of the clauses in the document.

Intellectual Property

[clauses 13.1 through 13.6]

Pretty much most of game development is about creating things. Creating content, creating game ideas, and creating code to realise the vision. Often the work is done on behalf of another party – a publisher or other client – who will actually retain the intellectual property of that work. If a developer is lucky, they are working on their own properties, and will retain the IP themselves. But in both cases, it is important that the relationship between any employees and the studio with regards to IP ownership is made clear. I won’t claim to be an IP lawyer, or that our T&Cs cover every facet of IP ownership. But they do lay out a clear basis for where the IP rests. Since each sub-clause covers a different major point, I’ll go through them in detail.

13.1

Basically, any IP created by employees, either on their own or as a team, needs to rest with (be owned by) the business, and not by the employee. Also, there is never a point at which the IP is owned by the employee, and then transferred to the business. All the IP created by the employees in their day to day work is the studio’s. This is not just a nicety for the business, it is a requirement, usually stipulated in all of the contracts with other parties. If you are developing a title for a publisher, the IP is passed to the publisher as part of the work for hire contract between the studio and the publisher. There is no room for some of the IP to be held by the employees, it has to all unambiguously be held by the studio, so that it can all be transferred to the other party.

Note this vital part to the clause: “while working on activities for the Company at whatever location“. One of the most important parts of the IP protection is that it balances the employee’s ability to create, with the company’s need to retain its IP without ambiguity.

I have in the past signed a contract which stated that whatever IP I created, regardless of whether I created it on company time, on company property or not, everything I did was owned by the company by default. Of course that means that any work I did at home, on my own machine, at the weekend, was theirs as well. This is unacceptable to most game developers – we all have our own hobby projects, and it’s vital to our morale and sense of personal creativity that we be allowed to develop those ideas. To have your employer effectively grab those ideas away from you, even if they don’t want them and never use them, such that you have to beg just to get them back, is stifling, unfair, and counter-productive.

I can understand the reasoning behind it: the same contract I signed also had the clause which said that I could be asked to work any hours, in any location, if the business needed it. If the company asserted that only work done during normal hours or on company property was owned by them, then any work I did on company projects on my home machine, or off-site in some way might be considered to be mine rather than the companies, even though I was clearly working on company business.

The phrase “while working on activities for the Company” is key here. IP created whilst working on company activities belongs to the company, regardless of when it happens, or where. IP created under any other circumstances may remain with the employee. While there is still scope for ambiguity, this should be minimised by having a clear separation between work activity and personal activity. Employees may do whatever they want on their own time, including being creative on their own personal projects. If they want to be creative on their own time that’s great, but it should be done outside of the office and on their own equipment, so they are safe from any possible insinuation that their work belongs to the company. In turn, the company can benefit from having motivated and creative individuals who don’t feel that their employers are heartless IP-stealing bastards.

13.2

This is a clause about fairness for the employee. If they come up with an idea or other piece of IP which they think is valuable, but which the company does not, they may ask the company to relinquish the rights back to them, so they can then use them as they see fit. This is often the case with game concepts – a game studio might see dozens or hundreds of game ideas from their team. Some are taken up, some might be taken up at a later date, but some might just be the wrong fit for the business, or just not something that can be made the most of. The company loses practically nothing by giving these ideas back to the employee, but gains good favour from that employee. Crucially, note the “for no consideration” part of the clause. Basically, if the employee asks for it back, it’s most likely they aren’t going to pay to do so.

If any IP is given back to the employee in this way, it should always be done so in writing, to make it clear what ideas are being handed off, and so that there are no repercussions at a later date. For employee hobby projects this isn’t a big deal, but any project that is a potential money spinner might cause legal wrangles at a later date if the relationship with the studio turns sour and the exact IP that was transferred wasn’t well specified.

13.3

Not just intellectual property, but also copyright needs to be transferred. Specifically, the business needs to be treated as the author of any created work, as it pertains to copyright legislation. So in this clause the employee is agreeing to relinquish any authorial rights they have. I’m not entirely clear on the details, but I believe that authors have the right to stop certain ‘detrimental’ things being done to their works by others. Obviously again this is a right which would make things messy unless the employee agreed up front to relinquish this.

13.4

Certain parts of intellectual property protection, such as trademarks, patents, etc. do need the involvement of a creator, in person. This clause stipulates that the employee must join with the business in securing those items, and in protecting the business’s interests (for example if the business needs to litigate against someone else who is infringing a trademark). There are two things that are key to note here: 1) the employee needs to help with these applications even after they have left the employment (crucial since such applications can take a long time), and 2) all the expenses and decisions are the employers (i.e. the employee shouldn’t be financially impacted by this responsibility).

13.5

This is simply a reinforcing clause like 13.4, pointing out that the employee needs to do whatever is necessary to make sure that the IP is assigned to the business properly, even after they’ve left, and that the business should carry any expenses incurred to make it happen.

13.6

This clause is the flip side to IP creation – it requires the employee to ensure, to the best of their abilities, that they aren’t infringing anyone else’s IP. As long as they exercise due care, they should be immune from any legal action directed at the business. That is, the studio can’t turn around and simply blame the employee for any infringement unless it is demonstrably their fault.

Next Time

And that’s it for IP. In the final post in the series, I’ll cover the remaining clauses which are games industry specific.

Our T&Cs have been ratified by our employment law consultants as being compatible with all current UK legislation, but they did not write more than a few sentences of it. The majority of the interesting clauses are very games industry specific, and on that they could provide no advice, other than to say that the clauses that were there did not affect the contract’s enforceability on unreasonable terms.

There are basically two thorny issues when it comes to employee terms: working hours, and IP ownership, each complex enough to warrant their own posts. There are also some basic company issues, which I’ll cover in a final post.

Working Hours

[Clauses 2.1 through 2.4]

For working hours, there are two main issues: 1) flexi-time/working-hours and 2) overtime. We state that our working week is 35 hours, Monday to Friday. Our office hours are 9 to 5, although in practice I don’t hold our team to that. Flexi-time is a good arrangement, but I believe it should be agreed amongst the team rather than trying to lock it down in the T&Cs. What is important is that teams know what hours they are expected to work, in any given week.

It’s not uncommon for companies to want to specify potentially unlimited working hours, for obvious reasons. The terminology to note, which we also use, is: “the demands of the business necessitate a flexible approach. This may require the Employee to work overtime and/or unsociable hours as required by the Employer”. Obviously this opens the door to massive abuses of the employees. The fact is, this is to cover the employer for when the s&*^ hits the fan. The critical milestone or gold master build absolutely has to ship on Sunday night, and all the stops must be pulled to get it done, or else the consequences for the business are dire. As much as we’d all like to get rid of it, in our industry we play fast and loose, and end up too close to the wire. What this requirement is not, and should never be, is a licence for the employer to have the employee working massive numbers of hours, week after week.

In the UK, the EU’s working time directive should kick in to prevent this, by insisting that no matter what, an employee can’t work more than 48 hours a week. In practice this is averaged over the last 17 weeks, making it somewhat tricky to find out just how many hours an employee is allowed to work next week. In the past there has been an opt-out, which employers have encouraged employees to sign, on the grounds that when they do need those last minute crunches, they don’t want to get caught out because employees have already worked too close to the limit. It’s important to note that a) you don’t have to sign the opt-out at all, b) any attempt or coercion by the employer that implies that you won’t get the job if you don’t sign it is thoroughly illegal, and c) even if you have signed it, you can retract that and opt back in at any point, by giving your employer a weeks notice. It’s all explained very thoroughly here.

I believe quite firmly that the opt-out shouldn’t even be considered. It certainly shouldn’t be mentioned in the T&Cs. I understand that it’s being removed anyway, and UK businesses will have to comply like everyone else. The plain fact is that employees shouldn’t be working anywhere near to the 48 hour limit, so there shouldn’t be any issue for the employer.

So back to our T&Cs – there is a note stating that we may need the employees to work over and above the normal week, but only in an exceptional case, and in those exceptional cases, the limits and consequences are clearly laid out. There is no room for abuse of the employee if the T&Cs are set out well. Exactly how the business chooses to deal with the situation is different for everyone, but it needs to be crystal clear a) exactly what the normal working week should entail, and b) what the employer and employee can expect if they need to work above normal hours.

We are a small business, and can’t afford to pay overtime to get things done. Instead, we operate a time in-lieu policy.

2.3 In the case of overtime, the time spent over and above normal working hours in any given week will entitle the Employee to time off in lieu of work to be done in future weeks. All overtime is at the discretion of the Employer, and must be agreed in advance. No more than 20 hours may be accumulated in any one month, and the time off must be taken in the following month. No entitlement can be carried forward without prior agreement. Any entitlement not taken will be lost.

In practice this gives us a lot of flexibility. If we need to work an 70 hour week one week, it needs to be balanced by not working at all the next week. If we were to work even 5 hours a week over the limit, by the end of the month 20 hours would have built up, and the employee may take them off, or agree to save them up for later. The key point here is that it allows the business to temporarily ramp up when we need to, while limiting the length of time we can do that for, and giving employees the choice as to how they want to handle it. If we need longer term crunch, we have to ask the employees (nicely), to accept the longer working hours. Conversely, the employee cannot simply accumulate a mass of time off in-lieu without the business agreeing to it.

At no point should the employee be working additional hours without an explicit agreement on how they should be compensated for it. Any vagueness in the contract can only lead to dilution of an employee’s recompense. Any promises of bonuses at a later date to offset overtime done now are just theoretical; and employees will often find that the bonus divided by the hours of overtime actually mean they are being paid below the statutory minimum wage for that time.

That’s a long enough post for now, next time around we will cover Intellectual Property.

This sort of debate annoys me, because it’s always couched in absolutes. In software engineering there are no absolutes. So I felt I had to respond when someone declared, without much in the way of context:

No they shouldn’t. At least, not unless your team ethos supports it.

Just like all of these statements about how things should or shouldn’t be done, there is a whole bunch of context needed before you can say whether or not a strategy is successful or not. You can’t just look at those stats and say “TDD is the way to go”, or “asserts should be everywhere and always on”.

Every last one of these tenets of development requires a particular way of working before it is viable and/or usable. Asserts are great, as long as the team ethos is to never (or nearly never) allow them into a live build. What do you think you get if you just turn asserts on everywhere, when the build is riddled with conditions which aren’t show-stoppers, but which result in asserts? You get designers and artists that can’t use the build any more, and everyone gets pissed off.

Similarly, what do you get if you have a team which is notionally doing TDD, but in fact many of the developers aren’t structuring their code to support complete tests, or have incomplete test coverage where it counts? You get slower development, without a great decrease in the number of defects, and now you’ve got less time to fix them when it comes time to ship.

People should stop looking for one-stop, quick fix solutions to the problems which all development teams have. Every last one of these solutions will a) make things worse if applied in a half arsed way, and b) stem from an underlying mentality which is “what can we do to improve maintainability, increase coder efficiency, and smooth out problems in our day to day development?”

Sure, read the stats, read other people’s techniques, but for the love of Mike, don’t try to just stamp a particular technique on your development team and expect it to improve your lot. Instead, take a long hard look at your day-to-day process, identify the root of the problems that your team actually has, and take small incremental steps to fix those problems. Repeat ad-infinitum (or until you ship).

More than anything though, make sure any steps you do take work with the team you currently have, not with some ideal team that you’ve read about. If you find yourself applying a solution which will only work if everyone has a certain mentality or set of skills, then you’d better make damned sure that your team has those things before you try to apply the fix.

Which is what bugs me about the whole thing. The product designers have added a whole mess of extra buttons, all of which adds to the cost of the product, to satisfy controllability that we really just don’t use. Even that last 5% of the time, if we didn’t have that extra controllability, we’d be able to just make do. It’s not a surprise to me that industrial microwaves have pretty much two controls: a dial for power, and a dial for time. Anything more smacks of designers trying to justify their own salary, or interference from people who don’t really understand their customers. To be honest even those two controls are overkill. A single button that adds 30 seconds to the clock and starts the microwave (if it’s not already started), and another to cancel. Simplicity.

This isn’t just a rant about our microwave. Okay, well maybe a little bit. But it’s a design principle that goes through everything, games design included. Understanding what your users want to do in the majority of cases, and give them just what they want, but resist the temptation to drown that out with other minor features. It’s not just user interfaces, it’s features as well. Even with the best interface in the world, games or tools that try to over-complicate things end up suffering. Not only do those features take valuable developer time to implement, they’re almost certainly going to increase the odds of those features adversely interacting with the important core features.

So why put in unnecessary features? Many reasons:

Of course it would be easy to take this advice, and ship a project with only a few features, claiming to be keeping things ‘clean’ and ‘simple’, even though they omit the features the customer is really most interested in. As always there is a balance to be struck. The important thing is to understand both the product/game you’re making, and the people who want to use/play it.

So basically I’m pleading with the game and product designers out there: add features sparingly. Not only do you keep your development costs down, you improve your chances of making a cleaner, more usable product, that fits better with what your customers want.

Suffice to say that while I’ve continued to work on CruiseControl.NET plugins, I’ve yet to write up anything useful that could be condensed into a blog post. My article on employee Terms and Conditions for IndieVision.net has been shunted to one side, again. I had a productive meeting on Friday with one of the developers of Visual Studio, making an effort to persuade them to include some games development friendly features with their next version (not 2010, the one after); hopefully one or two of them will make it in and I’ll have improved the development eco-system just a little bit.

But in general I’m still struggling with the long commutes to Dundee, and the limited amount of time in the evenings to be productive. So on that rather downbeat note, I shall finish up, and place a tick in the entry on my task list for “Development Blog”. Hopefully future entries will be more avuncular and jolly. Wow, how long have I been waiting to use that adjective to describe myself…

There are certainly good books on games design, GameCareerGuide.com I think has a few articles listing good titles. I couldn’t judge their quality as I’m primarily a programmer rather than a designer. However I’ve always thought that trying to learn games design by reading books (or even going to lectures in a design course) is a flawed way of doing it. You wouldn’t try to learn to play chess by watching videos of someone else playing; maybe once you’ve already got a good grounding in the subject and you know enough to realise how much more there is to learn. But until you’ve got a good handle on the fundamentals, it would just be a deluge of information, with very little context.

My take on it is that, rather than spend a lot of money on books on the subject, that one of the best ways to learn about game design is by evaluating games. That is, playing a wide variety of games, and taking the effort to critically evaluate and compare titles. There are titles held up as great examples in their genres, like Zelda: Ocarina of Time, Halo, Command and Conquer, Call of Duty, Fallout 3, etc. There are also games which try hard but just aren’t as good. As a designer, you’re expected to know why some games are good, and why some are bad.

If you can take a pad and pencil and write down what are the good and bad points of these games, and compare them against other games, then you’re learning the fundamentals of game design. Does the user interface feel good, or is it confusing? Look at the challenges in the game and evaluate them – are they fun? Do they allow players to learn skills, and feel like they are progressing?  Is the difficulty curve sensible? Is there sufficient challenge and variety in that challenge?

You can play a game and look beyond the immediate experience, to see the mechanics behind the game, and judge whether they work or don’t. You can look at several different games in the same genre and pick out what they have in common, and where they are unique. You can spot bad design just by playing a game, and then think of ways that you might avoid those flaws. Anyone can do those things, but a good designer is great at doing them. A good designer does that without even thinking, they celebrate the good in games they’ve played, and vilify the bad. And no-one can be a good designer without experience of games, lots of games, all different sorts of games. If you want to be a games designer, you should be playing as many games as possible.

The only other thing I would say, and it may sound harsh to those who come here hoping for insight because they want to jump straight in as a designer, but it’s better to clear up any misconceptions now. Practically no-one becomes a games designer as their first job in the industry. Really. I don’t think I’ve ever met anyone who was a designer as their first job in the industry, and I know a fair few designers.

The competition to become a designer is fierce, and it is very hard to prove your worth in an interview. Most often, designers start in another facet of the industry – most commonly in the art or programming side, but also sometimes from QA / testing – and while they’re at a studio in that role they can demonstrate their ability as a designer and persuade the management that they would be useful in a design role. And even then there are dozens of people at a studio, all of whom have varying amounts of talent in design, and only room for a few people in actual design roles.

So if you really, really want to get into games, then don’t focus solely on design, you need another role. At most studios, in most roles you will have some design input into the game you’re making, especially if you are keen and get involved in design discussions, even more so if your ideas are good. But if you’re expecting that you’ll do a Computer Games Design course at University X and then swan straight into a straight design role (even a junior one), then you are going to be sorely disappointed.

To be fair, this girl's been hard done by, as this image is used everywhere despite being a blatant photoshop job. But to indicate idiocy in all its forms, you can't beat it.

I refer potential applicants again to this post, although it should be noted that the unspoken rider to that post is that morons need not apply.

Isn’t that one chubby squirrel? Tim reckons that he just does the rounds of all the windows nearby, and lives off the generosity of the locals who like cute squirrels. He certainly doesn’t seem afraid of us…

Since rebuilding the repository revision by revision is always a massive pain, I’ve done some mucking around in the guts of the repository to get around the problem. And since my Googling of the issue has been less than helpful, I thought I’d post here to give a reference for anyone else with a similar issue.

Symptom:

Running svnadmin verify on the repository results in a “Checksum mismatch while reading representation”. The output here is misleading, because it will say something like “* Verified revision 23″ on the line before the error message. This means that it is in fact revision 24 which is bad. You will also find that if you try to dump the repository, it will successfully dump revisions 0 through 23, but then fail on 24. If you try to dump revisions 0:23 and then 25:HEAD like I did, you’ll probably find that the 25:HEAD revision doesn’t work.

Diagnosis:

One (or more) of the changes to files in the revision that is causing problems has a different checksum than the one that the revision file recorded at the time. So when svnadmin verify looks over the contents of the revision and recalculates the checksum it finds that they don’t match and tells you. This means one of two things: 1) the checksum recorded at the time was wrong, and the data in the revision/file is valid, or 2) the data in the revision/file is corrupt, and the checksum at the time was correct.

If the file generating the bad checksum is a text file, you might be able to look at the contents of the revision file and check if it’s noticeably corrupt. If the file is binary as mine was, that’s probably not an option. Even more so if the file is large (mine was several hundred MB).

2) seems to me more likely, so chances are the file in question is corrupt and you need to fix the data. But if 1) is the case, then all you need to do is fix the checksum. Either way you probably can’t tell at this point – so best to assume it’s gone and work from there, or at least treat it as suspicious and verify it against other sources for the data if possible.

Possible Solution:

If you’re happy to assume that file is corrupt, then you can get your repo back to a verifiable step by changing the checksum saved in the revision file to match the checksum which will be generated from the data as it is now. The data won’t change so you’ll still have to verify it manually or delete it later, but at least you can persuade the repository that you don’t care.

Process:

I’m assuming here you’re working directly with the server on Linux. I use Debian, so tools like grep and hexedit are usually available (although I had to install hexedit).  The same principles would apply on Windows, but the tools would have to change.

1) Identify the revision which is corrupt. This is straightforward – it’s the revision after the last successfully verified revision

2) Identify the file in the revision which has the bad checksum, and find the bad checksum in the revision. This is harder – the revision files (stored in /repository/db/revs) are binary, and in my case, huge. But grep is your friend here. svnadmin verify gives you the checksum that is currently recorded – this is stored in the revision file, right next to a description of the file. Here’s a grep command that searches the particular revision file for the checksum we’ve been given:

grep -e "79a1686d0dfb8618b8ccfc9eb7d74759" -A 3 -B 3 -b -a main/db/revs/24

384989609-id: 5cu.0.r24/384989609
384989633-type: file
384989644-count: 0
384989653:text: 24 75689685 293851064 294285337 79a1686d0dfb8618b8ccfc9eb7d74759
384989724-props: 24 384989543 53 0 113136892f2137aa0116093a524ade0b
384989782-cpath: /path/to/the/bad/file.exe
384989842-copyroot: 0 /

The number at the start of each line is the offset, we’ll use that soon. The cpath line is most interesting – this is the file you can expect to be corrupt. But it’s the :text: line that we need to change to get things working. As described here, (look for the section on the revision file format) this line is of the form “<rev> <offset> <length> <size> <digest>”. We don’t want to change the first 4 parameters – they’re most likely just fine. But the 5th parameter is the bad checksum, and we’ll need that in the next step.

3) Change the bad checksum to match the “actual” checksum which the svnadmin verify process is coming up with. Again, this is printed out when you run the verify. To make the change, I used hexedit, which thankfully doesn’t try to load the entire (huge) revision file into memory. You just fire it up, and press Return to enter the offset within the file to jump to. It wants it in hex, so a quick conversion turns 384989653 into 16F279D5. From there you can press Tab to switch to ASCII editing, quickly find the offending checksum and overwrite it with the new, valid checksum; then press Ctrl-X to save out the file and exit.

4) Re-run svnadmin verify. It should now successfully verify the broken revision and move on. If it doesn’t, check to see if the revision and checksum it’s failing on are the same – if they’re not then you have more broken files/revisions, and you should repeat steps 1 to 3 until they’re all gone. Hopefully there won’t be too many of them. And remember – just because your repository is now verifiable, doesn’t mean that your data is valid. All you’ve done is told the svnadmin tool that the checksum for the data you have is the same as the checksum it expects.

For us, really, it was a convenience thing. I studied in Edinburgh, and my first job (VIS Entertainment) was based in Dunfermline, so I commuted there for a while before they moved their office to Edinburgh. For 6 months or so I was seconded to the Dundee studio for a project, and the 2 hour commute each way took a real toll on my quality of life. Compared to that having an office in Edinburgh was a breeze, certainly much more social.

I’ve always loved Edinburgh as a city, it is an amazing city, with the warmth and personality of a smaller town, combined with the incredible history and range of night-life and culture that I think comes from it being a capital. So the best of both worlds I always thought. Glasgow is larger, but for me lacks charm and friendliness; Dundee has that charm and friendliness but lacks the same range of things to do that Edinburgh or Glasgow offer.

So all business motivation aside, I’ve always much preferred Edinburgh to the other options. When VIS went out of business in 2005, I had just moved flats and was committed to at least another 5 months of the lease. With that in mind, it was either Rockstar North, commuting to Dundee for a position with one of the various teams there, or trying to start my own studio as I had been thinking about for a while. With my own quality of life firmly in mind, I chose the latter, and started the studio, running it out of our spare room. The first 9 months or so was a struggle to find work, but I realised that there was a niche here in Edinburgh, for those developers who didn’t want to disappear into the behemoth that is R* North, but who (for personal reasons like me) couldn’t face shifting to Dundee, either relocating or commuting.

So rather than follow the herd and shift up to Dundee, I was determined to take advantage of both the personal enjoyment of living and working in Edinburgh and this talent pool. I figured that I would have a better chance recruiting people if I was running in Edinburgh, both experienced developers who wanted out of R* or Outerlight for whatever reason, and other people who would like to come and live in Edinburgh but who might not want to live in Dundee.

Of course, most of our business involves dealing with other games developers, and we do have a good working relationship with several studios up in Dundee. I do find that I spend a non-trivial portion of my time on the train up to Dundee to meet with those people, and that would be much easier if we were based up there with the other small studios. But many of our clients are down south as well, and so Edinburgh is well placed as a travel hub to get to all of those destinations.

Aside from the potential of easier collaboration with the many studios who are Dundee based, the other important consideration is premises rent. I gather that many of the studios who are tempted to the Seabraes developments are given massive discounts on the rent there, due to the council/Scottish Enterprise’s efforts to create a digital media hub. That’s a great thing, and certainly must weigh heavily on any manager who has to find space for their team. But for us, especially since we started out working remotely from home, this was never a pressing issue. When we reached a sufficient size where a shared team space was a good idea, we shifted out into our Palmerston Place office. By that point, with two developers, the proportion of our monthly outgoings which were rent was very small; with four developers it is even smaller. Salary has always dominated our cash-flow, and so rent price is less important than quality of life for the team.

We’ve been especially lucky in that both of our offices have come in at around 100 UKP per person per month, which even for Edinburgh is very cheap. Largely that is down to good fortune and timing, but it’s also because we’ve been prepared to look at non-traditional office spaces. Our first place was a room in a Georgian town-house in the West End of Edinburgh. The décor was fairly shabby, the services provided were minimal, but the place was nice; it had real character, and it was in a central location so that everyone on the team could get to it easily. There are plenty of pubs and shops and bus stops nearby, which makes it much nicer to work because you can get life stuff done. The new premises are set to be much nicer, the space is larger and it has a nice comfortable feel to it. The place is still being done up (hence the bargain rent), so it has many rough edges, but it feels like a good creative space. And again they are central so that quality of life is high.

The key thing I think for us is that the common feeling about Edinburgh (that property prices and rent are high) doesn’t hold up under scrutiny. We had quite a few options for office space, all within easily affordable price range, all central Edinburgh, all spaces in old buildings. The impression I get is that the myriad of old buildings in central Edinburgh have many quirky, odd spaces, which don’t allow the big, open-plan offices that companies seem to like these days. As a result, once your business expands beyond a certain size (10 or so people), it is very difficult to find a single space to suit, and so businesses have to go out of town, to spaces like South Gyle and Leith, before they find modern office-space that fits their specifications. And so the prices out of town rise, and there is a glut of small-sized offices slap bang in the centre of Edinburgh which keeps their prices reasonable.

As a small, creative business, we can make pretty much any office space work. We don’t have to have an open plan space, we would have been quite happy taking two mid-sized rooms in a town-house next to each other, and just wandering between them. So by being more flexible about the types of space we rent, we can fit into any of the odd shaped offices which central Edinburgh offers.

I realise of course that your questions are all relating to Dundee, and I’ve only talked about Edinburgh, but the answer to me is clear. We are based in Edinburgh, and unlikely to move, because:

1. Edinburgh’s great
2. Edinburgh’s cheap (enough for us)
3. Edinburgh has a talent pool we can take advantage of that a Dundee company can’t
4. Shifting to Dundee would make it easier to work with other Dundee businesses, but harder to work with everyone else

There are many good people and businesses that work in Dundee, and they probably disagree with me on the personal preference for Edinburgh as a city (in fact I can think of several off-hand who do, and tell me so on a regular basis); they would be better people to ask about why Dundee has been such a success. As an outsider, I certainly feel that incentives have played a part, but I think that probably a bigger factor is that the studios in Dundee are often started by Dundonians. And there are some very talented Dundonians, and the very fact that there are a lot of talented teams there already encourage more teams to set up alongside. So Dundee has a critical mass of talent, which itself helps to keep other talent nearby (its nice to know that if you’re relocating to somewhere like Dundee, that even if your new job goes belly-up, there’s plenty of other jobs nearby so you don’t have to relocate again).

The telling fact is I think that when one of those studios dies (e.g. Visual Science), the people involved with that will start up new businesses. The fact that those founders choose to start up again in Dundee and not relocate somewhere else does suggest that Dundee is a good place to run a creative team. Whether the incentives are forming an unnatural situation (i.e. those businesses would have moved elsewhere had incentives not been offered) or not is an interesting question, but one better answered by someone who’s started a business and chosen Dundee.

My only real mistake was to start reading some of the comments on the Dreamhost status blog regarding the move. Despite the fact that they were open and up front about the move – giving warning on the status page as well as by email more than 2 weeks in advance, they are still customers who feel free to bitch and moan in a most personal and horrific way. Seriously – this sort of stuff really makes me sad to see the sort of attitudes people have these days. Nowhere in the Dreamhost sales pitch does it imply that your 8 USD a month was somehow buying you a service that would be up for absolutely 100% of the time, and yet these folk think that even the best handled server downtime is grounds for some personal abuse. If I were running Dreamhost, I wouldn’t hesitate to respond to any of those “this is unacceptable” comments with “Oh I’m sorry, here’s a refund for the rest of your service, don’t let the door hit you in the arse on the way out”.

Anyway, trust in Dreamhost’s tech staff aside, my paranoia has been in high overdrive recently, so I had taken this opportunity to double check that our nightly backup procedure was working properly – and I was pleased to find it had. Which means that, should Dreamhost fall over at a critical juncture, we can fall back on our local mirror of the server and only lose work done since the previous night. Not that I’m expecting DH to fall over – they seem to have gotten on top of their random downtime issues, and since I’ve been tracking it with an external tool we’ve only been off-line for 4 hours out of the last 6 months, and no more than 2 hours in a single outage. Why don’t we just host our work locally and use an off-site backup? Well, we do a lot of collaboration with other client, and upstream bandwidth from the office is rather precious. That and the fact that Dreamhost already have quite a few mechanisms in place to restore connection and hardware problems, so they’re probably far more reliable than our local server machines anyway.

Of course, even that’s not enough for us, paranoia wise – not only do we have the primary copies in a well maintained place off site, and secondary copies in the office, we also keep physical (DVD) copies of the repositories in yet another location. Of course the first two are all automated, but the third requires me to actually go over and poke the office server to make a DVD and take it away with me. Unfortunately my attempts to train the local squirrels to do automate the process for me have been unsuccessful, but I have high hopes…

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.

In my view, the job of a back story for a game is to allow willing suspension of disbelief for long enough that the player can enjoy the game itself. If the game is fun, the player will remember the story with fondness, even if it does follow closely the plot of some more famous film or book. The key factor is that the story shouldn’t make the player cringe, and shouldn’t contain the kind of horrible glaring inconsistencies that they can’t ignore. Some of the most effective game back stories are the simplest. Mario has to rescue Princess Peach. Sonic has to free little animals from the evil Dr. Robotnik.

If you are going for a more complex story, consistency is more important than fleshing out details. Once you’ve persuaded the reader/player to make the first jump to your story, try not to force them to make any more. You might persuade them to accept that magic is real, or that technology allows you to move instantaneously between points, but don’t change the rules afterwards to suit some awkward bit of plot development. Choose your universe rules at the start, keep them consistent and simple, and then base your story around those rules. The player then has a nice consistent world view, they understand what’s going on, and they’re happy because there aren’t constant surprises.

If you omit details, the player will happily imagine the rest of the universe according to the basic world rules that you’ve established. Take Star Wars for example – you are shown a very small section of the universe, and the rest is simply implied. By not fleshing out endless irrelevant details, you avoid accidentally introducing glaring inconsistencies, and also avoid boring the player. Take it from the point of view of a character in your world. They don’t care about the mechanics of inter-stellar travel, they’ve been living in a world with it for a long time. It is mundane to them – they wouldn’t dwell on the details, they dwell on how it affects them. So don’t follow the Star Trek model of baffling the viewer with science details, instead show them the parts which affect them – e.g. travelling between point X and Y will involve hyperspace, and will take Z amount of time.

Basically it’s been a great experience right from the start – install went smoothly; all the parts feel solid and well constructed. The Wii-mote and nunchuck have a comforting weight to them, and don’t feel flimsy. I’ve been using the wrist-strap out of paranoia, but haven’t lost control of it yet. Last night was a wine fuelled extended session of Rayman with the girlfriend, who seems just as pleased and hooked by it as I am. I was watching her reactions to it carefully, as she’s really not much of a gamer; however she picked up the controls without any trouble at all, everything seemed natural and intuitive out of the box.

Rayman itself is a little esoteric, but the games make me laugh, and the lovely characterisation of the mad rabbits is fantastic. While I think it has some replay value, I think Wii Sports will probably get played more long term – especially with the fitness training thing. A lot of the Rayman mini-games and Wii Sports  games involve energetic movement, we were having to take it in turns to play as after a few we were out of breath!

Only minor gripe so far has been the fact that the News and Weather channels are offline, and that the Wii Shop channel failed to connect first time round. Other than that the experience has been great, and I’ll certainly be buying at least another Wii-mote (probably with the Play game) for multi-player fun. The girlfriend will probably be taking it to her family over Christmas as well for some fun games too.

Anyway, fan-boy ranting aside, I predict a glowing future for the Wii, and development on it. While the unique control mechanism is interesting and well implemented, I don’t see it standing in the way of traditional console gaming – since you can get just as much control from the wii-mote/nunchuck pairing even without using the motion sensitivity of the controls. I’d love to have the opportunity for us to develop on the platform, but we shall have to see what pans out.

Speaking of which – stand-alone Tremulous has finally been released! No more need to dig out the dusty old copy of Quake III you had.

Boy do I need a holiday though – its been 5 months straight now without a day off (or at least, not one that I didn’t have to make up at the weekend). I’ve been trying to put aside time for side projects (notably a game pitch demo using Torque and some more website work), but its all been taking second place to the main contract for Barco and some other part-time remote work. Not to mention all the paperwork and faff that goes along with the financial year end at the start of this month.

Still, coming up to the end of the Barco work at the end of this month – high on the priorities list are: getting VAT registered (so I can splash out on a shiney new lap-top), finishing up this game pitch demo, catching up on all the GDC/E3 footage, and a hundred other little things on the to-do list that I can’t even think about until I can get a good solid week-day in the office. But all of that can wait until I’ve taken a few days to relax, as I think I deserve a break…

Of course, game-to-movie conversions are always going to be at least a little cringe-worthy, even when the game story is good, the movie can’t fit everything in (like a book-to-movie conversion) and it loses its magic. At least movie-to-game conversions can expand on the movie’s plot and get you more involved in the world.

One good example I found recently though was the book that Raymond E. Feist wrote after the success of Betrayal at Krondor. I’ve never played the game (I know, I know, how can I call myself a gamer), but I can see the shape of the game in the book, and feel just how the various stages would map to quests and sub-quests; and how the character/group mechanics would work. You can even almost see the levelling mechanics at work in the character of Owyn. If only all medium crossovers were so effectively possible.

Update (25/09): Onto the front page now! My surreptitious linking from other places seems to be working.

For a brief synopsis, basically it’s shaped like a TV remote control (a rather small one) so it fits in your hand like a wand or a mobile phone. There are buttons all over it, and a d-pad, etc; but they aren’t the primary control mechanism. The primary control mechanism is internal sensors which detect the angle the controller is pointing. So full three degrees of freedom rotation, (including twisting). That immediately elevates it above the PC mouse as a pointing device (as mice can only support 2 degrees of freedom). So you’ve got a pointing device as flexible and instantly usable as a mouse, but in 3D. So all of those lovely fun little games that work well in 2D with a mouse (Pong, Tetris, point-and-click titles, etc.) can have their game-play mechanics extended into 3D without having to worry about controller dynamics! Not to mention, its apparently even more usable for first-person-shooters (a genre typically crippled by the average console controller) with the addition of a light, attached joystick to be held in the other hand. And I don’t think I really have to dwell on the coolness of a light-saber game based on a controller you can swing like a sword. Time to get that accidental damage cover for the fragile things in the living room…

Here’s a link to an external site with an advert for the controller (immediately underneath the main picture). Sorry the text isn’t in English, but I haven’t seen it copied many places yet. I’ll probably upda
te this entry if I find better links.

Anyway – wow again – I’m hoping other console manufacturers come up with clones or that this catches on. I’d certainly buy one for the PC in preference to my mouse for FPS games.

EDIT: more links

CNN
GameSpy
GameSpot

But I must say, this is in no way Rockstar North’s fault! People say that they made a mistake putting that content on the disc, but thats rubbish. If I were say, 1 month from beta and Design decided a particular bit of content should be removed from the game, would I:

a) Go through every build asset and code module and remove every trace of the content, then deal with all the bugs and other problems caused by such a major change (missing assets, broken links from other features which reused those assets, code flaws introduced by losing bits of code other modules expected to be there, etc.)?
or b) Flip a toggle in code which stops the user ever seeing the content, a toggle to which a legitimate player has no access, while leaving everything else in place.

I’m sorry, as a software lead, my responsibility is to take option b). If I went to a producer and said, I’ve got two options, one with possibly large and time-consuming consequences, and one with no ramifications which leaves a bit of unused material on the final master; I’d like to choose the first option, they’d laugh at me until they realised I was serious and then tell me I was an idiot.

If someone deliberately sets out to alter the game that we’ve developed and have had signed off, then how in the name of sanity are we responsible for what they do? If I make wooden spoons, and I sell them to a man who snaps one in half and stabs himself with the splintered end, am I responsible for it?

Brave had an unfortunate bug at one point which made him look really like he was humping a dead rabbit, until we added a few lines to fix the problem. If someone hacks our game to bring the bug back, do we deserve an 18 rating for bestiality/necrophelia? Or would such a thing be ridiculous?

This controversy isn’t about sex, or violence (even though GTA has them both in spades), its about responsibility. I refuse to be held responsible for what other people do to themselves using things that I’ve done.