(…continued from part 1)

First off, this implication that number of hours you work has absolutely zero relation to the level of talent you possess. I’ve worked with talentless hacks that “worked” 60-80 hour weeks and still achieved less than everyone else. I’ve worked with amazing people who worked bang on 9-5 Monday to Friday and were some of the most able and committed developers. Of course there are extreme cases – talented folks who love their job so much and are willing and eager to work extra hours, just as there are people who are so apathetic about their work that they don’t even want to do their contracted hours, and coast at every opportunity. Talent and the number of hours worked are independent variables. To try to connect them is not only foolish, it’s selling your employees short.

The coasters need to be sacked, plain and simple. Those who work extra hours but aren’t very good should be given the chance and help to improve, but if they can’t they need to go too. Those who work the 40 hour week and produce are the core of your business, and need to be treated like the stars they are: not only are they good at producing, they are sensible enough to do it in a sustainable way. Those who are great and want to work all hours can be gems, but only if they are managed properly. Try to keep them to a sensible working week, and they’ll stay gems for longer; if you don’t they’ll last a while, and then burn out.

Burning out

We’ve all seen it, many times. Constrain their hours and they’ll find other ways to excel; they’ll cram the same amount of work into the time they have, or they’ll go away and enjoy their evenings, eager to come back in the morning, brimming over with good ideas that they’ve been thinking up while they were away from work. But most importantly they’ll have had a life outside of the work, and that will make them happier with their lives and happier with their jobs. If you let them work those crazy hours, you are both taking advantage of their generosity, and setting an unreasonable precedent that other individuals on the team should be doing the same. No matter how much you tell your employees that 9 to 5 is fine, they’ll look at the long hours those few are putting in, and feel that by not doing those hours they aren’t pulling their weight.

Most of all I detest the idea that making games is special, and that somehow by getting to make games we forfeit some of our rights because we get to do work that we enjoy. Screw that. I make games for a living because I love it. I’ve already sacrificed the higher salary I could get in the regular software world. I’ve sacrificed the stability you get outside the games industry. Now you’re trying to tell me I should sacrifice my quality of life as well? And to top it all off, I should be thankful to those who pay my salary for the priviledge of doing my job? No thank you.

When I’m making games, I’m doing a job. I deserve to be paid for the job I do. You want me to sacrifice quality of life, you pay me for the priviledge. My love for what I do comes out in the quality of the products I make, and that’s the only outlet there should be for it. Making games needs passion because the games themselves need love to make them good. By asking for ridiculous working hours or low wages, you are asking me to be less passionate about my job because to do it I need to accept being screwed on pay and conditions.

I’m not some idealistic student, I know that it’s not as simple as just clicking your fingers and suddenly we’re all working standard hours for good wages. The business needs are always going to come first. Sometimes the deadline will loom, or things will go wrong, and we’ll have to work long hours to put it right. We are dedicated people, and exceptional circumstances require exceptional measures. But right now, the individuals working in games development are being regularly asked to subsidise their employer’s costs by means of their own time and effort. Worse than that, many of those employers think this is fine and right and just the way things are. Wrong. The sooner we accept that abusing our staff is unprofitable in the long term the better off we will be as businesses. The sooner we accept that the 40 hour working week is the norm, and everything we do should be trying to get us closer to that norm, the better off we will be.

And so the perennial topic of working hours comes back to us again, this time as a result of some spirited discussion from the IGDA. The exact nature of the discussion has been covered well elsewhere, but suffice to say that an IGDA board member (Mike Capps of Epic) has been lambasted by the game developer community in general for his statement that Epic doesn’t want to hire the sort of people who just work 40-hour weeks.

Slaves to the Grind

There are two parts to this issue really, the first fairly obviously is the problems that this has raised in the IGDA itself. Rather than take what seems to me the obvious route (make a public statement that Epic, while being free to run their studio any way they see fit, is choosing to operate in a way at odds with the IGDA’s stand on quality of life for developers), when pushed on the matter, the rest of the IGDA board has essentially folded, almost entirely on their QoL position.

