So I hinted last time about my continuing disappointment with the IGDA, and promised a more complete write-up of why. It seems though, just to take the sting from my tail, they’ve chosen this month to do something useful. So that has cheered me somewhat. It doesn’t erase the failings of the past, but it at least gives me hope for the future. Here’s a summation of my last couple of years of impressions of the IGDA.

[EDIT: the original draft of this article did not mention the IGDA press release made a week after the Rockstar San Diego Gamasutra post mentioned. Thanks to Erin for pointing this out in the comments, it’s definitely pertinent information, and in the IGDA’s favour.]

Credibility Hit #1: Mike Capps and working hours

This was the incident which prompted my previous posts: a board member, who had become aware of the IGDA’s efforts to work towards more sensible working hours, and didn’t agree with those efforts. Now, fair enough, the best (indeed only) way to influence policy in an organisation like the IGDA is to get involved, and he’s forthright about why he joined though:

But yes, I’m familiar with that [IGDA QoL white paper]. In fact it’s one of the reasons that I joined the Board in the first place. Because when I ran for the Board it was right around the time of “EA spouse” hitting and there were certainly organizations that were not taking quality of life seriously. But I thought that the efforts of the IGDA SIG task force were really misguided.

His stance ran completely counter to what the IGDA had been campaigning for. When pressed, the IGDA had the choice of standing by their original position, or defending what Capps had said and done. They chose the latter, which to me invalidates all they’ve stood for. Worse, individual board members made statements which pretty much supported Capps’ views, although many of them were later retracted.

Credibility Hit #2: IGDA and Rockstar San Diego

A chance to redeem themselves came in early 2009, when the wives of various R* San Diego employees got together and threatened legal action against their husbands’ employer. Not the best of moves admittedly, but a move borne out of frustration and an inability to help their situation any other way. After a week, the IGDA posted a press release which nodded to the Gamasutra article, and re-iterated their position on QoL, without outrightly accusing R*SD of anything (understandably so). This I can’t disapprove of, although I felt it could have been far more critical, and should have called for R*SD to respond publicly to the accusations made against them.

However I was worried by the immediate response (on the day of the article) from the IGDA, in the comments, as represented by Erin Hoffman. In it she voiced vague moral support, followed quickly by claiming that things were better than they were 5 years ago, defending the IGDA against criticisms about its inaction, and seemed to be blaming the developers for not asking the IGDA nicely for help.

It is an inflammatory red herring to call attention to the IGDA in this case. I have sat on the IGDA’s Quality of Life committee since it was formed and the ECQC since 2005 and its formation. No one from Rockstar has ever once contacted either group, nor, to my knowledge, sought advice from the IGDA on this issue at all. I have individually spoken with multiple Rockstar San Diego developers over the years and have known that this was brewing, but until someone was willing to do something about it, there was nothing to be done from the outside.

The QoL SIG has achieved very little over the years, and it seems very much that it is content to sit and debate the issue, without taking any active steps. What role does it have, if not to act as an independent voice through which the development community as a whole can criticise the actions of studios who abuse their staff’s quality of life? They shouldn’t be waiting for permission.

If there’s even a hint that conditions like this exist at a studio, it’s time to make a carefully worded statement condemning such practices, and asking the studio in question to defend itself: either by debunking the accusation, or by coming clean and apologising for the way things are (and explaining what they intend to do to fix them). The IGDA is one of the few organisations in a position to bring these practices into the light, and by doing so help us start the conversations needed to fix them. I was cheered to see their statement in January about Kaos studios and a similar situation. This should be the norm, and I hope to see more of it in the future.

But at its heart, the IGDA’s position is inherently unclear. Are they representing the individuals, the staff, who develop games? Or are they representing the studios (a large chunk of the IGDA membership is from ‘studio’ memberships, where every developer at a studio is a member only because their studio is a member). When it comes to Quality of Life, those two groups are in tension, and in trying to represent both, the IGDA would represent neither.

Credibility Hit #3: Tim Langdell

