A quick catch up

A little over 13 months ago I ended my last post with the following words:

For sanity and experience I’m taking a brief detour to go through the process of getting an app onto the app store. The features I’ve spent the last few months creating lend themselves nicely to building what could only be described as a hugely over-engineered sand timer.”

“I also intend to do it by the end of the month, which is very possible if I stop procrastinating, worrying and second guessing myself.

Two days ago I finally pushed The Hourglass Emporium into the review process on iTunes. At current rates I should be accepted or rejected by the end of the week, so I thought it about time to look back at a the process of making an app that went, what can only be described as, somewhat beyond the end of the month.

Thanks to source control, I’ve got a very accurate picture of the timeline of the project, at least technically. On the 8th of March 2013 I checked in my first hourglass level. I found an appropriate image on google (this one to be precise), then carved out the glass area to put sand in.  On the 11th I had added a flow rate controller, to mediate the sand and count down whatever time I chose. By the 13th I had added a system for pre-calculating where the sand would fall and colouring the initial sand correctly to build a picture as the sand flowed into the bottom bulb. Nothing technically difficult, just running the simulation twice and ensuring I used the same inputs and pseudo-random numbers both times. On the 18th I added taking photos, so you could use an image of your choosing as the sand texture and either watch it fall apart or reconstruct from a mess of grains into your chosen image. Then came reflection and refraction, using the front facing camera to place the user’s image dimly reflected and distorted onto the glass.

Sometime near the start of March I had received a text out of the blue from a guy called Matt who told me “Chris said you were looking for an artist”. After some initial confusion, I worked out that “Chris” was Chris Knott (at the time working at Lionhead, now at Rodeo Games), the beefiest and most Zangief animator you could ever hope to meet. Matt was Chris’ next door neighbour and offered to knock up some hourglass art for me. After a little back and forth he sent me this sketch of a darling little octopod, ever since referred to as The Kraken. After colouration and polish, the final art looks like this. With the winking (or blinking? we’ll never know) animation he makes for a very loveable character. It felt great to have actual art turn the app from coder demo to something you could imagine on other people’s phones. When I took prototypes of game ideas to the indie dev meet up in Guildford, I was surprised at how difficult it was, even for very experienced developers, to see past coder art and temporary textures and objectively view the gameplay. Seeing how high fidelity art transformed my prototype into something I felt could sit unashamed on the app store was a great feeling.

Around the time Matt was turning his sketch into final product, I was lucky enough that my friend Tamsin (of Wonderland and JiggeryPokery) put me in contact with an artist she’d mentored on an animation course, Silvia Bartoli. Silvia is a maker of many a fine critter and beastie and, while she was mostly interested in making games, she did me the great service of offering up her artistic abilities to create an hourglass for me.

An hourglass formed almost entirely of cats.

You can find a snapshot of that artistic finery here. Blinking animations followed again, bringing the hourglass to life, and it still looks pretty much unchanged from where it stood almost a year ago.

Another hourglass soon followed from yet another friend of Tam’s, Imi Hayati, who worked at Wonderland back in the day. In less than a week he went from a water soaked pencil sketch to this finished hourglass, replete with blinking animations and fading cat (blinking and cats forming an unexpected, yet continuing theme in the world of virtual hourglasses). All this happened by the start of June 2013, while I was bug fixing, adding features and optimising code. Certainly more than a month had slipped by since I started this endeavour, but I had no intention of releasing something sub-par, even if it was a pet project that had no realistic chance of being a break-out hit (I feel the market for quality, high fidelity hourglasses is somewhere between “tiny” and “non-existent”, but it might unexpectedly be as large as “some”). However, my eye was on the longer term goals of both writing systems I could re-use in future endeavours and making an app that, if it didn’t make me money, would at least be something I could use to get me a job, should the need arise.

In fact I was starting to feel the pinch financially. Whilst I was nowhere near the bottom of my savings barrel, going for an all-or-nothing strategy of blowing those savings to support myself, whilst making an app that might, at best, pay for a few hot dinners, didn’t seem like any kind of winning formula. It had gotten to the middle of June and I was on a family holiday, with my computer set up on the pool table in a cottage in Wales. Between bouts of bug fixing (and occasionally seeing my family), I was writing up design ideas for what I would do after the hourglass app was finished. I’d been going back and forth between a sand castle idea (too much art required), a sand art app (is there a market for it? what would it take to make it fun?) and an app revolving around the blowing up of things into tiny, tiny pieces (is it a game? is it a toy? what’s the monetization strategy). Any of which I would have enjoyed making but all of which had issues and none of which seemed like the perfect course of action.

