Only… we didn’t make it. Not quite, anyway. As of the end of our financial year, the 31st of March 2020, Black Company Studios ceased trading as an entity, eleven days short of ending its fifteenth year. I don’t regret that part either. As I said in this post, five years ago, it was time to admit that the days of being a team were in the past, and that’s just what happened. I broadened the sorts of clients I was consulting for, and the last five years have been non-stop work, of varying kinds, all satisfying. One in particular, ZeroLight, gave me so much work that I ended up working full time for them for several years, until eventually we acknowledged that it had ceased to be a consultant / client relationship and I became a full time employee of theirs, were I remain happily employed to this day.

So, Black Company became rather sidelined, a fact which will surprise no-one, given the dearth of posts here on the blog. Our little iOS apps still sell small numbers, but aside from that I haven’t invoiced a client in a couple of years. As such it made sense to wind things up, gracefully, and tie up all our loose ends. Black Company Studios Ltd will be struck off the Companies Register shortly, and the few remaining assets, including all our IP, will be purchased by me. That includes this website, which I intend to maintain in a limited form for posterity, and the Black Company name will continue on in the iOS store, at least until I transfer the apps to a personal account.

At this point I’d like to thank all of the members of my team over the years: Pete, Tim, Charlotte and Dan. You all contributed greatly to our success, and though it may not be the most notable line in your CVs, I hope you came away from it positively. I’d also like to thank all of our clients, whom we impressed enough to give enough repeat business to keep us going where so many other software businesses fail.

I don’t regret any of my time running the company, but I admit I’m a little wistful thinking back over all the years, and part of me didn’t want to close the door on that time. But there are new challenges to be tackled, and nostalgia is only good when you’re digging out your old games consoles and firing up a classic title to while away your time in self-isolation.

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.

I genuinely believe crunch is endemic because our development process leads to a disconnect between present and future phases of the project, a failure of accountability. In the early phase, when there’s planning, people are incentivised to cram as much as possible into the plan, in a short a time as possible, for as little money as possible, while still keeping it realistic. But the incentives are all based around promising more, aiming higher, and the judgement of what is realistic is deferred till later. Most developers will have worked in a place where the project was only landed because the publisher pushed back on what was feasible in the time, and the developer over-promised.

No-one in that process has ever been rewarded for under-promising, or aiming low. No-one in the publisher would get patted on the back if they revised the scope document down, or the expected price up. No-one in the developer’s management would get rewarded if they said they could deliver less given the same resources. You are punished right away if you fail to agree the best plan you can, but you are not immediately punished if you over-promised, and you might still be able to avoid that punishment in the future. The failure to deliver is only a possibility, in the future. Plus if you fail to deliver, it can be someone else’s fault, or you can push harder, or any one of a bunch of different things. But in the early phase, the solution to the problem you have right now seems to be to over-reach, even if it creates more problems for you in the future.

In the latter phase, when its clear you have over-promised, it’s too late. The deadlines are set, the budget is limited, the resources are finite. The only solution to the problem you have right now is to desperately try to eke out more productivity, any way you can. Short-term thinking is rewarded, because failure in the short-term is punished terribly. Crunch is a workable solution to hit the first milestone you are in danger of slipping, and the cost of crunching only comes due after that milestone. So the solution to the problem you have right now seems to be crunch, even if it creates more problems for you in the future. Again, the punishment for failing comes right away, but the punishment for making the decision to crunch is in the future, where it may be someone else’s problem, or it may be avoided, or it might be staved off by some other means.

Accountability is the problem. There will always be finite resources, money, time, staff and pressure to do more with less. But we wouldn’t be seeing these problems if we incentivised more conservative, realistic planning. If you make decisions that lead to failure later on, your punishment should be twice as severe as the punishment for if you fail early on. And you shouldn’t be able to offload the responsibility for that failure. If the team fail to deliver on your over-optimistic plans, you should be the one carrying the punishment for it. That can and should echo down the line – each person should have to face the consequences of failing to deliver, right down to the team level. But they should also be the ones estimating how much they can do. That does hit a snag at the tail end, in that at the leaf nodes, you have two conflicting goals. You’ve just incentivised your staff to promise very little (so they know they can fulfil their promises), you have to also find a way to incentivise them to promise a the highest amount that’s realistic. And that’s quite hard.

The problem I fear is that if you do this right, and you reverse the normal incentives so that projects are far more conservative and likely to go to plan, then the games produced are smaller, less radical, less interesting, and ultimately less profitable. And very possibly not profitable enough to maintain the companies involved. Still, I maintain that it’s better to be honest with yourself about the viability of your business, than it is to keep it afloat only by exploiting your staff resources and by failing to deliver to the clients and customers. After all, how much money do you think we waste, aiming too high and having to scrabble to recover; burning productivity well below where it should be because of crunch.

Game development is inherently unstable. Technology, markets, profit margins and teams shift regularly. Any of these can quickly destroy a previously comfortable business.

[…]

In the 90s, Sierra expected 1 out of 4 games to be a success and pay for the other products that failed to turn a profit. Recently, Mike Capps, the previous president of Epic, claimed that he couldnâ€t promise more than a 10% chance a game would be a success. If you made 10 games, on average, youâ€d expect only 1 would be considered a success.

[…]

Your budget is likely Target Revenue * Success Rate. So if thereâ€s a 10% chance of reaching $500,000, you should spend $50,000 on each project.

[…]

Over time success has been dropping. 25% is almost never seen in modern game markets. […]Given a set of equally competent games, only a fraction will become profitable.

What happens if that profitable game make $600,000? It earned 6X its costs! You made a profit of $500,000, enough to make 5 more games. However, you are still on the long road to bankruptcy, despite an apparent success. Thereâ€s only a roughly 40% chance those 5 swings at bat will result in a success. Long term, youâ€ll find yourself out of money or in debt.

[…]

It is a disservice to other developer to claim that a breakeven project is a financial success. Break even means almost nothing. You are still on the knifeâ€s edge of baseline survival and should operate financially exactly as if you had achieved nothing.

You cannot bank on individual successes being repeated reliably. Games, even those developed by the best of developers, are not reliably successful. Maybe they miss the moment where the audience is really looking for them, maybe they get the quality bar wrong, maybe there are technical constraints that rob the title of what it needs to really work. It doesn’t matter, because unless games development suddenly becomes much more predictable than it is, a business making games has to assume that some if not most of their games will fail. If that business wants to be one which survives, it needs to be profitable across all its games, success or fail.

A team where the developers are taking low wages, putting everything they have into their first game, makes for a great story for the press. Make or break. But it’s terrible business. A team that’s taking their funding and figuring out how many months that will let them operate for, and then planning a game to fit that period, is a team that’s most likely going to fail.  Even if they survive the first game and limp on to make a second, even if through talent and luck and timing they magic up a massive success that not only makes all its costs back but also nets enough to fund their next game several times over, chances are the next game will not match the first’s success, nor the one after that.

This is true even for larger teams. The publishers are the ones who have to look at viability longer term, so often developers can ignore that and just live title-to-title, but the same pitfalls are there. If you’re a developer whose best title only earned back twice what it cost, then you shouldn’t be surprised if the publisher drops your team after the next title that only earns back a quarter of what it cost. They just can’t afford to take the risk that your next title will be a flop rather than a mediocre hit, because you’ll have become a losing bet. You have to deliver the massive breakout hits if you want to make them confident that over time you are a reliable generator of income, and not a drain on their coffers overall.

When we’re looking at whether making games is viable, we need to be looking at long-term profitability of the team, not just per-title. Anything you do to hide the true cost of your development is really just selling yourself short, setting yourself up for a later failure. Don’t lie to yourself about the cost of your time, or the extra hours you’ve put in. Don’t hide the costs of one game in something else. A game that is profitable, as long as you don’t count the months you spent eating just ramen, is not a profitable game. Don’t believe your own hype. It might be hard to accept, but there are no guarantees that the business you love is a profitable one.

It’s a print-to-string line that formats currency for display as $1.23, regardless of the user’s locale. Or a user signup form that has one box for First Name and one box for Surname, and expects exactly one word in each. Simple things, taken from the programmer’s own experience as ‘obviously’ the way it is, thrown in because they have to get a working implementation done quickly, and no-one has asked them to take localisation into account. That can all get sorted later, right? No. Not when you build in assumptions at the very base level that simply aren’t true.

For example, Steam. I was probably one of the early adopters of it. I didn’t want to be, annoying system tray icon that it was, but I wasn’t going to wait for Half-Life 2. To sign up, I had to use my email address as a username. Sure. Whatever. It’s now over 12 years later. That email address, tied to an ISP I moved away from, is long since gone. Can I change my username? No. Because they insisted on a particular form of unique ID at the time, and they insisted that usernames can never change. New users don’t have the same restriction, they can pick whatever username they want, but mine is frozen in time. Even though there is an actual email field on my account which is wholly separate from the username, I still have to enter a 30 character email address that has no relation to reality every time I want to log in. While I can just treat it as not an email address but just an oddly formatted unique identifier string, it jars with me, every single time.

Arguably this is just the meat of development – changing requirements over time invalidating initial assumptions. But for me it’s a plea to other developers – to slow down and take some time thinking about your initial implementation. If it’s not on a specification handed to you and you’re winging it based on how you think it should be; maybe think to yourself what the ramifications of how you choose to implement it will be. What won’t you be able to do if you implement it this way? What are the awkward cases, the potential ranges of input. Will it be possible to fix it later once the system is live and populated with data, or are you building in something that’s a fundamental to the system?

For contractors, that’s a mixed blessing. Finally you get some breathing room, a chance to catch up on all the little loose ends that you’ve pushed to one side while you’ve been busy. For me, a chance to actually play some games instead of helping to make them. It doesn’t take too long however before you start to get restless, when you’re not actively engaged on something and your brain has some time to wander. During this particular down-time, I took the opportunity to try and reset my brain a bit, do some DIY, catch up on my reading, and other non-computer related stuff. I know that I could have been working on the VR stuff I’ve been putting off, but I felt like I lacked the focus needed to really get stuck into it, I’d been too long working on other peoples’ projects. Even when the DIY was done and I was properly back in the office, something was still nagging at me, and I spent more time pottering in the office organising than anything solidly useful.

The other thing staying busy with client work does is make you lazy about introspection. If I’m honest, the steady supply of business had allowed me, to fall into something of a safe, comfortable place. It was well past time to take a long hard look at the business plan and re-assess. Tim left the team over 2 years ago now, and Dan has been full-time on his Ph.D. work for almost as long. Black Company Studios is, and has been for a long time now, just me, consulting with our various clients and developing software for them. I think it’s time to stop lingering on the trappings of a larger team, and accept that reality.

There’s no shame in it, I feel. What we have always been good at is providing our expertise in software development to our clients. Actually making our own games and apps, not so much. For too long when talking about our work I’ve mentioned those non work-for-hire projects with a little bit of embarrassment, that they were things we notionally did, but they never received enough attention to make them projects we could hold up and be proud of, they were always just a footnote. That’s mostly because I felt that the work-for-hire we provided was always where we could add the most value. So changes are afoot to help us, me, refocus on that strength. The Belford Road office, large enough for 5, but really only holding me and a whole bunch of boxes and old machines, is being left behind, as of the end of April. There are hot-desk environments that would suit a lone developer much better, and often enough I’ll be working on-site with the client anyway. The machines and excess equipment have been sold off for token amounts and will actually see some use instead of lying cold in the corner of the office.

And finally, I’ll be trying to increase the breadth of clients I look to work with, not just games studios but all sectors. That’s already partly happening – 90% of the work over the last 12 months has been more 3D visualisation than games. Having to be a generalist for so many years has given me a grounding in many aspects of software development; .NET tools, DevOps and build pipelines, building web services and tools, user interface work both on the web and natively, high-performance/low-latency coding. It’s time I put those skills to work. Because after a lot of hard thought, I’ve come to the conclusion that what I enjoy about my work isn’t limited to making games, it’s knowing that I can do good, useful work, for whatever clients I deal with.

How does that relate to breast physics you ask? Well while watching the Sky Diver test one of the most prominent views you’re given of the sky-diver in question seems specifically designed to show off the rippling of their breasts in the wind. Or perhaps it’s the ASUS logo that’s plastered all over the suit (although curiously, not in the shot they use in their benchmark listing).

Not that I have anything against more accurate depictions of the human form in motion of course. I think the reason that it jumped out at me though was because it didn’t look natural. I can almost imagine the animator’s reaction to their initial feedback. “You want them to do what? Are you sure? Would they even move like that…? I don’t know, I’ve never worn a wing-suit. How about you go find me some video footage of an actual female sky-diver and I’ll work from that instead of your imagination?”

The reason this popped out at me as more than just an off-hand amusement at the benchmark graphics was my flabbergastedness at certain tweets this week, accusing game developers of sexism, for the crime of not devoting as much effort towards hair rendering as to shiny and reflective surfaces. This grinds my gears on several levels. The last time I shipped a console game (Brave), we spent a quarter of the entire frame calculating and rendering Brave’s hair, and exactly zero time on shiny or reflective surfaces. So to pretend that we’ve just never concentrated on hair is disingenuous.

