Pearls of Wisdom the Third

After talking to Mark I headed to the Drummond to meet up with Kostas Zarifis (alongside his visiting brother Kyriakos) and talk about his experiences in founding Kinaesthetic Games. For the last 18 months Kostas has been trying to raise the money to make Kung Fu Superstar. A journey which culminated in a recent Kickstarter campaign that sadly failed to hit its target. From my point of view, learning from others’ mistakes is just as important as learning from their successes.

During our catch-up the conversation flow was a lot less directed than it had been for Matthew and Mark. I had a list of questions from my first meeting, but hadn’t really asked any of them as we’d discussed a lot of specific instances from Kostas’ attempt to get funding, which were more anecdotes than advice and probably contained a lot of information it would be inadvisable to share. The one piece of advice I’d written down was the following:

“You will not be prepared for the hate” – Kostas was simply trying to make a game he was passionate about, that he thought would be an amazing experience and sell well, but he wasn’t prepared for how personally he would take negative comments about a game that engulfed all his waking hours for 18 months of his life. I’ve been mentally preparing myself to deal with the level of hate that John Gabriel’s Greater Internet Fuckwad Theory so succinctly illustrates, but I’m sure when the day comes that someone needlessly and unfairly pours hate on a game I’m fighting so passionately to make, then I won’t be as calm and unaffected as I’m currently hoping.  I can still try to prepare for that day though.

After coming home and starting to write up my notes I decided to send Kostas the questions I’d bugged everyone else with and he kindly wrote the following reply (somewhat cut up and re-hashed by myself).


Did you start a blog and did you feel it was worthwhile for gaining interest in your project?

“For me personally, blogging would take too long and detract too much from the core thing that I set out to do (i.e. make a game, not write about the experience of making a game). During the particularly hard days I was working literally around 16-18 hrs a day (no exaggeration) so fitting blogging in such a schedule would be pretty hard. Of course the practical benefits of blogging (like building some community around you and your work) are not lost on me. However I prefer to try and draw people in with tangible examples of my work rather than just writing about what I do on a daily/weekly basis. The internet these days is a jungle of information so in my case I didn’t feel like simply piling my voice on would bring any value to it or me. I have actually been keeping a journal, which I may look to publish in some shape or form sometime in the future, but as that is more of a private thing I feel no obligation to update it on a regular basis so it doesn’t slow down my more immediate plans.

That said, if you can do it in a way that doesn’t slow you down (when you’re running on your own dime every hour counts) and so that there’s tangible examples of work in there that make you feel like people will genuinely care (and by people I don’t mean your Facebook mates) then by all means go for it.

In fact that’s another piece of advice I left out, which is listen to everyone and listen to no one. Meaning, make sure you get advice from people but it is you who has to make the final decision on what to follow blindly, what to adapt to your needs and what to ignore completely. (Bruce Lee’s approach to martial arts – just to get a martial arts reference in there too ;))”

Did you set up your own website and/or forums and did you feel it was worthwhile for gaining interest in your project?

“Again, similar to the above: I only did it or in time for when we launched the trailer. Meaning I had no intention of doing it before we had anything to show for what we were working on. What was I going to say before? Hi, I left Lionhead and I am going to make a game? Big deal. Also we didn’t do forums, but we did a FB page which currently has about 22K likes. Everyone’s on FB these days and it gives you some really powerful market research/advertising tools so I think it makes more sense to build your community there (at least when you don’t have a dedicated community management person – or when that person is you). Aside: The company website I did set up pretty early but it was just a “shadow” page for a very long time and I only did that because I had to provide a webpage for the company for various things I had to register for (developer programmes/benefits, legal/HMRC things etc.)”

What middleware / SDKs did you use and what problems did they solve for you?

“Again bit of a special case in my case so not sure how much there is to learn, but as you might remember, what I did was I created the very first prototypes using very simple stuff that came with the XDK then when LH adopted Unreal I tried porting my demos to it and found it very easy. It also made my demos look amazing so it was a straightforward choice really. I also received tons of support from them so that made the decision to go with them even easier. If you have even the slightest possibility of brewing a success in your house then Epic like to keep you close, which is of course smart of them. That said, so do Unity from what I hear. In terms of transferrable lessons, like I said yesterday I personally have a bit of a mantra which is if you’re in the business of developing games you should do just that, i.e. develop games, not tech. It’s my personal subjective opinion and I can go into huge lengths why I believe this but it’s beside the point for now. Saying that though, if your game *is* your tech and if you feel you can build that tech at an adequate speed and level of quality then fair enough, feel free to break that rule.”