More trouble on the IGDA board. A member who not only does not represent the games industry, but indeed is someone whom the games industry is actively ashamed of. Someone quite happy to use the fact that he was an ‘IGDA Board Member’ to bolster his own reputation. Elected in March 2009, eventually forced to resign in late August 2009. His underhand tactics and practices regarding abuse of tenuous trademarks have since been thoroughly exposed, documented, and now thanks to EA of all people, consigned to history. But I mention this here not for those reasons, but because even once the full extent of Tim Langdell’s business practices were exposed, the majority of the IGDA board not only condoned his actions, several of them even defended him. Much like the Capps affair, it seemed clear that the IGDA board would stick together, regardless of their members actions.

The resulting furore and outright uprising on the IGDA forums should have been ample indication to the board that they had royally pissed off their membership, and that they needed to do something. What they did, sadly, was to first ignore, then to suppress the discussion, by locking threads and deleting the increasingly shrill posts condemning their actions. Month after month, it dragged on. Those most passionate about the whole affair demanded that Langdell be removed from the board, but the board refused to do consider this, stating that the IGDA membership would have to raise a petition before they’d consider it. But, they wouldn’t consider the forum thread a petition, nor would they consent to actively poll their members on it. Eventually, those involved had to scrape the membership’s email addresses from the website just to solicit the membership opinion. Very quickly thereafter, the support for Langdell’s removal (or at least a proper vote on the matter) was irrefutable. Only then was the IGDA board even starting to acknowledge that Langdell’s position might be untenable.

Throughout this whole affair, I was flabbergasted by just how disconnected the board was from its membership. If this is how the IGDA as an organisation responds (or fails to respond) to a matter where their membership is clearly polarised, how can they be expected to reach a representative decision when the matter is less clear cut. As a democratic organisation, it is continually struggling to reach quorum on its votes, and as a result very little can be actioned. Even board membership elections fail to reach quorum, but by convention the board accepts the votes anyway (otherwise the whole thing would fall apart). So how it can claim to represent developers, I’m not entirely sure.

Website

Ironically, the mechanism by which the whole Tim Langdell debacle really kicked off: the forums, is also one of their most chronic failures. For several years, a new website had been promised, all bells and whistles, which was to transform the IGDA website and how the community interacted with each other. To say that the website, when it was finally delivered (late), failed to deliver would be an understatement. The old forums weren’t great, but at least it worked. The complaints about new forums are so bad, it’s no surprise that conversation has dropped off to a pitiful amount. Which I suppose is great for avoiding controversy and criticism by your members, but much less so if you want to maintain a thriving community which promotes communication amongst your membership.

Benefits

It would be remiss of me to write a post like this without talking about the up-sides to membership of the IGDA. For an ‘international’ game developers association, the benefits of membership are largely not that international. The biggest tangible benefit: health-care discount, is only applicable in the US. The discounts on conferences are mostly for US conferences, except for GDC Europe. There are discounts on books and they provide web resources though, which is very likely useful.

There certainly are useful SIGs as well: the Toolsmiths SIG is a gold-mine of knowledge, a great place to bring some very good and very experienced tools developers together to share knowledge.

But the biggest benefit of the IGDA in my eyes however has always been the social aspect. The local chapters are where the real value of the IGDA lies: getting game developers to come together, share knowledge, and get to know each other. That is why, for all the organisation’s flaws, I’m still happy to see efforts to restart the IGDA Scotland chapter. As a banner to rally under, it’s a pretty decent one – well known and easy to find.

The vast majority of usefulness I’ve seen come out of the IGDA has been voluntary work, done by chapter organisers for the benefit of their local community, not paid for by the membership dues. I want to know how I can support those people, not the IGDA. Absolutely, let’s get together and get involved: the more we work as a community the better we’ll be. But that doesn’t need to involve paying $48 dollars to a US-based organisation, for some intangible benefits. Especially when that organisation gains both cash and credibility by counting you as a member, but is not actively working in your best interests.

Some people think the IGDA’s day is past, and the declining membership is a sign that a new organisation is needed. I don’t agree. There’s a new crop of board members elected, that know fine well what has gone before. Some of them (like Darius Kazemi) have been open and honest about the organisation’s flaws, and are working hard to make things right. I want those people to succeed, and restore the IGDA to being something I am not only happy about, but would actively support. And in taking a stance against Amazon’s app store policies, it looks like they’re heading in the right direction. I look forward to the day when they sort out their work on Quality of Life in the games industry, and I can reconsider my stance.