Secondly, the reason why there’s more shiny stuff in games than fabulous hair is not because, you know, screw women, but because rendering hair is hard. Not just developing it, making sure it moves properly and looks good, but actually getting it on screen is costly. Like fluid dynamics and other similar technical challenges, you’re having to simulate many, many small things at once, and then deform geometry and alter texturing every frame as a result; something 3D hardware would really prefer you didn’t do. Fundamentally, that’s costly, and the cost doesn’t go away just because you spend more development time on it. Whereas good lighting and reflections comes almost for free, from the way that hardware 3D rendering works; spend some development time on getting the lighting calculations right, and then they can be done for every fragment you see on screen, at only slightly more cost than just rendering the thing in plain lit colours. And once it’s done it works for everything, not just the subset of characters who happen to have long hair, but for everything in the environment and all the characters, even the short-haired ones. So from a development point of view it’s a no-brainer as to which gets you the most pretty for the least cost. Trying to make it an issue of sexism only serves to show how little you understand about the challenges of making games.

No-one is avoiding making the hair look good because they’re sexist, if it was affordable then they’d be doing it all the time. Because when your characters’ have long hair that looks good (regardless of their gender), reviewers gush over it, it’s immediately noticeable. When your environments are a little bit more shiny than before, no-one bats an eyelid. At best it’s acknowledged as part of a wider judgement that your game looks good. Why wouldn’t we want to go for the hair? Because even though it’s nicer to have in, it still costs too damn much to get right, both in development time and in runtime resources.

The unknowns to be addressed come from the parts of the tech that are new. Control, user interaction, is going to be the key. My concern here is that the old systems we used are just not ideal in a VR environment. Traditionally, we’ve been controlling avatars in a virtual world. We’ve had mostly free movement around that world, but there’s always been a clear disconnection – you’re controlling something other than yourself, and the screen shows you the view from their position. We’ve refined the control mechanisms so that feels natural, and trained ourselves to the point where it feels a lot less like we’re rotating an avatar, and more like it’s us. “Look right” becomes a quick flick of the mouse, even though our head doesn’t actually move. The avatar becomes an extension of ourself. That ability to make the control mechanism effectively disappear is key. In the same way it’s easier to drive when gear changing is instinctive and done without thinking; it allows you to focus on the higher level functions.

If you’ve ever watched someone new to games playing a first person or third person game, you’ll know the effect. When someone has to look down at the controller to remind themselves of which joystick to use. You say “look right”, and they have to stop moving their character before they change camera angle. So many of our games are designed to take advantage of the affordances already learned by gamers. It doesn’t matter that they haven’t played your game before, if they’ve played another game in a similar style. More crucially, when designers get it wrong, that failure permeates the whole game. When someone complains that moving your character around feels like driving a tank, that niggle interferes with everything they do in your game. For all of the great things about GTA 4, I struggled with Nico’s movement. I’d miss a door by just a fraction, and then he had a minimum turning circle that meant that I’d end up bashing into the other side of the door frame instead. You get used to it and learn to compensate, sure, but it’s a problem that needs to be overcome.

Bringing it back to VR, the change in viewpoint brings the control issues into sharp relief. The immediate and all-encompassing nature of the viewpoint makes it *you* that’s in the game. You’re not controlling what you see on that screen ‘over there’, you are controlling you. So when the controls feel unintuitive, it’s *you* that feels sluggish and unresponsive. So it’s important to get it right, and I’ve seen a variety of problems with the Rift demos so far.

Assuming that you’re using a joystick or keyboard controls, you effectively have a 2-axis input controlling movement. That we always had with first person games. But in the past there was a fundamental restriction in place. ‘Forward’ was always ‘the direction you’re facing’. There was no option to look to the right while still running forward, unless you were playing a mech or tank game which often mapped view direction to an extra input axis. But the natural mouse/keyboard or joypad controls we’re used insisted that you always look rigidly forward, the same direction your gun was facing. That extra axis (where the body of your avatar/vehicle was pointing in a different direction to the view direction) was discouraged, because people struggled to manage their awareness of the two directions (look and move). Skilled players learned to compensate naturally for this. While running forward, to look right you’d turn and simultaneously start strafing left. But you knew exactly where you were looking and moving at all times, because the restrictions were clear.

In VR, that restriction no longer makes sense. Instead we have different restrictions. Even if standing, the cable to the headset restricts your turning. If sitting, then there is an obvious ‘forward’, which is the direction your torso is pointing. You move your head to the left and right, but forward doesn’t change. However, the real problem is that the Rift headsets at least aren’t really anchored to that ‘forward’ direction. The headset knows what direction it’s facing, but it doesn’t know at what point the headset was facing ‘forward’ as far as the user is concerned.

Instead, all of the demos I’ve seen try to replicate the same restriction as traditional FPS controls have. ‘Forward’ is ‘where you are looking’. Walk forward on your directional axis, and look to the right, and you’ll move to the right. Which seems sensible, until you consider the need for complete freedom around the world. You have a limited head movement circle, so how do you turn completely around so that forward is south instead of north? You’re not going to twist your head 180 degrees round and press forward. So the demos map another axis on top of your head movement. So if you start facing forward and north in the world, turning your head 90 degrees right means that ‘forward’ motion moves you east. Use the rotation control to turn your character 90 degrees right, and you’re moving south. Return your head to centre though, and you’re moving east again. So even though ‘forward’ always moves in a predictable direction, you’re still having to manage awareness of that extra rotation. Your head orientation is being added on top of a base avatar orientation. That input-controlled axis is constantly fighting against the headset rotational axis. You can be turning your avatar right and rotating your head left to keep the view pointed in the same direction.

Having experimented, I think trying to cling onto that old input style is a mistake. It feels horrible when you’re craning your head around to the right because you’ve been using the head orientation as the primary means to choose your direction, only to find that you actually need to turn more than 90 degrees in either direction, at which point you need to fall back on the directional turn controls. Worse, when you’re running forward at speed, you have to keep your viewpoint locked directly ahead, because if you try and glance left or right you’ll start running in that direction. You’ve lost one of the big plus points of VR, freedom of motion in your viewpoint.

Keeping it so that you always have complete freedom of moving your viewpoint is I think key to making the user comfortable. We used to be able to make the controls avatar-centric, but now we need to be aware of the range of motion the user has, and allow them a natural way of expressing a complete range of motion without discomfort.

Instead of assuming that forward is where you’re looking, you need to build in some awareness of the user’s torso. The only natural way I can think of to do that is to add a quick and simple calibration point. Ask the user to look directly forward, and then press a button. From then on, that direction is the reference centre, and should align with the direction of motion of the avatar. Forward means moving in that direction, regardless of where the headset is pointing. Same for strafing right and left. Ideally, like the mech and tank games that have to do this naturally, you’d have an in-view indication of where forward is relative to your viewpoint. That might be your avatar visible from your viewpoint (e.g. a gun or arms), or a HUD indication.

To me the biggest thing that the public sector could do to aid the creative industries, especially games, is to provide the broader view that we in the private sector are solely lacking. The dearth of information on what is actually happening in the games industry is shameful. Sharing of information will help us all to grow, to avoid making the same mistakes, to spot opportunities as they arise and not well after they’ve been exploited by others. But we can barely even claim to know how many studios and developers are in the industry, let alone the more useful information like what they are working on or in what areas they are seeing growth/recession. We have trade bodies who poll their own members, but that represents only a fraction of the industry currently working. It’s frankly embarrassing that so little resources are put into tracking what the games industry is doing, and it seems to me that the government itself would benefit from being able to point to the growth of the Scottish games industry. It’s a manageably small sector to collect information on, smaller than the UK, and I’d guess more interconnected as well.

We in the Scottish games industry want to be able to shout about our successes, but we can’t, because we don’t have the context to say how much better we are doing than last year. Individual successes are great, but they are fleeting, what matters is the overall trend in the industry. I feel that it’s a positive trend, but I have absolutely no data to back that up, and asking around, it seems that no-one else does either, not even the government bodies who are supposed to be there to support the industry. But how can we be supported if they don’t even know who we are and what we’re doing? Don’t we run the risk of allocating resources based on a woefully out of date picture of what is happening? What use is it to the industry if support is provided for console games that form a dwindling share of development; or for social games when our market has moved on to mobile platforms?

I think that the very first step that must be taken is to put resources in to dramatically improve the information we have on the games industry as it is now; and to commit to keeping that information current as quickly as the industry itself moves. Without that information to inform us, I feel that the answers to all of the other questions the committee are asking run the risk of being out of date and useless before any actual answers can be agreed upon. Armed with that information, the public sector can know who to engage with, and the private sector can know how their industry is changing and seek out new opportunities rather than be left behind.

Standards Proliferation

Enough said.

1. Two of the hosted websites were no longer working: they were giving 404 not found messages.
2. A persistent message being posted at startup and various points during shell sessions: “no talloc stackframe at ../source3/param/loadparm.c:4864, leaking memory”
3. DHCP server stopped responding properly the day after the upgrade

I’d had to merge a few configuration files, of which Samba and dhcpd were one, so my initial thought was that I’d botched the merge. However there wasn’t anything obvious in the merge results that would explain why. Anyway, issue by issue:

No talloc stackframe

This one was the most easily resolved. This post points the finger at libpam-smbpass, a Samba module which seems to have an outstanding bug. Fine, it’s not functionality we rely on, so uninstalling the module makes the problem go away:

sudo apt-get remove libpam-smbpass

DHCP server stopped responding properly

This one didn’t bite me until mid-way through I was trying to diagnose the Apache issues, my DHCP lease ran out and suddenly the laptop I was remoting in to the server was without network. Super annoying. Setting the IP address / DNS of the laptop manually got me network connectivity to search for solutions, otherwise it would have been guessing blindly from the server terminal (which doesn’t have web browsing).

While there wasn’t anything hinting at a DHCP problem in the logs, I noted at server reboot time a line along the lines of the following:

Apparmor parser error for /etc/apparmor.d/usr.sbin.dhcpd at line 69 Could not open /etc/apparmor.d/dhcpd.d

I couldn’t find that line anywhere in my logs, but I probably wasn’t looking in the right place. The configuration file that is complaining is basically trying to #include the dhcpd.d subfolder, and failing. Still, it suggested some sort of permissions or configuration problem with AppArmor and dhcpd. Oddly though, DHCP had been working after the upgrade the afternoon before, and I could see successful DHCP negotiation going on from this morning, but it all ceased an hour or two before my DHCP lease expired. All of my searches were throwing up results for the package isc-dhcp-server though, whereas I was pretty sure the package was dhcp3-server. On checking, isc-dhcp-server was not installed. Installing it:

apt-get install isc-dhcp-server

Lo and behold, DHCP was functional again, using our already existing configuration. So, I’m guessing, the packages on our legacy machine (upgraded using do-release-upgrade from 10.10) aren’t properly handled by the release upgrade procedure, and were left with folder permissions set incorrectly; which was fixed by installing the correct DHCP server package.

Apache website issues

Ubuntu 14.04 brings with it a fairly major upgrade from Apache 2.2 to 2.4. While the web server was still functional, and I could access pages resting directly under the DocumentRoot, our two sites set up using Alias directives were no longer accessible. Both returned 404 errors. Using a symbolic link in the filesystem under the DocumentRoot would allow them to be accessed, but that wouldn’t allow us to enable/disable the site at will. While there are changes to the permissions system in 2.4, we don’t use those with our sites. So all very odd.

Our setup was very simple: each site had a configuration file that only contained a single Alias line, remapping the appropriate site folder to the folder on the local disk. Further experimentation showed that we could shift the same Alias line into the default site configuration, and have it work. It gave a 403 Forbidden error, but not a 404 any more. Adding an appropriate Directory element with a “Require all granted” directive inside fixes the 403. So presumably the default permissions for an aliased directory have changed to deny by default instead of grant.

So from that I can only conclude that Apache 2.2 was more forgiving of having Alias directives standing alone in their own site .conf files, for whatever reason. I’m probably missing some nuance of the setup as to why it worked before. Rather than spend too much time figuring it out, I’m going to just go with having the sites as a part of the main site instead of as sites on their own.

So when you get challenging problems, it’s really quite refreshing, because you have to go back to first principles of analysis and visualisation techniques to solve them. Where you’re presented with an overwhelming amount of information, and you have to design and implement something which wrangles that raw data into something coherent. Where you have to figure out a way of presenting that information in a way that is visually compelling and conveys that information in a useful, concise form. They are fundamentally hard problems, sometimes solvable, sometimes not, and finding the right solutions, if they exist at all, takes a level of concentration somewhat higher than the usual required to bring our games to life.

This is the state of mind I’ve been in for the last few months. For confidentiality reasons I can’t say anything very much about the project itself (it’s not the lovely visualisation linked above of course), but I wanted to talk about the satisfying nature of developing visualisations in general.

Often when you’re developing code, your debugging tools are limited to logging and step-by-step debugging. But for complex data sets, especially those dealing with spatial data, it’s far more useful to display that data visually. The same is true for end users – a sequence of numbers means very little; a dumped spreadsheet of data, while accurate, doesn’t let you see shapes or patterns. Turn those numbers into 2D graphs, and you can discern patterns, noise and trends. But that still may not be enough. You can make a line graph of each component of a 3D position that changes over time, but in 2D those graphs make little sense. Allow it to be viewed in true 3D space however, and suddenly you can see the shapes. But a line covering every point that 3D position visited tells you nothing about how quickly it moved between those points. So you introduce animation over time, or colour, and suddenly the data makes sense. When writing processing code, a visual representation of the outputs lets you pick out flaws that would otherwise be hidden. Spikes where there should be smoothness, patterns where there should be only random noise, correlations that hint at relationships you didn’t realise existed.

