Tag: indie

Dev Update #14: Money, Money, Money

Dev Update #14: Money, Money, Money

by Gus Martin ♥ 0 Leave a Comment

Heyo folks!

Thanks to those of you who tested the terrain demo and gave us your feedback! It was very useful!

Some takeaways:

-The function of the flatten tool isn’t well communicated. It is currently flattening the tile by the vertex closest to the pointer. Need to think of a way to communicate it better.

-Bigger brushes for decorations, so that you can place trees in a bigger area. This is on the list for tomorrow.

-Ability to paint terrain/decorations so that you can just drag and move the mouse around covering an area. This is something I’m still considering, as I’m expecting the gameplay to change once I make tiles cost money.

Which is what I just did. Today’s update is focused on the All Ighty Ollar. I mean, the almighty dollar! From now on, the tiles will cost a specific amount of money (whose value will change a lot as the game gets further in development), making you consider more the kind of course you wanna build. No way to get the money back yet, as that will require actual little golfers paying to play your course! But that will come next month.

I also added a simple bulldozer tool, which basically reverts the tile back to grass, removing any decorations it may have had. Also works with holes.

Only decoration and tiles cost money; removing tiles and moving the terrain doesn’t cost anything.

Here’s a sample course I made:

expensive_hole

As you can see up there, I ended up with $4,200 remaining after plotting that hole. Since I started at $21,000, this particular hole cost a whooping $16,900! Is that a lot? I don’t know! Price balancing will feature more on the demos from now on, and I’m happy to receive your feedback!

Thanks for reading!

Quirk #3: Shorter, but is it?!

Quirk #3: Shorter, but is it?!

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:

astarlol

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 #10: Base Shot Generation is Ok!

Dev Update #10: Base Shot Generation is Ok!

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:

baseShot

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 #10: Terrain controls good to go.

Dev Update #10: Terrain controls good to go.

by Gus Martin ♥ 0 Leave a Comment

Howdy!

Terrain controls are finalized! Created the displays for showing the vertice height to give you a better idea of the differences in your landscape. For this stage of the game, you can:

-Flatten the tile (to the value of the vertice nearest to the mouse pointer):

FlattenControl

-Edit the tile (by clicking and dragging the tile up and down with the mouse. It influences nearby tiles as well):

TileHeight

-Edit the vertice (by clicking and dragging the vertice up and down with the mouse. It influences nearby tiles as well):

VerticeControl

And as a bonus; since I added some thickness to the tiles, the current base shot generation function works mostly fine. But still need reworking. So that’s the next focus: Improve the base shot generation system. Also need to make it take terrain features into account.

With that out of the way, should be able to get a demo up for testing the terrain and course building, and implement the feedback. Once I’m happy enough with it, it’ll be time to add some golfers to the course!

Stay tuned for more!

 

Dev Update #9: The Hills are Solid

Dev Update #9: The Hills are Solid

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!

tilesolid

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!

Dev Update #8: Terrain Controls are In!

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:

terrainmagic2

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!

Dev Update #7: Auto Tiling FTW!

by Gus Martin ♥ 0 Leave a Comment

Howdy!

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

gridM

(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!

Dev Update #6: No more seams!

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!

noseam1

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

Dev Update #5: Implemented the new Terrain

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.

Dev Update #3: Automation and Refactoring

Dev Update #3: Automation and Refactoring

by Gus Martin ♥ 0 Leave a Comment

Heyo!

Today’s update is pretty much what I had announced on the previous update, plus some work moving certain methods to better locations in the code.

So now the base shot will be automatically updated as we modify the landscape surrounding the course. This will only work if the hole is closed, so that you can’t modify the hole as players are playing it. (This may be revised later if it proves to be more fun to allow you to grief the AI)

Also optimized the process by making the course cache the nearby tiles once the course is created, and then further process to calculate the base shot become a lot faster and cheaper since we don’t need to do raycasts every time we update. It also allowed me to add more precision by refining the raycasts and adding the neighbours of the tiles to the cache as well. Here’s some pictures explaining the process:

Start off by placing the Tee and the Hole tiles, the base shot is generated. No fairway, so it is happy to find a random grass tile somewhere:

hole01

Then I begin adding some fairway to the course. You can see the path change, and become incomplete. That tells you that this course isn’t really eligible for the public since it can’t find a proper Par without having to resort to landing on grass, and that is bad mkay.

hole02

On the next patch of fairway, the course becomes doable, as it can finally reach the hole:

hole03

Needs more challenge, though, so I add some bunkers here and there, and modify the overall base shot:

hole04

That’s more like it. That first stroke is treading dangerously near the bunker, which is great. So on to continuing my edit:

hole05

A short Par 5, which could easily be completed in 4 for a nice birdie, or even for an eagle if your chipping game is strong. Still could do with some adjustments here and there, but it’s a nice start. And all done dynamically, so I don’t need that “refresh” button anymore! Progress++!

Next step will be taking hazard into account when making the base shot. Now the function will only seek to land in fairway or green, which is what we want. But if there’s a tree in the way, it won’t care and draw the path right through it. That’s NG, as we say in Japan. This might be a stroke for a better golf player; but the par is calculated based on the handicap 0 player, who likely wouldn’t try such a risky move! So that’s the next issue to tackle on my list!

Hope you enjoyed the break down! Any questions/suggestions, don’t be afraid to comment!