Now for an organisation that has put QoL very high up on its list of priorities, this is a real problem. The developer community (or at least, that part of it that I hear from and talk to) has always struggled to see the value in an IGDA membership; it doesn’t provide much in the way of tangible benefits, and the social and networking aspect varies massively based on the activity of the local chapter in your area. Certainly the IGDA doesn’t provide anything like the benefits that a union would, as it’s specifically written into its constitution that it cannot become a union or anything like one. But the IGDA’s advocation on quality of life issues has always been one of the big pluses for it in my book – it occupied a niche in that it is placed to represent the best interests of its member developers in campaigning for a better industry for us all. To take away that advocacy position seems to me removes the biggest reason to support or recommend membership to others.

The furore surrounding both the original statement by Mike Capps, and the subsequent IGDA refusal to condemn his stance on general principle is what confounds me though. There is no reason why individual members of the IGDA, even board members, have to work for studios that slavishly follow ever policy that the IGDA might recommend. And with that in mind, it’s perfectly acceptable for Mike Capps to remain a board member, even when his employer’s position conflicts with the recommendations of the IGDA. The next time the elections come around, the IGDA membership will think long and hard about whether or not it’s a good thing to have a board member whose personal policies conflict with such a high profile policy of the organisation. Great. That’s democracy in action.

No, what bothers me is that the other IGDA board members have steadfastly reversed their own organisations positions rather than criticise another board member. They even seem to have gone so far as to implicitely defend Epic’s policy. What, exactly, is the point of saying “all studios should aim for a 40 hour week, because it’s better for everyone involved”, if you then follow it up by saying “oh, unless you’re an IGDA member already; in that case you can run your studio however you like, and I’m sure Epic have a good reason for preferring a longer work week, they do seem to be quite successful and all.” The whole discussion on the IGDA forums has been flabbergastingly forthright in its defence of the over-working of individuals in games development.

The board members, and other senior figures in the IGDA, all seem to be quite surprised at the vehemence with which they’re being attacked. They don’t seem to see their own stance as hypocritical, but attempts to get them to justify their position have resulted in only anger and latterly heavy-handed moderation to quell the continuing argument on their own forums. More recently they have come out with public statements to clarify their position, and to attempt to re-assert their original position on QoL issues, but it all smacks of too-little-too-late unfortunately. The board’s own defence (both implicit and explicit) of Epic’s practices have in my opinion exposed their stance on QoL as nothing more than lip-service towards the ideal, despite the obvious importance the issue has with their (non-management) membership. If that membership hasn’t already voted with their feet and left by the next elections, I hope they show their dissapproval and vote out the incumbent board members in favour of some who actually believe in the policies the IGDA publicly endorse.

All that said, I’m not an IGDA member, and with all of this, I have no intention of becoming one now. No, what worries more is the attitude shown originally by Mike Capps, and latterly people on the IGDA forums. That somehow a person who only wants to work a 40-hour week is just a jobsworth, there marking time and collecting a pay-cheque but with no real passion or involvement with the work they do. That somehow the number of hours you work is linked to your talent. That somehow the fact that the job is making games makes it special, and exempt from all of the normal moral implications of taking advantage of your staff. 

(continued in part 2…)

We were having a discussion this morning about the perils of building your business around a popular tool that you’ve made, and I thought it might make a good blog post. Really this is inspired by the impending upgrade I’m going to need to do to SmartSVN 6, despite having only just bought a SmartSVN 5 licence. It’s a nice package, especially the diff tool. And there are times when you really do want to navigate the changed files in a large tree of directories, and TortoiseSVN and the command line shell really suck at that.

My problem comes in that pretty much all of the functionality I needed from the tool has been present since version 3. Sure some of the new features are nice, and the overall application is prettier now. But mostly what has come in subsequent versions has been for me superfluous bloat. It means the installer is bigger, it means the application is slower to respond, and more complex to navigate the interface. And really what I actually would most value is if I had pretty much the exact same set of features, but a) bugs were squashed and no new ones added, b) the support for the underlying system (in this case Subversion) had been kept up to date, and maybe c) the interface was improved and streamlined.