Of course it isn’t as simple as layering in more and more information. With too much visual clutter, it becomes impossible to discern any useful patterns from the data. So knowledge of what data is important becomes vital; ways of filtering information to show only what is relevant allow you to show information where it is needed, and hide it when it is not.

This, again, is one of the reasons why I’m so enthused about VR development. Being able to visualise spatial data is very dependent on good camera work – you have to be able to look around the visualisation. If the camera is out of your control, then you’re utterly reliant on the generated camera. If that is poor, then you might as well have a 2D visualisation of the data, because you need to have some useful spatial context to be able to process what you’re actually seeing. It’s for that reason that many optical illusions that rely on a particular perspective are defeated by moving your viewpoint; if you viewed the same illusion from a static perspective, you wouldn’t be able to tell it was an illusion at all.

Floating cube

So the introduction of VR allows us to get great flexibility of viewpoint, while not requiring the user to learn a cryptic set of control inputs to gain full 3D control over their viewpoint. That opens up great possibilities for exploring even more complex datasets and 3D structures. We’re living in an age where technology has advanced massively and the integration of computing into our everyday lives has resulted in masses of new information becoming available, in overwhelming amounts. Being able to visualise and process that information is the first step to being able to make use of it, and we’ll need new tools and tricks to do that.

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.

Since NASCAR: Redline shipped I’ve been busy with various different things that I’ve been neglecting, not least of which is looking ahead to see where to go next. While I’m still positive about smartphone development, I’m conscious now that the market is rather saturated, and I feel like we have missed the window where a small team can do great things and get noticed for it. That’s entirely my fault, focusing too much on work-for-hire development and neglecting our own projects, but I stand by the choices good or bad.

Recently though I’ve been investigating the resurgence of Virtual Reality tech, specifically the Oculus Rift project and castAR. Both are using modern technology to revisit the old holy grail of immersive digital realities, but unlike previous attempts at it, these project really feel like they are breaking through and making this a real possibility. The enthusiasm around both projects is real and infectious, and having gotten a hold of a Rift prototype in October, I confess that I joined in. Potential projects, interesting research opportunities, titles that you just couldn’t do before, they’re all bubbling up and out of me, and I’m enthused about getting my hands dirty in a way I haven’t been for games development in a long time. What’s clear to me is that many or most of the existing techniques we use, both for user input and for user interfaces, just don’t work in a VR setting. We’ll need to throw a bunch of our old preconceptions about how to build games out and learn them anew; as well as conquer a few more problems which are unique to VR. I have plenty of ideas on that front, but will need to try them out to see if I really understand the problems, let alone the solutions.

My Rift prototype turned up earlier this week, and I find myself massively frustrated that I’m busy with other more pressing projects and can’t get started. I’ll hopefully rectify that soon enough, and you should probably expect a bunch more posts around my experimentation with the kit. I’ll have to wait until next year for a castAR kit, but that will open up even more possibilities in a different way to the Rift, and I think the final solutions will draw on the lessons learned from both systems.

For most developers, the underlying business reality is that the deadlines are fixed, the budget has little room to grow, and the scope is broadly fixed when the title is green-lit. The only axis with any real wiggle room is quality, but dropping your title’s quality will hurt sales, and even if it doesn’t cost you this time, your next contract will suffer because you let the quality bar slip. But it’s that inability to shift any of the parameters which is the reason why crunch is so common in our industry. Starting off with an unrealistic schedule is what causes crunch. Failing to respond to external or internal factors that have increased the project cost, either by shifting the deadline, cutting scope or increasing the budget causes crunch. If a team is closing in on a deadline they can’t make, and the developers can’t shift the deadline or cut scope, then of course they’re going to try crunch, ineffectual as it is. They’re stuck. Why? Because the entire thing was unrealistic in the first place.

Most big games seem to involve crunch in some way (whether they turn out good or bad). But we all know, management included, that crunch is something to be avoided. At some point, the management and/or the team, voluntarily or not, decide that crunch is the least bad of all their available options. Given how bad crunch can be, and how many bad experiences we’ve all had, I don’t believe that smart, capable people would make that decision for no good reason. So I want to explore that reasoning, and perhaps bring it out into the open.

I’d like to posit an example that I’ve seen a few times, obviously it’s not the only case. The developer is mid-way through their project. Two weeks from a big milestone, the time for what needs to go in doesn’t fit into two weeks. Publisher won’t budge on dates or features, and there’s no more people to put on it. But maybe it’s only three weeks worth of work. So the team does 60 hour weeks, but they still don’t quite get it all done. But they were close enough that the publisher accepts it, and the work still left to do (lets say a couple of days) gets rolled over, because you’ve claimed to deliver it, right? You can’t get it cut later, the work still needs done. But hey, only two weeks of crunch is productive, right? And it felt productive – you got 2 and 3/4 weeks done in the space of two. And the crunch is ‘done’. Only now you’ve just cut two days out of your budget for the next milestone. And even if you hadn’t the next milestone was actually a week over budget as well.

Chain a few of those milestones together, and not only have you been alternating between fortnights of crunch and 40 hour weeks, but your actual feature set / quality is lagging behind the milestone list, and the publisher and their QA team know it. For milestone one the decision seemed obvious – it was only an extra week of work, and you pretty much nailed that. For milestone two, well, you knew there had to be a bit of knock-on when you slipped the first milestone a little. Third and fourth? Now the publisher is on your back, and things are getting awkward. Now it’s not “we need to somehow get an extra week’s work done to make this the game we want it to be,” it’s “we need to get an extra fortnight’s work done just to avoid the publisher canning us for breach of contract.” They’re running just to stay upright.

At that point, the management are sitting there with a pretty rubbish choice. If they do crunch, well then perhaps those work-time studies were right, and the team will actually get less than 40 hours done in a 60 hour week. But if they don’t crunch, then they know they’re going to fail. The milestone won’t be hit, the bills won’t be paid, and it all goes south really fast. The only hope they have is that the studies were wrong, that their team is at the top end of that bell curve, and that they can still be more productive than normal even though they’re pushing harder. But the fact is, they don’t really know. There’s no control group to compare themselves against, there’s no equivalent game being made without crunch. So they crunch and hope, while they try to dig their way out by other means (pleading with the publisher for more leeway, slashing the quality bar below where they’re happy with it, stealing resources from other projects / teams).

Thing is, the alternative: no crunch, and hope that by not crunching you actually do more already assumes that you’re so far down the road of crunch that even with >100% effort you’re doing <100% actual work. And most teams aren’t prepared to admit that. Not the managers, the teams. They know that the shit is hitting the fan, and they want to bail the team out, they don’t want to be the ones saying “actually guys, I was zoned out for a whole bunch of last week and maybe did 30 hours of actual work in my 60.” They see their bosses sitting in the meeting rooms with the publisher with all serious looks on their faces, and a lot of them (usually the younger ones who haven’t been through the wringer quite as often) feel guilty that they couldn’t be more effective, that they’re struggling after a few long hard weeks.

Worse, if the managers did say “no crunch, and we’ll do better work,” they’d have to admit to the publishers that they’ve been barely able to hit the milestones they agreed on, making them look like a poor developer. Because even if the publishers aren’t aware of the crunch before, you’ve got to explain why crunching now isn’t even an option. Now if there’s been shifting milestones or external factors that can be argued around a bit, but fundamentally the developer is having to admit to the publisher that they’re not good enough at development to deliver on what they’ve promised, for whatever reason. That’s a bitter pill, and not one that most developers want to swallow.

Again I think it’s stemming from the harsh financial conditions and unfounded optimism: the budget is fixed low due to market expectations, but the feature set / quality bar doesn’t shift; the developers agree to the optimistic assessment because it’s sign this gig or go hungry. Then everybody loses. The team gets burnt out, the developer loses money and their team, the publisher gets a shit game if they get a game at all, and the customer gets delays on their game and a poorer experience. It just isn’t as simple as those who’ve been burnt by crunch saying “it simply never works.” Long term we know that’s true. Even short term it’s not great. That doesn’t mean it won’t happen, or that sometimes it doesn’t need to happen.

Most developers are pitching for business from publishers. A few get their finance from a non-publisher entity, but the relationship is effectively the same. Publisher-owned studios are in much the same situation, it’s just that the pitch and negotiation stage isn’t between two distinct businesses, but between units in the same business; so the negotiation is less antagonistic, but the basic relationship is the same. One side provides the finance, and gets the revenue/profits from selling the game; the other provides the game for some cost. The financier is buying a title that it can sell on for a profit. The console market has moved to a place where to make a profit, you have to hit a certain level of quality and have a game of a certain level of scope. So there is a minimum viable product for the financier, and an effective market size that means it’s not cost-effective to make a title unless it costs little enough that it can make its costs back. Most titles cost is proportional to the number of man-months involved, so shifting a deadline out doesn’t really save any money, quite the opposite – the developer staff need paid more for that extra time. So generally, the deadline is fixed.

It’s with that price in mind the only variable left gets decided: scope. How big a game will it be? How complicated? Will it break new ground, or go with a safe mechanic or style that the developer is confident of delivering for the budget? Here’s where the problem comes: how big does it need to be to make its money back? I think we’ve got to face the very real possibility that the effective cost of making the games the console market expects outstrips the likely revenue you’ll get from those titles. If it does, the difference has to come from somewhere.

From the developer’s point of view, it is hard to get a publisher to sign on to what you think is a reasonable price for making the game they’d like. Of course they want more for less; their margins have been squeezed to the bone as it is. But if you have a team of staff waiting to make a game, the cost of refusing to make a game because the publisher is only prepared to pay 80 or 90% of what you think it will actually take to make their game may be that you fold altogether. At least if you take the 80% deal you can argue the scope down later, or find some other way of making it work.

That’s where the trouble kicks in. If your company is bidding low to get financing, then making up the difference through crunch (which is effectively asking the employees to subsidise the project cost through ‘free’ labour), then it’s screwed. But the alternatives aren’t much better for the company, although they’re clearly better for the staff:

1. Don’t make the game at all. Company has no business, shuts. Financiers get no games, can’t make a profit.
2. Make a smaller game. Market rejects it due to unrealistic expectations, financiers lose out, next title doesn’t get funded, company shuts.
3. Bid low and try to make the game for less than it costs, through crunch. Company and financiers do okay on this title. Staff get burnt out, next title costs even more to deliver (through reduced efficiency/quality), repeat this choice scenario again but with worse numbers to start with.
4. Bid low and manage to raise the price later. Company does okay, but financier loses out when revenue doesn’t match cost. Next title doesn’t get funded, company shuts.
5. Bid realistically, financier knows the numbers don’t work. Company loses out, shuts. Financier either gets no games, or finds some company willing to choose scenario 3.

You can probably see why companies choose option 3, even when they know what the consequences are. Because it’s the least-bad option available to them. And they can persuade themselves that this time will be different, this time they’ll work smarter, and they’ll hit those lower costs without crunching, because they’re good at what they do. When that works out, everyone’s happy. When it doesn’t, there are lots of factors they can blame. NB: “Bid realistically” here means hiring great planners, and adopting a sensible, reactive planning approach like I described last time. A company can be bidding low without even realising it, but that doesn’t make their situation any better.

When the fundamentals of it are that it costs that particular developer more to make that particular game than they thought, that’s a business doomed to extinction. Crunch is a side issue, one of many symptoms, of which the root cause is denial about how much it actually costs to make the games we are building. The only way out is to make different games, maybe in different markets, which actually cost less to make than they take in revenue. Maybe I’m wrong, maybe the console games business is eminently viable. But the reality of difficult financial conditions and the developer’s strategy for dealing with that is the core problem underlying crunch. Railing against crunch is going to do little to help us, if we don’t address the underlying business conditions that cause the unrealistic expectations in the first place.

Recently, in response to this article on crunch, I found myself  coming at this tired old debate from another angle. Many in the industry, generally not management types, are frustrated by the management’s inability to put in sufficient contingency, resulting in an almost inevitable period of crunch, where the developers put in overtime far over and above their expected working hours, to try and get the title out  for its fixed deadline. Typically, when the ‘more contingency’ argument is rolled out, it is countered with “game development is hard, and unpredictable,” and “you can’t schedule for ‘fun’.” The counter-counter argument to that is typically that other software industries deal with equally unpredictable factors, and they don’t have to crunch in quite as pathological a way as we do. The core of these arguments is really this niggling underlying sense that crunch is a natural consequence of not being quite good enough at making games, and that’s problematic.