It looks like a well meaning group are attempting to restart interest in a Scottish chapter of the IGDA. While I’m all for more cooperation between Scottish developers (and engaging with other people interested in the industry), I’m still rather soured on the IGDA itself. Since my earlier posts relating to working hours, the organisation has only been further devalued in my eyes. But rather than rant about it now, I’m going to make the effort to attend a local meetup and meet the people in question, and tell them just why I’m cynical. Maybe I can be persuaded that I’m just being a stick-in-the-mud, but at least they’ll be going into it with open eyes. Either way, I’ll thrash out the arguments both ways, and write it up for here.

In the meantime, I haven’t much that I can interestingly write about here. We’re juggling now 5 distinct projects (6 if you include the much neglected internal prototype work), none of which I can freely write about here. Well that’s not true, of course I can talk about our own project, but right now I don’t quite want to, at least not until we can put up some interesting looking screenshots. But more importantly for us is the fact that we’re actually progressing one of our ideas, instead of continually putting it off till the next bit of down-time between client work. I think that’s good, both because it’s cool to be doing our own work, but also because it keeps us from going a bit mental with an seemingly never-ending pile of work-for-hire. As much as we like our clients, their work is theirs, and it’s hard to get super-enthusiastic about other peoples’ projects.

I’m personally feeling a bit of burn-out, largely because I’ve been working solidly since before October, with no breaks of more than two or three days, and there’s not likely to be any let up for the next month or two at least. So refreshing our heads with a bit of our own work is a good thing to stave off the madness. Sadly the same lack of available energy is the reason why the scarcity of posts here. There have been plenty of interesting topics come up, I’ve just not been able to find the time to write them up for here.

It’s funny, because when I was working as an employee for someone else, it never occurred to me that I needed a holiday. I threw myself into the work, but not completely, there was always room for personal stuff. Since starting up for myself, the greater focus on work means that I’ve had little creative energy left over for anything else. And if I want to refresh my batteries, I think I need a proper (i.e. not thinking about work at all) holiday. But I should stop dwelling on that now, because I find myself staring out of the window here at the pretty sunset, day-dreaming about what I’d do on a holiday, and that’s just rubbing salt in the wound. 🙂

It’s been a busy winter for us, but this story (originally in the Daily Mail, unsurprisingly enough), made me grumpy enough to warrant a post.

It concerns a mother who is indignant that Microsoft are ignoring her complaints about her 11 year old child being ‘allowed’ to spend over £1000 on XBox Live. Over the course of six months as well, so it’s not like it was a spending binge.

Some choice quotes from the article:

“It is ridiculous to allow someone of his age to make payments without any checks being done,” out of pocket mother Dawn Matthews told the Daily Mail.

Indeed. Lucky there are several checks in place to ensure that children can’t spend someone elses money. All of which you bypassed for him.

“When he is in gaming mode he can’t be thinking about the money. You can’t put all that responsibility on a young boy.

Yes. Heaven forbid a child understand the concept of money, and the spending of other people’s.

“It is impossible to monitor everything your children do. These companies should take some responsibility. They take advantage of vulnerable people.”

Well, someone should certainly take responsibility. I’m going to go with the person who gave the child the ability to spend that money, and to a lesser extent the child for actually spending it.

“A thousand pounds isn’t that much to people like Bill Gates,” concluded Dawn Matthews, “but for a single mum it is a lot of money that I don’t have.”

Okay, well a) Bill Gates has been gone from Microsoft for a long time, and b) if you don’t have the money to spend, then you should be careful about how you allow it to be spent. Six months went past before this was stopped. That’s six credit card bills with their contents ignored. If you don’t understand what you’re doing with your credit card, then maybe it’s not a wise thing for you to have a credit card.

As if the refusal to accept responsibility for disabling all the parental controls and putting her credit card details in wasn’t enough, a cursory examination of this 11 year old’s public gaming history shows a slew of 16+ and 18+ plus titles.

And finally, the last part of our look at our Employee Terms and Conditions. Since the document itself is written in suitable legalese, I wrote up a more succinct (and decidedly less formal) version that conveys the spirit of the terms rather than getting bogged down in exact wording.

