5th Anniversary

So GoGo-Robot will officially be 5 years old in April this year, so I thought it was a good time to reflect on my past years in the games industry, give an update on what’s been happening with both me and the company and what’s the direction for the future. I’ll point out some helpful tips along the way that I’ve learned and will hopefully be of use to someone. I guess this post is a bit longer than I’d planned, but I enjoyed writing it, so I hope you enjoy reading it. So without further ado, let’s take a look at…
The Past
I normally start my story about being in the games industry just after leaving university and going in to my first job at a games studio, but I think for this I should really start at the very beginning. I’ve been playing with computers in various forms since I can remember, and have always been interested in how they work, and how you could make them do all sorts of interesting things. Our family has always been surrounded by computers, with my parents running a local computer shop, so we always had all kinds of different makes and models to play with. The first computer that I personally owned was a ZX Spectrum with the lovely rubber keyboard, and straight away I wanted to figure out how it worked. I’ve always been like that with pretty much any electronic device, which has led to quite a few instances of electrocution, but thankfully no lasting damage. Not only could you take them apart with a simple screwdriver and look inside, you could also just type commands in to them and make them do all sorts of things. I first started with BASIC, but dabbled in some machine code too with the help of my brother. I guess I was maybe around 7 at the time, though my memory is usually pretty bad (hmm, maybe those electrocutions did cause some damage after all). It was fascinating how you had these few simple commands, but you could combine them in all sorts of different ways and create so many things. It’s pretty much just like Lego in that way, and everyone loves Lego.
I was always tinkering with computers in one way or another – after school or on weekends I’d go to my parents shop and play on them there, trying to figure out how they worked (which I think is an often overlooked area by many programmers – if you don’t know how the computer works, how can you program it effectively?). Anyway, I eventually got a PC (well, the parts of a PC so we could put it together ourselves) one Christmas. It was a 386 SX 25MHz PC with a 20MB hard drive, and you could tinker around with all sorts of things on it. I eventually found Microsoft’s QBasic, with its bundled games that were fun, but that you could also just edit the code for to change the game.
Anyway, through school and college, there wasn’t really much to speak of in the way of computer education. The school’s IT course was mostly concerned with a database program I’d never heard of before or since. I can’t even remember its name, but I know we had to save our work regularly, and always under different filenames, as the program would either crash randomly, or just corrupt your save file, so I guess they maybe just spent a couple of years teaching us about backing up. I’d been continuing to teach myself programming throughout school, teaching myself C/C++ mainly (which meant I’d taught myself so many bad habits that if I looked back on some of that code now I’d probably cry), so I wanted to do computing at college, thinking that then I’d get some really tough problems to sink my teeth into, and get into some decent programming work. Although we did some theory in a couple of interesting areas, and we did finally do some programming (PASCAL and 68000), they weren’t the major part of the course. I took the opportunity to do some extra curricular activities in PASCAL and made a couple of little games to play in class and annoy the teacher (there was a trend of annoying teachers throughout my time at school & college), but our main project was… Yup, another database. Sigh.
So when it came round to choosing university courses, I was split between a pure programming course, or something more electronics based (A.K.A. ROBOTS!). I decided to go with a computer games programming course; after all, I’d enjoyed making those games and playing them, so I thought it would be ideal. Looking back, I’m borderline undecided as to whether or not that was a waste of three years (education wise – experience wise it was definitely not). When the course contains modules such as “History of games”, which culminated in a multiple choice question exam featuring questions like: Who is this? a) Sonic the Hedgehog, b) Mario, it was not looking good. There were some interesting modules on the course, mostly to do with maths (yes, with an ‘s’), which gave a good grounding of the maths that I’ve used countless times in games, but overall there was not really much to speak of in the way of structure. In my mind, a good way to learn games programming is to, you know, program games. It’s a shame that there were so many missed opportunities on that course to deliver an excellent package. It’s a three year course – surely it could be structured in a way that you can design, build and test at least one or two games over the time you’re there, right? Instead, we were taught a mix of semi useful and totally useless modules, with no connection between them.
As was always the case, I continued my own learning and programming at home during my university time, so I’d already learned most of what they were teaching us by the time it came round to doing the module at university, which was both a good and bad thing. Good in the way that the course was just cementing things I’d learned, but bad in the way that there was nothing really new or interesting on the course. I was expecting a university course, especially in computer programming, to be full of new, cutting edge methodology and technology. It wasn’t, and not only that, it wasn’t really giving you a good grounding of the fundamentals of game programming. It was kind of a random pick’n’mix of some parts of other computing courses, thrown together without any kind of direction. I’ve often thought about one day applying to that university to help them structure the course in a much more coherent and beneficial way, just because I remember how disappointed I was with the course and don’t want anyone to lose out on what could be such a valuable learning experience.