Thing is, being bad at making games is a cause of crunch. But not because the people making the games are bad at what they do. Because part of making games is estimating how long it will take (and correspondingly how much it will cost) to make the game, given the team you have. Not an ideal team, not the team you’d like to have, the team you have actually got. Planning is hard. Some game-devs, usually the ones who’ve not had to make a plan for any sort of sizable project, think that all that is needed is ‘more contingency.’ This is waved around as if it was really simply to do, and that the management / planners are not doing it deliberately so that crunch is required, because crunch is cheap, and contingency isn’t. But anyone that has to make a plan, and more importantly anyone that has to sell a plan to the game’s financiers, knows that simply whacking on a bigger and bigger percentage figure for contingency doesn’t work. It is admitting that you don’t know how things are going to go, and trying to pick a single large fudge factor that insulates you against bidding too high or too low. We almost never make the same game twice; previous games aren’t much help at predicting how long future games will take. You can break things down to estimable components, but the way those components interact, in ways which may or may not work, which may or may not be fun, is what turns a project from under-budget to over-budget.

That’s not to say we can’t get a lot closer than we do, with better planning. Game-devs in my experience are almost always hopelessly optimistic, even though project after project teaches them that requirements do change, designs do change, and that a sizeable software project invariably has nuances that couldn’t reasonably be predicted at the start. Fundamentally though, there are two changes that need to happen before we’ll stop seeing regular, mandated crunch.

Firstly, we need to accept that the scope, design and timetable for the development is flexible. Trying to nail down the plan up front is foolish and naive. Either the developer does stick to the plan, and the game is crippled because it didn’t respond to the practically inevitable changes that were needed to make it the game it should have been; or the developer diverges from the plan, and either the publisher has to pick up the cost (from the deadline slipping) or the developer does (either by paying for more development time, or by burning out their staff with crunch). As the development continues, the plan should become more and more clear, but it won’t be clear up front. A good developer, and the publisher/financier that is bankrolling the development, will be continually re-assessing the plan as to what is feasible, and what is desired. The publisher will always be pushing for more for less money, and the developer will be pushing for less, but it needs to be accepted that the ‘plan’ is a continually shifting thing, that is going to end up being a comprimise, negotiated by both sides.

Secondly, both the financier/publisher and developer need to be honest about how much it actually costs to make the games that are being made. Hiding the real development cost of a title by burying it in crunch is effectively passing off some of the cost of development onto the staff, and that is fundamentally bad for all concerned. But more importantly, it’s leading both developer and publisher down the road to bankruptcy, from sticking their heads in the sand. More on that next time.

NASCAR: Redline

I’ve shown screenshots there that give you a sense of how great the Eutechnyx art team got the cars and tracks looking, but at its core this is more about the tactics and strategy of real NASCAR racing than it is about twitch driving skills. Not to diminish the thrill of watching the lovely 3D segments where you see your driver slipping through the tiniest of gaps or avoiding a big pile-up, but the off-track decisions play as much a part in your final position as the driving. When to pit, how far you can stretch your tire wear, choosing the right parts for the track you’re racing on, you need to get all those things right to come out on top. For the real NASCAR fans they’ll love competing against their favourite drivers, on all the real NASCAR tracks, to really feel like they’re part of the Chase for the Sprint Cup.

I had a great time working with the team at Eutechnyx to help build this title, so it’s a real thrill to finally see it out there on the app store making NASCAR fans happy. As for me, I’ve been taking a well-earned break, to try and get the constant thrum of highly tuned engine noise out of my head.

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.

Management isn’t generally the problem, the problem is that after a certain point the structure starts to exist to serve the structure, not the needs the structure was originally supposed to serve. All organisational structures, be they flat, tiered, cabals, whatever, are there to facilitate the business needs. Generally a games developer needs to make better games, faster and cheaper. When you spend all day in interminable meetings because your hierarchy is a bad fit for what actually needs done, then communication overhead means that more time is spent talking about what should be done than is spent on doing it, you’re not serving the business. When you spend a bunch of time flitting between tasks because it’s not clear whether you should be doing something or someone else should, and end up doing the same thing as someone else while other vital things fall between the cracks, you’re not serving the business.

All different sorts of management can be fine, great even, as long as everyone remembers that at the end of the day it’s supposed to make the work go better, not worse. It doesn’t matter whether it’s top down, bottom up, side to side or shaken not stirred, as long as it’s making it easier for real, productive, money-making development to happen. Remember those Time and Motion studies? I think that’s what we need sometimes – someone from outside to point out when our structures are getting in the way rather than helping. It’s very hard to see when you’re in the thick of it; you get a sense that something is wrong, that this madness can’t be the best way to do things, but not how to fix it.

For some background, I’ve recently read the Game of Thrones series, which for those who haven’t read it is a gritty fantasy series set in an essentially medieval world. The characters are dark and flawed, and the line between the heroes and villains of the piece is most definitely blurred. ‘Good’ characters are not uniformly noble, and ‘evil’ characters are not unremittingly bad. The main characters are vulnerable as everyone else in the world, they don’t have special skills, they’re not extraordinarily lucky. They die just like everyone else, and just being a main character is no guarantee they’ll even survive till the end of the book. Interesting stuff happens all over the place, not just where the main characters are. Fortuitous events are as often bad for the protagonists as they are good. I won’t say “just like real life” because real life doesn’t have a whole lot of dragons in it, but certainly a lot more plausible than a lot of SF&F fiction.

I’m almost tempted to use the term ‘grown-up fiction’ here, but I think that’s doing a disservice to SF&F fiction, which can be as grown-up and compelling as regular fiction. But the tropes that I see in non SF&F games are the same ones you come across in SF&F fiction and games. Here are few:

• The protagonist(s) turn out to have amazing powers that elevate them far above regular people, e.g. amazing strength, abilities with weapons or magic, or supernatural senses; or maybe they’re the one and only person who is the fulfilment of some ancient prophecy.
• These powers are often previously undiscovered and the protagonists develop them through the course of the story, leading to the story’s climax where the full range of their abilities will be tested.
• The antagonists have powers or a similar advantage that rival the protagonists’, but they will already be in full command of them at the start of the piece
• Alternatively the antagonists will be in control of the world situation (e.g. an evil government commanding an army of minions), and the protagonists are only safe because they are hidden, and achieve victory by using their superior abilities against ever-increasing numbers / strengths of minions.
• Minions will be so staggeringly ineffective their only purpose is to be cannon fodder for the developing protagonist. The unstoppable army that has supposedly swept away all resistance seems to be entirely staffed by soldiers that seem unable to tie their own shoe-laces.
• If the protagonists don’t have great abilities, then they are at least unnaturally lucky – other minor characters throw their lives away while the main characters are miraculously untouched, despite the antagonists being in a clearly superior position.
• Alternatively they will be the rich and noble sons and daughters of the rulers of the land; uniquely placed to get involved in high adventure, without needing to ever sully themselves with something as hum-drum as a regular job, just to earn enough to put a roof over their heads.
• The protagonists will always be in the right place at the right time for interesting stuff to happen. The village which has been ignored by the evil emperor for years is raided by the empire’s secret police only a day after the protagonists seek refuge there.

Sounding familiar? Star Wars, Lord of the Rings, Harry Potter, Eragon, The Belgariad; Call of Duty, Half-Life, Doom, heck – every FPS ever, Uncharted, GTA, Max Payne, Prototype, Ninja Gaiden, God of War. They’re not unique to SF&F settings, but SF&F does use them rather a lot.

This I think is where my feeling that these are immature stories comes from. They appeal to our sense of wanting to be special, we sympathise with a powerless character becoming powerful, and standing for all that’s good against a clearly evil villain. We don’t want them to have weaknesses because we’re putting ourself in the protagonist’s place, and we don’t want to have weaknesses. But the notion of a super-powerful character who is only vulnerable because they don’t realise just how strong they are is the very definition of an adolescent fantasy of what a great character would be. He’s a ninja with super-strength, who can fly faster than the speed of sound, and can also stop time and can totally be invisible. Really? And he hasn’t conquered every enemy in the entire world yet why? Comic writers have realised this since the start, as the arms race of super-hero versus super-villain is a never ending one. A super hero who is invulnerable and superior to all his foes is a really boring character.  They have to be vulnerable, both in their powers and in their characters, to be able to weave them into an interesting story. And no, not being able to be everywhere at once isn’t a vulnerability, at least not a proper one. This isn’t limited to super-hero fiction either: if you’ve played Call of Duty or Wolfenstein but haven’t seen Band of Brothers, watch at least a couple of episodes; the brutality of fighting in WWII is inescapable – one man wouldn’t be mowing down dozens and dozens of Axis soldiers, they’d be lucky to kill a half a dozen before luck meant that they took a bullet themselves.

Now flip it around the other way. There is a surfeit of fiction out there that doesn’t fall into these traps (classic literature such as Dickens, Austen, etc. not to mention crime novels, historical fiction novels, romance novels). But comparably there are very few games which don’t. There are plenty of abstract games (e.g. Tetris), simulation games (e.g. Gran Turismo, flight sims, or The Sims), but I think most people would struggle to name more than one or two high profile games with narratives that don’t fall prey to these same easy tropes. From memory I’d call out “Hotel Dusk: Room 215,” as being a good story with compelling and believable characters without any of the tropes I’ve mentioned above. Similarly the LucasArts games did very well at telling a story without requiring the main characters to be super-special in any way. But these are the exceptions and hardly the norm.

Of course, there are reasons why the fiction in games is written the way it is. A Call of Duty game where you were dropped by a single bullet quite simply wouldn’t be fun. An RPG where you played a subsistence farmer, struggling to get by, wouldn’t keep any but the most masochist player interested. However I still think it’s important to recognise that there is a richness of narrative fiction out there largely untapped because we are treading the safe road we’ve walked before. When accusations are levelled at the games industry that we only make games for kids, and that we’ll never make a game that will make people cry (a lie, I know), I look at the sorts of games that get made, and I can’t help but think that we’re not doing ourselves any favours.

That’s not to say that some games aren’t bucking the trend. “Dear Esther” sounded like a laudable attempt, although I’ve yet to play it. I’d love to see more crime fiction brought to life through games (L.A. Noire, for all its plodding repetitive game-play, was a great stab at this genre). I wish someone would tell a compelling ghost story in the form of a game. Heck, I’d even settle for romantic comedy. Just, you know, something that stretches our boundaries a bit, and not just another bullet-proof space marine or boy that finds he is actually an ultra-powerful magician.

In my defence, it’s been a crazy summer, and I have been juggling many different balls. Thankfully, all the work we’ve been doing has finally come to fruition, and is all now out there in the world so we can talk about it. First off, the work I’ve been doing for the last year or so with Sumo Digital, on Nike+ Kinect Training.

This was mostly working on the localisation aspect, as the game is translated into some 15 languages across 3 discs, there was a lot of voice content to get in. I can’t take much for anything else, but I think the folks at Sumo did a great job on it – certainly when I’ve had to actually stand up in front of the Kinect and do some real exercise, I’ve certainly felt the burn!

In-house however, we’ve had another big project that we’ve put our heart and soul into. Last year, Bliss Kiss Productions approached us with a pitch to re-make Daley Thompson’s Decathlon, for mobile devices. Of course, we loved the original game, I think anyone who had a Spectrum or Commodore 64 will have played it at some point: personally I abused my old rubber-keyed Spectrum 48K terribly to try and get a decent score. Thankfully I didn’t have a joystick at that point, otherwise I’m sure it would have been broken just as many others did theirs. So the chance to bring it to mobile was something we couldn’t pass up.

While we did some solid work on it in autumn last year, other commitments meant that it wasn’t until this summer that we could tackle it in earnest. Which, combined with all our other ongoing commitments, made for a lot of work. Dan’s been in pretty much the whole summer working flat out on it, and seems pretty chuffed with his first proper published title.

It’s a remake from the ground up, obviously. Looking back at the original version it was clear that the design was still fun (we spent more time playing than taking notes when researching), but the rose-tinted glasses of nostalgia allowed us to forget just how dated the graphics looked. On the Spectrum version, Daley’s an all-white blocky sprite with only a few frames of animation! There were also a lot of design decisions that were clearly made due to technical limitations (such as the shot put taking place on a straight track, instead of in a circular pit as it does in real life). Some of those decisions we revisited, but where there was a design case for it, we erred on the side of the original.

What was pretty clear,  from even the first round of focus testing, was that the original was brutally hard in its learning curve. Running events like the 100m and hurdles are straightforward enough, but three events in particular were unique in their own way: the high jump, pole vault and discus throw all differ in style. Instead of rewarding frantic tapping, they are games of timing. In the 80s, it was fine to spring that sort of challenge on the player and expect them to learn it on their own, but modern players are nowhere near as understanding. With that in mind, we put in a practice mode that allowed players to learn how to master particular events, without the added pressure of participating in the whole decathlon; and we put on-screen prompts and buttons to guide unfamiliar players through each event.

Also needing wholly revisited were the controls themselves. As a first principle we wanted to replicate the frantic button mashing / joystick waggling of the original; the user should have to break a sweat to get those high scores, especially in the 400m. At first glance the touch-screen controls seem obvious, alternating between left and right sides of the screen to run. But finding a way to let the user throw and jump without a) accidentally jumping when they didn’t mean to, or b) having the on-screen feedback be underneath the user’s fingers, was not a trivial task. Worse, when you introduce multi-touch, we had to find a way to handle input so that it was always physically hard to achieve the maximum speed. Later focus testing revealed that our use of an on-screen button for throwing / jumping wasn’t working; users were interpreting “HOLD” as a prompt, not a button, and simply holding their finger down wherever they last tapped. Based on that, we revised the controls to respond to exactly that action.