Did you use advertising and do you think the cost/benefit was worth it?

“When we launched the trailer the Facebook group got to about 13k Likes within a couple of weeks (goes to show, the more you have to show and the higher quality it is, the less you’ll need other means to draw people to it). As it happens the rate of likes started dropping soon after though up until it came to a halt. We then started running some ads which in the space of the next 4-5 months doubled the likes on the page. I spent about £500 on that all in all (ran a campaign for about £5-8 a day which I paused and resumed depending on the promotion needs of the period we were going through – for instance we ramped it up pre-Kickstarter). The whole point was to have a launching pad for the virality to trigger from, once the Kickstarter was live. To answer the second part of your question (was it worth it?). In my case: No, I don’t feel it was. The conversion ratio of Facebook likes to Kickstarter pledgers was abysmal (if you hunt through the campaign updates you’ll find one where I go into a lot of detail about this which is quite interesting). Again though: should you try to divulge any transferable conclusions from this? I am not sure you should. There are so many project specific reasons as to why the conversion ratio was so low that trying to come up with a canonical rule of thumb from this would be wishful. Overall I think it’s great that we managed to raise such a relatively large community and I think even though I didn’t see the kind of value I was hoping for from it on this occasion it doesn’t mean that I won’t see it at a later date (if I take the right steps to leverage it of course).

I think I am over-complicating matters though…in short, is advertising worth it? Yeah I think you can’t avoid it. The way to do it though would be to just use it to make people *aware* of your product and then *instantly* give them a chance to try it and hope it’s good enough so that you can hook them in immediately. Don’t do it prematurely, don’t do it to gain customers if you don’t have an awesome product that people can experience pretty much immediately after seeing your ad/promotion.

Did you try to get a publisher to fund your game and what were the costs/benefits? How did you handle intellectual property rights?

“I don’t think it’s applicable to small iOS type projects (thankfully!). As to IP like everyone says I too am of the school of “hold on to your IP like it’s your baby” but then again it’s all relative isn’t it (what good is an IP if you can’t do something with it?). So applying one’s critical thinking here makes sense.”

How did you get content made for your game? Did you use students or friends for free / profit shared work or did you have to pay?

“Yeah this has been a bit crazy in my case and potentially one of the most (unexpectedly) successful aspects of the project. It all started with people within LH helping out on turning my simplistic prototypes into awesome looking demos for the creative day. Then a lot of these guys kept lending me a hand here and there after I left. Once we decided to do the trailer though and set down the requirements for that I soon realised that we need even more hands on deck. I decided to head hunt hobbyists and/or professionals where possible from online communities like the UDK forums, CGHUB, deviantart etc. Once I spotted people who fit my needs I would reach out to them and pitch to them the plan. Work on the project, use your work on your portfolio when the time came to make it public and also get paid according to the work you put in if/when the project made any money. The demos and the LH background helped a lot and in fact I had many more yes’s than no’s (I actually had to “let some people go”). At one point I had 30 people working on the project this way. It was m-e-n-t-a-l. But it worked. Anything you’ve ever seen of the project was done this way.”

What do you think are the general pitfalls of forming a start-up?

“You tend to romanticise what it’s like before you actually start doing it. The money, the fame, the creative control! Sure, 0.01% of those who set off on this journey will probably experience some of that. However 100% of them also experience this:

– It’ll strain you to a degree that you can’t even begin to imagine
– It’ll strain your personal relationships
– There will be times when you’ll question yourself and be tempted to feel regret (don’t!)

It’s normal and you need to be prepared for it. Keep a level head and always do that internal dialogue where you rationalise your decisions to yourself (you’re here because you wanted to be here and guess what: at the end of the day you were right to want that – persevere through the pain and win or lose you’ll come out a winner).

Other than that I really can’t think of any other major pitfalls. Keep a calm and level head, stay confident, and anything else that crops up you’ll be able to do deal with easily.”

What were major causes for delays? Did the project take a lot longer than you thought?