Tip: Don’t just learn at a course – practice at home and in your spare time. Make small games and build a portfolio.

I graduated in 2005, then sat around for the rest of the year to have some down time and mostly play Counter Strike, until my money ran out and I thought it was probably about time to get a job, so I began applying towards the end of 2005, and got a programming job starting January 2006 at a games company in the North East of England. I’d been offered a couple of jobs at different companies, but I went with this particular company because of their diversity in projects and the atmosphere in the office when I’d been there for my interview. They created a lot of very different games and worked on a lot of different platforms, so it was an ideal fit for me, wanting to learn all sorts of new technologies and methodologies. It was a medium sized company (I think around 40 – 60 people at various times), but usually split into smaller teams for the different projects we had going on, which meant you didn’t get lost in the crowd and had quite a bit of responsibility on you to make sure you weren’t falling behind.
I think working in an office like this is the best thing for any graduate. There was plenty of experience in the office from industry veterans, so you could see how things actually worked in a games company, and you were thrown in at the deep end, so you had to learn fast. And there is a lot to learn. There’s also a lot of responsibility, and if you make a mistake, you’d better learn from it. I think one of my first mistakes was to tell the artist working on a project I was on to bake all the text for the game into the background images, because it was easier for me to just display an image than to have to get the Sony PSP to render text using our engine. Unfortunately, we then had to do an EFIGSD version of the game (English, French, Italian, German, Spanish, Dutch), and the images all needed to be cut up manually into various sized tiles to be used on the PSP (stupid PSP, not supporting non-power of 2 textures). This meant a lot of work (and I mean, a LOT) for the artists, and a lot of animosity towards me (Sorry!). However, I did learn after that that you shouldn’t really try and take the easy way out (and never bake lots text on to images, especially if you need to translate it), as it’ll always come back to haunt you!

Tip: Don’t take the easy way out – plan for the future

I have to say, I really enjoyed working in that company. I think everyone should work in an office for a while at least once in their life so they can get to know how the office dynamic works, and more importantly, see how the whole production process of a game works. It’s much more difficult to understand how people are working or what to expect from others when you’re freelancing or working from home. You can’t just wander over to someone’s desk and watch their work flow or how their thought process plays out, and you very rarely get to catch problems early on, instead just getting a dump of work from one freelancer to another. It really pays to have an insight into how other disciplines will give you their work, so you can plan appropriately. I think it’ll always be the case that a designer will never give the artists and programmers what they want, an artist will never do what the designer and programmers expect, and programmers will just do whatever they feel like.

Tip: Work in an office before freelancing to get a feel for how others work

That actually leads me on to one of the down sides of working at a games company. It’s very easy for the entire team to become games designers, much to the detriment of the quality of the product. It’s one thing to have input into a project from all team members, and that can be very beneficial in the early stages of development, but you’ve got to be careful to know what your role is in the team, and respect the game’s design, especially if the game is for a client. A game in development is a very fragile thing. Often, they are running with ridiculously short development times, a tiny budget and lots of stressed co-workers, clients and managers. Someone coming along mid way through development and adding or changing features can, and will, cause time to slip more than you realise, and costs to go shooting up. It’s one thing for a client or manager to decide a change is the best thing for the game, as they can be made aware of the effect on the project and decide if they want to go for it or not, but when a team member takes it upon themselves to change things because they thought it would make the game better, lots of bad things can happen. I’m not saying keep your ideas to yourself, but remember there are timelines, budgets and clients to manage, and that ultimately you’re working for a business. Or your idea just might not be that good.

Tip: Don’t be too precious of your ideas, and don’t try to take over other people’s roles. Designers design, programmers program, artists create art and producers are master solitaire players.