On the visuals and audio, we wanted to aim somewhere between modern and nostalgic. For the art side, we brought in Paul Helman to work on the graphics, and we feel he was right on the mark in his style – not blocky or restricted in colours, but also not trying to be too realistic. At first we were worried about how Daley Thompson would react to the stylised look we gave him, but all the feedback was positive.

For audio, we worked with Gavin Harrison, who did a great job experimenting on the audio we needed. Evoking the ‘old style’ in audio is somewhat harder; the audio chips of the 8-bit era had a very limited range, which just sounds silly nowadays. In the end, we went for a simple synth-sounding musical theme, and some very slightly distorted audio samples.

We finished our work at the end of September, and the game itself was released on iOS and Android on the 21st of September. The PR machine for the launch is in full swing, and we’re eagerly awaiting the public’s reception of it. When the dust has settled, I’ll try to write up a post-mortem of everything we’ve done, what worked and what didn’t, but right now I’ve been enjoying some well deserved time off!

First off I’d agree that this case in particular is not a major issue. None of them (indenting conventions, space conventions, capitalisation conventsion) are, but that isn’t why it gets people worked up when one coder decides to go ahead regardless. The problem is that you have a choice between:

• Original coder does it as agreed first time

or

• Original coder decides to ignore convention previously agreed on
• Entire team endures negative effects of said change until either:
  • Another coder takes time out from whatever else they’re doing to fix it:
    • If they do it as part of a commit they’re already doing, it obscures the diffs for the ‘real’ changes they’re making.
    • If they do it as a separate commit, they’ve got to take the time to make sure that they’ve not accidentally broken something everyone chooses to leave it as it is and over time the entire codebase degenerates into a collection of such issues
  • Somebody writes an automatic tool to fix the problem

Fixing it after the fact is not a good solution, because it’s far more expensive than just doing it right the first time. If there’s a policy, then everyone should stick to it. If they don’t agree with the policy, then they should take that up amongst the team, not just ignore it because they don’t agree and they expect someone (or something) else to fix it later. If it’s a stupid policy, then the team can agree to get rid of it. If it has merit for others then they should respect that even if they don’t personally agree with it: because they’re working as part of a team, not just as individuals, and that should entail a certain amount of respect to your team-mates.

Most of us will have known ‘renegade’ coders, who go off into their own zone and implement some big bit of functionality without consulting with the rest of the team. Sometimes that works well, and other times they come back, throw the code over the fence at the rest of the team and act surprised when they have problems integrating it. That is no way to work, and not only will it lead to friction amongst the team, it also generally means a bunch of wasted effort that could have been avoided with better communication up front. Not respecting coding conventions isn’t nearly as bad as that, but I feel like it’s the first step down the road towards it.

When you’re working in a team, you don’t have the luxury of implementing things in a bubble: you have to work with other peoples’ code, and they have to work with yours. Coming to a common agreement as to how to work with each other is the most basic part of that, otherwise you’ll find yourself working at odds with each other. There can and should be compromises to get to that agreement, but ‘agreeing to disagree’ is generally not a viable option.

Symptom:

You have one bit of code (perhaps a library or a DLL) which thinks that sizeof(std::string) is 28 bytes, and another bit of code which thinks that it is 32 bytes. In Release mode they both agree that the size is 28 bytes. In our case it was actually std::wstring, but both string objects are actually the same size and exhibit the same problem.

Diagnosis:

You have a mismatch in your configuration between the two projects, essentially you’re trying to mix Debug code and Release code, which is just fundamentally not allowed. This much information is readily available on the Internet with some basic searching, but crucially most of those places don’t tell you the one piece of information you really need: exactly what setting is different? Which one of the dozens of settings that typically differ between Debug and Release is the STL code actually paying attention to?

The real answer lies in the details. It is not a Debug vs Release problem (well it is, but only indirectly). If you’re like me, the first thing you checked was the presence (or absence) of the _DEBUG or NDEBUG pre-processor directives. After all, they’re the defines most often used to get differing behaviour between the debug and release builds. You’ll find however that those definitions have no bearing at all on the size of std::string.

Now is probably a good time to visit this Stack Overflow question which links to good information on the subject.

In fact, the root cause is the presence and value of the preprocessor definitions _SECURE_SCL and/or _HAS_ITERATOR_DEBUGGING. If these are defined and set to 1, then sizeof(std::string) will be 32. If they are defined and set to 0, sizeof(std::string) will be 28.

More troubling is that even if those definitions aren’t explicitly listed in the set of pre-processor definitions, I believe the compiler (the Visual Studio compiler at least) will define them for you, based on its own internal logic. _SECURE_SCL will always be 1 for both debug and release builds, but _HAS_ITERATOR_DEBUGGING will be 1 for debug builds, 0 for release builds (as it has a tangible performance impact). You can explicitly turn off _SECURE_SCL to get more performance if you want, but you should understand the drawbacks before you do so.

I will update this post if I find out more about the internal setup of those definitions, but simply knowing that they are the cause of the size difference is usually enough to get to a resolution. I would certainly recommend adding some logging to both code modules that spits out the value of these two defines so it’s clear to you what the values are on both sides.

Resolution:

For most, an immediate solution is to simply manually define iterator debugging to be on or off in both projects so that they are consistent. To do that, simply add _HAS_ITERATOR_DEBUGGING=1 (or 0) to your project’s preprocessor definitions.

You may want to avoid setting it explicitly (ideally you’d simply rely on the compiler defaults), in which case you’ll need to figure out why iterator debugging is enabled for one module but not the other. For that I’m afraid you need more information about how the compiler decides to set those defines, but presumably another one of your project settings is indirectly making the compiler decide that iterator debugging should be enabled or not, and it is that setting which is different between your two modules.

That’s not to say that I discount students from vocational games courses though, far from it. But the quality of those courses varies dramatically, and so it’s even more important to assess the quality of the education they’re receiving. The first and probably biggest alarm bell that rings is when courses employ lecturers without games industry experience. That to me is utter madness. They might have masters degrees or doctorates, they might be the most engaging lecturer in the world, but without industry experience, they are wholly unqualified to be teaching a vocational course. That’s like someone teaching others how to swim when they’ve only ever had a bath. There are many other warning signs of course, but to me an institution that thinks to staff their course with vocational teaching staff with no experience in that vocation is only ever going to produce sub-par graduates.

So my advice to those institutions is this: hire industry experienced people. Poach them away from the industry with better working conditions and less stress, even if you can’t offer them more money. Entice them with the notion of enthusing a new generation of games developers. Find the next big studio that gets shut down (there’s no shortage of those), and see if anyone wants to take a break from the industry proper to teach. But whatever you do, don’t hire academics who’ve never shipped a game in their life.

And don’t hire people who couldn’t get into the games industry on their own, but who want to pretend like they’ve made games so get into teaching. Hint: you’re not a professional games designer until someone has paid you real money to design a game which has shipped. That doesn’t include:

• designing games for your friends
• designing your own game but never actually making or releasing it
• writing books about other peoples’ game designs and how they are good or bad

If you’re going to teach games design, personally I think it should be compulsory to detail which games you designed (or part designed), and how well they did. Your students should be able to go find your games and judge for themselves how good your design chops really are, before they start taking your opinions on design as ‘the way things are.’

That depends on whether you’re interested in building games or shipping games. You’re trading many man-months of effort on a new / unknown engine versus a non-trivial licencing cost. How many games do you have to ship on your internal engine before the difference in cost becomes positive? And what do you do with all those engine developers you’re carrying once the engine is done? Because they’re part of your burn-rate now.

Making your own tech is simultaneously the risky option for the business, and the safe option for the developers. Why? Because as long as you can persuade someone to bankroll it, there’s a tonne of work to do, and it’s nice, tangible work with obvious goals and milestones. You know when you’re done. You know what you’re making. The customers are the other developers on your team, and they’re not nearly as fickle as the public. It’s a lot easier to find success in building your own engine than it is to find success making and shipping games.

That is super short-term thinking though. Because once you’ve succeeded in making the engine, you’ve still got to ship a successful game, and worse, you’ve probably got to ship several successful games before the engine development effort is paid back. Plus your engine will have a lifespan just like they all do: if you don’t profit enough from the games made on it in that lifespan, then it’s been a net loss.

It’s no wonder that individual developers don’t like middleware. It’s clunky, it rarely fits right with what you’re trying to make, and you’ve got little to no control over its development. But “it’s expensive” isn’t a great argument against it, because the alternative is expensive too. It’s not risk-free, but it’s certainly less risky than doing it yourself. It’s a known cost, and in most cases a known risk. Fundamentally, it frees your employers from having to take a gamble on the tech you build, and when the money they’re gambling on your tech is money that they could be gambling on your games, I don’t think that’s really very attractive.

I’d prefer to be working for a smaller company that can be more agile, more robust, and capable of shipping more games, over a company that’s carrying an engine development team, that has to build games based on tech that won’t be done till some future date, and which has less capital to work with because it’s invested a chunk of it in an engine that has yet to pay that money back.

• Hard but rewarding work – need talent and passion.
• The feeling you get from seeing other people pick up the work you’ve made and get real entertainment from it is fantastic.
• Making games is a business, but not a hugely lucrative business. If you want to get rich, look elsewhere.
• Don’t expect a job for life, or gamble everything on one team.
• Employers vary in quality. Good teams make good games. Business can still kill good teams.
• Margins are much tighter, hiring people is a risk.
• Show your talent: make a demo, work on mods. An academic CV is unlikely to be enough.
• Passion should not equal crunch. Enjoying your work is not a licence for exploitation.

Is it bad to be compulsively checking the UPS tracking page for my new laptop? Or to be a little nervous because it’s currently in Kazakhstan, and all those Call of Duty games made me a little nervous about ex-Soviet republics? Is that over-protective? It’s not even here yet, and I’m clucking over it like a mother hen.

Whatever, as long as it gets here in one piece and is suitably shiny. We’re kicking off with our new client this week, and it was immediately apparent that my current 32-bit dual core laptop (now five and a half years old) really wouldn’t cut the mustard. It was okay, just, for building for 360, because the console does all the heavy lifting. But it won’t run a PC build of anything substantial, and compilation takes an age. Not to mention the graphics flashing and sporadic unexplained hard freezes. So the new Macbook Pro kills two birds with one stone – it’s modern and chunky enough that it should build and run the client’s title, and it means Tim and I no longer have to pass the older Macbook Pro whenever there’s iOS work needing done.

To put it in some context, Tim’s machine needed a new graphics card as well to bring it up to spec. His new graphics card scored ~1600 on the benchmarks. The new Macbook Pro’s graphics score ~1300. Tim’s old graphics scored ~500, and the old MBP ~270. My current laptop (and bear in mind I got the Dell Precision M65 with the graphics ‘upgrade’) scores 71. Yes, 71. I had to go three pages down on the benchmark list before I could even find it.

Of course, even the new MBP isn’t up to the level of the monster Alienware M17X that MGS bought for me, but on the flip side, it also won’t weigh 7 kilos and sound like a jet turbine taking off. While I do still miss the glowy lights and brushed aluminium body of the M17X, the added benefit of crotch-based heat sterilisation from the MBP is surely enough to seal the deal.

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.

I’ve the office to myself for a couple of weeks, as Tim has taken the opportunity to use up the load of holidays he’s saved up before the end of the year, and Dan is busy with both university and other projects. I’m somewhat surrounded by Amazon boxes, as my wife has been using the office as a delivery drop-off for a vast amount of Christmas presents for all and sundry; as a personal rule I don’t shop for Christmas until it turns to December, but she’s a bit more efficient and organised about it than I am. As compensation for that though, and because she’s just generally lovely, she’s also had them deliver a shiny new copy of The Elder Scrolls V: Skyrim for the 360. There was a certain amount of giggling with glee when it turned up, as I’ve been quite jealous of all the other devs who are enjoying it: I do like a good open-world adventure. Where I’m going to find the time to play it I’m not quite sure yet, but even rationed out over weekends I’m sure it will be fun. A first quick blast in the office had me running away from dragons, which is always a good start.

On a whim a few weekends back while I was huddled up trying to beat off a nasty illness, I picked up a copy of DCS: Black Shark from Steam; I do like sim games, and the X52 in the cupboard doesn’t get a chance to come out. It was tragically disappointing though. Not because the manual isn’t the manual for the game, it’s the manual for the actual helicopter. That’s half the fun. No, what put me off was the terrible way it was presented. In a nod to playability, they include ‘game’ toggles for the flight and avionics. The ‘game’ flight mode is much friendlier to new players, but takes away half the fun and control I enjoy. However I learned my lesson with Lock On: Modern Air Combat; actually learning the radar and weapons controls for a real combat aircraft isn’t nearly as much fun! So I want ‘game’ avionics, and ‘sim’ flight, and set the options accordingly.

