A couple of people have asked how to do this, after my post on bitmap font rendering. It only takes a small change your shaders (so long as they’re CG shaders to begin with, not fixed-function ‘shaders’), so it’s quite easy to use with 2DToolkit or NGUI.
Start by making a copy of the shader (if you’re not sure which one, find the material used by your font).
Open the shader in a text editor. If you’ve never messed with shaders, it might be worth pointing out that the shader name at the top of the .shader file is the name used when selecting shaders within Unity – so give that a new name.
The most important change is in the fragment shader, where the texture needs to be sampled using tex2Dbias(), rather than the regular tex2D().
Here’s the modified version for one of the standard 2DToolkit shaders (for NGUI it should be very similar, just with some slightly different variable names):
fixed4 frag_mult(v2f_vct i) : COLOR
fixed4 col = tex2Dbias(_MainTex, half4(i.texcoord.x,i.texcoord.y,0.0,_MainTexBias)) * i.color;
Then all you need to do is add and expose the new _MainTexBias parameter, so add it to the Properties section of the shader:
For sharpening up UI and font textures, you’ll want a mip bias between 0.0 and -1.0 (-1.0 means ‘sample one mip level higher than normal’). Positive values are usually bad, as they make things blurrier.
If changes to the bias parameter are not visible immediately in the editor, it’s probably because your 2D framework has created an instance of the material internally, so it isn’t getting the parameter changes. It should normally update when you press the play/run button, though. If you want to check that it’s having any effect, try an extreme value such as 4.0, which should make things very blurry.
(And make sure that your textures have mipmapping enabled, and trilinear filtering enabled, otherwise you won’t get the desired results!)
In an ideal world, any bitmap fonts would be rendered at a 1:1 scale, and we’d use vector fonts with fancy subpixel antialiasing whenever possible…
But in reality, at least the reality of game development, we often need the performance and versatility of bitmap fonts, and it’s rarely possible to achieve pixel-exact rendering, especially when dealing with platforms that have dozens of screen resolutions.
But that doesn’t mean that your game text has to look bad. If you simply avoid making some common mistakes, bitmap fonts can look pretty good, even when heavily downscaled. Unfortunately, it’s quite common to see font rendering done pretty badly… so here’s some tips.
Creating bitmap fonts
Well, just about everyone uses BMFont these days, from AAA studios to solo indies. It’s used by some of the most popular Unity 2D/UI packages (NGUI and 2D Toolkit), too.
There’s not really much to say about the BMFont process. Just make sure you export the font at a large size, at least the largest you need to display. Never try to upscale bitmap fonts (or bitmaps in general), it’s never going to look pretty. But with a bit of care, downscaling can be made to look rather good.
Try to fit your BMFont fonts onto a single texture page. If there’s free space, increase the font size until the texture is close to full.
You can take the output texture into Photoshop, and easily add an outline, bevelled edge, drop shadow, and so on. If you’re adding outlines or drop-shadows, you’ll need to use the padding settings in BMFont, to leave space around each glyph for these.
Texture Filtering: Doing it right
This is where people often get things wrong. Here’s some examples of different texture filtering setups, on a font which is being scaled down a lot. Yes, it’s best to avoid scaling quite this much, but sometimes it makes things simpler – if you have multiple text sizes, and running on Retina and non-Retina iOS devices, for example. It’s also not the cleanest font for a test like this, with the bevel and gradient on it – but it still shows the difference between texture filtering setups quite clearly (click for full-sized image):
Example 1 – well, it’s just there as a comparison. Nobody should use point sampling unless they’re rendering at 1:1, or going for an intentionally pixellated look.
Example 2 – This is fairly common. People avoid mipmaps on font textures, as ‘it makes them blurry’. In this case, it doesn’t look terrible, but it gives quite jagged edges when there’s a lot of downscaling. We can do better.
Example 3 – Mipmaps, with just bilinear filtering. Extremely blurry, as only a lower-res mipmap is being used. Yuck.
Example 4 – Trilinear filtering. Now it’s taking a weighted average from sampling two mipmap levels. A definite improvement, but still a bit soft. But that’s fixable.
Example 5 – Now we’ve added a negative mip bias. Negative values bias the sampling towards higher-resolution mipmap levels. The -0.65 was chosen here, as to my eye, it was a nice balance between smooth and sharp. You may want to tweak it a bit, depending on your specific font.
Example 6 – A slightly stronger bias, biasing by one whole miplevel. This also looks good. Not a huge difference from 5, but the diagonals are starting to get just slightly more jagged.
Example 7 – Just for comparison. This very high mip bias has completely negated the effect of mipmapping, and it looks just like test 2.
Mip Bias? – How do I do that?
If youre working with D3D or OpenGL on desktop machines, look up D3DSAMP_MIPMAPLODBIAS or GL_TEXTURE_LOD_BIAS.
On mobile (GL ES), or if you’re using Unity, you’ll have to do it via a shader, and use tex2Dbias to sample your texture (If you’re using 2DToolKit or NGUI, it’s easy to create a modified version of one of the included shaders, with an added Mip Bias parameter, and using tex2Dbias)
Texture ‘fringing’ and solutions
Whenever alpha blending is used (and particularly when Photoshop is involved), you can end up with nasty white (or other colour) fringes, like this:
This happens because the transparent (alpha=0) pixels in your image have RGB values which don’t match the edge of your image (in this case, they’re white).
When bilinear/trilinear filtering is used, Texture sampling will take a weighted average of the R,G,B, and A values of a number of texels. So around the edge of the image, the colour values from completely transparent texels are being included in this average!
Ideally, more people would understand premultiplied alpha, as it’s the most ‘correct’ solution to this problem. But the alternative is to make sure these transparent pixels have sensible RGB values.
Unity 4.2 added an ‘Alpha is Transparency’ button, which is an automated fix for this in most cases, it will set the RGB values of transparent pixels to match nearby non-transparent pixels. A while back, I wrote a little C# tool to perform a similar fix myself, essentially ‘extruding’ the colour outwards from non-transparent edges into nearby transparent pixels. Other people recommend a ‘Solidify’ filter for Photoshop, which does the same sort of thing.
Or you could use premultiplied alpha. I should probably write something about that one day, as it’s pretty awesome.
One more thing: Text with outlines
Outlined fonts. It’s a common thing to want to do, in games where text may be rendered over any background. But very few font rendering systems support it well…
The first example shows the naive way to attempt it – and what goes wrong – when there’s a chunky outline, the outline overlaps the previous character, and this looks bad. Option 2 is an exaggerated example of the all-too-common solution, to simply space the characters out more…. Don’t do this!
The final example shows how it should look. The solution is trivially simple. Render the black outline first, then render the (un-outlined) glyph on top.
The simplest way to achieve that would be to use two textures, but if the outline is black, you don’t need that. Use vertex colours to render the font (glyph+outline) in pure black. The use additive blending to *add* the glyphs – the non-black bits – on top (without redrawing the outline).
And if you understand premultiplied alpha, you can do this in a single draw call, without changing renderstates!
(The images in this post were created using 2D Toolkit in Unity, after modifying its font renderering code to handle two-pass outlined fonts, and adding shaders with mipbias support)
There was some discussion on Twitter last night, about indie devs posting sales figures, and how it tends to be those that do unexpectedly and spectacularly well that are most likely to talk about it…
So here’s another data point. Some numbers for Skyriders.
Skyriders released on iOS and Android last October, so it’s had the best part of 8 months on the App Stores now. So how has it done?
The iOS version:
The game initially released as a paid app only, at £1.49/$1.99. Soon after, in November, I also released ‘Skyriders Free’, which let you play the first zone (the first 20% of the game) for free, with an one-time in-app-purchase to upgrade it to the full version.
It’s hard to say whether the trial version was a good or bad idea. There weren’t many sales of the IAP upgrade to the full game – but it did get another 20,000 or so people to at least try the game, and maybe a few more of those bought the full version instead of the upgrade? But I think I made too much of it free, really. Especially with the difficulty of the final ‘challenge stage’ in each zone – I suspect a lot of players won’t have reached the ‘upgrade now!’ screen.
The price was dropped to £0.69/$0.99 for the New Year’s App Blowout promotion, before increasing it to £1.99/$2.99 afterwards as a short experiment, then dropping it down to £0.69/$0.99 again, where it still is today.
The game was also released on Android. The Android version remained at £1.49/$1.99 (in part, due to price changes being a bit more hassle on Google Play!).
No graph for Android, as I’ve not found an easy way to get the units sold/IAPs sold figures out of Google Play, but overall, the Android version accounted for 23% of overall revenue from the game. It’s also had over 130,000 downloads of the free version.
Promoting the game:
I failed here a bit. I was a bit burned out from getting the game finished, and quite ill around launch time – I tweeted a fair bit (and got a few nice retweets from developers with more followers that myself), and sent out a load of review codes to iOS gaming sites (somewhat neglecting Android), and did get some nice reviews.
I got some fairly positive comments on a TouchArcade thread, and tried to respond where reasonable, and patched a couple of scoring bugs/exploits reported by some of the more enthusiastic players.
I also put up a Steam Greenlight page for the game the day that Greenlight launched. This got a reasonable number of views (although it was clear within a few weeks that Greenlight was never going to be a practical route onto Steam, so I took the page down, and decided not to bother with a PC version)
I probably could and should have done more to promote the game, really, especially the Android version.
Piracy figures, reavealed very clearly through analytics systems, are quite shocking on mobile. Particularly on Android. Flurry reveals that Skyriders has had over 900,000 unique users on Android. This is clearly a long way from the 130,000 free downloads and 1000 or so sales that Google Play reports…
But there’s not a lot you can do about it, other than try to ignore it. The bulk of the pirates appear to be Chinese, anyway, and that’s not a market that I’ve been really considering – according to Flurry, out of those 900,000 Android users, almost 700,000 are from China:
So let’s just ignore that, and move on…
Anyway, adding up the payouts that I’ve seen from Google and Apple (so after their cut and sales tax, but before income tax), the overall revenue figures are:
(It’s currently selling at a rate of maybe 2-3 sales per day across both platforms)
Out of that, there weren’t many direct costs for the project – the main ones were paying the musician, and renewing my Marmalade license. Then there’s the not-quite-so-clear costs… Upgrading to an iPhone 5 as soon as it launched, so I could test on the new device… and the occasional piece of software and PC upgrade that wasn’t entirely essential but helped things go more smoothly.
So was it worth it?
Well, if I ignored the cost of my time/cost of living – I could consider it a success. But the reality is that I’ve got rent+bills to pay. Even if I don’t go out much, my current cost of living (rent, bills, food) is around £1000/month – as I’m living alone in a rented flat.
I spent a little over 6 months on Skyriders. Full-time-ish – meaning technically full time, but slowed down by periods of low productivity (a mix of depression, lack-of-direction, distractions, procrastination, and just plain laziness every now and again). I guess it should have been closer to 4 months if I’d worked more flat-out, really.
So taking that into account, it’s not been a profitable project, but it has given me a bit of income – at least enough to slow down the rate at which I was burning through savings, somewhat…
Skyriders wasn’t really a ‘sensible’ choice of project. It was something that I wanted to make, and knew that I could make well (given my lack of art skills but better coding skills). But it was never a project that was likely to be a big hit. It doesn’t fit into a clearly-defined genre, or have a quirky art style, or follow often-profitable trends such as voxels or zombies.
And it’s not the game that I originally planned to make. The original intention was to make a more tunnel-based game, where you could ride 360-degrees around the inside of the tunnels (more like STUN Runner than Sky Roads/Trailblazer). But earlier prototypes didn’t really work out, and it gradually evolved towards the final game.
Maybe the platform was wrong, too. The game might have been more successful as a PC game, with lots more polygons/draw distance/effects (rather than holding back to keep it at 60fps on iPhone 4). But with Valve/Steam’s stranglehold on PC game distribution these days, and the increasing difficulty of getting anything onto Steam, I’ve more-or-less ruled out developing anything for the PC, at least for the near future.
Anyway, I’m happy with the end result, and glad that I managed to finish it and get it out there. It’s certainly not perfect – letting the player choose between tilt or buttons for control was a big mistake. And it suffered from the common problem of getting too hard quite early on (even though it feels trivially easy to the developer…)
I’ve got no immediate plans for a sequel or major update to Skyriders, but I do keep considering trying to port it to the web, as there’s now several options for attempting to get a C++ proejct onto the web: Emscripten, FlasCC, and NaCL.
So what about Little Acorns?
As publishers were involved with Little Acorns, both on iOS/WP7 and 3DS, sadly I can’t give numbers.
This was a bit more successful – but with more people involved with the project, and a publisher taking a cut on top of Apple’s cut, and launching at $0.99, you need to sell a *lot* more units to be successful.
Whilst more successful than Skyriders, it’s not made anybody rich, but for the months spent on it, it’s been a bit more comparable to what I could earn in full-time employment, but of course, more fun – as we were making a cute 2D platformer and in full control over the design!
And what’s next?
That’s a good question… At the moment, I’m considering a few options – I’m back in the position where I need to pick a game that I can make look decent with minimal art skills. I’ve got lots of fragments of ideas, but no cohesive plan yet.
And there’s always a chance that Team Pesky may get back together – we’ve not ruled out a sequel to Little Acorns, or something different entirely…
I noticed that I had quite a collection of Skyriders screenshots in my Dropbox public folder, that I’ve tweeted or posted to Screenshot Saturday during it’s development. And thought I’d write a little ‘Making Of’ post based around them…
So by February this year, I was finished with Little Acorns. I probably should have done the sensible thing, and made another platformer, based on the codebase and experience from Little Acorns. But I wanted to do something quite different. I experimented with voxels and deferred shading on the PC briefly, a 2D rollercoastery game featuring a caterpillar, and a word game, of all things – before starting Skyriders…
The beginning… Let’s get some polygons rendering. I had a decent amount of reusable code from Little Acorns for 2D rendering, but the 3D side of things needed doing from scratch. I was working in C++, with Marmalade, but also had a native Win32/D3D build to maintain. Anyway, the first screenshot… basically a tilemap wrapped around a cylinder. With the old HUD from Flutterpillar (the caterpillar-rollercoaster prototype) on top. Just seeing this rendering really smoothly on my iPhone4 made me want to carry on.
Later in March – the tunnel could now curve left/right/up/down, and I’d written a basic model converter/importer (Export from Blender as COLLADA, and convert to my own custom format. A very simple format that supports hierarchies and basic material properties, but no animation). This was the first successfully imported model – the Blender monkey!
I’d also started to hook up a physics engine. I went with Tokamak, as it seemed fairly lightweight compared to newer engines, and therefore easier to integrate into a Marmalade project, and more likely to perform OK on mobile devices. I had fairly minimal physics requirements – I just wanted a sphere colliding against a static environment. Although the environment did end up having quite a lot of polygons in it.
Textures, and a skybox! And the first experiments with models for the player. I didn’t really know what it was going to be at this point, but you can see the basic shape of the player ship that survived to the final version!
By this point, the tracks were getting more interesting, and weren’t limited to cylindrical tunnels. I could blend between a range of cross-sections, allowing the tunnels, flat sections, and curves like those in this next screenshot. I’d also improved the textures a fair bit, and added boost/slow pads (although they were just textures at this point, gameplay was still fairly non-existant)
Tracks were built using my ‘TwoDee’ editor. This was originally designed for non-tile-based 2D game. Then adapted to support tilemaps for Little Acorns, and then abused to build Skyriders tracks! You can see that the track is 20 tiles across, with a special column of ‘control tiles’ at the right hand side. These control the cross-sectional shape of the track, and also control the curving and banking of the track. It’s nice and simple, and keeps the level data very small, but it’s not WYSIWYG, so can be tricky to work with. Luckily, I could get the edited track back into the game and test it within a couple of seconds/couple of clicks.
Yay, I had a name for the game! And it was time to replace the old HUD. Not sure why I made this a priority so early on, but this was the first mockup of it. And it stayed more-or-less like this until the end:
The player ship had also been updated, looking very much like the final version. But with a fairly rubbish attempt at a character within it! It was also environment mapped, but still didn’t look great.
So where did May go? I suspect that was spent on UI work, and implementing that new HUD layout – sothe screenshots of that were less exciting!
It was either that or the threading woes. I’d decided that I’d generate the track mesh on a thread, as it comes into view – to avoid generating it all up-front as the level loads. I wanted to be able to join up a number of levels into a long ‘Challenge Stage’, and expected problems if I allocated and generated the whole thing at once. Well, I got that all working nicely, or so I thought. It was fine on PC, the Marmalade Simulator, and on an iPhone4. But on an iPad 3 it just crashed randomly. As I’m using Marmalade, I couldn’t do any on-device debugging, and the crash was too random to track down by printf debugging alone. It turns out that Marmalade had known issues with threading on iOS. I couldn’t be sure this was what caused my problems, but I’m guessing that it was…
Eventually, I just scrapped the threading. For normal levels, the loading pause is fairly insignificant. For the (much longer) challenge stages, there’s a noticable loading pause on slower devices, but nothing major. It did require a fair chunk of extra RAM, though. But it improves performance in-game, as it’s not generating geometry in the background.
Here’s a shot showing debug output, just after adding support for mesh entities with collision meshes. The green polygons are the currently active sections being collision tested.
By this point, I’d got a nicer looking player ship, an improved skybox, and the red/yellow colour-switching mechanic was in-game. I’d also added some glow effects (ships engines, and the collectables). The new HUD was also in.
Tutorials… I hate implementing tutorials… I’d prefer to assume that gamers can figure out simple control and scoring systems, but for mobile games, you can’t really even assume that… I also had to explain the less-obvious colour-switching mechanic.
Time for some tech work. I’d been getting the Android build up and running. This needs a separate data build, as iOS uses PVR texture compression, and for Android, I needed to use ETC1 instead. My first attempt at supporting ETC1 didn’t quite work…
But soon that was sorted, and it was running quite nicely on Android – here it is on an Xperia Play, and a Nexus 7:
Oh, look – there’s a ‘Games We Like’ button there, too!
By this time I had a composer helping out on the project, and adding music to the game made a huge difference, as it usually does! We experimented with dynamic music, by playing two music tracks at once – keeping one playing all the time (percussion/bass), and fading the ‘overlay track’, containing the melody, in and out based on how well you were doing. This worked out fairly well, but it’s something that we could have taken further.
(Ogg playback was done via stb_vorbis – This worked well, except for discovering a small memory leak in it, which I only found when my release candidate crashed!)
So I’d spent the best part of 5 months on the game now. Longer than planned – it was supposed to be a quick project. But writing my own tools and rendering code, as well as doing my own art had slowed things down. And I only had half a dozen or so levels built. I was aiming for 40 levels, split over 5 zones. So it was time to start on the skyboxes/textures for the other zones, and get building levels!
Here’s an early shot of Zone 2: Emerald Nebula:
I’d also found time to add the trail effect to the player. I’d been wanting to add that for ages!
One of the biggest late-ish changes was to lower the camera and widen the field of view. This hugely improved the sensation of speed. After doing that, and improving the Zone 1 textures, I was, for the first time, quite happy with how the game was looking:
Levels, Levels, Levels. I really underestimated the time required to build levels. Even after Little Acorns, where we did exactly the same…
But much of September was spent on level design and zone retexturing, as well as adding the upgrade system. Zone 3 became a very vivid orange, but I was quite happy with how the skybox turned out. Skyboxes were created with the excellent SpaceScape, and Genetica was used to help with texture creation.
I also had some playtesters trying out the game, and got some decent feedback, which led to a bit of UI tweaking. The UI was looking a bit nicer now, too:
So by the end of October, I had a finished game! yay, finally!
I’d gathered together all the required screenshots, text, and icons for a submission, and it should have been on its way to the App Store, but plans were somewhat spoiled by Apple’s release of the iPhone 5…
Well, the game runs on an iPhone 5 – look, 1136×640!:
Unfortunately, that’s not good enough for Apple. You’re not allowed to support that resolution with using the new 6.0 SDK. Which isn’t a problem for native developers using XCode, but as I’m using Marmalade, I can’t update the SDK myself, I’ve got to wait for Marmalade to release an update. (And it sounds like they’re still struggling to get hold of an iPhone5! – I must have just got lucky to walk into an O2 store and get myself an upgrade!). It’s a shame that Apple won’t give major middleware providers earlier access to hardware and SDKs, to help avoid such delays.
That update should arrive at some point this month, and I’m praying that it won’t cause any new problems, as I’ve got a hopefully-bug-free submission-ready build here now…
So whilst waiting for that, I’ve been tidying up the Android build. That one will be a free download, with an in-app upgrade to the full game. This makes sure that nobody pays for the full version on devices that won’t run it well. That’s in a fairly good state now, although I’ve still got a couple of issues to track down that occur only on one specific model of phone so far…
And I made a trailer
If all goes well, the game should be arriving on the App Store and Google Play around the end of October, maybe early November!
And there’s some screenshots from the finished game here
Yes, it’s been that long since I posted anything on here… although I’ve been tweeting a fair bit.
Little Acorns was released, did OK-ish. News on other platforms coming soon-ish (unfortunately, it doesn’t look like we’re releasing on Android, though). Anyway, after that I spent time prototyping a couple of other ideas – a word game, then Flutterpillar, a rollercoastery thing with a caterpillar.
The new project
But neither of those went very far, and I ended up working on a 3D into-the-screen game, influenced by old classics such as Trailblazer, Sky Roads, and STUN Runner. The working title is ‘Skyriders’, and it looks something like this (video is a few weeks old, though). Technically it’s going quite well – it runs at a nice smooth 60fps on an iPhone 4, and the rendering is working fairly cleanly – simple-but-effective lighting, environment maps, and alpha-fading out in the distance. You really can’t do anything clever with shaders on iOS is you want to run at 60fps on the iPhone 4, unfortunately…
It’s been a slow few months for progress, between being ill, unmotivated, or just plain distracted by things like this:
A small quadcopter, powered by an Arduino, a Wii Motionplus board, and the open-source MultiWii software… It’s done a lot more crashing than flying so far, but it more-or-less works…
Anyway, time to start updating this site a bit more, and try to do some proper dev blogging!
At the start of 2011, I was working at FreeStyleGames, and had worked on a couple of great projects there (DJ Hero 1 and 2). But early that year, a project was cancelled, and it was looking like Activision were going to close the studio.
We went through a very grim 3 month consultation period, expecting the worst. In the end, the studio survived, after making significant redundancies. Which turned out to be my opportunity to have a go at some full-time indie game development!
I’d experimented a bit with iOS earlier in the year, and decided to use Marmalade (formerly ‘Airplay SDK’) – as this allowed me to develop in C++, using Visual Studio on Windows, and target both iOS and Android. It provided a ready-made platform abstraction layer and a good build system. And it let me use OpenGL ES directly.
My first game was initially going to be ‘Fluff’, a physics-based rotating-level platformer that I’d already started to prototype. But I quickly realised that it was quite an ambitious project, especially if I was going to do my own art. So really, I either needed to work with an artist, or work on something smaller, at least for my first iOS game.
Fluff had actually made some decent progress though, especially looking back at this screenshot (before I really messed up the grassy tileset, trying to reduce the chunky black outline/shadow on it!). But there wasn’t much gameplay there.
Fluff is currently on hold. It may be revisited in some form, eventually.
From Little Acorns…
But by July, I’d teamed up with Andy Gibson (who I’d worked with in the past at Gusto Games), to work on what at the time was called ‘Hurry Home Mr. Squirrel’. Andy had been trying to make this game himself for quite a while – but as an artist, it was his first programming project. So whilst the art style had made a lot of progress – the game code, based originally on the XNA Platformer Starter Kit wasn’t in such a good state… Andy had been aiming to get it out on XBLIG, but really wanted to get it onto iOS.
Initially, it looked like a very simple project, maybe 2 months or so, keeping it really simple – a scrolling tile-based platformer with only a few enemy and collectable types. I adapted my existing level editor, ‘TwoDee’, to handle tilemaps for the project, and withing a few days there was a squirrel jumping around them on my iPhone.
An early build of Little Acorns, running on iPad, iPod, iPhone, and Windows (on a Mac…)
Soon that quick+simple project started to grow in scope… I wanted to add the grappling mechanic from one of my Ludum Dare games. We prototyped it, and both loved the results. I polished the controls, optimized the rendering to ensure we’d get a solid 60fps out of an iPhone 3GS or above, and it was starting to look rather good.
Playing other iOS platformers – which mostly had poor controls or bad framerates, motivated us further. More features! More polish! More levels! And a shorter name… ‘Little Acorns‘ fits nicely under the app icon!
After a surprisingly productive 3 months or so, the game wasn’t far from finished – it mostly needed levels building (but we had another level designer helping out, too). We sent a build to Chillingo, who liked it, and are now publishing it.
That led to a fair bit of tweaking and a bit more feature creep – and before I knew it, it was late November… That little project of ours had taken about 5 months (1 full-time-ish coder, 1 part time artist/musician, 1 occasional level designer)
Anyway, it’s finished now (at least on iOS), and I’m quite happy with the end result. It’s just down to Chillingo to spread the word – it’s going to be in the App Store on Feb 16th!
Little Acorns: Screenshot from the finished game
It’s got a preview thread on TouchArcade here, and a first trailer is here (cool, almost 1000 views!).
So that was my first 5 months of indie development. December was a bit of a write-off, I’m not really sure where it went. I did bits of work on Little Acorns porting (Android/PC), but we’re now holding back on that to see if the iOS version sells, and whether it’s worth investing further time on these.
I also started working on a word game prototype, some sort of mix of Scrabble, Tetris, and Greedy Bankers. The current working title is ‘Cunning Linguists‘, but that may have to change…
So what else happened in 2011. Well, I completely failed to do anything about my weight/health. I’d hoped that once I didn’t have a full-time job, having less stress and not being tied to a desk from 9:30-18:00 would have helped. But so far, it hasn’t. I’ve spent a similar number of hours at a desk anyway, but without the walk to and from work… I really need to make more of an effort this year to cut down on the beer and snacks…
I’ve accumulated way too many mobile devices (6 iOS devices, 1 Android phone, and 1 WP7 phone so far), and expect to end up with even more if I get serious about Android… Or if Apple really do release an iPad 3 with a ‘new year’s resolution’ of 2048×1536 (1024×768 doubled) that I’d have to support… But I started out with a reasonable amount of savings (saved whilst living cheaply, like a student, in a shared house whilst earning a reasonable salary for a couple of years!), so I’m not broke yet, and I’m anticipating at least another 6-12months of indie-ness, before having to find a job if I’m still not earning anything significant…
On the more positive side, Midlands Indies got started this year – monthy pub meetups, alternating between Leamington and Coventry. The turnout has been pretty good most of the time. And I managed to get to a couple of TIGJams, which were fun. And of course, there were a couple more Ludum Dare entries!
So now it’s 2012…
Despite Little Acorns taking significantly longer than intended, maybe that wasn’t a bad first 6 months as full-time-indie. One game made, from start to finish. £0 income (yet) – but some reusable tools/code developed, and a fair bit of experience dealing with iOS. Also, my Photoshop skills have improved a fair bit.
So what’s to come this year?:
Firstly, Little Acorns updates and porting work. If we go ahead with the ports, or an update for iOS, this is likely to be keeping me occupied for at least a little while. We’ve got an Android build to tidy up, and have the option of releasing on PC, too (maybe via IndieCity), and it looks like we may be porting to WP7, which is a significantly bigger job.
Then I’d like to finish at least one, but ideally two more games this year. The first is likely to be the word game (iOS), and the second will be something a bit more ambitious. There’s the possibility of a momentum-based iOS action game. Tiny Wings meets Unirally, sort of. Or a fast-paced into-the-screen 3D game (influnced by STUN Runner, Trailblazer, and more). Or maybe I’ll resurrect Fluff…
Alternatively, I may do something with Flash (+Stage3D). Maybe finishing the twin-stick-shooty-game that I started for Ludum Dare 22, or maybe something rather more ambitious and multiplayer…
Also, I’ve got to avoid becoming too addicted to SWTOR or any other evil MMO!