Thursday, 10 January 2013

Topia update update

Topia update progress

For anyone waiting for the update, sorry this is taking so long. Progress has been slow for several reasons. Firstly, for the last few months in the run up to release I got almost nothing done other than programming and had a lot of stuff to catch up on. Some of it work related, some of it more personal. I also had to make some significant changes to how Topia saves progress.

Why is saving broken?

Arguably saving isn't actually broken in the current version, it's just a questionable design implemented in a slightly stupid way. It is possible to save a 'timeline' of everything you do and play it back. The reasons for doing it this were related to a bunch of vague ideas of where the game might go in the future. It offers these advantages:

Timeline saving, pros:


  1. The initial fractal and an hour of gameplay recording takes less than 100kb rather than the 2000kb+ that a straight save takes. This would make any potential level sharing very efficient.
  2. Being able to break into a timeline at any point and takeover has got to be cool hasn't it?
  3. I really can't think of a third anymore, there must have been more surely...

Timeline saving, cons:

  1. The concept is pretty difficult to present in a clear way to players.
  2. For a player to get to where they were before, the game has to play back the entire recording.
  3. potential for synchronisation errors as game logic changes with updates.
I hate to admit it but I really hadn't considered the first problem until I was putting the finishing touches to the UI. I could have possibly hidden what was happening and made it seem like a normal save system except for one other issue, directly related to con 2.

Because of the looming deadline I had problems getting the 'load by fast winding the timeline to the end' feature working in time so I left it out of the initial release. I hadn't realised how attached people would get to the simple editing and that it would become an issue. As the game was released I was getting more feedback criticism for the lack of save than the lack of an actual game. It was clear to me that I had to get 'fast winding' working so this became the top priority for the update.

Finally working on the update

I was expecting to be able to get a 60x speed fast wind working. This seemed reasonable as 12 minutes of editing would fast-wind (or 'load') in 12 seconds. Unfortunately when I actually got it working I only managed a 12x speedup on iPad2. This would mean that 12 minutes of 'timeline' would take an entire minute to 'load'. I could have focused on optimising the fast wind and might have even got as far as that 60x speedup but even then, a little maths suggests it might not be fast enough. Anyone editing for an hour would have to wait a whole minute to 'load' and with easier saving, people might edit for several hours, maybe even the 10 or so it would take to fill the recrod buffer. It was becoming clear that the entire concept was broken.

New save system

So I've now added the ability to just save out a level and reload it instantly. This is so much easier to work with. It's also allowing me to redesign the interface so that saving and loading all works as a normal human might expect. I've also in the middle of adding a few extra editing features. The update will feature.
  1. The ability to select between painting dirt and grass, making painting more interesting
  2. a tool to 'stepify' the landscape as seen below
  3. a tool to paint forests
  4. new instant save and load of levels
  5. redesigned menu flow
  6. redesigned game control and more control modes
  7. A bunch of under the hood stuff to increase reliability
  8. A few silly tiny visual effects I couldn't resist
I know I said the update was 'imminent' before but when I missed the pre-christmas deadline I took the opportunity to rewrite a few underlying systems and start a new project based on the same code. This took a little longer than I'd planned and combined with the fact i've been visiting my father in hospital twice a day means it's still only 'imminent' but it will be submitted very soon.

Tuesday, 23 October 2012

Topia is out! Where's the update?

The last few months of dev

It has been very a very stressful summer, as I've moaned before in this blog, while a year and a half might seem like a long time to wait for an iOS game, it's nothing for something like Topia with a programming team of one. It became clear some months back that we were leaving it a little late to put a game in. Josh and I had been toying with the idea of releasing it as a sandbox for a while but I'd always been determined to sneak some sort of game in there for the initial release.

Then we realised we had passed the point where I could kid myself I'd be able to get a game in before I completely ran out of money. Meanwhile we had something that was kind of fun. Definitely more fun than most 99c games, maybe we could get away with it after all...

