Pearls of wisdom

One advantage of working so long in the games industry is that I’ve met and worked with a bunch of talented people who have gone on to do amazing things. On Tuesday I was lucky enough to get Matthew Wiggins (ex-CEO of Wonderland Software, makers of Godfinger) to meet me for lunch and talk through his experiences of founding a start-up and making his own games. Here’s his advice as best I can remember it, mutated and possibly badly paraphrased (damn me for not taking a tape recorder). 

“Never start a company with anyone you wouldn’t want to go to war with.” – For now this doesn’t hugely apply to me, as I’m currently a one man band, but in the future there’s a good chance I’ll want and need help making the sort of games I want to make and asking myself this question about any potential  co-conspirator will save a lot of pain in the future. Are they someone who would have your back without question? They have to be as you are going to literally rely on them for your livelihood.

 “Know your competition” – Your game doesn’t exist in a vacuum. It exists in a (potentially over-saturated) marketplace where you will be competing for the consumers’ time. If you don’t know what else is out there, what they’re doing right, what they’re doing wrong, how your game is different from the herd and how you’ll persuade your customers to play and pay for your game and not someone else’s, then you’re taking a huge leap of faith. If someone is making a game better than yours for cheaper (or free) then why would they ever part with their cash for what you’re making. Not only will you learn about the marketplace ecology, but someone might have fixed a problem you’re having with some aspect of your game (maybe in a significantly different gaming space) that will save you time and effort. Unless you directly copy the art or the line-for-line code of a game it is horrendously difficult to break their copyright. Zynga have proved this over and over again, though I am not a lawyer, so it’s worth speaking to one if you’re suffering any confusion about potential legal issues.

“Publishers won’t be interested in funding a one man start-up” – I’ve been considering various options for financing myself and any potential games I make. I’ve thought a lot about my costs and outgoings on a monthly basis and figure I can carry on for around 2 years without any sort of financial input (though I’ll be continually re-assessing my situation and only continue long-term if things are on a generally upward vector…ending up penniless without releasing a game or two that I expect to do well is not an option). However, there are more costs to making games than simply keeping myself in tea and biscuits (and paying for my rent, car, insurance, tv license, internet, electricity and so on and painfully so forth). Where do I get art and how much will it cost me? Who will test my game, on which platforms and what will that cost me? Will I need a second programmer (or a third or fourth) to get my game design implemented and what will that cost me? Where do I get sound effects? Do I pay someone to make game music? Do I need to use middleware or SDKs or buy in libraries to save myself time? All of this could cost money or a percentage of the final game profits, so figuring out how to pay for it is a core consideration and knowing that getting a publisher involved is not a solution, might well affect the game design to ensure I can minimize those costs.

“Decide on the platform you’re passionate about and focus on that” – So far I’m aiming for my game to be as cross platform as possible. I’ll detail technical considerations in a separate post but the route I’ve taken so far is C++ and OpenGL. These technologies (with the appropriate glue code for each platform) will allow me to target almost any platform apart from Windows 7/8 phones and Microsoft Surfaces. I’m tempted by the Marmalade SDK as it should allow me to continue with this line of development with pretty much zero glue code, but that’s something I’m going to have to delve into in a more serious way before I can make that decision. Up to now, though, I’ve only implemented the glue code for iPhone. OpenGL ES 2.0 works for anything from 3GS and onwards, which opens up a large enough audience for myself, although testing to date is limited to my iPhone 4. Matthew’s advice was to pick a precise format and make that my focus. Multi-platform support considerations are all well and good, but trying to do everything from the off defocuses development and exchanges time for future potential. With a dev team of one I can’t afford to do that. I shouldn’t even initially be putting effort into supporting iPad, which essentially requires no changes to iPhone code, until the iPhone version is complete. I think that’s pretty wise. To not dilute effort until I first have something worth pushing onto the primary platform means I’ll stay focused and get to that goal sooner rather than later. I think I’ll need that morale boost of finishing something, further down the line when things are tough and I’ll be glad to not have to seriously consider the multi-platform knock-ons for each and every technical choice I make. However this will almost certainly make it harder to move to another platform when the time comes.

