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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I remember well the moment I realized that game art was probably going to be the most rewarding and fulfilling career option for me. I was talking with another artist and it was almost an hour into a conversation dedicated to techniques of achieving ambient occlusion in real time. At this point I realized three things. Firstly, that peculiarly, I was still enjoying the conversation and felt I had things to say. Secondly, that for the sake of everyone else, it was a good thing I had never met another games artist at a party, and thirdly – that game art is probably my best chance of getting a job doing something I love.

I’ve come to realize that game art is a fairly niche interest. There isn’t a digital art society at the university, and even if there was, I suspect the chances of me meeting another games artist there would be low. When I explain to people what game art actually is, I think they imagine it more as a technical skill – they imagine learning how to use certain computer programs or tools in a similar way to when they learnt how to use Microsoft Word. Perhaps this is to be expected. Although many games in the past have been very beautiful, and I’ve played games in which I’ve been attached to a certain character, often any real feeling is overshadowed by underwhelming storyline, hollow characters and immersion-breaking glitches and oddities. It is still generally an odd thing to think of game art as something that expresses emotion, feeling or ideas – something that comes so naturally to conventional art forms.

I suspect the majority of games artists, when you ask them what they do, will say they “make games”. Not, as their title might imply, that they are “an artist”. In some ways I resent this. Not because “making games” is some sort of trivial pursuit, but because in a greater sense, an artist is attached to themselves, their own experiences, and the artistic community – more than their company or game, of which they might have little input into the real “game” part of. Even more so, game art is not like programming, or the technical use of a special tool. Game art is a creative process. It requires the same state of concentration used for other creative processes. It requires experience, training and knowledge. It requires for the artist to hold an image of what they wish to create in their head.

Perhaps people’s impressions will soon be changing. There is a new form of media taking it’s baby steps into the world – so called “interactive storytelling”. I may not be in the majority with this view, but I am extremely excited about it.

As computer power, artistic skill and graphics engine design have improved, we have finally reached a point where we can render semi-photo-realistic scenes in real time. This gives “interactive storytelling” something over film, books and music – a level of simulated interactivity. Whether this can actually contribute anything to the experience is up for debate, but what it certainly does do is create a reason for this new form of media to exist – and that is enough for me.

There was recently an update to what is one of my most anticipated game developments ever:

The Dear Esther Graphical Remake

Not only is Robert Briscoe one of my favourite digital artist of all time (Having worked on Mirrors edge, a game with simply spectacular visuals), but Dear Esther will probably have been most people’s first introduction into interactive storytelling, and probably the best example of its genre to exist.

The graphics in the updated development version are not only stunning in their realism and technicality – but more importantly they are deeply emotional and the product of a personal project – something that is perhaps more familiar to the creative process of conventional artwork than we have seen before in the games industry. In this sense, the update is a true landmark.

I can’t wait for Dear Esther. Not just because I believe it will be a unique and beautiful experience crafted by some of the best minds in the games industry, but because it might even make me reconsider how I view myself. And perhaps the games industry will do the same.