It’s not just SmartSVN though, it’s lots of applications. GetRight, ACDSee, Word/Excel/Office, all of which have gone through many revisions, each one adding more and more features that I don’t really need or appreciate. In the case of ACDSee the later versions actually made the interface worse, which effectively removed the one feature that people bought it for – the quick and easy way to mouse-scroll through whole directories of images.

The problem here is that what the end users want is fundamentally at odds with what the business needs to do. The end user would be quite happy having the same application and just keep using it forever. But for the business that authors the application, that’s a losing proposition. They’ve made one sale, and they get no more. What they really want is to be able to sell more things to the same user. If they make a new version of the tool, they can put enough new features in to persuade the user that it’s actually a new application. The user isn’t an idiot though. They know it’s not a whole new application. Maybe they need or would like some of those new features, maybe not.

Most likely they’re buying the new version because it fixes bugs in the old version, and is better supported. I’d even go so far as to say that they’d be willing to pay for those bug-fix and maintenance updates – not as much as they’d pay for a whole new version, but something at least. Some companies, like Whole Tomato (who make Visual Assist) have a refreshingly straight-forward approach to this: you buy the application, and you get X months of updates along with it. After X months, you have to pay again a smaller amount to keep getting updates.

Even Whole Tomato though are guilty of the most annoying of the application developer’s sins (from an end user’s point of view at least) – feature creep. Every development has a Request For Enhancement list which is used as a back-log of items that might make their way into the application at some point. Anything reasonable the end users request goes on that list. And because the developer is a business, that makes its money from cranking out new versions of the application, they work through that list, pretty much endlessly. So an application which is clean, usable and decently featured in version 3 can turn into a Swiss-Army-Knife of an application by version 8; bristling with functions, features and options, which the majority of users, other that one user who requested it originally may never touch.

It seems that very rarely is the decision taken to just draw a line in the backlog and say “it’s good now, let’s just stop adding features”. Keep selling it, keep maintaining it, putting out bug-fix and maintenance upgrades, but no more features. What, I ask, is wrong with making compact applications with specific and targetted functions? Even if there are valuable features to be added, why not ask if there is value in maintaining a Core and a Premium version of the application? Or even multiple Premium versions? Find your users and target the groups who want to buy your product. Give them each their own version. Discontinue versions that don’t sell well, and maintain versions which have.

A well architected software development can maintain development on multiple branches simultaneously with not too much extra effort, certainly there is a cost but I believe there is also a reward. Give your users exactly what they need and no more, and you avoid becoming the behemoth application that is under-cut by a spunky fresh new competitor, that didn’t have all of your features but had “just enough” to be valuable, was cheap enough to develop to undercut you on price, and flexible enough due to its small size to adapt quicker and better to changing technology than you did.

Some discussion on the Chaos Engine about code reviews and check-in process had inspired me to write up a post on my thoughts on this, but on my morning trawl through my RSS feeds this morning it looks like Lee Winder has beaten me to the punch. He pretty much covers all of my thoughts on the matter, and I don’t think I disagree with any of his opinions, so hey, job done. 🙂

In summary if you don’t want to follow the link though, I’d say code reviews are a good thing, especially as teams scale and there are differing levels of skill and familiarity with the code-base. They get everyone on the same page about what is being written and how it is being built. Pretty much all of the criticisms levelled at the process are from people who have had bad experiences due to issues completely outside the scope of the process. If your code review was useless because the reviewer was being a) petulant and petty, b) disinterested, or c) unable to comprehend the issues involved; then the issue is with your team ethos and make-up, not with the review process.

I want to write up my thoughts on the ongoing IGDA debacle, but suffice it to say for now that any interest I had in re-kindling the Scottish chapter have been well and truly snuffed out.

So it seems that aside from just the usual wildlife inside the office (i.e. the ubiquitous Edinburgh mice), we have some visitors from outside as well.

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