As I circled myself in interminable uncertainty, I received two job offers in the space of 24 hours. One from a friend who wanted an app to be made for his business, the other from Lionhead asking if I wanted to come back and contract for 4 weeks on Fable Anniversary: a reworking of Fable 1 onto Xbox360. Be it serendipity or random chance (clue: it’s random chance) I took them both up on their offers, to give myself time (and funds) to figure out what I would do next.

Working 5 days a week slowed the final development of the app significantly. I’d chosen a name: The Hourglass Emporium. I’d also chosen and cut the features down to a manageable set. Taking pictures and rebuilding images were both out. The reality of user images against the cartoon backdrops jarred too much and whilst rebuilding the image while counting down from 10 seconds would take a few seconds to calculate (by running the simulation through to completion before starting the timer), the pre-calculation increased linearly with the time chosen, turning an interesting idea into an annoyance for the user. Reflections and refractions were also dropped, as they never looked right and were just non-core features eating CPU and GPU cycles.

I added in iAds and in-app purchases so I could give the app away for free and still hope to make a little money out of it. Drawing people in with a wall of cats then up-selling them Krakens, Wonderlands, Demons and Angel Bears (the former by my friend Clare Innes, the latter again by the octopod loving Matt Brown). Choosing between hourglasses meant adding a carousel feature (open sourced from here, but it’s never as simple as dragging and dropping), then a page in the GUI for each artist, giving them a bio and a link to their web pages, which is the least you can do for people you feel guilty for working so hard on something you deeply expect will give them back very nearly nothing. I added a variety of alarms, each stolen from free sound, options for changing the clock sizes and timing from a second, to a second short of a day. I installed credits and hints pages, a variety of methods for pausing and restarting the hourglasses and the ability for users to email me feedback, should the fancy take them (I can only imagine nothing good will come of this).

I also added five different sizes of grains of sand, because this would, in no way, be a complete pain in the ass. If you couple the limits of CPU power across the range of Apple devices, multiply it by the different screen sizes and their respective aspect ratios, then fuse that with five sizes of sand grain, which you want to be as plentiful as possible, but pass through the neck of the hourglass with enough alacrity to countdown whatever time the user chooses, then you might just find yourself sitting in front of xml files at some ungodly hour of the morning, minutely adjusting an endless stream of numbers for reasons you’ve either forgotten or regret or both.

But it’s over now and, thanks to writing a test harness at the 11th hour, I’ve had an iPad and iPhone faking touch inputs, level loads and random gravity for 24 hours apiece without crashing. I feel I’ve achieved making an hourglass timer of robustness, fidelity and finery, far beyond the realms of the necessary and will have plenty of code and systems that will make the next thing I work on a giant leap easier than it would otherwise be.

 

So then.

 

Onto the next thing.

…and suddenly two months fall by…

It’s incredible how quickly time can pass when you’re getting your head down to work. With a smattering of snow on the ground outside I can pretend it’s still winter, but with the advent of British Summer Time and some actual light in the evening, I’d have to engage unreasonable levels of cognitive dissonance to fool myself into thinking anything except “Time Has Passed” and “I Should Already Have Gotten More Shit Done”.

We’re approaching a quarter of a year since I was expulsed with much alacrity from the warm bosom of Lionhead and started working on my own project. A lot of it has felt like mucking about as I’ve jumped to whatever I’ve felt like working on, on any given day. Admittedly this has been driven by an overarching plan (with all good intent to lead to a game), which I’ve been hesitant to talk about because, well, there’s paranoia that someone else will steal my glorious ideas and beat me to market. This is, of course, hogwash. Whilst any reasonably competent programmer could jump in and replicate everything I’ve done, I think there’s very little chance anyone really would want to or be willing to put the time in. Besides this, even if they did do such a thing, they would either do it worse, but quite possibly do it well enough to create a market that I could step into, or they would do it better, in which case I’m only delaying the inevitable as they’d be quite capable of copying what I’ve done post-hoc and stealing whatever tiny niche I’ve carved myself out from under me. As for copyright in games, well the NimbleBit’s Tiny Tower vs Zynga’s Dream Heights debacle tells us pretty much everything we need to know. If they don’t steal your actual assets, then there is *very* little you can do about them stealing your game idea, however specific it is. As of right now there is most likely prior art for every idea out there. This protects innovation and is mostly worth the price of lack of protection for your game idea (unless you’re ripped off personally, then it’s a tragedy, but at least you’re only ripped off and not sued by countless zombie companies set up to buy copyrighted ideas like “interacting with an input device to make a thing happen”). So it’s probably best to ignore theoretical, potential, highly unlikely idea theft and focus on working hard and making the best game I can, which leads me onto what I’ve been up to and where I’m heading.

