Tag: gamedev

Dev Update #19: Blocky Waterfalls?

Dev Update #19: Blocky Waterfalls?

by Gus Martin ♥ 0 Leave a Comment

Heyo!

Today’s update is more a question rather than a proper update.

I’ve been working on the water implementation to make it less… Crazy noisy. Right now it just takes the shape of the original land tile; you could end up with crazy heights in certain locations of a lake, which looked quite cool but also quite odd.

So I attempted to make the water more level so that there could be waterfalls and stuff.

However, it doesn’t look quite there yet… This is what I came up with:

waterfall_test_base

The water is level in some areas, with a straight fall downwards. Which isn’t bad, but looks odd specially in places like the left side fall. Some of this could be fixed with some particles and effects, like my sketch below:

waterfall_test

With some good particle work, I’m sure it could work but… Hmm… It feels too blocky. Since the terrain is less “voxel” and more “low-poly”, the procedural water mesh would need a lot of work to make it work consistently in this.

However, as I write this post, a potential solution came to me. I could simply make the water default to the base water level (or lower, if the terrain goes below base water level), and then add specialized waterworks tool, so that you could add some special decorations to the water; floating plants, waterfalls etc. This would indubitably be much easier to implement than getting a procedural thing that works well.

So I guess I’ll go with that!

Man explaining things really help you come up with solutions! Cheers folks!

-Gus

Dev Update #18: Playing with Water

Dev Update #18: Playing with Water

by Gus Martin ♥ 0 Leave a Comment

Hello  folks!

For today’s update, we’ll talk about water!

I have implemented the feature to allow you to build rivers/lakes along your golf course! Woohoo!

Just have a couple of kinks to iron out ahead of tomorrow’s demo, but it will be fine. Here’s something I built with it:

lake_hole

Still have to decide how to work with the water level and whatnot. Should the tile be flattened first? Shoul the water descent to a specific level? Or is it fine to have it all undulating surrealistically? Not sure yet! That’s what tomorrow’s demo will be for!

Stay tuned for more!

-Gus

Dev Update #16: Improving control!

Dev Update #16: Improving control!

by Gus Martin ♥ 0 Leave a Comment

Heyo folks!

One of the highly requested feedback from our terrain demo was the ability to place several tiles/decoration at once.

So, I did it. Delegated the selection handling to a separate class, so I can do more awesome things with the selection options, and it worked flawlessly right off the bat.

Here you can see me building my course with multiple tiles at once:

terrainTool

And then adding multiple trees in one go, and increasing their amount as well:

decorationTool

For the height, it will be tricky. Maybe for that, I’ll just make different size brushes and use them. I’ll give it a test tomorrow, and see how it goes.

This weekend there’ll be a new demo with the new terrain editing tools, money, and water.

Oh! One thing to note is that the game will allow you to build things even if you have no money. This is something I had to think about as there were really three possibilities for area placement:

-Cancel placement if you don’t have enough money

-Place as many as your money will allow

-Place everything, and put you in the red if need be

I decided to go with the third option, so that you will have to be careful about how you place your terrain, and make the decision to go into the red if you want. (Be careful to not drown in debt!)

That’s it for today’s update! Please do let us know if you have any comments or feedback!

-Gus

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!

Dev Update #13: All connected! (Save for the golf course)

Dev Update #13: All connected! (Save for the golf course)

by Gus Martin ♥ 0 Leave a Comment

Hello folks!

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.

finished_implement

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:

treePlacing

And I also went ahead, and updated the decoration system to make it match the tile underneath, adjusting as height changes:

treeHeightening

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!

Dev Update #12: Chunk Terrain is Connected

Dev Update #12: Chunk Terrain is Connected

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!

implementedTerrain

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

Quickie: Going Chunky

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…

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:

good

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

Quirk #2: Stupid isn’t good either

Quirk #2: Stupid isn’t good either

by Gus Martin ♥ 0 Leave a Comment

For today’s Quirk, it’s an attempt to fix the greed issue on the base shot function. I added one simply look ahead step to ensure that the current maximum has at least one option going forward, so that the function doesn’t settle on a tile with no good moves.

It worked, to an extent. As you can see below:

greedisbetter

So while it does avoid certain obstacles, it ends up taking too many strokes to do so. Issue is also with the obstacle detection: if the line of a stroke so much as brush through a tree tile, for example, that stroke is completely discarded in favor of something else. I’ll add now a function to analyze the angle between the potential stroke and the center of the hazard, and allow it to pass through if the angle is large enough.

With that in place, in the example above, it could easily reduce 2 strokes off the base shot, making it more acceptable. (This is a Par 4 hole based on distance).

Here’s hoping that the third time is the charm!