Invisble walls

One of my most frequent frustrations with games I played when I was a kid was invisible walls. There was almost invariably a particularly enticing area of a level which simply couldn’t be accessed. Needless to say, this is something I’d very much like to avoid in my own games if I can avoid it. To this end, I decided to experiment with endless procedural terrain generation whilst developing the first prototype for Another Ewe.

By the end of the 2014 Global Game Jam, I had new tiles of terrain automatically generated whenever a player moved too far from the terrain pre-generated when the game first begins. It was set up so that the new terrain would be generated before that area of the level was visible, so as far as anyone playing was concerned, the level was endless.

Endless so long as you don’t go too fast

This approach, however, was very far from perfect; if a player decided to head off in a straight line and kept walking without stopping, the new terrain couldn’t be generated quite quickly enough and they’d eventually see the new terrain being drawn. There was also the issue that the game would stutter a little every time a few new tiles had to be created at once.

The most obvious place to start was to optimise the terrain generator. If it could be optimised enough, then it should be able to be generated quickly enough that a player could never ‘outrun’ the generation of new tiles, and it would all hopefully happen fast enough that there’d be no visible stutter. The Unity profiler (thankfully available as part of the Unity Pro licence made available for a couple of weeks to all Game Jam participants) proved invaluable. The profiler highlighted some areas where I’d known the code could be more efficient, but had resisted optimising prematurely, but also some other unexpected areas where simple changes made huge differences to performance. This helped reduce stutter and made it much harder to outrun the terrain generation, but ideally this will be useable on mobiles and tablets (if not for this game, then certainly for others). Probably more importantly, any system that generates terrain endlessly will eventually run up against memory limits; clearly there was more work to be done.

Endless so long as you don’t go too far

At some point, inevitably, some of the terrain that’s been generated will have to be discarded to make way for new terrain as players move around. To this end, terrain tiles are tracked based on their location so that any too far from a player’s view can be removed. The removals happen slightly further away than the additions so the two processes don’t have to compete.

So now players can freely explore as far as they’d like without ever being confronted with those impenetrable, invisible walls that so plagued my childhood. This approach should hopefully prove useful not just for Another Ewe, wherever it might end up, but also for some other projects I have in mind.

Over the past couple of days I’ve been preparing an Android version of Another Ewe. Unity still keeps surprising me with just how easy it makes porting to other platforms. There were a couple of small things — Postprocessing effects generally don’t work (or if they did would probably kill performance), and of course phones/tablets don’t really work with the same sorts of input as PCs — but overall the process always proves amazingly simple.

As always, there will be a lot more work to improve performance and make the controls a little more intuitive, so there'll be a few updates coming over the next few weeks, but for the moment, check out the Android version in the Downloads section and let me know what you think in the comments.