There was also the fair share of crunch time there as some projects careered out of control and deadlines flew by. This is the one of the worst parts of the games industry, working through till the small hours then start early the next day just to try and get a project back on track. It causes a lot of bad feeling in the team, a lot of stress, disappointment and misery. I don’t think it can be overstated just how bad this concept of “crunch” time is, or that it is so accepted in the industry, even now after high profile cases such as the wives of EA employees. It’s one thing that we as an industry need to keep on top of, and that people who set the deadlines need to understand. Happy employees will always lead to better products, more creativity and a better working environment.
Unfortunately, things ended up getting pretty bad at the company, and the money ran out. They closed down at the start of 2009, and I was left wondering what my next move was. They had wanted to keep me on as a programmer in a new company that was being set up, but I’d decided to try setting up my own company. The company I’d worked for were involved in mid range games for consoles (PS2, Wii, etc.), and I could see the market had turned towards casual mobile gaming, and heard all the huge success stories, so I thought (as a lot of people naïvely did back then) that I could just throw out a couple of casual games onto iPhone and watch the money roll in. And so, in April 2009, GoGo-Robot was born, run from home with just me. The idea originally was to create casual games on indie platforms. The first game, Galactic Aquarium, was a fish tank management game, with plenty of programmer art and an annoying soundtrack. It was still quite a fun game, and I think the reviews, although very polarised, showed that. It was pretty much an even split between “WTF is this?! The fish don’t even animate?!?!” and “OMG this is the best game evar!!!!”. It was released initially on XBox Live Community Games (or Indie Games, whatever it’s called now, if it even exists anymore), and then a couple of months later on iOS. Unfortunately, sales weren’t as I’d hoped, most likely down to the lack of production quality and lack of exposure. At the time, I’d only really had experience in the programming of games, and an understanding of the art process, but not really much in the way of production or marketing. I did some updates to it to try and keep it fresh and visible, which helped a little, but I think that it would have taken so much more effort than I had time to get it anywhere near being successful. Luckily, it hadn’t been a massive drain on money, so it was good as a learning exercise.
The next release was Alien Attacks!, an accelerometer based casual game where you have to defend your alien UFO from humans who are trying to blow it up. Again, this had very low production value (more programmer art), and was an attempt to refine general development practices to get development time down and learn more about the iOS platform.

Tip: Know your limits and delegate to people who can do the job well. Also, programmers suck at art.

At the same time, I had started looking for work for hire, and was starting to get some good iOS projects to get stuck into. These did really well for paying the bills, and were always interesting projects. I had the luck of being contacted by a mobile development agency who have kept a constant stream of high profile contracts coming in, which has ensured that I’ve never struggled to find work, only time. One of the downsides of doing any kind of work for hire is the danger that you take on too much at once. I’ve learned the hard way, and seen others do the same. You get too eager to please your clients, or the work is too interesting to pass up, and you take it all on, inevitably leading to not spending enough time on projects, missing deadlines and delivering poor quality work. It’s crunch time all over again, except this time you’ve got no one to blame but yourself.

Tip: Don’t take too much work on at once

The idea behind GoGo-Robot was that it would be allowed to grow organically as the industry changed and technology developed. I’d be tasked with bringing in contract work or working with designers to develop game concepts for original IP, then a team would be contracted in for development on that project, much like the film industry. In theory, this is a very good way of running any kind of company that develops creative products, and the film industry has shown that it can work, but it’s a lot harder to actually accomplish than it sounds. For starters, you actually need people who can deliver what you’re expecting and promising your clients. A couple of times I’ve had to finish delivery of a project because I figured the people I’d hired couldn’t meet what was being asked of them, and wanting to get it done myself to make sure it got done. These unforeseen extra pieces of work detract from the time you should be spending growing the business, finding more work and developing original IP.

Tip: See previous two tips. Really.

So with the failings of my own, programmer arty games and the time taken to work on contract work, I decided the next move was to collaborate with a designer with whom I’d worked at my first job. He had (and still has) a whole bunch of ideas for games, and there was one in particular we wanted to try. A retro styled, gravity mangling, multiplayer buggy shooting game named Blast Buggies. I’d knocked up a really quick prototype earlier, and we’d been building it on and off for a while, and we knew it’d be a hit. Back then, there was still some hope of an indie scene on the Xbox 360, and we wanted to get it at least on there, if not signed by a publisher for a full Xbox Live Arcade release. We got it to a state where we could show some gameplay videos, and play a playable demo, and it looked really nice, then took it to some industry meet ups. One thing I quickly learned there, people don’t go to these things to be sold to (obvious I know, but something a lot of people, including myself, seem to miss). As a side note, it’s been my experience that people also don’t go there looking to find people to do contract work form them. Again, obvious, but if you’re expecting to go to an industry event and walk away with work or a publishing deal, you’re going to be very, very disappointed.