Gah. New rule for Subversion repository maintenance – run “svnadmin verify” as often as you run your off-site backup process, and arguably don’t do the backup if it fails. One of our support repositories (as opposed to a development repository which I’m a bit more paranoid about) has had a dodgy revision in for a few months now which would have bitten us had we had to restore from scratch. It looks like it was a failure while checking in a massive binary file – it doesn’t affect the day to day running of the repository, but it means that we can’t dump or load (and correspondingly can’t effectively restore from backups).

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

Symptom:

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

Diagnosis:

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

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

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

Possible Solution:

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

Process:

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

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

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

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

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

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

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

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

Here’s a little spiel I wrote up in response to a student doing research who was asking why we set up in Edinburgh rather than Dundee, and what I thought of Dundee as a creative hub. It’s got a bit of history of us in there, so I thought it would make a good blog post.

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

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

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

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

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

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

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

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

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

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

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

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

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

Amongst various things I had to sort out today, I was asked to write out a blurb for a potential client about improving build processes and automating/scripting things in the development pipe-line. It’s a subject I get quite passionate about, because unlike so many things in games development, it’s a nice task to do. There are clear, quantifiable goals (“make creating a build a one click process”, “speed up turn-around times for artists by 50%”), and usually plenty of options about how to get there. It is also a nice, self-contained task that you can just wade into and make progress on, unlike for example gameplay coding, where you can often get blocked on feedback from the creative team, having to rework things and so on.

I think that’s possibly why I like to spend time on improving our pipe-line at the weekends or in my off-time; even though I could spend more time on the big pile of client work that needs done, I find myself tackling little bits of our own pipe-line because I know it’s a task I can get done without any other input.

On that note, with some more collaboration with the developers on some little niggles, we finally switched our creaky old makefile based system over to using JamPlus properly. Both build processes still run side-by-side, but the JamPlus version has a fraction of the number of lines in the makefile, runs much faster doing dependency checking etc., and in general is much cleaner and will be more maintainable going forward. I’ll have to walk the guys through what’s there so they can maintain it too, but after that I should be able to scrap the makefiles altogether.

Next step is the art/audio asset to platform binary conversion process, and this is why I really wanted to switch over to JamPlus. Our previous art pipeline would always rebuild platform assets, even if the source assets hadn’t changed. That was fine early on, when all of our tools ran lightning fast and we had few source assets, but very quickly it grinds when you introduce slow tools (such as our font encoding tool that does smart packing of glyphs and colour conversion), or many assets. Also the build scripts which make those assets are all Lua based, and so we have different technology for building code than for building art and audio. I’m pretty hopeful that we can make JamPlus fulfill both functions, and in the process get fast dependency checking for our art assets so that only the assets that have changed get rebuilt. But for that I’ll need a free day, and those are few and far between right now.

Exciting news! And pictures!

We’ve finally shifted to our new place in Belford Road. It’s really just around the corner from our old place, but is generally much nicer, larger and more flexible than our old place. If you look back at the pictures of the Palmerston Place office it’s clear that we struggle to fit all four of us into the room, what with all the boxes and kit and other things. The new place has a lot more room to breath and so everyone gets more space. Plus we have a whole wall that we can have nothing but white-boards on, and I won’t need to hover behind Pete’s desk to draw on the white-board while he’s trying to work.

Enough talk – some pictures and a movie link:

Exactly what we’ll do with all this space I don’t really know yet! Obviously looking at the movie you’ll see the place is still being worked on – thankfully that just means that we get a good deal on the rent in return for putting up with dust and loose ends everywhere. But even with that, it feels like a much more creative space than the last office, a place that I can see us making games in.

In less upbeat news, we’ve been somewhat idle over the holiday period; one of our more important clients has had to stop giving us work due to a publisher they’ve been working with having trouble. So we are currently casting around for new clients and opportunities. Sadly that does mean that we’ll probably have to trim sails for a bit to get through the rough patch, and exactly what will happen we can’t really predict. And in the meantime we will just have to fill in our time by experimenting with some new gameplay ideas that we keep talking about but never get any proper time to do anything about.

Okay, note to library developers. When you’re providing documentation for your class library, a bunch of pages like:

SomeObject::GetID method

Gets the ID for the object

Does not mean that you have thorough documentation. Seriously. That is all.