So, I set about fixing bugs, made a tutorial mode and, after a little testing, submitted Topia to Apple.

Release

So, almost two weeks ago we crossed our fingers and released Topia on the app store. We tried to be as up front as possible about the lack of objectives in the game but had no idea how people would actually react. It's not exactly getting solid five star reviews but it seems most people get what we're trying to do and are looking forward to updates or are getting 99c worth of fun from the app which, I like to think, provides something unique even if it isn't exactly a game. Yet...

I totally understand those who are giving it one star for being 'pointless', I fully appreciate that the app store is a mature game market and 'standards' have evolved for games which we have arrogantly ignored.

The biggest surprise though has been just how keen people have been to use Topia to create worlds. We have had more (totally valid) complaints about the lack of a decent save world system than we have about the lack of a game.

Update

Because of this, the focus of the first update is going to be on level saving and loading. I'm part way through the coding work already, the confusing system of recorded replays is going and will be replaced with something that will let people work on their worlds for as long as they like.

hopefully it'll be submitted very soon. Enhanced creature AI and actual game modes after that.

The video below is a quick test of the output from the wonderful 'Reflections app' which turns your Mac or PC into an airplay device which can also capture video and audio. Not much happens in it, it only really shows the silly fake water refraction shader I sneaked in at the end when I could probably have been doing something far more productive.


Thursday, 23 August 2012

Topia update

Where the hell is Topia?

As i've said before in this blog, Topia is proving to be a hell of a lot of coding work. Some of this is fun, creative gameplay and graphical stuff but, being the only coder on the project, I also have a lot of irritating system level crap I have to deal with. Here's what has been going on since the last blog. This is possibly going to be a little boring in technical but that's been my life for months now so I thought I should spread the 'fun' around a little. If you aren't interested in technical details you should probably wait for the next blog which will feature a video with sound effects. You've been warned...

At the end of May I replaced the old file system with something rather more direct and powerful. They old one was very cool, designed to enable background loading on hardware that doesn't support multitasking (for example Nintendo DS) but was kind of getting in the way on hardware like iOS (and everything else we're planning to support) where something less clever on another thread makes more sense. This was pretty simple but I'd been putting it off for a long time.

With the new filesystem in place I was able to start on the changes to the editor. Up until this point 'editing a level' consisted of selecting a bunch of parameters for the fractal generator and a 'time of day' for the lighting. With the new system in place it was possible to paint landscape changes into the editor and store these as part of the world's definition. These changes were vital in making it so that a Topia levels are well under 64kb each. Before this levels were taking around 3mb, this is a 50x saving which means we will be able to include is many levels as we can come up with without bloating the download size into hundreds of megabytes. At this point I realised I had to optimise the landscape moulding code and worked out a sneaky way of getting a 7x speed increase to fix loading times. A really cool side effect of this is that the in game building tools can now be much larger, making building landscape feel even cooler.

I also added a bunch of extra features into the editor (which will be part of the full game) including complete control over lighting and atmospherics, the ability to paint paths and save out a level already populated with creatures. At some point after the initial release the editor will be released to players in an update. In it's current state it can't be let out to the public as it'd just confuse most players and confused players just quit your app and give you a one star review. I know this for sure from the stats of how many people finished the second level of Ground Effect...

I then spent a week working on another project that I will blog about later. This was for an iOS unity based project from a very cool new startup and they happened to need a couple of mad custom shaders written in a hurry. It was cool to finally get to use Unity. It's clear that something like Topia could actually be made with it (something I hadn't realised before) but you'd  be doing so much work in native plugins that you'd lose most of the benefits of using it. Cool to get a little Unity experience though.

It was great to actually be working in an office with other developers, some of them guys i'd worked with before many years ago. The atmosphere of a working office hugely increased productivity so I hung around their office for a couple of extra weeks working on Topia. During those weeks I completely rewrote the multitouch handler making it 100% responsive on all devices.