Tip: Industry events are for making contacts. Do not expect to sell to anyone or find work there, that only happens or rare occasions.

After being very, very disappointed, we decided to try entering it into Microsoft’s DreamBuildPlay 2010 competition for indie games and got… nowhere. Another disappointment, so we decided to finish the game and release it on Xbox Community Games. Unfortunately, actual paid work took precedence and the game (in an almost complete state) was put on indefinite hiatus. I think the problem for it was that, in order to develop the rapid prototype, we’d used a physics engine to get the buggies driving along and flying around. For one, it was total overkill for what we were trying to do. Secondly, we then had to network it for multiplayer, which is an absolute nightmare. We ended up with a game which mostly worked, but had all sorts of weird bugs due to the hacks we’d done for the physics system to get the buggy behaving how we’d like and to sync multiplayer. We’d also needed to do a lot of optimisation to get it running well on the Xbox. All in all, it was a bit of a mess, but a hell of a learning experience.

Tip: Don’t be put off by failure, learn from it

We’d also decided to give the Old Spice Challenge a go, only about a month before the deadline. The Old Spice Challenge was part of Microsoft’s DreamBuildPlay 2010 competition, sponsored by Old Spice, where developers needed to create a game based on certain assets provided by Old Spice. So, with one of us working from home, and the other working half way around the world in China, we sat through our own month long crunch time and created Newton Vs The Horde, a physics based zombie defence game. We entered that into the competition, then caught up on a month’s worth of sleep. After being shortlisted as a finalist, the games were put to a public vote, so due to our absolute lack of marketing skills, we figured we wouldn’t win, especially as we had no real way of reaching the American market. Nevertheless, we gave it our best shot: Facebook adverts, forum posts and getting everyone we knew to spread the word. And it worked! We won the competition, and we got a nice chunk of prize money for it.

Tip: Trying can actually pay off

We’d decided that we should set up a second company to deal with the original IP stuff, using the prize money from the competition, and that GoGo-Robot would just concentrate on contract work. And so in August 2010, we set up RadiationBurn, to create original IP games, and we moved in to an actual office, where we worked on our first title, Newton Vs The Horde. We’d decided that we’d do a conversion, while the game was still fresh, from Xbox 360 / C# to WiiWare & iOS in C++. How hard could it be? Well, it turns out it can be a long, gruelling task, especially when there’s always more contract work to be done. It took us from August 2010 to December 2011 to get the WiiWare and iOS versions out of the door. Having to convert, optimise and tidy the game took far longer than we’d anticipated, and by the time we had the WiiWare version out, Nintendo had already announced the WiiU, the final nail in WiiWare’s coffin. During that time, GoGo-Robot had taken on its first full time employee, and we were trying to juggle contract work and original IP. It was a difficult but exciting time, and there was a lot to learn, but looking back, I’m not sure there was much need to set up the second company. Our first success was done in spare time, from home, over the internet. I think we both thought that things would really take off at that point, but they didn’t.
The second company also confused the roles of people in the office quite a lot. Technically, all employees worked for GoGo-Robot, with RadiationBurn as one of GoGo-Robot’s clients, but it didn’t really feel that way in the office. The two companies felt as if they were one and the same, and GoGo-Robot’s clients’ work generally took precedence over RadiationBurn projects, in order to keep the wages paid and the office open. It’s amazing how quickly office and staff costs can build up. We’d started taking on work placement students from university to help us, but realistically we should have realised that this should have been more of a teaching exercise for them, and overestimated how much work they would get through.

Tip: You don’t need an office to create games

