Smooth Terrain Testing

Smooth Terrain Testing

Hello folks!

Talking to a player of the game, he gave me the feedback that he didn’t quite enjoy the landscaping because the current terrain system looked a bit too unrealistic. Plus the looks of it looked a bit odd depending on the lighting conditions: the light would reflect too strong in certain areas, not strong enough in others.

So I went ahead an prototyped a simple replacement for it. Basically, I added a Terrain object to the game, and am using the existing systems for processing the information, while setting the height of the terrain based on it.

The results are here:


I quite appreciate the smoothness of this terrain. With the proper texturing, it could look pretty sweet and clean. I’m studying how to apply the terrain textures to it (grass, gree, fairway etc), but since this has a decent support for normal maps too, it could add some much welcome depth to the terrain features.

It is, however, a trick. The mesh is still pretty much the same as it was before (at least at this stage), and you can see the difference when I turn on the wireframe mapping and some zones:


But the smooth shadow makes it look a lot nicer. Playing around with some height limitations, I could make the height tools affect nearby vertices as well, to give a smoother climb. There’s no performance loss either at this stage, which is great.

I’m gonna prototype how to apply the terrain textures to it, but I have a hunch it would allow me to more easily use higher-res tiles. And for the zones, I can just keep the current system as they work decently enough as an overlay.

Considering some changes to the planning aspect of it too, but that’s for later!

That’s all for this microupdate!


Miles and Miles and Miles

Miles and Miles and Miles

Hello folks!

Quick update on the implementation of the new terrain for Boss Golf!

Look at this:


That, my friends, is a massive terrain composed of a 20×20 grid of chunks, each chunk containing 16×16 tiles. That’s roughly 102400 tiles. All much more easily manageable, and with better performance than before. Now I can actually make the terrain surrounding the golf courses so that you no longer can peek at the end of the world!

As explained before, this new system relies more on preprocessing the grid data, so that alterations to vertices and UVs are much more quickly resolved than before. No more loops inside loops inside loops!

Just finished implementing the UV mapping to it, as well as the mapping of surrounding tiles and vertices. No seams when you move vertices between chunks. Already have some plans for new terrain tools too, to give you more possibilities when editing your golf resort course!

Next up is connecting it to the existing controls, and changing how the decoration system works so that placement is handled better and performance is improved.

Stay tuned!

Terrain Sculpting

Terrain Sculpting

Hello folks!

As I’ve said previously, while coming up with the concept and the systems for AI, I’ve also decided to rework a bit of the terrain features in order to make it smarter and improve performance.

So I’m almost done plugging in the new terrain system into the game. This time around, I went a bit smarter with my separation of concerns. The current system in the game features a breakdown of the mesh into tiles, quads, triangles, vertices, all controlled by a single TerrainController script which manages the actions on each tile.

It works ok, but it’s a bit overcomplicated in certain areas, and too simple in others. The point that really sticks out is when it has to update the mesh after any alteration is done to it.

Basically, it is currently rebuilding the vertice/triangle/UV list every time you do an alteration. This isn’t ideal, as it contains loops inside loops querying data that hasn’t been changed to find the ones that have been. Plus the current system is also less conducive to having multiple chunks and altering between them. It would be fine if we just stuck to one chunk and made it massive, but that’s not ideal specially if we want really massive levels and easier to manage data.

So, enter the new system! This time around, I have a SmartMesh class who holds the reference to the Mesh component itself, as well as a TerrainChunk component that holds it all together, managed by a TerrainBase class that can decide how many chunks will be spawned and the dimensions for each chunk. Reworking the input management as well means cleaner code and easier to expand. Most important is that all vertex data is held by TerrainVertice objects, which can be directly accessed either y the TerrainChunk or the SmartMesh. The SmartMesh also generates a mesh on startup of the position/index of each TerrainVertice. So what dos this mean?

It means that when a TerrainVertice is changed, it changes its position, and it tells the SmartMesh which index of the vertex list needs to be updated. This is done, and the new vertex list is assigned to the Mesh component. Hey presto; no more nasty loops within loops within loops!

Similar concept will be applied to UV and other aspects of the terrain. So the end result is a cleaner system that’s more manageable. I’ve also picked up more knowledge as I’ve progressed with development, and it has been ideal to implement it now.

Oh, and you’ll also be able to “sculpt” the terrain better, and I’m also reworking the height limitations of the course so you can have nicer features. Check out the simple demo below:


You’ll be able to “paint” the heights with the new tool. (Also keeping the old options too for those who prefer them). And since the vertices are easier to manage, I’m also updating the height limitations to give you more freedom to build taller things, and smoothing out the process: if you move a vertice too far above a threshold, the neighbouring vertices will also move up, creating a more organic flow.

I should be done with this work by the weekend. At the same time, I’m also implementing the AI system, so stay tuned for that too!

Tomorrow I’ll make a post about the memory system!

Have a nice day, folks!