I also ditched Ground Effect's over-complicated and, paradoxically, under-featured sound system and went straight to OpenAL. The new sound system supports blending between multiple ambiences and 3D sound placement. Not rocket science and probably standard these days but all pretty new to me and very impressive that a phone can mix these many channels without grinding to a halt. The game is awesome with the sound in. I'll blog some details just as soon as I can make a video with sound.

Since spending a week or so on the sounds (thanks for the samples Josh) i've been focused on creature AI. Tikes (the fast carnivores) can now decimate herds of Pinos (the cute blue sheep) and i'm thinking the initial release won't just be a 'sandbox' we were planning, it'll also feature 'Pinos v Tikes' as the first minigame.

Thursday, 24 May 2012

Retina resolution and lazy developers

This blog has been sitting in my drafts for many weeks and would have been more relevant a while back but I though I'd finish it anyway...

A lot has been said about the new iPad's wonderful Retina resolution. Apple fanboys love it and are, seemingly, running magnifying glasses over every app, counting the pixels. Only full retina resolution is good enough. This is understandable as it is the main difference between it and the iPad2 and does look amazing.

It's also pretty easy to support. For Topia, and I imagine most other 3D universal apps, it 'just worked', the test for Retina that already existed for iPhone just kicked in and doubled the resolution, there were two issues though, one was that the UI was too small (this took an hour to fix), the other is the subject of the rest of this blog...