“The app store is an honest marketplace” – Essentially what Matthew meant by this was that he thought it was difficult to game the app store by buying reviews or artificially inflating your game rank. I pressed him on the best way to get my game noticed by the general public. As I keep saying, the app store is a very saturated marketplace. Getting your game noticed, however good it is, will be a struggle. He thought that the best people to court were journalists and early adopters who will get your game on the front pages of gaming portals and across to their friends by word of mouth (or tweet of twitter). Buying good reviews from a handful of large outlets would be quickly swept aside by real opinions from other journalists and early adopters, whose reviews and social media output would be legion. I questioned him more about how best to do this and his opinion was that keeping a blog is good for journalists but not the general public (only a small handful of people would be really interested in reading a blog), his blog is generally linked to from twitter, where he follows many journalists and builds interest and respect by talking about games and gaming developments with those journalists, as they arise. It’s their links back to his twitter feed, blog and games, as well as their news articles about all three, that gets him onto those websites to be seen by the early adopters who tend to be more interested in gaming developments, but push that information out to the general public by word of mouth. This is definitely an ecology I’m going to need to interact with and understand more, as gaining media traction and gamer interest is the most significant known unknown I have.

“Have a website, but keep it simple and mobile friendly” – When you manage to get journalists interested enough to post about you, your company or your game, then it’s a shame to let that publicity go to waste by not having somewhere people can find out more about you and maybe even buy your product. Having a website is a great start, but many people make the mistake of making it monitor friendly, with 1600 by 1200 resolution for that high definition background wallpaper, when your customers are iPhone users who will be looking at it on a relatively tiny screen. Having a link that takes them directly to the app store on their device is also a must, presuming your game is ready. There’s limited point to having lots of publicity long before they can actually buy your game. The chances of them remembering to come back without a future reason to are limited, so don’t waste publicity by making announcements long before your game is out. You might want to build excitement, but this should be in terms of days or, at most, weeks before the launch.

“Videos should be short and sweet” – If you get a video on your website or otherwise out there for public dissemination, then don’t fail to get people to watch it through by ruining their viewing experience after you’ve persuaded them to click. You’re advertising to the 10 second attention span generation, so starting a video with a black screen and fading up the music before showing your company logo 10 seconds in, means they’ve already clicked onto the side panel showing skateboarder kids bouncing their faces off the pavement whilst failing at stunts. You want to be into the action straight away, with minimal build-up, engaging the viewer with a new game feature every few seconds to get as much salivation-worthy material in front of their eyes before presenting a button to take them to the app store to buy your game. Sure, get your logo in there somewhere. Put it in the corner out of the way or display it at the end of the video. You can even make it clickable, but don’t let it get in the way of making a sale, because almost no-one will care about you or your company. They will only care about your game.

“Get analytics for your game and release into a smaller territory to get feedback before general release” – Knowing how your game is played, where players got to before giving up, what interactions led from a free game being converted into a paid for game or what caused in-app purchases to be made is hugely important to your business model. Being able to release into a relatively small territory to test the waters and make general improvements to increase customer spend could be the difference between failure and success for your game and your ability to continue with indie development. Matthew mentioned Flurry Analytics as a good option for this purpose and it’s something I’ll be checking out, along with a few of its competitors, as my game progresses into full production (as opposed to the prototyping stage I’m at now).

So those are the nuggets of wisdom I managed to remember. I’m sure there were more and will add anything that springs to mind. If you have any similar suggestions or links to other people’s top-10-things-to-remember-when-making-an-indie-game, please post them below.


Technology choices

Decisions are hard. They’re hard because you can almost never foresee how the result will pan out until you’ve fully implemented them and by then the effort is spent and you’re going to have to start from scratch with hours or days wasted from your schedule.

I’ve restricted my game idea to something I can technologically implement myself, has minimal art requirements (at least with the first release) and I can complete in a matter of months (how many months depends on how smoothly things will go, which they no doubt won’t, but I’m guesstimating around 6). With that in mind, even if the design changes I have a rough idea of the kind of things I’ll need to implement or otherwise acquire.

The list currently stands at:

  • Graphics engine
  • Sound engine
  • GUI
  • Font renderer
  • Level editor
  • XML level importer
  • Touch interface
  • Camera movement and zoom
  • Multi-platform considerations

The big decision here is how many of these do I write myself and how many do I try to find some middleware or libraries for? I’ve not yet decided how much to say about the game, but what I’m trying to do graphically, whilst not particularly complex, requires low level interactions with OpenGL and based on previous implementations of the core mechanic, even writing in Objective-C turned out to have too much overhead (the overhead was the message passing of method parameters, with lots of small functions called many times per frame, switching to C++ doubled the framerate in places. See here for someone else’s comparison). So I’m stuck with C++ and OpenGL, which doesn’t mean I can’t call through to Objective-C (or many other languages if required) but it makes sense to keep going in this vein unless there’s good reason not to, especially as OpenGL and C++ are fairly platform independent (they’ll work for pretty much everything apart from Windows Phones and Microsoft Surface and those might catch up at some point).