Our next project with RadiationBurn was BOOMBA!, which again took far too long to develop. BOOMBA! was supposed to be a rapidly developed game to release to try and claw back what we’d lost from the development of Newton Vs The Horde. I think the main problem with BOOMBA! was that we didn’t settle on a clear vision for the game at the outset. We’d started by developing it as a small, casual title, but then came up with the idea of making it an online, multiplayer, cross platform title. Once again, we aimed at a multiplayer physics game, but this time cross platform. And once again, we didn’t give it enough time, and spent the majority of our time juggling work for hire projects, and development dragged on and on. We’d also hired a couple more programmers and a couple of artists in this time, and moved to new offices in June 2012.
We released BOOMBA! on various platforms in the first half of 2013, and it was well received and rated highly, but unfortunately that just didn’t translate into sales. We’d once again failed at marketing, though I think we’d done better than our previous efforts. Press releases had gone out, reviews on websites had been written and people actually downloaded and played the game. I think we put too much hope in people playing online multiplayer at launch, and neglected an AI based fall-back for those first few days when there weren’t many players, so people lost faith in the online functionality due to lack of active games to join. We also failed to design in how we’d actually make any money from the game. Should we use micropayments? One single payment? We ended up going with a single payment to unlock the rest of the levels, and unlimited multiplayer games (yeah, we’d limited the number of multiplayer games that people could play a day if they hadn’t upgraded the game, just to further hurt our multiplayer mode). As it turns out, different platform users expect different payment methods in your game. While downloading the game for free but unlocking later levels with an in app purchase is fine on iOS, users on Windows Phone 8 found this to be too unacceptable. I really don’t think we could have known that different phone users have such different expectations when it comes to in app purchases, but we certainly learned that. Eventually we updated the iOS and Android versions to be ad supported, which I think we should have just done from the start given the amounts we were getting from in app purchases compared to the amounts we got from the advertising network.

Tip: Know how you will monetise from the start, and know your markets

Ultimately, we lost money again on BOOMBA!, but learned even more from it, and I made the decision to leave my post at RadiationBurn and shut down the office of GoGo-Robot. It wasn’t an easy decision to make, after having invested so much time and effort into both companies, and to have to let the staff go was not easy in any way, especially when I consider the staff there to be good friends. For a few of the staff, it was their first job in the games industry, and we all had a lot of good times I think. For me personally, I think I’d been trying to juggle too many things at once, and it had gotten to the point of just being permanently stressed, working too much, sleeping too little and neglecting my personal life. I’d been so focussed on trying to make the two companies work, I’d ended up at a point where I would try and fix whatever was the most immediately obvious problem and not be able to take a step back to take stock.

Tip: Take time out to analyse your situation and make a plan. Remember that walking away is always an option.

The present
So 4 months ago I left RadiationBurn, shut down the office for GoGo-Robot and decided to put running a company on hold. I’m currently back to doing freelance programming work (bills still need paying after all), and am evaluating where to take GoGo-Robot next. I’m actively trying to make sure I give myself time for personal projects and relaxation, which is especially hard when what you do for your job is also your hobby. It’s important to have that down time away from work, and as a freelancer working from home, it’s also important to make sure you get out of the house. I think the most important advice for people freelancing (other than make sure to try working for a company first), is to kick yourself out of your own house regularly. Get out and do something. Take up running or go to the gym, cinema or pub. Even at home, remember to have down time. I find it a bit silly that working in the games industry, I ended up never actually playing any games, and just worked all the time. I’m now allowing myself to stop work every so often and play some games or watch some TV. There’s still some stress there from current projects, but by making sure not to take on too much at once, I’m starting to learn to manage that.

Tip: Get out of the house, do something fun and make time for yourself.

I’m glad it doesn’t feel like I’m back where I was 5 years ago, freelancing from home. I’ve learned a lot of things and met some wonderful people, and although there’s a lot of sadness involved with moving away from a company and the friends you’ve made there, I think it was the right decision. It’s good to be able to keep in touch with the people I’ve worked with over the past 5 years, and see them grow in their own endeavours.
The future
So what does the future hold for GoGo-Robot? Well, I’m exploring options at the moment. One of the many things I’ve learned is that a company should have a clear direction and focus. Trying to be a jack of all trades just gets far too unmanageable, so I’m currently looking for what direction I want to take it, and how it should regrow (if that is the right thing to do). There are so many possibilities that are on the horizon now that we have such powerful computing devices in the palm of our hands and built in to so many things, I think it’s fascinating to consider how we can further integrate all of this power to create so much better entertainment, work and life experiences. You know, either that or robots!