Quirk #3: Shorter, but is it?!

August 19, 2017 by Gus Martin ♥ 0 Leave a Comment

Hello folks!

In the process of today’s update, I came upon an interesting quirk when using grids.

I have finished implementing the hole creation in the new terrain, works like a treat. Now I’m in the process of processing the tiles in between the hole and the tee, so it can make calculations regarding base shot, par, actually distance etc.

Using A* to find the shortest path between the hole and the tee, leads to some interesting visuals:

Above, the path traced by A* is marked with black spheres. The drawn red line shows the actual shortest path (a straight line) between the two points. When in a grid, the path marked by A* does signify the shortest path between two certain points in the grid. It can be set to ignore diagonal traversals, or to allow them (as is the case of Boss Golf).

Visually, though, it looks so quirky. To us, it’s clear to see that the shortest path is the line between the start and the finish. To the game, though, the shortest path ends up creating these doglegs all over the course.

That’s all! Almost done with the processing of the base shot, coupled with a lot of refactoring and reinforcement. Once it’s done, it’s demo time!

Stay tuned!

Dev Update #12: Chunk Terrain is Connected

August 17, 2017 by Gus Martin ♥ 0 Leave a Comment

Hey folks!

Today’s update will be a short one, but it is a good one: I’ve finished replacing the existing terrain system with the newer chunkier one!

And took the time to begin redoing other hastily designed systems for more solid ones, improving performance and maintenance as well. By the weekend, I’ll have it back to full functionality with improvements. And a new demo for playing around with the terrain!

Stay tuned!

Quickie: Going Chunky

August 16, 2017 by Gus Martin ♥ 0 Leave a Comment

Hey folks,

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!

Dev Update #11: Procedural Tree Placement!

August 15, 2017August 15, 2017 by Gus Martin ♥ 0 Leave a Comment

Hello folks!

Today’s update is an awesome one.

If you’ve been following us so far, you’ve noticed that all our tree placement looks rather… Mechanical. One tree per tile. That’s just not how nature intended. We should do something about it.

And we did. Look at this barren course:

It needs trees.

So we give it trees:

Wow look at that! Beautiful procedurally placed trees, make the course look much prettier and breaks the monotony of single placed trees! Hurray!

But how?

Well with the new system! It will attempt to add a tree to a desired tile. If there’s already a tree, it simply adds to it, and jumbles up their positioning. A maximum of 4 trees can be added to any tile. Here’s the feature in action:

As a bonus, if you’ve reached the limit of 4 trees, and you try to place another one, it will simply randomize the positioning of the trees. This way you can keep playing around with the tile until the RNG gods smile upon you!

Next is ensuring the trees stay in location when you modify the terrain!

Til next time!

Dev Update #10: Base Shot Generation is Ok!

August 14, 2017 by Gus Martin ♥ 0 Leave a Comment

Heyo folks!

Finally fixed the base shot generation. Since it’s simply a guideline, it doesn’t really care about the sloping of the course: all it cares about is that there’s no direct obstacle in front of the shot! Technically, this is already an upgrade if compared to SimGolf since in SimGolf there were many instances where it would attempt to mark the course by going through trees or rocks!

Below you can see the course path being automatically edited to account for removal of valid tiles:

That pretty much covers the basic shot generation. Great success!

I’ve already implemented utility functions for calculating the usefulness of aiming at a certain tile. With this update to the basic shot generation, I can move forward on finalizing the spawning of certain objects when painting the terrain (ie: trees) and create a basic demo for testing the terrain building. If you’re interested in trying it out, give me a shout!

Stay tuned for the next update!

Dev Update #9: The Hills are Solid

August 13, 2017August 13, 2017 by Gus Martin ♥ 0 Leave a Comment

Heyo folks!

I’ve just finished tweaking the mesh generation to make the terrain solid. Instead of being a simple flat mesh, each tile is a cube of sorts, portraying the underground level of the course. Looks much nicer!

I’ve also tweaked the terrain controls so that the stepping is smoother, in this way you won’t accidentally create a massive hill when editing your course. (Unless you really want to!)

Now it’s time to finish up the terrain controls! Stay tuned!

Dev Update #8: Terrain Controls are In!

August 12, 2017 by Gus Martin ♥ 0 Leave a Comment

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!

Dev Update #7: Auto Tiling FTW!

August 12, 2017August 12, 2017 by Gus Martin ♥ 0 Leave a Comment

Howdy!

Finished implementing a basic 4-bit auto tiling system using bitmasking. Works like a treat!

(You can find some helpful resource on using bitmasks for auto tiling here and here.)

It has been implemented so far for the fairway, for the bunker, and for the green. Going to draw up the tiles for the trees next, and integrate the hole with the green. Next is height controllers!

Dev Update #6: No more seams!

August 12, 2017 by Gus Martin ♥ 0 Leave a Comment

Good news!

Contrary to what I was speculating, the issue with the seams turned out to be simply the bleeding from the textures. It always ended up sampling at least one pixel from the adjacent texture too.

So, the fix turned out to be an easy one: rearrange the tiles inside the texture so that they are always bordered by affinity. And seams are gone!

I’ve also increased the tile size to 32×32, so I can add in more detail later if so desired. Now two things to finish off the basic implementation of the new terrain:

-Make it so the tile chooses the correct texture to display based on its neighbours

-Add controls for changing the height of the vertices

After tackling those two, I’ll need to take a new look at the shot creation system, since before it was relying on raycasts for some things still. Either change the system from raycasts to simply analyzing the grid, which could be cheaper, or turn the flat tiles into cubes so that it has a proper volume. That’s for later!

Dev Update #5: Implemented the new Terrain

August 11, 2017 by Gus Martin ♥ 0 Leave a Comment

Heyo!

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:

heightmapped

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:

gridstuff

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.

Boss Golf

Golf Management Game

Tag: programming