Having the graphics engine in OpenGL means any library for the GUI (which would hopefully encapsulate font rendering and multi-language support) would have to play nicely with OpenGL, would most likely be in OpenGL and would need to not cause problems when I’m displaying their GUI in the foreground whilst still running my game in the background (or not cause enough problems if I had to switch between the two). If it was simply displaying some clickable buttons I’d be very tempted to write this myself and reinvent the wheel one more time (which can make sense if you want to really ensure that the wheel fits nicely to your car), but it would certainly be preferable if I could find a free-to-use library that took care of the GUI and would happily display any UTF-16 encoded languages I threw at it. The decision then becomes do I try to find some SDK that can do most of the above list for me or use libraries by part and hope they all play well together, as well as with my current codebase.

In terms of SDKs, the only one I’ve found so far that’s lets you have low-level control of OpenGL and allows you to write in C++ is Marmalade SDK. My main problem here is finding out if their GUI system will play happily with my use of OpenGL i.e. with both displaying during the same frame. No-one has answered this question anywhere in the Marmalade forums (which seem to worryingly have a lot of unanswered questions), but there is a 30-day trial version I can use to answer it myself. The other advantage of Marmalade is that it offers cross-platform support, so will, at least theoretically, allow me to target Android alongside iOS.

There are a few more options for a free-to-use (LGPL or freer) GUI library. Clutter is the main one that springs to mind, but there are others such as kivy and apparently cegui can work on iOS, though it isn’t officially a supported platform. It seems that, after many Google searches, there is sadly no plug and play, well tested, cross-platform, free, OpenGL C++ GUI. It’s almost as if there’s no-one out there willing to do all my work for me.

So tomorrow I’ll start by downloading a free version of Marmalade and see how easy it is to get my game up and running on it, then see what their GUI will do when it’s running over the top displaying Japanese. If that fails I’ll try Clutter. Clutter is free (as opposed to Marmalade’s $149 per year) but if it gives me Android for that price, it’s a price worth paying.


Of course the journey of a thousand miles begins with a flat tyre and a broken fan belt. I made the crucial mistake of letting my iPhone update to iOS 6.0 late last week. This led to my needing a new (1.6GB) update to Xcode 4.5, which proceeded to require me to revise the UITouch code as they changed the library interface. Nothing earth shattering and hardly an unknown unknown, but it’s a significant time drain how often something like this happens and makes software development about much more than software architecture and code implementation (this is the second time updating my iPhone iOS has required other code updates…last time I had to update my Mac OS as well as Xcode, which took several hours on a much slower connection and caused my perforce server settings to get blitzed, adding some extra superfuntimes).

Just for fun* I’m going to document other random delays caused by technology in the comments section below. I expect this list to be quite long by the time I ship.

*for some definition of “fun” YMMV

Day 1

It’s been two weeks since I was still applying for finance jobs in London, ten days since I handed in my notice, one long weekend since my last day at work and today is day one of being an indie game developer.

I’ve been a games programmer for more than 15 years, the last 10 of which I worked at Lionhead Studios on AI, gameplay and GUI. In some ways this puts me in good stead for writing a complete game by myself, but working in a succession of companies where so much is taken care of for you and so much knowledge is available within walking distance, I’ve no doubt that the future will be full of surprises and interesting times.

As Donald Rumsfeld put it, “…there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns — the ones we don’t know we don’t know.”

It is these that are going to bite me in the ass.

So I have a plan. I have a game I dearly want to make, a list of features and tools I know I’m going to have to write, a rough idea of the amount of art I’m going to have to find someone to create and a few ideas of the social media maelstrom I’m going to have to engage in if I want anyone to have heard of my game before I drop it into the maw of the over-saturated app market and hope it doesn’t disappear into immediate obscurity.

All the while reading the experiences of others and hoping their mistakes and their hard earned knowledge turns a few of those unknown unknowns into something that won’t blindside me at the 11th hour.

I’m keeping this blog to keep track of my decisions, to make very public mistakes and to learn as much as possible with it costing me as little as possible in wasted time and effort. The best way to ensure I really understand something is to turn it into concrete text and the best way to make sure that understanding doesn’t contain untenable levels of idiocy is to get as many people as possible to point out when it does.

I’m going to keep this blog updated with investigations into code libraries, middleware and SDKs. With game design decisions and anecdotes of when things go right and wrong. Hopefully it will turn into a journal documenting the whole game development process in a useful way I can return to in future to understand all those decisions I made along the way and toast the ones I didn’t end up regretting.

Which is to say, I am really, really, really looking forward to this.