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.
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.
Working on Dark Surrounds has given me some time to think about where this might go. Initially this was just a practice run for the 2012 Global Game Jam, but having developed more advanced techniques over the last year, I now have a few ideas on how this might become more than just a demo. I'm fairly happy with the feel of driving in the game – I placed much more of an emphasis on fun than on realism – but the environment is pretty boring. Perhaps that's to be expected given it just uses Unity's inbuilt terrain engine (and the inbuilt textures), but using the tools I've developed for Dark Surrounds, I can come up with something much more interesting.
I likely won't actively develop this for at least the next few months while I continue working on Dark Surrounds, but I'll be further developing my toolset with this in mind which should hopefully mean I can progress fairly quickly once I have some time to devote to this.
If you've played the demo above, hit me up with a comment and let me know what you think about the driving mechanics; it's very early stages for this game, so it'd be good to get some feedback before I go too much further.
Perhaps more important than merely creating trees, is giving them life. Trees move constantly; they sway with the wind sometimes groaning with the strain, their leaves rustle and twist back and forth, and they grow. Given their central role in the game, it seemed not unreasonable to try to recreate at least some of those details.
My home automation system has been working fairly well for a while now, though not without the occasional light obstinately refusing to turn off despite repeated requests for it to do so. This (I hope) is not so much an issue of any particular affinity for perverseness on the part of my lights but rather a weak radio signal coming from the transmitter I butchered whilst creating the system.
In its current state, this project also suffers from some other not entirely insignificant inconveniences. Firstly, while it's quite nice to be able to turn lights on and off remotely, there are times when it would be much nicer to simply flick a switch. One of the next phases of this project will be to investigate using some cheap 433mhz transceivers as the basis of a physical interface to the system.
There's also a small issue whereby my modem/router won't allow for connections to my external IP from within my local network. A very simple solution to this is to buy a new modem, though that feels too much like giving up to be truly viable. The current, not particularly elegant workaround is to run a local DNS so at least my phone would be directed to my server's internal IP whenever I'm home and connected to wifi. There's always a minute or two's delay while it sorts itself out after connecting to wifi and that's usually the very same minute or two I'd ordinarily like to spend turning on lights so I don't walk into things as I enter my house.
What I'd like to do, now that my web server is happy floating around in the cloud somewhere, is to have a low power server – in all likelihood a Raspberry Pi – as the bridge between the web frontend and the electronics that will drive the various components of the automation system. This not only provides an excellent excuse to play with my RasPi, but will also be quite energy efficient, and importantly means that the interface to which my phone connects will always be accessible via the same IP/domain name.
Whilst developing Dark Surrounds I have so far taken the approach of simply implementing new features as I see fit - not being overly concerned with performance. It has generally been fairly obvious when something is hideously bad (modelling water as hundreds of particles, each with their own physics-based interactions, proved somewhat infeasible), but beyond that, trying new ideas has been more important than being overly concerned with finding the best possible way to implement them. It has become apparent, however, upon testing a build on my (now somewhat antiquated) HTC Desire that three frames per second probably won't be acceptable to most players and that diverting some attention to efficiency may be warranted. It also seemed a good time to attempt to bring the file size down to something more reasonable than the ~100MB my attempts to date had yielded.