Here’s where it starts to go wrong. If you set either of those options, the game considers you in ‘game’ mode. And there’s an entirely distinct control configuration for game mode. It doesn’t tell you it’s in game mode, or give any indication as to which controls are ‘current’. You are just supposed to know. It’s not even in the manual anywhere, I checked. Worse, the control configuration isn’t accessible from the in-game menu. So you start a mission, take off (because that part is easy), but find you can’t operate one of the controls (of which there are many). Can you look it up? No. Because to look it up, you have to exit the mission, and go check the control configuration in the front end. I don’t even want to change it, I just need to see which button it’s mapped to.

So instead of actually enjoying the challenge of controlling a complex, agile helicopter, I find myself getting into the mission, only to find that the weapons systems are unusable, and I get shot down because I am spending a good few minutes just trying to get a particular bit of it to work. And there aren’t any missions in there that let you just concentrate on one thing at a time. You don’t get a ‘free flight’ mode, you don’t get some a mission with nice simple targets that don’t fire back right in front of you so you can familiarise yourself with the weapons systems. It’s either ‘quick start’ (which throws you into a mission assuming that you have full control over everything), or ‘campaign’. At least the first mission in the campaign takes you through some easy flying, but there’s no practicing of flight maneuvers, just ‘fly there, then there, then home’. That’s not what you need to practice. You need to practice low level flight, and going from full forward to stopped and hovering before popping up over the brow of a hill. You need to practice strafing and orbiting targets. None of which is encouraged in the missions provided.

Anyway, suffice to say that the nod towards making it ‘friendly’ very much fails. It’s not that much friendlier for novices, and those parts are ignored by intermediate or pro pilots.

Lastly, and on a completely different note, we’ve got ourselves a new accountant, who comes recommended from a couple of other game-devs around Scotland. This is a bit of a relief to me, since our filing deadline is the end of December. The previous accountants, who I’ll not name (although they do deserve to be shamed) have been informed, although they can’t have expected to keep our business, not least because they’ve been avoiding contact with me since spring (and their refusal to pay the fines they incurred through their incompetence).

Why is that relevant to object orientation? Well, because the means by which you most commonly ‘fix’ a circular dependency is to abstract one side so that it becomes unaware of the other. So your character system knows about your audio system because characters carry around audio references; but instead of your audio system being aware of characters (so that they can, say, position sounds), you rewrite your audio system in terms of ‘character-like things’. Or more cleanly, ‘things with position’. Because that’s all the audio system really needs to know about. In an object oriented system, you’d use an interface definition to say that characters can satisfy the definition of a ‘thing with position’; of course that’s not the only way to achieve the same goal, but it’s certainly a nice easy way to do it. What’s important is that the library has a nice clean interface, that expresses exactly what it needs, in a succinct way. Ideally, it is also written without explicit knowledge of any other libraries. Having a clean and clear interface is what helps you keep that lovely de-coupled code, and lets you re-use it elsewhere.

Personally, I’ve never had a problem with using interfaces or other object-oriented mechanisms. But recently Pete has been trying to persuade me that object orientation is the dark side, and that our code would be much better if we only thought about things in terms of data transforms. There’s been a lot of eminently sensible stuff written on it, including stuff by @noel_llopis over on his blog, and by @TonyAlbrecht in a talk for GCAP. I’ve read their pieces, and don’t really disagree with most of it. If I have an issue at all, it is that their concerns about OO (and C++ specifically) primarily relate to performance, and when I’m coding, performance is only one factor; an equally pressing factor is how easy the code is to write and maintain.

Here’s the thing though; object-orientation can be really bad for performance, sure. And used badly, it can be really bad for design as well. C++ has a whole lot of cruft that means that expressing the code design you want, without locking yourself into bad assumptions, is hard. Not impossible, just hard. But there are a whole lot of code design needs I have which are very hard to satisfy without the basic features of C++. Interfaces and polymorphism straight off, and probably more. Really though, my problem lies with anyone that tells me that we should all go back to using C instead of C++, because it will avoid all of that bad stuff. Well, sure. I could go back to writing in assembly and never worry about variable aliasing as well, but I’m not going to. I’ll use C-style interfaces when they help, and C++ when they help, thank you very much. Whatever gets me the simplest, cleanest, most maintainable interface, that still lets me do the work.

I have no doubt that using C-style library interfaces would avoid a lot of unnecessary object-orientation. @PetMac is trying to persuade me though that a C-style interface is just plain better, and not only that, but that the inputs and outputs should only be structures defined in the library interface. So an audio transform would be ProcessAudioEmitters, and if you want to process a bunch of positional audio emitters, one for each character, you have to marshal an array of audio emitter structures, and copy the position from your character into its audio emitter. Which doesn’t sound so terrible, if it leads to a cleaner interface. I’d probably be fine with that. At a simple level, for core systems like audio or rendering, where the inputs and outputs are clear and rarely change, I think that would probably work well. Best of all it makes the audio library completely independent – it knows nothing of the things that it’s working with, except the data the other systems choose to feed it.

My problem comes when I consider how I would make that approach scale to all the other systems I need to build. The example I posed to Pete was one of an AI system. To use Pete’s preferred paradigm, and think of data transforms, the AI system would be a DecideWhatToDo transform. Great. What are the inputs and outputs? Well, that depends on the AI. One type of AI might want just a list of character types and positions. Another might want to know about the environment as well. Smarter AI might want character positions, damage levels, movement histories, factional allegiances; as well as the ability to co-operate with other characters. The outputs of the AI are just as bad – they can affect everything from the desired target position, to queuing animations, in fact pretty much anything a character can do might be an output of the AI.

I would describe Pete’s system as a ‘push’ system. Everything the system needs has to be fed to it explicitly, in terms it can understand. The problem with push systems though is that when the number of inputs goes up, the amount of code you have to maintain just for the marshalling of the push grows with it. You find yourself implementing the same code several times: you add the notion of damage to the character, then you have to add the ability to marshal the damage information into a structure the AI system would understand, then you have to add the notion of damage to every single AI interface that wants to know about damage. And in a system with dozens of different sorts of AI, that might be a lot of interfaces.

To me that smells wrong. It means that you’re baking implementation details (like AI ‘X’ cares about damage) into the interface. Conversely, the ‘pull’ system stays relatively clean. You simply pass the list of characters to the AI, or the environment, and allow the AI system to ask the character interface for only the data it needs. Characters might provide a vast array of query-able state, and the AI can pick and choose what it asks for. Of course this comes with a down side. The AI system now has to have knowledge of the character system (or at least, provide abstractions which the character system can fulfil). It’s no longer truly independent. The performance impact of lugging over the entire character object, when perhaps you only want to access a few small parts of it, is very real. But in terms of the ability to write clean code, without a massive amount of interface book-keeping, it’s a big win. That said, I’m open to persuasion. If someone can describe to me how they would write a succinct AI library interface in a C-style, for a few dozen varied and sophisticated character AI, without giving the AI library knowledge of the character interfaces, I’d be happy to change my point of view.

There will be those who say that if your structures are that complex, you’ve already done something wrong. That’s very idealistic thinking. The simple fact is that we are often writing fantastically complex simulations. Sometimes the ‘pure’ systems that you’d need to build to support the level of complexity the design calls for are just far more effort than the benefits they would give. When it comes down to it, we need to write code effectively more than anything else. We need to be able to code quickly, cleanly, and flexibly; especially when the game design is changing quickly as well. It’s of no benefit at all to spend months building a fantastically clean engine to support one game design, only to find that in the time it took you to build it, design changes have rendered it obsolete.

To sum up, because I’ve gone on for a long time: the one thing I like less than being accused of ‘drinking the OO kool-aid’, is the notion that there’s only one right way to do things. As a coder, you should be constantly and critically evaluating all your systems and interfaces. Sometimes a data oriented approach is better: consider the purity of the interface and the vastly improved ability to parallelise and minimise your memory accesses. Other times the structures and inter-dependencies are simply too complex, and object orientation is the most effective tool at keeping your code clean and versatile. I won’t claim to always get it right (as Pete and Tim have both at various times pointed out, I tend to over-structure my code), but I’d hope I always aim for clean code as best I can.

The iPhone app we made for PASG has finally launched – Hold’em Manager for iOS. That was our focus for much of late last year and this first half of this year, so it’s nice to see it out in the wild. It’s a partner application for users of the Hold’em Manager suite of apps, which are a great tool for any serious on-line poker player. Mind you, I do have to persuade our accountant that the money paid to on-line poker sites during testing are in fact valid business expenses. Not sure exactly what category that comes under in our year end accounts.

I took some time out in late July to tackle something I’d been meaning to do for a while: get us some official Company t-shirts. Here’s me modelling the black version:

Very ‘man from C&A’, I know. I’d never make a model.

Our month long experiment with allowing people to comment on the blog without registering first is now done with, as I’d suspected, it didn’t really help much with the spam. Instead of a few dozen spambots registering on the site and needing deleted, we got a few dozen spambots registering on the site and needing delete and a few hundred spam comments which Akismet blocked before ever seeing the light of day. We don’t see a lot of discussion here on the blog, so the increased maintenance effort on my part wasn’t really worth it. Back to registration first for the foreseeable future.

Too much time this month was wasted trying to rebuild Dan’s PC, which had taken to freezing on boot and blue-screening. After swapping out every single component (graphics, PSU, motherboard/CPU, HDD, heck even the keyboard and power cable), we eventually figured out it was the DVD drive. Operated as a DVD drive perfectly, but if plugged in would cause failures. As a result we’ve got pretty much all of the bits of a new machine, so now Dan has his own, entirely rebuilt machine with Windows 7 (instead of a hand-me-down server machine running XP). I also get my XP server back, which I’d been missing as it’s nice to have a box I can run Cruisecontrol and background tasks on. It’s doing a sterling job with our tools work for Sumo, which is occupying most of my time right now.

Team Bondi went into administration. Not entirely unexpected, but still not nice when the livelihood of people is on the line. Hopefully it will serve as a warning to other studios as to what happens when you mismanage a project so badly with regards to working hours. However more likely it will all be pinned on Brendan McNamara, and the crunch part will be played down. The people I really feel sorry for are those at KMM (the only other sizeable employer of digital art staff in the area), who escaped Team Bondi and its management, only to find that their nemeses have now followed them to their new job.

Anyway, that’s pretty much it for now, back to tidying up all the boxes of PC components strewn around the office.

“So, you’re basically making killing people and stealing cars in GTA more realistic.”

At the time it didn’t even seem like too bad a response. In some ways it was a fair trade. Computer graphics are clearly not one of his interests, and insurance is most definitely not one of mine. What he said was somewhat true in its sentiment, but it remains a rather depressing way to look at it.

And I can’t help but finding myself wanting to fight the fight. I wish I could bring more people around to the art, observation, maths, science and problem solving behind graphics! Even gamers see graphics as a very linear and steady progression. You buy a better graphics card – you get better graphics. At the end of the day few care, or really want to know about the details.

To me the fascination is exactly in the details. Sometimes I feel like I’m viewing the world in twice – there is so much more I see! I could tell you the type of shadow your laptop is casting – I could give you the component parts of that shadow and outline them for you. I could tell you why your fingers glow red when you put them right up to a light, and how headlights reflect across a wet road. But graphics gives you even more than that! It tells you so much about the world in general. Through building virtual objects you learn about the real ones. I could tell you about the different ships in the 15th and 16th century, their parts, purposes, strengths and weaknesses. I could tell you in depth about renaissance sword fighting techniques, about the anatomy of a goat, the ways birds can fly and the mechanism for wheellock rifles. Of everything I’ve studied, I’ve found nothing more enriching to my world view.

In my opinion computer graphics is one of the most interesting fields in computer science. It has huge amounts of investment, research and some exceptionally smart people at the forefront. Progress is made by brilliant ideas over processing power. My favourite example is a new technique used to emulate a phenomenon called radiosity. This technique is called Sphereical Harmonics (or Precomputed Radiance Transfer if you like). The effect it emulates, radiosity, is basically when light reflects off a colored surface onto some other surface, lighting that up with some of its own color.

This technique was first developed in 2002 by Peter-Pike Sloan, Jan Kautz and John Snyder at Microsoft. It combines maths from all kinds of research areas, in some spectacular ways. But the real core of up and coming research is what is fascinating, because it’s borrowing from various quantum physics papers that are using similar Spherical Harmonics models for looking at the rotation of quantum particles. There are stories of e-mail exchanges between the physicists and the programmers, with the programmers requesting help mapping the maths from complex-number space to real-number space so that it can be done on a processor.

All this is where virtual reality will come from. Not from the CGI movies, but from games, because they are interactive, and render images at 60 times a second. This is how I like to look at real-time graphics.

If I became a billionaire overnight I would hire the world’s greatest environmental artists and graphical programmers and my game would be a recreation of all the most beautiful places on earth in stunning realism. Because, if I can settle down for the evening in my living room and experience in true virtual reality, with feeling smell sound and sight, the the sun set over the Himalayas – a casual walk along the Great Wall of China early in the morning, then why would I sit down and slog through several more hours of the next GTA?

The final note comes from John Carmack, the real inventor, and prolific innovator of, real time graphics. As well as his primary hobby being rocket science (proving computer graphics really is more interesting than rocket science!), he provides a quote which I think most people involved with graphics can really relate to.

