Cleared out my blog - except for one entry. Decided that it was time to start afresh. This is going to be a dev-only blog from now on.

For the past couple of weeks I've been working on remakes of Sentinel and Archipelagos in Unity. Sentinel turned out to be quite a tricky game to write, not least because I have to go by YouTube videos as I've never played it. The feature of the two games is that the landscapes are pseudo randomly generated. Something I've never been confident with is level design. But both Sentinel and Archipelagos manage to create their levels on the fly. I've also realised that there are many games that create levels and data using pseudo-random generation.

The one I've known about for years is, of course, the original Elite. But if you have a game where there are seemingly endless levels then chances are there's pseudo-randomness going on. The beauty of pseudo-random generation is that you can create entire levels and worlds that look the same from game to game but take up very little memory.

Creating Sentinel's levels has been quite tricky and I haven't quite got it right yet. Archipelagos, on the other hand, has been much easier. However, I am cheating a little in that there won't be endless levels. The game's maps have been created randomly using a Perlin Noise generator. I put it onto a large 2D texture which was saved out into a .PNG file. I then opened it up into Photoshop and extracted some of the more interesting 'island' formations manually. These were then saved into their own 512 x 512 & 1024 x 1024 images.

The results haven't been ideal. Perlin noise tends to produce rounded and quite uniform hills and troughs. There's no jaggedness at all. However, it's probably good enough for now. If I can figure out a better way to generate the map then I'll do it later. The way the code has been written allows me to use any map, so long as it uses the same basic colours for the 'tiles'.

And this is another issue.

Originally the game was going to use tiled maps. That would be the obvious approach, right? The problem is that, at the moment at least, the largest texture size (the texture holding the 2D map of a level) is 1024 * 1024 pixels. If I was to convert the map to a set of polygons laid out in a tiled way, ​that would equate to over a million polygons! However, Unity works a little differently to some game engines in that it insists on turning polygons into triangles. Not sure if that's optimal for GPUs. It's useful if you've been too lazy to optimise a 3D model, but if you've optimised things into quads then Unity's way of handling polygons doesn't look too hot. Either way, in our case that equates to more than 2 million triangles. Not good - especially if you're aiming to target mobile devices. And with this remake, I am ... and in particular Gear VR.

So how to go about optimising it? Every tile has to be clickable. If I made every tile one of half a dozen coloured planes then I could attach a trigger to each one. That would be the simplest way to do it.

But no ... too much stress on the GPU.


The solution was to use a single large plane and place the texture map onto it. The main problem then was to convert the coordinate systems. The plane would use a 3D coordinate system with the centre being 0, 0, 0. The 2D texture map's zero location is at the top left [No. No it isn't. See the entry further up]. I was trying to place objects using a pseudo-random generator but they weren't locating properly. Took me a good few hours to realise what I was doing wrong ... I wasn't taking into account the different coordinate systems. Stupid! Stupid! Stupid!

After writing a couple of 2D/3D conversion methods in my C# code, it worked like a charm [again. No it didn't. It looked like it was but Unity's 2D texture coordinate layout was screwing things up for me]. I was able to get objects to place on each level properly without any manual input from me. All thanks to pseudo-random number generation. And it would work exactly the same way every time the game was run.

Another beauty of the way the system works is that to change the colour of a 'tile' (remember, the tiles aren't actually polygons), I need to just change the colour of the appropriate pixel in the level's texture map. In Archipelagos, the trees spread infection across the land. When a tree changes position, I just have to get the tree's new location, convert it to 2D coordinates and change the colour of the pixel the tree is now on. It's a lot less work for a mobile GPU than having to handle more than a million polygons.

I'll stick up some in development screenshots in my next post.