Last month I published the first iteration of minigolf, this was put together over the course of a week was a very barebones minigolf game. A number of holes, a ball and a 'manager' to handle state.  

From the start I really wanted the ball to be a physics object, to me it felt like it would make the game easier to develop and feel better for players. A win win, let the engine do the hard work.

Work got started, I opted to use a tile set for my geometry; drag in some prefabs, make a minigolf course. Repeat. Nice.

Unfortunately I started experiencing ghost collisions where sometimes the ball would hitch when rolling over the edge of a tile and onto the next. Not acceptable for a game where precision rolling a ball is important, I reluctantly swapped to using traces.

I tied up the loose ends and published to get some early feedback. The initial feedback was OK, however I knew when publishing that the game was quite hollow.

s&box is the perfect party game platform. Hop on with some friends, jump right into a game and hopefully have fun. 

I made minigolf with this in mind, join the game and you're immediately playing - no fussing about in menus.

Everything should be working as expected, please let me know if you're experiencing any issues. 

Layla mentioned that staging had some ghost collision fixes and that as long as the surfaces were a single mesh collider people shouldn't be experiencing them. This led me to have a bit of a eureka moment.

s&box has a way to grab vertices and indices from models at runtime. What if I just grab these from each of my tiles, bundle them up and just make a unified collision mesh at runtime?

The result:

Is this the correct approach? I don't know. Does it work? Yep.

This was a good moment for me, I could now add physics to my balls again without having to worry about people complaining about ghost collisions.

A lovely reviewer mentioned that my courses needed more variation, I agreed but was hesitant to do so until other things were a bit more set in stone. I now know what I can and can't do, the physics simulation works great. I can add some life.

I've put together a small base set of obstacles that will allow me to start adding variation to courses.

Any good minigolf game has water, or lava, or something else that forms an integral part of the course. It's there to piss you off when you fall in it.

I think the s&box ecosystem is good and that games on the platform should make a reasonable effort to support the cosmetics system provided.

I wanted to add hats anyway so this wasn't too far of a stretch for me. In the cosmetics menu you'll have the option to wear the hat your s&box avatar is currently wearing.

A select few trails and ball skins are also available in the cosmetics menu. Thanks to whoever made the skins.

Bonus: If you play any time during October you'll unlock a Halloween themed skin & trail.

The holes that shipped with the game in September were all a little bit on the small side, this isn't necessarily bad but in order to take advantage of everything I've been working on the courses need to be a little bit bigger.

When you start a game a number of holes are randomly selected for you and your friends to play through, I've added another 10 holes this month. I've reworked some of the older, boring holes too.

I think this one is quite fun

Achievements are a great way to satisfy players and retain an existing player base. This month I've added a handful, some of them unlock cosmetics.

I wanted some cosmetics to be locked behind achievement unlocks, I've managed to do that but my implementation is a bit finicky and unresponsive to achievement progress.

Achievements can be accessed through Achievements.All, however without digging too far into it this appears to be cached and only updates when the player first joins a game. It'd be great if I could fetch achievements and their progress whenever I wanted, similarly to stats. Currently I achieve the below by updating the relevant stats, waiting for the OK, fetching the package manually with Package.FetchAsync and then providing feedback (below) to the player - it doesn't feel nice.

Nonetheless, it works.

After playing each hole for the first time you will be prompted to give it a thumbs up or thumbs down, I'm hoping this will give me an insight into what people like/don't like and I can use this knowledge to help shape future holes.