tl;dr: We don’t take them. Thanks, but no. Best of luck making your game.

Why is a little more complicated. Even when I was still actively looking at our own development projects, our problem was never really a lack of ideas, it was a lack of time for the ideas we had. It’s naive to think that just the idea is enough, that the idea just starts good, or that it is already so good that it ‘just needs made.’ Ideas are cheap. We have them all the time. Working in games, playing games, watching what others are doing, ideas come all the time. Some better than others, some already made by other teams. But realising that idea takes time, and by extension, money. A lot of it. Even the best ideas are worth very little until they are implemented. Not even fully implemented, just getting the idea to a state where it can be pitched to a financier for funding takes a non-trivial amount of effort. It’s important to realise that whenever you have an idea you are trying to progress, what you are doing is investing in that idea. How much you’re investing depends on how valuable your time is (both to you and others), but you should always be aware that it is costing you to make this idea a reality, and that if you want it to succeed, it needs to realistically be able to pay you back more than you put into it.

Amateur developers often misjudge that equation. Their time spent on the idea is cheap, because it is enjoyable time, time they might want to spend anyway. Their assessment of the merits of their idea is often inflated because they are passionate about it. I think it helps to consider: “what if I had fifty ideas?” Then, time spent on one idea is time you can’t spend on one of the others. It forces you to think critically about the value of your time and on which idea really merits the investment you put into it.

That awareness that you are investing should also temper your desire to get other people involved. Because you are, effectively, asking them to invest into your idea. It is no different from going to friends or family and asking for a loan to start a business. There are some fundamental questions to ask, even before you get to the idea itself. “Yes, we want to help you. But what do we get out of it? What are you putting into this? What are we putting into this? Who gets what when it does well? What if we disagree on how this business should be run?” For these reasons it’s often easier to go it alone, at least to start with, or to only throw in your lot with people you know and trust. Because you don’t have to persuade those others of the merits of your idea. If you put the effort in, if you progress the idea to something that by itself can demonstrate that your idea has legs, then you start the relationship with your collaborators on a much better footing. “This is what I’ve done, this is what I think it’s worth, I could use a hand getting it finished, and if you agree with me on its merits we can come to some agreement on how to work together.”

This may be the jaded viewpoint of a professional developer, someone for whom new ideas and projects have to be traded off against lost income from other work, but I think all developers, amateur or not, should be thinking about their work not just in terms of potential but of cost. Because while this idea you have might be good, the next one might be great, and if you sink all of the investment you had to spare in the first idea and it doesn’t pay off, we’ll never get to see the great idea come to light. The ideas can only be realised when the development is sustainable, and to be sustainable requires the ideas to, on average, pay for themselves. Some amount of up-front investment is fine, but at some point one of those ideas needs to pay enough back to cover all of the ideas which didn’t.

What I didn’t take the time to blog about last month was my attendance at the Scottish Games Network launch event held in Edinburgh. I’ve been broadly supportive of the idea of making SGN official since Brian announced it in October. I’m sure it must be a little disconcerting for him to think that simply declaring that SGN is now the official games industry trade body for Scotland is enough to make it happen, but it’s not really as simple as that. All a trade body really needs to be taken seriously is the support of the companies it purports to represent. Officially or not, I think SGN has been doing a pretty good job of representing our interests, without being asked, or paid. The proof is in the pudding as they say, and so we will judge it on the work it does.

What I’ve said, both here on the company blog and in person when I’m out and about amongst the rest of the industry, is that communication is key. As an industry we’re not generally competing with each other. We gain a lot by collaborating, sharing knowledge, ideas and inspiration. Many if not most of the client relationships we have were started by going out, seeing what the rest of the industry was doing, and letting them know who we are and what we do. Without a focus point, to do that we’d all have to be contacting each other, and that is time-consuming and not very practical. The simple fact is: locality is important. I know what many of the game developers in Edinburgh are up to, because I meet them. Either at @GameDevEd, or at other industry events around town. I know what some of the developers in Dundee are up to, but generally only because I’m in touch with individuals at various studios up there and we chat regularly. I’d love to know more about what’s going on up there, as it’s very easy for me to lose touch, especially when we or they get busy.