For the last few months I’ve been playing around with a prototype, which could best be described as “moving a bunch of sand around a screen”. You can do this via the touch interface, flicking the sand about, either against gravity or as if pushing spilt salt across a table. The grains have nice momentum, interact pleasantly and can be used in reasonable abundance. They can also co-exist in levels with the few mechanical contraptions that have most easily translated from ideas into code: conveyor belts, suckers, blowers, lifts, sliders etc. I’ve worked on a variety of prototypes getting rectangles, then triangles, then arbitrary shaped objects first statically displacing the streams of sand as they pour around the screen, then pushing the sand around under player or automated movement. At every stage optimising and re-optimising the new mechanics until they played as smoothly as I needed them to (nothing ever works as fast as you *want* it to…if I can have x thousand grains of sand at 60fps, then I *want* double that, at least…almost certainly more).

All of the above was for the goal of coming up with an idea that would be novel (at least ostensibly through leveraging the sand mechanic), in a game I could code by myself before dragging an artist in at a late stage to turn my coder-art horror into an aesthetic wonder. I settled on a sand version of Feed Me Oil (specifically I came up with the wholly unimaginative idea of moving sand around a screen from some start point to some end point, via player controlled mechanics and had friends point me towards games that did similar with non-sand-based commodities) and knocked up a few tutorial levels and one fully functional level with the features I had already built. I then took everything I’d done (levels, prototypes et al.) along to the monthly Guildford Indie Game Dev meet-up (mostly ex-Lionheaders to be fair, sorry other Guildford Indie folk, you are, of course, welcome) to get people to have a go and see what they liked and what they didn’t.

It turned out that mostly they liked drawing penises. In fact we came up with the metric Time-To-Penis, as the only difference between people playing with the sandpit-esque prototype levels was the amount of time it took them to draw a cock.

It wasn’t that anyone said anything against my game prototypes, but mucking about with the sand in the sandpit was certainly a moreish pursuit that everyone happily got along with. All this left me a little uncertain with how to proceed. Did I want to make a competent game that is fun but lacks that magic touch? Might decent level design take a bunch of mechanics and turn a competent game into a good one? Might art input take a good game, add visual flair and personality and make something great? Whilst considering all of this, should I instead be leveraging everyone’s desire to use sand to draw willies?

I have to confess the last three weeks have involved a lot of self-doubt about what I’ve been doing and what to do next. I thought I’d be further along by now or at least know definitively what I was heading for. In the midst of this uncertainty I’m left with this constant desire to get something out there, to get something concrete finished. This leads onto what I’m actually doing now. For sanity and experience I’m taking a brief detour to go through the process of getting an app onto the app store. The features I’ve spent the last few months creating lend themselves nicely to building what could only be described as a hugely over-engineered sand timer. You could make it any shape, with rather more sand than is in any way necessary. You could also add aspects of all the mechanics I’ve made so far, with conveyors and blowers and gravity not necessarily a constant fixture.

I’ve no delusions that such a thing is what the app store has been crying out for, but I can certainly make something that will stand out against the current sand timers you can find therein (oh, what a huge download niche that must be). At the very least this will push me to make more art contacts, finish a project to a fully polished level and get something through the certification process with analytics and everything else necessary built in. I also intend to do it by the end of the month, which is very possible if I stop procrastinating, worrying and second guessing myself.

Now all I need to find are some artists who can create beautifully designed hourglasses, persuade them they really want to and find out just what they might want in return.

Bitten by the floating point bug