“When I started, various sources told me expect about 6 months to sign a publishing deal. 6 months in I was at the point where I was redesigning my game because the first pitch was not right for the market and climate of the time (Kinect was dying). 6 months later I was pitching again with the redesigned version and also testing the waters (with the trailer) to see how much traction we could gain with the community. Another 6 months in and still nothing and this time around we’re putting everything we’ve got together and pitching the game directly to gamers on Kickstarter. So yeah, it took me a year longer than what I originally expected. To fail 🙂 So in the words of the lady announcing train departures… “Expect delays” 🙂 This is exactly why it is super important that you don’t add delays in your side of things, especially since most of these delays are actually out of your control (don’t get me started on how long it takes to hear back from publishers once you start the pitching dance with them). So anything that’s in your control make sure you act on it urgently and efficiently because even when you do, you *will* be slowed down by others. Again, potentially less so for an iOS/Android game, but still.”


Reading through Kostas’ words I agree with him that only so much can be directly applied from a full blown console title to an app-store game with a much more limited scope. However, there were definitely nuggets in there that will apply to me throughout the project, especially as the romantic notion of game development turns to the strain of the reality.of making games. Not that I haven’t done a lot of this before in the safe environment of a larger company, but only having myself to rely on is going to be tough.

Back in The Drummond, Adam and Glen turned up just before Kyriakos had to leave for some clandestine meeting, taking Kostas with him. Tune-in soon for more questions, answers, experiences and advice…


Pearls of wisdom II

After listening, scribing and finally implementing some of Matthew Wiggins’ various nuggets of wisdom, I decided to throw the net wider and talk to a few other ex-Lionheaders who have made the move to indie development. It’s perhaps worth noting that I was briefly a slum-landlord to two of these fine fellows before their successful launches into indie games, so I’m hoping that something about living in the same abode in Aldershot will be the nudge I need for certain success. I can almost taste the future millions.

First up is the other founder of Wonderland Software, Mr Mark Rose. I’ll not repeat the suggestions he made that reiterate Matthews’ views, as he had plenty to say otherwise when we met up at Guildford Starbucks.

“A start-up is not a small version of a big business, it’s a search method” – with a start-up I should be trying to find or create a niche that I can create a business in. I’m not an established company with a business plan set in stone. I’m a small, agile, proto-company that shouldn’t be wasting its time trying to fight for market share from a large company doing the same exact thing. If I fail to find a niche to exploit in the area I started looking in, I should search elsewhere or close without wasting too much time, effort and money. This rings true with the sort of game I’m trying to make initially, to some extent at least. I’ve been told of a few other games that fall into the same niche, which on the one hand makes for competition, but on the other hand shows me there’s an ecology and an interest in that niche.  However if I can’t find the unique selling point, I should be moving on. This can just be doing something better than others, but I better be doing it a lot better, as otherwise I’ll be ignored as just another clone of X.

“Utilise what already exists” – I shouldn’t be reinventing the wheel, especially not when the wheels out there will do the job I need them to do. I certainly want to use other people’s libraries or code where possible and only build what’s unique to my game. However if something is reasonably simple to build and I’ll need it to do exactly what I want, then writing from scratch could well be faster in the medium term. I’m going to have to find myself a level editor that will allow me to create levels with basic objects, in 2D, with position and orientation, which can have meta-data attached. Nothing complex required and if I can’t find something suitable in short order then writing something myself that does exactly what I want makes a lot of sense.

“Keep interfaces simple” – I think I’m going to have to be brutally honest with myself when it comes to user interfaces. If my mum can’t use it from the get go, without having to be told how to do some interaction, where the first attempt she takes to do what she wants isn’t the method I’ve implemented, then I’m going to have to re-write the user interface until she can. That’s one of the things I find Apple get so right. My iPhone almost always acts in the way I expect. If there’s something I want to do, then it normally does it the way I expect the first time I try. I should always aim for that with my own GUI.

“Don’t over plan” – paying the price of being multi-platform now, just to be future proof, costs me planning and implementation time now for potential time savings later. This is rarely a good trade-off. I’ll be keeping things flexible now, but only in the most cursory ways necessary to not completely trip myself up later. This balance is going to be hard to keep.

“Keep the game design simple” – Mark was definitely of the mind that keeping the game design as simple as possible made the most sense and that however simple you have it, you can almost always take some level of complexity away to improve the game. Keeping it simple also means that later you can still add to it a layer at a time without much difficulty, but removing a feature that’s entwined with the whole game design can be very difficult (and a huge, risky unknown) once the game is in production. The game should also be something you can play straight away without having to work through tutorials. I want a game that makes sense the second you look at it. Not a mish-mash of nonsensical buttons that you gradually learn how not to fear. I have no problem with games that slowly increase in complexity as you play through levels, introducing it (and the appropriate interfaces) as you progress, but starting there will only scare the players.

