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.
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.
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.