My game lives in a world of integers. In a modern era of powerful floating point geometry, for reasons of optimisation and simplicity, the main mechanic requires me to use only the wholest of numbers. However, mid-way through development, I decided it might be useful to use box2D in the future. I have my own very specific physics engine within the integer maths framework of my game, but box2D offer a lot of very fast solutions to a lot of mechanics my own physics can’t handle and potentially dumping parts of my world into it and pulling out the solutions as and when it was apt, seemed like a reasonable thing to do (a lot of games use box2D for their physics, including some rather famous ones, I love this anecdote from GDC). Unfortunately, according to the documentation, box2D works best at scales from 10cm to 10m, so my base scale of 1 would not sit well. Taking this into consideration I decided to introduce a world scale and have my entities give their positions and sizes in this scale, then move it back and forth to integer maths where necessary (and in many places hold onto both scale systems for speed, as a test with only moving into ints at the last minute, but every frame, caused a noticeable slow-down from all those casts).

Then I came across a bug where entities were appearing one pixel off from where I was telling them to appear. So I delved into the debugger and found a common issue with floats, but in a form I thought would be “safe”. To quickly recap, floats are stored internally using a mantissa and exponent, with the function being something like mantissa * 2 ^ exponent. If you check out this calculator you can see that the number 123 is actually stored as 1.921875 * 2^6. The problem this has is that the number 0.7 might be stored as 0.6999999992 and if you multiply that by 10.0 and cast it to an int naively you could end up with the integer value being 6 rather than 7 (as someone kindly pointed out, the value 7 is stored exactly as a float, but as soon as you start performing operations on it, then the certainty disappears).

Unfortunately, with my world scale of 0.1, I was taking an object of size 4, turning it into a 0.4 and then later dividing by the same scale to get back to 4 for some internal machination. In this case, sadly, it turned it back into a 3. I scratched my head and ran some tests dividing and multiplying numbers by 0.1 in the function where the problem was occurring, but these numbers all came out fine. As both the numbers were stored as variables, I tried dividing out the 0.4 variable by a float literal 0.1 and it gave me 3, but doing the same with a 0.4 float literal and the variable 0.1 gave me 4. In the debugger it was displaying the variable values clearly as 0.4 and 0.1, not as some almost approximations that would have hinted at a problem. One solution to this was to use roundf, which would give me the number I was looking for, by rounding the float to the nearest whole number, but if this could happen in this one spot, then it could happen anywhere else I was doing the same sort of calculation and I didn’t want to have to spend the time introducing a rounding function everywhere in my code, nor the overhead of calling it in terms of CPU. In the end I decided that, as I wasn’t using box2D now and could kick that can down the road, the thing to change would be having a world scale and doing all the division necessary to get objects into box2D as and when I end up using it.

I guess this is just one more example of where future proofing development has come back to bite me in the ass. That I introduced this issue before being advised against future proofing my project makes me feel a little better, but every day seems like a constant struggle to get the game closer to being finished and wasting hours on bugs like this is not where I want to spend my time (though learning a little something new about coding always feels worthwhile).

The Maths, it burns!

Whilst I am someone who enjoys a bit of maths*, would love to know more and, when playing the theoretical game of “what degree would you do if you could do another one?” would put it up there with physics or generic-interesting-science-I-just-read-about-on-slashdot, I do find I tend to struggle when it comes to aspects of 3D code I feel I should find relatively simple.

For instance, yesterday I decided to implement touch controls. Getting a reasonable framework for touch inputs, to get them from objective C into C++  and fire in my game, took a little bit of thinking about to get right, but was fairly quick. Then I got to the point of taking those inputs and turning them into pan and zoom functionality. It’s not that making the camera pan and zoom in vaguely the right direction took much time, but to get whatever was under my finger to stay exactly under my finger as I panned was a little tricky and to get zooming to work, so that it zoomed precisely between my fingers and kept what was under each finger under that finger exactly, took me about three hours.

 The order of operations I found to work after trial and error (the worst sort of programming, as it often shows you don’t really know what you’re doing, as you’re doing it) was this:

  • Take the inputs in screen space (320 * 480 resolution, not the 640 * 960 graphical resolution of the device)
  • Translate by half the screen space towards the origin
  • Divide by the camera scale
  • Divide by the screen space
  • Multiply by the relationship between the frustum and the viewport (I have this encapsulated in a function called GetMysteriousMultiplier as it’s simply multiplying by 2 and this was my best guess as to why)
  • Subtract current camera translation divided by camera scale
  • Turn this into a translation matrix
  • Translate camera by the matrix
  • Scale camera
  • Translate camera back by the matrix