“Don’t overanalyse the design, go with your gut feeling” – this is definitely a piece of advice I could use. I keep sitting and imagining the design and interactions, wasting time trying to perfect it in my head before I code it. If I implement the simplest feature first and play that, then I think I’ll have much more success as the next feature to implement will be much more obvious. So long as my gut is telling me that the first feature seems like a good one.

“Give the player some reason to shout about your game” – Get them to want to post their new high score on Facebook, either for its own sake or for a few coins of in-game currency. Whilst I generally ignore all the Facebook games that shout for attention, many others won’t and free advertising is an important way to bootstrap your game sales.

That was most of Mark’s advice, as I can best remember it and extended from my scribbled notes. I suppose I could record these conversations but I wouldn’t want to write anything I or the advice giver couldn’t later plausibly deny. Just in case, like.

Next I moved to the Drummond to meet up with Kostas Zarifis and hear of his experiences trying to get Kung Fu Superstar funded…

Little by little

For the last couple of weeks Christmas has mostly taken over my life, where a week in Devon with my family, playing board games, drinking and repeatedly attempting to run up waterlogged hills has reduced the amount of time I’ve spent programming. Still I took my Mac Mini South-Westward, plugged it into the monitor in my Dad’s office and took a few hours each day to at least stare at some code, if not make effective, focused advances.

The main emphasis of the last week and a half has been to get an XML level loader up and running. Choosing an xml library was fairly easy. The main choices were between RapidXML, TinyXML and pugixml.

Most critiques suggested that RapidXML was the least feature rich and had the least useable interface, whilst it was also considered the fastest. Between TinyXML and pugixml, the latter was considered smaller whilst running and faster at parsing files.

Pugixml has a comparison on their website for a variety of parsers and, whilst they might be somewhat biased, they provided all the files for others to test with themselves, so I find it cautiously reliable. Based on the above I ended up choosing pugixml, which has done everything I need and seems simple to use so far.

Once the XML side of the loader was done, I then started with the level creation. That forced me to take my prototype code, which essentially just about held together the bits of tech I’d written already, and start forming it into a proper game loop, with more sensible organisation of the code and the various aspects of the game. When you’re knocking a prototype together you generally don’t think too much about where feature divisions should be, as you just want to see things work (or not) to decide whether it’s worth continuing in the direction you’re prototyping (or not). Going from having various bits of OpenGL code sitting in the physics engine (there were reasons, honest), to having a well-considered interface between the two, easily eats up days, as you don’t want to have to do this sort of thing more than three or four times before the end of the project. By the time that was done I had to pack up and return to Merry Olde Wormley, wherein I got to meet up with some ex-Lionhead friends, each of whom have had a different experience in trying / succeeding in forming their own start-ups over the last couple of years. Experiences that I shall start typing up now…

Advice is a two sided…something…

There are two aspects to advice, first someone has to give it to you and then you actually have to take it. As Matthew Wiggins suggested when I spoke to him last week, “Decide on the platform you’re passionate about and focus on that”. I then rattled on about technology choices, finding a GUI that would be cross-platform and possibly taking on a third party SDK.

So I spent a few days trawling for a free, OpenGL, cross-platform GUI library: Reading into Clutter before I found out that the only iOS implementation was no longer being developed and had never been part of the main release. Looking at cegui before discovering the same. Checking out QT before finding out that the iOS version has been under development since August but has no release date. Downloading LibRocket, then ccmake, then make, then trying to build the libraries both using ccmake and Xcode and failing despite following instructions to the letter (I think it might have been conflicting versions of the freetype library on my Mac causing link errors). Finally I downloaded Marmalade and started the long task of rebuilding my project in that, whilst worrying that I would lose being able to directly debug on my iPhone when using their SDK and other suggested problems.

 And then I suddenly started wondering why on earth I was focusing on being multi-platform when I’d listened to and roundly agreed with Matt’s comment above, “Decide on the platform you’re passionate about and focus on that”. So I loaded up Xcode, googled how to add a button programmatically (to check it would play nicely with my OpenGL code) and within 10 minutes had a pressable button in my game that looked just fine.

I’ll go to the trouble of adding a thin abstraction layer between my game and the objective-C calls that use the Apple UIKit, because the generalising programmer in me can’t be ignored *all* the time, but I think I’ll be making a New Year’s resolution early: To actually take the good advice I’m given.

It seems it’s not enough to simply listen to advice, agree with it and write it up because you think it will be useful to others. I actually have to take it myself. Who would have thought?

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.