“…after so many years immersed in the science of graphics, he [John Carmack] had achieved an almost Zen-like understanding of his craft. In the shower, he would see a few bars of light on the wall and think, Hey, that’s a diffuse specular reflection from the overhead lights reflected off the faucet. Rather than detaching him from the natural world, this viewpoint only made him appreciate it more deeply. ‘These are things I find enchanting and miraculous,’ he said, ‘I donâ€t have to be at the Grand Canyon to appreciate the way the world works. I can see that in reflections of light in my bathroom.'”

Crunch is avoidable. But it requires a level of maturity and acceptance that the game industry sorely lacks. People argue that thereâ€s always a period of crunch necessary at the end of a project. But thatâ€s not true, either. If you are disciplined enough to accept deadlines and understand that thereâ€s a point where you have to stop adding features, schedules can be planned with some lead time for debugging.

Anyone who tells you crunch is unavoidable is a fool. It might be that the games being made just now are unprofitable without crunch, but that’s not a reason to crunch; that’s a reason to change the way we make games.

On a similar note, you will find a couple of opinion pieces from me over on I <3 Crunch, a new blog set up specifically to raise awareness about articles on crunch, studios who are crunching their staff (and those which aren’t). I hope that by talking about this more we can put to rest this ridiculous notion that crunch is somehow acceptable or something we just have to live with. It’s the industry’s dirty secret, and the more we bring it out into the open, the better we will all be.

My issue with the way the IGDA work with regards to these reports of crunch is pretty much the same every time. They don’t seem to do anything unless someone makes a formal complaint to them, and even then they seem to put the onus on the individuals at the studio to be acting on it themselves. To me, it should be the other way around. There should be a ‘report a company’ button on their website which is 100% anonymous, and really simple to find/use. Once pressed, the IGDA (or whomever) would come along to the company and ask the company if it’s true. Either:

1. the company says it is, and they’re not ashamed
2. the company says it is, and they’re sorry, and here’s how they’re going to address it
3. the company says it isn’t.

In 3) the IGDA can then ask if it can speak to employees at random for their opinion. The company can only really refuse if they’ve got something to hide. The company won’t be allowed to know who said what, and they’ll have to ask enough people so that the employees can’t be threatened or accused of ‘ratting the company out’. The employees will either:

1. confirm that there’s no crunch, and the original report was bogus
2. confirm that there is crunch (and ideally give details), showing that the company is both deliberately crunching, and deliberately lying about it.

In most of those outcomes, they can publicly state the results of their investigations. It doesn’t have to be a big fanfare or singling particular developers out (at least to begin with), just quietly announcing what they discovered when they asked the question.

• If a company is never reported on, you can take that as a good sign.
• If a company isn’t crunching its staff, it can be held up as a good example.
• If a company is crunching its staff and isn’t ashamed, the IGDA can publicise that fact (and discourage potential applicants).
• If a company is crunching its staff but wishes it weren’t, that can be publicised, and the situation monitored; if they have a plan to fix it, the IGDA could go back in a year or two and see if they’ve made progress, and if so hold them up as an example to others as to how to get out of crunch mode.
• If a company is crunching its staff but pretending they aren’t, that can be publicised as well, including the fact that their staff say something different, all of which will discourage potential applicants.

Even those at the IGDA who are convinced that the “40 hour week” is some crazed ideal that not everyone agrees with can’t really argue against that, because you can do it neutrally, without stating categorically that crunch is bad. Even if you think crunch can be a good thing, it can be highlighted in the findings. What matters is that the situation be made clear to one and all.

It only relies on the simple fact that any organisation can ask a question of another publicly. The respondent is then put on the spot, either they have to ignore the question, lie, admit it, or deny it. Failure to answer the question is damning enough in itself. An organisation which doesn’t crunch has nothing to fear, an organisation which crunches and doesn’t care (like Team Bondi) won’t mind the question being asked. The only organisations which would be disadvantaged are the ones who are crunching and trying to hide it. In which case simply asking the question is enough to bring it out into the light.

Our real problem is that the press and the IGDA and others aren’t talking about it enough. Not in general terms (‘crunch is bad’), but in specifics (‘the kind of crunch being talked about at Bondi is bad’). If no-one asks the awkward questions until after it’s been so f*(&ed up for years, then it’s only going to continue.

Curse you and my steel (tin) prison...

At least the squirrels have the decency to stay on the outside of the office though. This little gent (or lady, I didn’t get close enough to check), was the second littlest of a family of mice that have been tormenting us for weeks now. Leaving little presents on our desks. Something in the last couple of weeks must have driven them out looking for nesting material though, because they were all inexorably drawn to the box of packing peanuts that lay out in our office. Bold as brass, we found them rustling around in the box, and popping out the top with a polystyrene peanut in their mouth, trying to get away. Thankfully, their attraction to the box made it much easier for us to arrange things in such a way that we could more easily trap them when they did show themselves. At the current count, I’ve caught four of them, and Tim caught one [Hah – I win!]. We’re presuming the one Tim caught was the daddy, as he was much larger.

All of them were released into the wild (or as wild as it gets 100 yards in either direction along Belford Road), as we’re both softies at heart and couldn’t quite bring ourselves to kill them. Tim’s catch was released on the Dean Bridge itself, much to the amusement of passers by – hopefully it won’t have decided to end it all and take the leap off the edge. They probably have a homing instinct of some sort, but we figure as long as they find a similarly attractive home somewhere along the way back we’ll be rid of them for now.

The second area is in the modding scene. This consists of unofficial add ons, changes and modifications to the games called mods. The modding scene has existed since PC gaming began. It has had wavering popularity but game developers such as Epic with the Unreal series still herald their games “moddability” as a selling point.

The interesting thing about these two scenes is their complete isolation from each other. It sometimes even goes as far as hostility. Modders can see indie developers as stuck-up and pretentious – working on mediocre puzzle platformers with pixel graphics. Indie developers can see modders as simple fan boys, making Call of Duty machinima videos set to “let the bodies hit the floor” and yet more tedious realism mods.

On course, in reality, neither of these are exactly true. My background is the modding scene, so perhaps I have a natural bias toward it; but I’ve been lingering in the indie gaming scene and increasingly I’m seeing the void between the cultures as doing increasing damage.

Artists and Programmers

One of the major differences is that the indie scene is largely constituted of programmings – often contracting out artwork for games. The modding scene, on the other hand, has an abundance of artists, across all skill levels, willing to get their hands dirty.

It isn’t really the obvious benefit that could be gained by a more balance skill set that bothers me most. What I find most annoying is the disjointed and boring artistic direction in both scenes. In the modding scene I don’t want to see another Star Wars mod, another Lord of the Rings mod, another Graphical Enhancement mod – and this is coming from someone who loves all these things like no one else.

In a similar way, in the indie scene I’m so bored of pixel graphics, cartoon graphics, crappy looking 3d games, terrible assets.

In both scenes we have very uninspired and boring artistic direction, with poor technical features due to the tiny number of graphical programmers working with, or being, artists.

More collaboration, sharing of ideas and passions, would be amazing great!

Individuals and Teams

For the modding scene the de-facto standard is to bring a team together to put our your mod. This is seen as essential on anything large at all, and timescales are assumed to be as short as possible. Indie development is the opposite.

I’m not going to discuss if team development or individual development is better or worse. That is one for another time. They clearly have their strengths and weaknesses. Team development is all but useless without someone in charge who is organised and knows what they are doing and individual development is powerful but suffers from burnout.

I think both sides just need to view (or experience) the benefits of the other. Indie developers seem unkeen to share their vision with untrusting individuals, missing out the benefits of a shared workload and new and interesting contributions. Modders set their sights too high, assuming the team will carry the weight, just to fall at the unreliability of others.

More importantly though, I think there needs to be more communication from those with successful and released modding projects and indie games – giving insights into what is needed to finish a product.

Money

For many indie developers making games is a way to make their living and the idea that they are developing for money is a no-brainer. modding on the other hand is almost always free and has a feel about it akin to the open source community.

The result of this is that modding can be more fun – you don’t feel the pressure, and legal complications are greatly reduced. The problem of course is that there is a huge uproar when someone wants to charge for their mod – they are often benefiting off much previous development made by other teams in tools, tutorials and tips. There are strong feelings of betrayal and greediness.

The ideal situation would be that modding remains fun, with reduced legal issues, but developers are more motivated due to potential of making money. The modding community needs to have a serious think about this if it wants to progress, and there are lessons to be learnt from indie developers. I don’t want to make games if it isn’t fun, but I, like everyone else, am sick of failed projects.

Unity

So this is my modest proposal: A community for indie developers and modders to get together and find ways of working on projects that everyone is excited about.

So here is a guide, intended for those readers who want to try to understand exactly what is going on with their computer, and why it’s gone wrong. You’ll have to be prepared to stomach a bit of technical jargon, but I’ll try to be clear. I can’t claim full knowledge on this, but I’ve been working with PCs for over 15 years, and I’m pretty confident I understand what is going on.

My problem arose when I was shifting my existing stuff to a new hard drive, as the only one was reaching the end of its life. I’d like to write up my situation and how I fixed it, in the hope it will be more useful for others than the internet search results I came across while figuring out what I needed to do.

The Situation

Some time ago, I upgraded from Windows XP to Windows 7, and at the same time bought a small Intel SSD to put it on. I’d heard bad things about the upgrade procedure, and felt it was time for a clean install anyway, so I installed W7 on the SSD from clean, no upgrade. The fact that it was an SSD isn’t relevant here, this would happen with regular hard disks too. But what that meant was that I had two operating systems available on the computer. To its credit, the W7 installer was fine with this, and once installed, I had the option of booting either operating system. I got my W7 installation set up the way I liked it, and eventually deleted the XP install. Again, all was well.

I have several disks on my machine, but only two are relevant here: 1) the SSD with a single partition on it (C:), and 2) an HD with two partitions (D and F). Crucially, the D partition was where the XP installation used to reside, and the C partition is where the W7 installation lives. I wanted to migrate the D and F partitions to a larger new disk, and simply remove the old drive. This I did, with the help of Norton Ghost and it’s drive copying functionality. So at this point I had partitions C (SSD), D & F (HD1) and K & M (HD2). I would then reassign drive letters such that the new drive would have partitions called D & F, and the old drive would have no letters at all (and could be quietly removed from the system).

The Problem

As soon as I removed the old HD (HD1) with the D and F partitions on it, the machine would no longer boot, prompting me to insert a system disk. Explicitly choosing the SSD from the machine’s boot menu or reordering the boot order made no difference. Re-connecting the old disk, everything was fine again.

Diagnosis

To boot from a hard disk, a computer needs an ‘active’ partition (active or not being a property set in the partition, usually when it’s created). Normally there is only one active partition on a machine, but if there is more than one, the order in which the computer looks at the disk becomes important (hence the setting in the BIOS to change the boot order). On an active partition, the computer expects to find a Master Boot Record (MBR), which will tell it where it should look for a program which can start an operating system. In a typical, simple setup, the MBR lives on partition 0, the C drive, along with the operating system. But there’s no reason it has to. You can have an MBR on one partition pointing to another partition altogether. And that is what happened here.

Originally, the MBR lived on the partition now called D (it was C back then), with the XP operating system. When it came time to install Windows 7, the W7 installer put itself on C, but it didn’t make a new MBR (because there was already one available). Instead, it simply modified the existing MBR so that it could boot either W7 or XP. Whenever the machine booted, it would look at the SSD, find no active partition, and move on to HD1, where it would find an active partition and MBR, which then pointed it back towards partition C and the W7 install. Everything happy.

When I removed HD1, I was left with the SSD and HD2, neither of which had an active partition or an MBR. So the system did not know where it could boot from, and complained.

Solution

I needed to make the W7 partition active and bootable again, so that the system would operate even if the old disk was disconnected.

To do that, I dug out my W7 installation CD, and put that in the drive (making sure that the BIOS will boot from the CD before trying the HDDs). After starting and selecting a language, you are presented with the installer, but under that is a repair mode. Selecting that, I could tinker with the existing setup. It tried to find a viable OS to repair, but said there were none available (even though I knew the W7 install was still there). I’ve deduced this is because an OS not installed on an active partition doesn’t count. However it still lets you click Next, and gives you various options to work with. Startup Repair (the user friendly option) didn’t work, basically because there wasn’t anything to repair because the repair system didn’t realise the W7 install was there. Again, advice on the internet seems to be just ‘run Startup Repair a few times and it will fix it.’  That’s bad advice, you’re much better off trying to understand what’s currently wrong, because that will guide you as to how to fix it.

From the command prompt, you can run various tools to interrogate the current setup. With other MBR related problems, the advice is usually to just run ‘bootrec /fixmbr’ and ‘bootrec /fixboot’. For me, /fixmbr did nothing (presumably because there was no MBR to fix), and /fixboot gave the error ‘Element not found’. I think the former problem is because there wasn’t an MBR available to fix, and the latter was because bootrec relies on knowing which partition to put the new MBR on. Because the W7 install hadn’t been detected, bootrec had a choice of several partitions, and didn’t know which one to use. It may be that it would work just fine if the W7 install had been detected (if the partition was marked active).

However, from the command prompt you get access to the diskpart and bootsect tools, which are more helpful, even if they do require more technical savvy. I had two immediate problems, 1) the C partition wasn’t active, and 2) there was no MBR on the C partition even if it was active. Both problems needed fixed before I could progress.