Now it’s not that I didn’t work out I had to do most of these right from the off, but not quite all of them and not quite in that order and getting it right took about as long as writing everything else did in the first place. Try as I might to picture the scene in my head and do the transformations one-by-one to work out what needed to be done, after enough steps it slipped away from me. Suffice it to say, my MysteriousMultiplier still feels a little bit like this: http://blog.stackoverflow.com/wp-content/uploads/then-a-miracle-occurs-cartoon.png and I sense it will come back to bite me in the ass at some future juncture (the fact that the first place a google image search found me this image was stackoverflow tells me I may not be the first person to have this sort of issue).

*I spent Christmas 2011, at my parents’ place, writing out every aspect of the Navier Stokes equation  for fluid dynamics on 20 odd sheets of paper to try and get my head around it. I came pretty close until it came to implementing it, then the kernel smoothing functions broke my dainty little mind.

Asset Management

It’s been eleven days since I last updated this blog and two weeks since I wrote about something I’d actually done to progress my game. Last time I wrote about my project I had just finished writing the level loader using pugixml and was refactoring my prototype code into something more generally useful and game-loop like. With each generalisation I added I was removing some presumption I had previously been making, where each of those presumptions had allowed me to not have to think about tricky edge cases or how some feature would work in a fully-fledged game.

In the prototype, if I added a physics object here and a physics object there I could vaguely test the physics system and see if it worked and gave the kind of feel I was looking for. If I placed the two physics objects on top of each other and they interacted badly, I could fix that by just keeping them apart for now and worrying about the issue later. When moving towards a more robust system that I can use to test out a multitude of game ideas, dealing with edge cases, rather than working around them by not using the system fully, stops being an option.

For instance, when I started writing an asset manager to deal with loading textures, I remembered Adam Clixby’s advice about testing in low-memory environments and factored that into the design. So any reference to assets in the game is managed by handles passed to the asset manager and would be agnostic of the state of that asset in memory. A game object might use a specific texture and on creating that object I tell the asset system to give me a handle to that texture, so that later I can bind the texture before rendering the object on screen. In this context that handle is an internal type of the asset system and on passing that handle to the asset manager to get hold of the texture name to bind it, the asset manager will then load, reload or pass an already loaded texture name back for rendering. Now, if I get a message from iOS that the device is getting low on memory, I can dump all the textures and know the system will smoothly reload them when my game becomes the currently interactive app again.

The asset system also deals with multiple objects using the same texture by simply returning the ready loaded texture handle when an identical texture is required from another source (identical by filename currently, hopefully this won’t cause too many issues later). This doesn’t cover all my needs though, as I have textures I adjust during gameplay and could be updating them every frame. There’s an overhead to constantly loading textures into graphics memory, but it’s a requirement for what I’m doing and isn’t prohibitively costly. What it does mean is that I might start off with a 128 * 128 texture, where the texels are being changed frame by frame, then later resize the texture and load new images onto empty parts of the resized texture. Keeping the game in lock-step with these changes, such as resizing arrays in the game for data that relates to the textures and copying old and new data into the correct portions, has taken a good proportion of the last two weeks to get running robustly and without the heart sinking feeling of suddenly seeing uv coordinates flying all over the place as some part of the system gets out of sync with the rest of it.

The result is that I now have a game that can load levels from xml, create game entities and run the gameplay, so that I can quickly prototype a variety of game ideas around a theme. It’s definitely taken me longer to get things up and running this way and I could have been prototyping game ideas in a more throw-away manner, but everything I’ve taken time to code in a considered way are systems that I will need for making the final game and any future proofing lies within the scope of the current project and on the initial platform. It feels like I’m half in full production and half in prototyping but if I’ve balanced it right then the bits in full production are the bits I know I’ll need in the final game and the bits I’m prototyping in a quick and dirty fashion are the bits that will be used to reduce risk and can be happily thrown away. The ideas that make it can then be moved into production territory, once the prototypes have led to definitive design decisions and it’s not a waste to spend time doing it right.

Pearls of Wisdom Goes Forth