So, everyone who has bought a new iPad is waiting for stunning new retina-supporting games and excitedly downloading updates for their existing apps (which are all at least several megabytes bigger, but that's another story) and any dev who delivers an app that runs at full speed in 2048x1536 gets a bunch of fresh five star reviews, applauded in forums and called awesome in podcasts while those who don't are considered disappointing at best, lazy at worst.

 Lazy devs

Consider two developers:

Developer A

Imagine a developer aiming to support the first iPad. Rendering terms the new iPad is much more than 8X faster so has no trouble at all filling 4X the pixels. In code terms support for the new iPad might take an hour or so or in some cases, no work at all. 2D graphics redesigns of course take much longer but that depends on the game.

Developer B


Now consider a developer who was making the most of the extra horsepower of iPad2, adding cool shaders to make a game that looks more Xbox360/PS3 than 10-year-old-PC.
It's very likely that when it was first run on the new iPad at Retina res, the frame rate dropped considerably.

At this point they have several options:

  1. Accept the lower frame rate
  2. run at a lower resolution
  3. make the Retina version run full res but use cut down shaders so it doesn't look quite as cool as iPad2
  4. Optimise (and maybe pull a few features from) the 'nice mode' shaders so the Retina version runs full speed and the visual quality of the iPad2 version is slightly compromised
  5. as above but add an optional super-shader mode (possibly even beyond what you're doing for iPad2) that really shows of what the graphics chip can do but at non-retina resolution

Unfortunately, at the moment at least, the first three options would result in complaints and one star reviews from the pixel-counters. Option 4 is the only sane way to go (other than being Developer A).

Option 5 is of course the real solution but I think it would just confuse people and not worth the risk.

The question is of course, who is the lazy developer? A or B? I know who the stupid, time wasting developer is already...

Wednesday, 28 March 2012

Rethinking texture blending

Most landscape graphic engines have to represent different types of landscape and the question of what happens when impassable rock meets flat ground comes up in a lot of them. For some games it's entirely an artist problem but for those of us making lives hard for ourselves by using procedural generation, we've tended to find ourselves blending from one texture to another across a simple fade. For a while now i've liked the idea of textures blending in a more realistic way and did in fact get it sort of working ten years ago on Battle Engine Aquilla at Lost Toys (video link at bottom of page).

Battle Engine mixed the textures with the CPU while generating them local to the player as mentioned towards the end of my 2011 GDC talk but that was back in the days of fixed function hardware. These days it can easily be done in the shader. I'd been intending to get Topia working like this and spent most of the last few days actually implementing it. Here's a screen grab from yesterday morning. 



Notice how the grass sort of flows into the cracks in the rock and lumps of rock seem to be poking out of the sand on the beach. This is because the shader is actually working out how 'rocky' each pixel should be by adding the low-res 'rockiness' map to the detail-bump-map of 'rockiness', this is effectively modelling the rock poking through the sand and allowing the grass into the cracks in the rock.




Another screen grab, sadly more out of focus as i've taken to pointing my phone at my iPad to take screenshots via instagram. Notice that the reflection of my headphone lead poking out of my phone is in perfect focus. As is the side of my head where you can see the other end of that lead going in my ear...



Taking things a little further, i'm now bringing the bump map of the grass texture into the calculation. Notice how the lumps of rock are poking through the ground but the fuzzy grass is also overlapping the edge of the rock. I'm pretty pleased with how well this worked.


This last pic, though not as excitingly coloured as the others, is probably the most relevent as it's an actual screen grab of Topia running on my iPhone. This messing with Instagram really brings home how important tweaking colours is going to be as it looks kind of bland in comparison. It illustrates the texture blending pretty well though.

Battle Engine doing it into textures 'back in the day' (2001)






Friday, 17 February 2012

Game coding is easy but...

From the perspective of someone who spent most of the last few decades as a graphics coder, worrying about cycle counts, cache misses and API overheads it always seemed to me that game coding was the easy bit. At this point I should pin down exactly what I mean when I say 'game coding' as other people will draw the dividing lines in a project in different places. I draw them like this:
  • System stuff
  • Graphic Engine
  • UI
  • Stuff from elsewhere
  • Gameplay
Those are in order of how much time i've spent on each. 'Stuff from elsewhere' is any middleware, library, code from your previous game.


Arguably 'Graphic Engine' is part of 'System stuff' or 'stuff from elsewhere' but for me at least, it's been a significant part of everything I've ever worked on. Similarly, if you have your shit together 'UI' should be pretty much data driven through code cut and paste from the last game, it never seems to work out that way for me though and I find myself writing a new system from scratch yet again.

'Gameplay' is the most important part but it also seem like me to be the easiest. From my perspective it
always seems to be the guys writing the game that get to sit around leafing through books on coding style, casually using slow-but-powerful features of C++ or maybe insisting they have to use STL, often not worrying about optimisation. Just making the core of THE GAME.

The problem is, when you are programming a game on your own it doesn't seem to work like that. It's difficult to find the time to focus on gameplay when there is so much other code to distract you. My previous iOS game Ground Effect for example probably had about a week of solid gameplay coding in the whole project.

Topia has rather more than a few weeks of gameplay coding but when the is still tedious 'system stuff' and a few tweaks to the 'graphic engine' it sometimes feels like an indulgence to be working on the fun parts like the minds of the creatures or tweaking exactly what it fels like when you stroke the landscape into interesting shapes or direct a herd. Even fixing bugs that cause things like this to happen is kind of fun.





In an ideal world I'd be able to focus on the gameplay (plus maybe those graphic engine tweaks) for the rest of the project and have someone else do the boring bits. Oh well, at least i've been able to spend the last few weeks on what I call 'gameplay', i'll be doing the same with the next few, as long as I don't get distracted by something else. Like maybe making the A5 shader even cooler or putting in those clouds that Josh keeps asking for... Oh dear...

Friday, 3 February 2012

A quick video of some big herds


Very quickly thrown together, which explains why you can only see one corner of the iPad screen at one point. I have to admit to being impressed at the quality of the iPhone 4S camera though considering I just pointed it at the thumb print covered iPad and hit record.

It's very difficult to nurture a herd properly while filming which is why I couldn't muster a herd of 1000+ like in the still shot