Endless procedural terrain
Posted almost 4 years ago by Ed Bassett
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.
Have your say
New comment
Another ewe for Android
Posted almost 4 years ago by Ed Bassett
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.
Have your say
Leave a comment --->
New comment
Where to from here?
Posted over 4 years ago by Ed Bassett
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.
Have your say
Leave a comment --->
New comment
The trees
Posted over 4 years ago by Ed Bassett
Trees have been an important part of both the visuals and the gameplay of Dark Surrounds since its inception at the 2012 Global Game Jam. While the green trees looked reasonable enough – albeit in a cartoony sort of way – those without leaves looked like a poorly designed umbrella after a strong gust of wind. I'm not sure they were even recognisable as trees; clearly something needed to be done. So I sat down with blender and subdivided and extruded away until I had something more closely resembling a tree but still a very long way from something I'd be happy with.
By hand
Modelling that one tree had taken longer than it reasonably should have done – and no doubt I'd get much faster as I modelled more – but knowing that I didn't want all the trees looking the same, I reasoned my time might be better spent writing code to procedurally generate a limitless selection of trees. That would also have the advantage that I'd be able to very easily make changes to all the trees as the art style for the game developed.procedural generation
Creating trees with code is hard. Creating meshes procedurally is relatively straightforward, a few vertices here and there, a couple of triangles between them and suddenly there's something floating around in 3D on screen that you haven't had to model by hand. Normals, UVs, tangents and such are a little bit more work, but still nothing too strenuous. Trees though... they branch... and branching complicates everything. And it's not just that they branch, but when they do, they might branch into two, three or really any number of branches, and each of those might come off the main branch at a different angle, be of a different thickness and extend for longer before branching again. Some branch quite evenly, essentially just dividing in two again and again until finally giving up and making a leaf instead. Others have a thick trunk, from which only small branches protrude. The more you look at actual real life trees, the more you realise just how many ways they can vary and the subtle details that compound upon one another to make one species completely different from the next.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.
Really, really hard
The most challenging problem in developing all this has proved to be texturing, and it's one I haven't yet solved. Texturing is a bit like wrapping a Birthday present: you start with a flat piece of paper and fold it around whatever you're wrapping until you have a beautifully wrapped gift... and a horrible mess of tape and odd folds on the bottom. Which is really what you're aiming for when texturing; hide all the weirdness and joins somewhere it won't matter. Texturing things by hand affords the opportunity to tweak things along the way whenever something looks a bit odd. With these trees, however, I'd very much like not to have to intervene. And so texturing has become the next major challenge I'll need to overcome as I develop the trees further.Have your say
Leave a comment --->
New comment
Automatic raspberries
Posted over 4 years ago by Ed Bassett
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.
Have your say
Leave a comment --->
New comment
Optimising things
Posted over 4 years ago by Ed Bassett
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.
More frames!
A logical place to begin is with the trees. There are many of them, and each has thousands of vertices, tens of thousands of tris, and sways in the breeze. Swaying trees are lovely, but do come at a cost when each of those vertices' locations are being animated every frame. For the moment - at least for mobile - swaying trees are out.Fewer bits
When I first built Dark Surrounds for Android, I'm not sure I even looked at the file size; I was really just elated that I suddenly had it running on a mobile with such little effort. However, if ever people are to actually play the game they must first download it, and at around 100MB I can't imagine many being willing to do so.What actually makes all the difference
Have your say
Leave a comment --->
New comment
A solid first attempt at some trees
Modelling by hand
Procedurally generated... getting better
Leave a comment --->