With a brief cross-over and much handshaking and “Merry Christmas”-ing before Kostas and Kyriakos left, Adam Clixby and Glen Watts joined me in the Drummond to continue with my day of interrogation. Adam is a founder of Rodeo Games, makers of turn-based strategy games Hunters and Hunters 2 and currently developing Warhammer Quest. Glen is a long-time Lionhead veteran, recently freed and looking to start his own indie games company. I first worked with Glen in 2001 at Dogfish Studios and we both ended up at Lionhead a short time later (Glen via HotGen, myself with a more direct trajectory). Most of the following is Adam’s advice, arising as the three of us talked about making games.

“Testing on iOS is like xbox, testing on Android is like PC” – The Android platform has such a variety of mixes of hardware that testing for Android is much like testing for PC. There are an unfeasible number of permutations of hardware, which almost guarantee that your code will fall over somewhere, causing a very vocal backlash against your game and one star reviews that you have almost no control over. Even a given version of a specific phone can have subtly different pieces of hardware in different territories, one of which might crash and the other of which won’t. This level of testing hell is expensive to deal with and almost impossible for a small developer. iPhones, on the other hand, have much more homogeneous hardware, making testing a far more constrained problem.

“Use the NS data types on iOS” – this is a specific piece of coding advice, but Adam said that loading in from XML to the NS data types made everything very easy in terms of serialisation. The whole data structure just ended up as a dictionary of dictionaries after load and saving became updating those dictionaries and pumping it back out to XML. I don’t know if this will make me redo the work I’ve done with pugixml, but it’s at least worth looking into.

“Throw away everything that doesn’t work between games” – You’d think that between writing versions one and two of the same turn-based strategy game, you’d only be expanding and refining your codebase, but apparently the only things kept between versions were the renderer and asset system. The reason for this is that they (much as Mark advised me to) didn’t over-plan and didn’t write generic systems that were unlimitedly extensible. They just wrote the game they wanted to make as quickly and fat-free as possible. Maybe if they’d known the additions they’d wanted to make for Hunters 2 they could have built Hunters 1 differently and made it extensible in just the right way that more code reuse would have been possible, but that would have required incredible prescience, a lot of luck and still come with the trade-off of time, effort and money. As a self-funded start-up they almost certainly made the right choice. They certainly made the safe one and they’re still in business now, two games down and making a third for Games Workshop because of their success.

“Test for low memory situations” – One of the early bugbears for Hunters Part 1 was the game crashing when it was sitting in the background as the user was using another app. iOS might then decide that it was running out of memory and would dump Hunters or part of its resources our of memory. This wasn’t a situation Rodeo had tested in before release and it caused a lot of unhappy customers. Making sure my app deals with partial or entire unloads, then jumping back to the game where the user left off, will certainly cost time and effort to do, but the alternative is one star reviews and demanded refunds. On switching back to your app after a partial or full unload, Apple gives you a warning message and then display the last frame of your game before it was switched away from, giving you time to get everything back together ASAP.

“For freemium, balance your costs for in-app purchases very carefully” – Punch Quest was originally released as a free-to-play game, where you could earn in-game currency and spend it on in-game items, with the option of buying extra currency to purchase things quicker in-game. It seems the developers were too kind with their pricing of in-game items and with 600,000 downloads, they only made $10,000, forcing them to eventually switch to charging for downloading the game. Here’s the article in depth. Whilst you want your customers to like your company (good will still counts for something) and enjoy your game, you’re still a business and finding a good way of getting people playing your game to pay for it shouldn’t be misconstrued as ripping anyone off. You might want to make it that players could, in theory, play the entire game without paying a penny if they put the hours in, but making that laborious to the point that most player would consider paying for extra items or content is just good business sense. This is in no way advocating pay-to-win, which will definitely alienate your customers in multiplayer games.

“Make something good. Tell everyone.” – It sounds obvious but sometimes the most common of common sense advice is forgotten. If there are two stages to making a game, these are they.

“Give exclusives to interested journalists, then digg/twitter everything to fuck” – If you give an exclusive to a gaming site, you’re doing so because it’s more likely they’ll more prominently display the article about your game, but what you really want is for *everyone* to read it. If you then go on to use all your social media heft to get it out there, there’s more chance of other social media outlets picking it up, which brings us neatly onto…