Bear in mind, when running from the installation/repair CD, the drive letters your drives are assigned may not correspond to their normal assignments. So I’d advise the following steps:

• At the repair command prompt, run ‘diskpart’
• Type ‘list volume’ to get a list of volumes. One of these will be the CD/DVD drive, note which one (for me it was H); another will be the partition you want to boot from (for me it was D), note that one as well.
• Type ‘list disk’ to get a list of disks. One of them will be the disk you want to boot from (you’ll have to recognise it based on size / brand).
• Type ‘set disk X’ (replace X with the correct disk number).
• Type ‘list partition’ to get a list of partitions. Again, one of them you want to boot to.
• Type  ‘set partition X’ (replace X with the correct partition number).
• Type ‘active’ to make the right partition active.
• Type ‘exit’.

Now your boot partition should be active, but it doesn’t yet have an MBR on it. To get that, you need the bootsect tool. That tool is on the installation DVD, but in a subfolder.

• Type ‘H:’ (or whatever your DVD drive was called.
• Type ‘cd boot’ to move to the subfolder containing the bootrect tool.
• Type ‘bootsect /nt60 D: /mbr’. This will write a new boot sector / MBR to the partition called D. The /nt60 is for Vista or later operating systems.

This should result in the computer now finally being able to boot from the local disk rather than the CD.

New problem

When booting, the message ‘BOOTMGR not found’ is displayed, if you try to boot from the disk you just made active / bootable.

New diagnosis

Now we have progressed a stage. Instead of the BIOS telling us that it didn’t even know which drive to boot from, instead now it is telling us that the drive we told it to boot from isn’t as bootable as we claimed it was. Booting a drive is really just running a particular program – the information in the MBR is not just ‘what partition do I boot from’, it’s also ‘what program do I run from that drive’. For Windows, that program is BOOTMGR, which it expects to find in the root of the bootable partition.

So when I installed W7, not only did it not make a new active partition or MBR, it also didn’t put the bootable software in the new partition. Instead it just modified the configuration for the old (XP) BOOTMGR which used to live on D, and told it about the W7 installation on C instead.

New solution

We need to get a copy of the boot software onto the bootable partition. Thankfully, this is the job of the operating system, and if we boot into the repair disk one last time, we can get it to help us.

Boot from the installation CD, and go to the repair menu. Now we’ve made the W7 partition bootable and active, it should be correctly found by the repair option, and show up in the list of operating systems. For me it was marked as ‘recovered’. There was also another ‘recovery partition’ recovered as well (I believe this is used for other sorts of system recovery, although it was useless in this situation), which I ignored.

On selecting Next, we get the same list of repair options as before. This time, we can select ‘Startup Repair’, and let it do its thing. If you click on the option to view more details about what the Startup Repair is going to do, it should list all the things it checked. For me, the file system and various other things were fine (reported as error code 0x0), but it correctly detected that the boot software was damaged/missing, and needed replaced. Allowing it to proceed, and restart, and hey presto: after a reboot, the W7 partition is correctly booted from, and normal operation is resumed.

While the market for such an app is obviously limited to those people with iPhones either in Edinburgh, or planning to visit and drive, it’s a simple enough design that we’re thinking of making equivalents for other cities with similar parking systems. But we shall see how people like this one before we tackle that.

Next for us? Well, we’ve got a very promising game design in a pretty functional state right now, so hopefully we’ll be able to polish that up and release our first game title! I’ll perhaps share some sneak preview screenshots next time.

The real trouble is that we here at Black Company make terrible cold testers. We’re technical, so we tend to focus on the implementation details rather than the broader feel of the interface. We’re advanced users, used to knowing everything about the software we use; being forced to learn a whole new interface makes us grumpy, but not nearly as grumpy as having not having all of our usual tools to hand. So as I usually do with such things, I hand them straight to my wife without saying a word, and simply watch how she uses it. The question was, really, would it find a use naturally, or would we be using it for the sake of it? And what would that use be?

Put simply, it did, and the use is: content viewing. I had thought that my computer time was read-write, but in reality, outside of work, the majority of my time is spent consuming content and not creating it. Facebook, Twitter, blogs and RSS feeds obviously, but more and more with on-demand video services like iPlayer. The iPad keyboard is, frankly, not pleasant to use (I’m writing this blog post using it as a proper test), but for the majority of content viewing we do, that’s not an issue. In fact, in the few months we’ve been using it, the biggest annoyance has been the fact that much of the on-demand TV we want to watch is on Channel 4, and their web solution was Flash based (i.e. not available on iPad.

And it was what we had to do when we did want to watch those things that drove it home to me. The iPad lies around the living room happily. It’s discreet and portable. To get the laptop out, plugged in, booted, takes a good 5 minutes, not just because it lives in a bag in the other room. So it’s a new way for us to experience the content out there, that we just wouldn’t have done before, and I don’t think I would have appreciated that without properly field testing it (or at least, allowing Vicki to do that).

That’s not to say that there aren’t other lessons to learn too. The bad apps we’ve found are the ones which simply take an iPhone user interface and make it bigger. But the key thing to appreciate about the iPad is that there’s likely to be only one in the household. Whereas the iPhone is a naturally single user device (not just because it’s something you keep on you as you move around), the iPad is passed around amongst the household. So apps like Facebook and Twitter have to account for the fact that you’ll want to easily pop back to the top level and switch users; as well as some loose protection against accessing other people’s accounts. You trust the people you share the iPad with, but not that much. And of course, it’s far less likely to be moving around out in the world, so apps that focus on the geo-location data are far less useful. On iPad, the value is on it’s versatility to display content in a relaxed environment (not necessarily at a desk). The larger display is key to that versatility.

The trick will be to take the things we understand about how the iPad gets used, and use it to inform our app designs.

I loved the original, even though I wouldn’t have bought it were it not tacked onto Half-Life 2: Episode 2. It always struck me as a wonderfully weighted title – just the right length, elegant in its simplicity, and with a level of polish that larger titles just don’t achieve. More than anything though, it was a title that left me wanting more, not because it was too short, but because it was so good. Much like a wonderful novel or film where I get immersed in the universe and characters, the end comes with both a warm glow of satisfaction at the conclusion, and an aching for more. More of the characters, more from the rich universe. It’s a rare creation that brings that level of quality to the observer, and both Portal incarnations have that quality in spades.

I’ve been ranting somewhat about the poor judgement of top-end games development recently. Quality of Life and financial issues are just one facet of a deeper problem: that we’ve been trapped into an arms race of scope. To justify a ‘full-price’ cost, developers feel they have to match or out-do each other. Worlds grow larger and larger, not even bound by memory constraints, since every large game streams their environments off disc. Stories grow more and more epic, and require game-play lengths to match. More characters are wedged in, even though there’s not enough time to get to know them in any great detail. Their voices are provided by more and more famous actors. Cut-scenes get flashier and longer.

The problem is that the underlying mentality to it all is ‘go big, or go home.’ Budgets spiral upwards, or if they don’t, then quality spirals downwards. Both hurt a title’s chances of success. But more quality doesn’t justify a higher price tag to match the increased costs. The players have shown in a wide variety of ways that they’re not prepared to pay any more for games than the already high cost. Second-hand sales and rental mean that the RRP quickly gets turned into the ‘real’ price – far lower. Popular titles drop slower than unpopular ones, so market forces still apply. But as an industry we still delude ourselves that we ‘deserve’ the RRP times the number of units sold.

That’s not the real madness though. The real madness is that despite all our profitability numbers showing the decline, developers and publishers keep on down the same path. They know how much more it costs to increase the scope of the games we make, but they do it anyway. Why? Because they know if they don’t invest enough in titles they flop, because they are competing with other titles on quality. But they don’t know how to turn investment money into quality. Quality is hard. It’s intangible, and you don’t always know it until you see it. So they put the money on things they can understand. More levels, more characters, bigger worlds. They set themselves a benchmark of their competitors, plus some. Because if X was a success, and we have more of everything than X, then we’re as good as X, right?

So when a title like Portal comes along, I regain a bit of hope for our industry. By showing that you can make a massively successful title, not by making it bigger, or more complicated, but by making it good, it’s a bit of ammunition for the decision makers. They can point to Portal and say “it doesn’t need to be big, as long as it’s fun”, or “let’s find a mechanic that works well, and just stick with that”. And maybe we can halt this crazy race to massacre our industry’s profit margins.

[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.

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 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.

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

I was recently discussing the new GTA facial animation technology with some friends and someone made a comment along the lines of “Meh. It’s a shame people will be praising this, the gameplay will no doubt  suck.”

Hearing a comment like that isn’t uncommon, and nor is hearing support for it. There have been a bunch of memes with a similar attitude flying around the internet for the last few years, so I figured I should give a go at dispelling some of the main ones in the chance for some unity and piece of mind.

Modern games just focus on graphics instead of gameplay

This is by far the most common one to hear, and though there might be some truth in it, it’s just a gross dismissal of the issue. The statement is purposefully ambiguous – as to actually use a word other than “focus” ties people down. For these people graphics have just become a scapegoat for bad design.

Most commonly by “focus”, people mean that more money is being spent on graphics than is justified. While games do have much larger budgets for artwork now – budgets across the board have increased. Programming teams, too, are larger, with a requirement for a much vaster selection of technical skills. These teams have had to deal with increasing expectations from the industry as well. The building of expansive maps and characters, which is often the standard now, isn’t just an artistic burden! Design teams are larger too, with a host of new dedicated positions for mapping, scripting, writing and many others. The idea of this paradigm shift by funding toward “having to be the best looking game” is simply a myth.

Even more to the point – does anyone really believe money can simply be thrown at good game design, and if it was the case, with the kind of sums made from WOW, wouldn’t developers and publishers be doing it already?

All my old favourites were just about gameplay

Recently I went back and looked over some old reviews of one of my favourite games, Populous: The Beginning. I expected it to score well overall, being a fantastic game. But what I wasn’t expecting was the fact that in almost every review it scored 10/10 for graphics.

Thinking about it afterwards, it didn’t seem so odd. The graphics for the time were amazing. Deformable terrain and flowing lava, as well as a beautiful world which felt alive with a host of subtle touches. Thinking about it even more I realized that almost all of my favourite games are in the same boat – Quake, Black & White, Sonic 3, Half Life, numerous others. I couldn’t even think of an example with graphics significantly worse than average. Developers have been pushing both graphical and technical bounds since the beginning of gaming.

Graphics are largely unimportant in a game

I think most people would agree, that almost by definition, gameplay is the most important part of a game. But pretending that graphics are unimportant is simply ridiculous. Atmosphere is one of the key parts of a game, and is deeply tied to the graphical style and quality. Immersion also is important, and while this doesn’t really relate to the number of polygons a game can draw, the consistency of the visuals are hugely important.

Developments in graphics are a hugely important device in opening up doors and new opportunities for game designers. It isn’t just coincidence that the vast majority of games for early systems were very similar, and usually tile based or 2D scrolling platformers.

Perhaps in the near future we’ll see another shift in game design and development, similar to what happened when 3D worlds became a legitimate mechanic. I, for one, want to be around when that happens, not lamenting over my Sega Mega Drive.

I don’t care about graphics providing the gameplay is good

This one is most commonly heard from the die hard fans of games such as Dwarf Fortress and the various MUDs and Roguelikes out there. There are grains of truth in this statement but most advocates seem to just be picking and choosing what they consider to be “graphics” when it suits them.

Gameplay and graphics can’t be separated so easily. Interaction, the key element of games, requires graphics at some level, and if it is impossible for a person to relate to this representation of interaction, the game is bound to fail.

The origin of this meme appears as an attempt to distance oneself from the typical screaming Call Of Duty kid, but just because a game doesn’t look like a generic Gears Of War clone, with bloom and HDR turned up to 11, doesn’t mean it isn’t impressive graphically or technically – often quite the contrary.

A good example is the indie gem Minecraft. Perhaps suprising to some, most artists would agree Minecraft has excellent graphics – and the progammers are reasonably impressed too. The whole game is soaked in atmosphere, the style is charming and consistent. There isn’t much more you could ask for.

Look on the net and you’ll find hundreds of instances of most incantations of puzzle and platformer games. It isn’t a surprise that the most popular version is usually the one with the most charming graphics ( N,  Orisinal come to mind).

Number of polygons might not matter to some people, but the ultimate system for how interaction is achieved, does.

So whose fault is it

One of the common trends I see in great games that stick in your mind, is an approach where by the essence of the game appears to be drawn out from the world. Populous, as mentioned above, is a good example of this, as well as another old favourite, Dungeon Keeper. In games such as this, the world and gameplay go together so beautifully that it isn’t even possible to quantify the gameplay mechanics without including the graphics, the atmosphere, the story and all the rest with it.

It seems that many modern blockbusters have a focus on “features”. Fallout 3, for example, feels very odd to play because it is set in this wonderful rich universe, but the gameplay is still more or less completely separate and abstracted from the setting. In a similar way, you could name a number of other recent titles, that seem like basic first person shooters with a graphical setting, and a number of “features” tacked onto the side – and none of that holds together very well.

Graphics and gameplay aren’t these two brothers competing for attention, and if you intend on making a truely great game, act like the responsible parent and don’t send them to their individual rooms – force them to play nicely together.

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.