Today’s update is a quick one due to lack of time to work on the game, but it is a pretty good one!
I’ve implemented the hole mesh into the hole tile! Hurray! It also has a flag in it! Hurray x2! It also moves with the hole! Hurray x3!
You can see me creating a new hole and manipulating it below:
With this, you’ll be able to actually finish a hole by attempting to sink your putt. I’ll try and add collision to the flag mesh as well, allowing you to attempt to hit it.
Now, in the future I’ll also add the possibility to move the hole inside the green, so that you’ll be able to customize it further. Having it as a separate object will also improve accuracy of some measurements used in the game.
This system works better for attaching things to the tile than the ones I currently use for the trees and other decorations. So eventually I’ll migrate them to this one as well, and use it for anything else that is added to tiles. Accuracy++!
That’s it for today’s mini update! Stay tuned for more!
So just before sleep, decided to do a quick test to see how far I could push the new terrain system.
And well, very far.
The new system can handle a grid of 96 * 96 without any issue. That’s just under 10000 tiles. Of course, them using the same texture and all made it far easier. But still, that’s pretty badass.
Will run more benchmarks over the weekend, but this is very promising.
Today’s update is a bit of a detour on the plans, but a damn good one.
I’m still working on getting the multiple decoration sizes (1×1, 3×3, 5×5) to make your life easier when adding lots of decorations at once. Having to rework the selection system a bit, which is ok! That’s how we do things in Japan; we rebuild it until it is good.
Anywho, I also went ahead and added an awesome low poly water shader to the environment, to make those links look even more epic. And the results are awesome! Check it out:
You can see the waves hitting and crashing on the cliff, looks so cool! Shader still needs some tweaking when it comes to reflections and whatnot. Ideally it should be more opaque.
But it’s a first pass, and it looks great. I’ll also experiment with water tiles using the same shader, so that you can build some great looking ponds and rivers through your courses, to make your golfers extra happy!
That’s it for today’s update, folks! Stay tuned for more!
As expected, today I was able to finish implementing the new terrain system completely, and connected it to the GUI and everything. So as far as terrain editing/tile placing is concerned, we’re all good to go.
The decoration system is also quite a bit better in placing things, though can still be improved further if there’s a need for more separation between objects:
And I also went ahead, and updated the decoration system to make it match the tile underneath, adjusting as height changes:
It’s not 100% precise, due to the triangulation of the meshes. I’m thinking of looking into better triangle striping in the future, but that’s not a priority for now.
So with the new system in place, performance improved by a lot, and we can now create massive courses. Plus, I was able to re-engineer the architecture of the game to make it more modular and future proof!
Next step, reimplement the course building. Then it’s time for a new demo!
That’s all for today folks! Stay tuned for more!
Today’s update will be a quick one, as the task is still underway.
I decided to do some test to check the performance of the current system if we use larger terrain chunks. So far, all testing had been done on a 16×16 grid, and performance was fine.
So I decided to up the ante to 32 x 32, and the performance was bad…
There was a very notable dip below 60fps, and that’s not good. Not to mention this was just a barren terrain, and that is bad. I’m sure there could be some optimization done, but it still isn’t good enough.
So I decided to redo the tile system again (third time is the charm!), this way separating the terrain into chunks of 16×16 tiles, all contained inside a single mesh. (Chunks can be made up to near 64×64, due to Unity limitations regarding vertices in a mesh). As a test, I spawned 3 chunks of 32×64, and placed it all on the scene. This is roughly 6000 tiles on display, spread across 3 large meshes.
This is the result:
As you can see, the performance stayed at 70fps range, render thread was cut by 75%, cpu remained 4ms faster, much smaller number of shadow casters, batches, and a vastly greater number of verts and tris.
So I’ll need some time to adjusting the current system to match this. The generation itself is working fine, as is the UV mapping. But I’ll need to rework the shot system since it’s all under one big mesh collider. Some things will be vastly simplified, though. And the game will run better for it!
Stay tuned for more!
Woo! Great progress this weekend.
Finished with the basic implementation of the terrain raising/lowering controllers.
You can now edit the level at the vertex and the tile level. (which raises all surrounding vertices). Simply select the desired tool (per vertex/per tile), click and drag the desired tile; up increases height, down decreases height. Simple as can be:
Though that’s less a valid course as it is a trip through hell.
Now I gotta work on the stepping levels so that the course building is less insane. Though you’ll still be able to reach insane levels if you so desire. I also want to implement a controller for edges, and one for raising up the selected tile only, similar to what you can find in the Rollercoaster Tycoon of yore.
Next perhaps a flattening tool, and even the possibility of affecting multiple vertices/tiles at once. All should be straightforward to implement with the current system. But will be in the wishlist for now.
Til next time!
After wrestling with it, was able to replace the current tile system with the height-enabled terrain system. I still need to do some adjustments so that trees and other objects are also automatically placed, but I’m glad to get the thing working as it is:
You can see from the wireframe map that the shared vertices are also taken note of and raised together to avoid some bad geometry. Working on improving adding controls for manipulating the height of the map too!
However, one issued appeared:
Every square is it’s own separate mesh. Did it that way to have easier control/prototyping of the UV maps since each quad has it’s own easily accessible UV array. (If they were in a single mesh, it would be trickier to handle them, but not impossible).
So for some reason, there is a seam in between the each mesh, as you can see circled in red:
The cause of this is, I’m guessing, some imprecision regarding placement of the vertices and the processing of the graphics going bad at some point. Tomorrow I’ll experiment with using a single mesh and keeping track of UVs with structs or something, and see if this issue goes away.