“Tak’s pyramid of upselling” – Named after Tak Fung, co-founder of Supermono Studios, this isn’t an alternative to making a creative, fun, polished game, but a solid approach to gaining traction in the media to publicize it. Tak suggests that, in the beginning, the big sites are unlikely to have much interest in you. Unless your game is so left-field creatively that it’s news by itself, it’s unlikely to be immediate front page material. However, like any ecology, there is a food chain and whilst the largest gaming sites might have little interest in eating your output initially, they’ll happily eat the best output from the sites one level down. If you find small sites and get them interested enough in your game that they put you on their front page (maybe as an exclusive, as suggested above) then the sites above that are more likely to consume your content from that level, and so on up the chain. This is unlikely to get you to the top in one go, but by the time you do your next round of publicising your game, the sites one level up the chain might have heard of you and could be willing to take an exclusive, until you find yourself getting your emails replied to by the biggest sites directly.

“Be careful and well-crafted with your output, the press might repeat it verbatim” – If you give a journalist some copy to read, there’s a chance that the headline you wrote (or some mash-up of your first sentence) will be the headline of their article and the rest of the article will be a verbatim reproduction (or some condensed version) of the rest of that copy. If you can’t imagine what you’ve handed them looking good as an article on their website, then re-write it until you can. This isn’t any guarantee that what you write is what will end up on their front page as-is (most will at least re-write it to keep within their own style guidelines), but a good failsafe against your poor language skills ending up being the next thing a potential customer reads about you.

“Give the journalists anything and everything they ask for” – Screenshots, videos, sound bites, your sister’s phone number, just do it or you run the risk of the article about your game being at the bottom of their front page, under the articles about the games of people who did.

https://testflightapp.com/” – This website looks amazing for beta-testing your game. It takes all the heavy lifting out of getting a signed version of your app onto the devices of whoever you like (specific friends or x number of strangers), then feeding back usage analysis to you. It’s something I’ll definitely use and currently it’s free, but great things can’t last forever.

“Always keep the game stable” – At Rodeo they always stop production whenever anyone hits a significant bug and ensure they fix that bug before continuing. I think we all agreed that asserts should be unskippable and should crash the game. If you’re checking something is true and it isn’t then stop and fix now (including it not really being an assert and removing it), don’t let people “come back to it later”, when they never will. Keeping the build functional at all times will save more time than it costs.

“Xcode static analysis” – We used to use lint a little at Lionhead, but there weren’t enough evangelists about it for it to be used enough. Using static analysis and cleaning up all the complaints will get rid of a lot of hard to repro bugs (uninitialized variables and the like) before they cost you time and sanity.

“Pay up front worked better than unlocking in-game” – Hunters Part 1 was initially a free to download game, where you unlocked the ability to continue upgrading your characters beyond level 2. This wasn’t working as well as they hoped, so after a few months they switched it to pay to download. This was worrisome for them as all the people who had already downloaded it for free would get the update and now have it unlocked for free. Only new players would be paying to download the new version and make them any money. It turned out this was worth it as their daily income doubled. No doubt a lot less people got to play the demo version for free, but they made more money in the long run.

“Apple offers automatic refunds but few people take them up on it” – Apple’s policy is that anyone that asks for a refund on an app gets it, no questions asked. The app is also not removed from their device and they can keep playing as normal after the refund. If this sounds bat-shit crazy and scary to a developer, I can understand it, but only around five people per week ask for that refund on Hunters, which says a lot about the people who choose not to pirate games in the first place.

“Use GIT for source control” – Currently I’m using perforce for free on my own computer, but I really need to get everything in the cloud in case others join my project. My perforce directory is in dropbox so I’m reasonably safe from losing it under most conditions, but I shall have to soon do it “properly”. There are many possible solutions but GIT was Adam’s favourite.

“By the time your game is released it has to be your personal favourite game” – I think this is a great sound bite and something that will have to be true before I release anything myself. If I don’t love it and can’t be the best evangelist for my own game then what chance does it have in the highly saturated app store?

Thanks to Adam, Glen, Kostas and Mark for their time and advice (I think they enjoyed giving it as much as I enjoyed rapidly jotting it down). I’m sure I’ll head to Guildford and assault more ex-Lionheaders for their advice in the future, but for the next while I’m going to spend my time doing less typing of English and much, much more of C++. Happy 2013 everyone :)

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?