So for me there’s a definite niche to be filled, that of a locus for information, someone or something capable of routing information around. That’s especially true for those outside the industry. I’m sure there are many, many Scottish organisations that are interested in interactive digital entertainment, with ideas and projects just waiting to be made. I don’t know who they are. I’d love to talk to them though. They don’t know who we are. Few outside the industry do. It’s just as infeasible for them to cold-contact every games developer in the country as it is for me to cold-contact random organisations to offer our services. But if there were a central point of information, obvious and high profile, those two organisations can be connected together. They can go to that central provider and say “we’ve got a budget and an idea, but we don’t know who can help us,” and be told “Well, Black Company makes games about that size, or Proper, or Storm Cloud. Here are their details, I’ll introduce you.”

More importantly I feel that the government bodies here in Scotland, the Parliament, Creative Scotland, the many media departments, could all be engaging with the creative digital interactive media talent here in Scotland much more, if they had a reliable conduit into the industry. Scotland is a country exploding at the seams with culture and history, and I feel it’s crying out to be exploited in interactive media. I’ve long chafed at the need to globalise and homogenise our games to appeal to the world-wide audience. We should be embracing our heritage and making games that tap into our local culture. Such as Beeswing, a lovely little project, set in rural Scotland.

Beeswing

It’s fantastic that the Kickstarter for this was successfully funded (with a few of my pounds as well). Instinctively though I looked at it and thought – this is the sort of stuff that the Scottish government should be actively encouraging. I believe they would too, if they had a practical way of engaging with the Scottish games development community to start these discussions. So again, a central focal point can enable those two sides to get together and make amazing things happen.

Visibility is one of the main reasons we are members of TIGA, and is why we’ll be happy to become paying members of the Scottish Games Network as well. Not because one is better than the other, but because they serve different localities. The TIGA folks are lovely, and very efficient. They give us a presence in Westminster that I feel is important. They cover the UK industry and beyond, and that is also an area in which we are very interested. We don’t cut our business dealings off at Hadrian’s wall. But like it or not, Black Company isn’t well placed to attend events in London, and so a sister organisation that can provide even more coverage in Scotland seems like a very good idea to me.

A post, or possibly series of posts, on reasons behind crunch in the works now I have a bit more slack, but until then, I thought I’d share something that made me smile this morning.

Suddenly, melon.

Dean Village is a lovely place to have an office, but the locals are… Well, let’s just say that random large fruit by number 12 doesn’t surprise me any more.

Happy New Year! Tim and I have actually been in the office since Monday, eschewing the traditional extra Scottish bank holiday in favour of getting cracking on our big stack o’ work. Today though we’re here in defiance of all the sensible advice to avoid travel! Trees down, tiles smashing onto the ground, signs being torn off buildings and thrown around the roads like crisp packets in the wind. There are a few nice things about being in a basement office, and shelter from the wind is one of them.

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.

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.

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.

The microwave in our office is quite annoying. I mean, it does its job: nuking food with radiation, but to actually persuade it to get that far is an unnecessary chore. It’s got a numeric keypad, plus another half dozen control buttons and a start button. If I want to get it to heat my soup, I have to press Time, punch in 3,0,0, then Power, then Start. To be honest, I don’t even know what those other 4 buttons do, and I’m a tech savvy person. We have that self same sequence written out in a note taped to the top of the microwave, since it’s exactly what you want to do 95% of the time.

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.

So after a weekend up north in Glencoe, trying to get my head back in some kind of productive space, I hear from my sister that she’s given birth to not one, but two miniature people today. So I’ve raised a glass or two to my sister’s new family, which pretty much excludes the possibility that I’ll do anything useful tonight.

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… 🙂