1.1 You’re an employee, we’re your employer. Welcome aboard. Get to work.
1.2 If you’re too sick to work, don’t be surprised if we get a temp in to cover. Don’t worry, you’re not being replaced.
1.3 Just to make sure – you’re okay to work here, right? You’re not also pretending to work somewhere else? Or claiming benefits from being out of work?

2.1 We expect you to work a typical week, but when the s&*^ hits the fan, we might need you to stay late.
2.2 If you’re putting in a regular day, you can totally take some time out for lunch. Just don’t eat anything that stinks the office out.
2.3 We can’t / don’t want to pay you money for overtime. But since overtime is definitely over and above the call of duty, we want to recognise that, so if we do need you to do it, we’ll let you take time off later, as much time off as you put in extra now. That doesn’t mean you get to take the piss and work silly hours for a week, and then not come in for a week. What it does mean is that, if the business needs it, you and your manager can work out when you’re going to work extra, and when you get to go home early (or stay off) to make up for it. Even at that, we’re going to cap it at 20 hours in a month, because that seems like a reasonable amount; anything more and you’d not be usefully working anyway.
2.4 Don’t f*(& around. Really. We pay you to work, we expect you to work. Don’t take the piss, and you’ll do just fine. On a more serious note, this is really how we want you to work. We don’t want you working stupid hours into the dead of night to hit our deadlines, we want you in and focused 100% on your work for the 8 hours you’re in the office each day. We’ve already said we’re going to send you home at a sensible time every day, and we hope that will help keep you sharp and eager to work when you’re at your desk. Obviously there’s some give and take here, but it’s at the discretion of your manager. Rest assured, he’s probably occasionally web-surfing too, but within reason, and he expects the same of you.

3.1 This is obviously a condition written when we were still all working from home (we have an office now). We’re not going to up a move to Guadalcanal without some notice, but if we do have to move, we don’t expect you to come with us without being paid to relocate.

4.1 You get paid! Hurrah. You get paid after you do a month’s work, at the end of the month. (If we didn’t pay you at the end of the month, you’d be within your rights to not come back in at the start of the next month until we did).
4.2 We’re not going to fix you on this salary for ever, but we can’t say when or how we’ll change it next. We will however work out when that’s going to happen with you in advance, usually when you take the job.
4.3 Legal stuff.

5.1 If you’re working for us, and you pay money out of your own pocket to do that work, we’ll pay you back later. But you’ve got to do it by the book, so receipts, and get the claims in sharpish. And for goodness sakes, clear it with your manager first.
5.2 Company credit card? How much do we trust you? Okay, so we do, but you’d better not abuse the trust, and it’s still ours.

6.1 Details
6.2 You get a certain amount of holidays a year, and you earn a fraction of those holidays for every day worked. This is to stop you from joining the company, then trying to take all 30 days holiday in the first month. Holidays come after the work, not before.
6.3 6 weeks holiday – but bear in mind that includes the what, 8 days of bank holidays that some other places add on top.
6.4 You have to let us know when you want to get off. Usually that will be fine, with advance warning, but sometimes we need you in the office for certain deadlines. The farther in advance you let us know, the more likely it is you’ll get to take it; if something comes up for the business then so be it – we won’t ask you to cancel a big holiday planned in advance because the client pushed the deadlines forward (or back)
6.5 (see 6.3)

7.1 You’re never so sick that you can’t make a call to the office and let someone know. NB: Emailing is not letting someone know! You have no idea if that email’s been picked up, maybe the person you emailed is sick as well. You have to have made a sincere effort to let someone who has made it to the office that day know.
7.2 Doctor’s note if you’re really sick – we need the paperwork to cover us for sick pay reasons, etc.
7.3 More statutory stuff that says we’ll still pay you if you’re long term ill, but in line with government rates
7.4 same again
7.5 and again
7.6 If you’re getting a wad of money from sueing the drunk driver that knocked you over, some of that money comes to us to cover anything we’ve paid for your convalescence.
7.7 We might need to check your health, for our own insurance reasons, or because we’re trying to stop all of you sedentary developers from keeling over with heart attacks due to your bad diet and lack of exercise. Don’t worry, we’ll pay for it all.
7.8 Just because you’re ill, doesn’t mean that we can’t terminate your employment. In fact, whether you’re ill or not should have nothing at all to do with us letting you go.

8.1 We might, at some point, need to sack you. Might be your fault, might be a decision we have to make for other reasons. If we do, we’ll tell you about it a month in advance. If you want to leave, you also have to give us a month’s warning. If you’ve breached these terms though, we’ll put you out right away.
8.2 If you’re leaving, for whatever reason, we might want to just pay you for your notice period without actually having you around. Don’t take it personally. Whether we do or not is up to us though, not you.
8.3 If you’re leaving, and we keep you around for your notice period, then we don’t have to give you any real work to do, or even let you back in the office.

9.1 We might give you some kit to do your job, but if you’re leaving us, then you have to give it all back, including any copies you’ve made
9.2 And you might have to swear that you definitely have done this, so if it turns out later you were lying we have something we can point to and moan about it

10.1 If you are involved in any other business that might relate to us in any way (like a competitor, or even a similar business), you have to let us know. We might not mind, but you definitely have to tell us. That includes your direct family too.
10.2 Once you’re working for us, you agree not to start anything like that either. We don’t mind you buying shares in a business like that, as long as it’s not a very big stake.
10.3 Stuff defining some examples of how we mean ‘involved’ in those other businesses.

11.1 You’ve got to tell us if you were a crook, generally a dodgy character. And if you find out that a bunch of your colleagues are planning to leave and strike out in competition with us, you’re obliged to tell us as quick as you can. And if you know that one of your colleagues is screwing us over, tell us that too. Otherwise we’re going to believe that you were helping them.

12.1 Don’t tell anyone else things you know because you’re working with us. That includes other business’s secrets – our company has agreed to keep those secrets, and that includes you.

13.1 Any ideas or content you come up with “while working on activities for us”, belongs to us, wholly and completely. That applies whether you’re in our office our out on a client’s site somewhere, or even if you’re working on company stuff in your home. Conversely, if you’re not working on activities for us, your ideas are your own. Bear in mind, you shouldn’t be working on activities of your own when you’re at work at all – we expect you to either be at the office, working, or at home, not thinking about work at all.
13.2 If you do come up with something at work, and we really don’t want it, you can ask, and we might just give you all rights to the idea. This will basically take the form of a signed document that say exactly which idea we don’t want and we’re handing off to you.
13.3 Some copyright specific stuff to make clear that we, the company, is the author/originator, and not you, when it comes to IP
13.4 We might need you to sign your name and generally take part in the process of sorting out trademarks, patents, etc, that you had a hand in creating with us. That’s true even if you’ve left the company’s employment since you did the work. You won’t be able to do those things on your own, it will have to be us that drives the process.
13.5 You’ve got to do everything you can to make sure that the IP rests properly with us, and not you; even after you leave us.
13.6 Don’t steal anyone else’s work and pass it off as your own (and so ours), or make some libellous or obscene content in our name.

14.1 You’re going to be exposed to at least some level of our company’s secrets – you’ve got to keep them. If you do divulge anything, you’d better have our written consent first.
14.2 You can’t start a business in competition with us. But we don’t mind you owning shares in a publicly listed company that competes with us (that’s just investment). Shares in privately held companies are out though.
14.3 You’re not allowed to poach recent (in the last 12 months) customers from us
14.4 You’re not allowed to poach recent (in the last 3 months) employees from us
14.5 You’re not allowed to use any confidential information you have as a result of working for us, or tell anyone else that information (apart from tribunals or courts that you’re obliged to tell the truth in)
14.6 You’re not allowed to record details of what’s going on inside the company, unless it’s to benefit the company
14.7 You’re not allowed to pretend to still be working with us after you’ve quit
14.8 We know this legal wording’s pretty complicated, and different situations lead to different justifiable periods, so if this contract would be valid if we took out some of these restrictions and/or reduced the times involved, then that is the contract instead. I.e. you agree not to try and work around these agreements by finding a loophole in an otherwise reasonable clause.

15.1 Don’t do something on our behalf that would tarnish the company’s name. We’ve written down how we expect you to behave, roughly, so you should read up on that so you know what to avoid.
15.2 If you’re new, then we might skip the more rigorous disciplinary procedures; but you can take your complaint to the company director, if you’re not happy with the way you’ve been treated.
15.3 Please be sensible, and work things out with your line manager before starting the formal grievance procedure. But if you do want to do it formally, make it in writing.
15.4 If you’re formally doing things, you have the right of appeal of your decision
15.5 If you’ve since quit, please still raise the grievance with the company director.

16.1 Legal statement that nothing else interferes with these terms
16.2 We might need to change these rules, but if we do we’ll let you know a month in advance.
16.3 Where to find the employee handbook

17 Legalese

18 Legalese

This post is the last in the series (see parts 1 and 2) on the Employee Terms and Conditions we use here at Black Company. Here we cover the remaining clauses, which are not exactly games industry specific, but apply to any creative business.

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.

This post continues on from the previous one on the Employee Terms and Conditions we use here at Black Company. The second part concerns Intellectual Property, an important facet of any game development studio’s work.

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.

I agreed some time back to write a post for IndieVision, on the Employee Terms and Conditions we use.  Actually, although they will hopefully be useful to my peers in the indie game developer community, originally I made them publicly accessible as a service to other employees within the games industry. There is always discussion on IP clauses in employment contracts, overtime, and I wanted to show that there were sensible, fair contracts that both preserved the needs of the business but were still amenable to the individual employees themselves. I had hoped that it could be taken by employees, so that any attempt by unscrupulous employers to say “these are standard clauses, and you won’t find a games job anywhere that doesn’t have them” could be rebutted.

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.

So for some time now, I’ve been using Stack Overflow as a great reference for the sort of iPhone development questions that come up when you try to do anything non trivial. Of course the SDK documentation covers quite a lot, but when you are trying to express a particular structure of UI, and find that you’re not doing things “the Apple way”, it’s not immediately clear exactly why or what to do. Of course, for almost every case, there are dozens of developers who have come before me who have already asked, and usually answered, the same question. Instead of hours of painstaking research or trial and error, usually the answers on Stack Overflow are enough to point me in the right direction, if not provide a solution to the problem outright .

And it’s that sort of standing on the shoulders of giants that I hope that the Game Development Stack Exchange site will help provide. Recently out of beta, the community there has quickly flourished into a fully fledged site, with a good breadth of knowledge. As will all the Stack Exchange sites however, it’s only as good as the community makes it, so in an attempt to be helpful, I’ve tried to ask some interesting and useful questions, and provide some informative answers of my own.

Sadly, as with any open and un-gated site, there are more than a few contributors who are, quite frankly, not contributing so much as dragging the place down. Thankfully there are mechanisms in place to vote down the more useless questions (such as What’s the best phone for game development?) and vote up the more interesting ones (like Fixed time-step vs variable time-step and What can cause alt-TAB to be annoying / slow / glitchy?).

As always though, only time will tell whether it will turn into a useful resource, or will degenerate into questions asked by amateurs and answered by idiots. The only way I can see to properly raise the signal-to-noise ratio is to encourage my fellow developers to visit, find a few questions to answer, and vote down any questions that don’t add any knowledge to the community. And so this post, such as it is, is my little attempt to raise awareness of the site amongst the wider game development community. And feel free to add an answer to my only question so far. 🙂

So we haven’t seen Sid or Sally Squirrel for weeks now, after them being around almost every day. Tim spotted another visitor though, who left before we could figure out if it was one we already knew. This one seems substantially stupider though. Not only is it still out and about even though the weather has turned decidedly chilly, he tried to stash a peanut he’d found here: in the corner of our window. Right out in the open. Yeah, no-one else will ever think of looking for it there. Certainly not all the birds which nest in the trees all around here.

I have this narrative in my head now of a lazy squirrel that wakes up one morning in November, hung-over to all hell, and realises that it’s frosty and he’s seriously late for winter. And now he’s dashing around, cursing under his breath at the monster head-ache he’s got, stashing food any old place. All the good places are taken as well, so he ends up stuffing them in all sort of rubbish places. Since I’m an unabashed cynic though, the story ends with him lifting up a particularly grumpy cat’s tail and trying to stash an armful of brazil nuts under the cat, only to be unpleasantly and messily devoured.

It’s often the case that in the industry,  people will do research on particular software engineering methodology, or a team will publish a post-mortem in which they talk about a particular style of working and how successful it was for them. And the discussions following those posts will usually descend into an argument, with different people chiming in on how they tried that methodology, and it was rubbish, or how their own methodology (or ideal methodology) is better.

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.