MiniGolf Creation Blog (revisited)

So, last year I was tried to make a simple MiniGolf game with Unity for my 1gameAmonth challenge.
But, i definetly bit off more than I could chew, especially trying to get it done within a month.

I have decided to look back at this and start from the ground up and write about it as I go, Hopefully as you read, you might pick up something of use to yourselves, or if you see me approaching something strangely, please let me know as this will be writing as I go, so any improvements or changes to workflow, ideas would be greatly appreciated.

I will try and do my best to push all the repo commits to Github after I work on it each day I can.


I did start this last week when I had downtime at work, and due to the severe lack or artistic talent on my behalf I employed the might of MS Paint for sketches :slight_smile:

20/03/17 (1 Hour Spent)

Ok so I have an idea, I want to make a MiniGolf game within Unity! Where the heck do I start??
Aim low and functional for a start, all the art and tweaks etc can come later, long as I get core gameplay and mechanics right.

Thinking out loud
just from a prototype standpoint to get something in there that I can mess around with. But I dont want to go through all the hassle of making assets, if ive not thought about how I might use them down the line.
Firstly I was thinking that I want the course to be of a modular nature so that I can build levels relatively quick within the editor. So do I want it all to be on one level (flat) or do I want to put hills in it? Think I do want some hills to hit the ball up, as a totally flat course would be a bit boring.
So if I want it to be modular I will have to make each section easy to click together.
If I say each course ‘module’ will fit in the part of a grid so that they can be put in and be sure that they will fit together. That will definetly make it easier to construct.
Question: how am I going to handle the ups and downs of it, like putting in slopes etc?
Thought: well, what if I say that each of the grid positions could have 4 different heights to choose from to place the course part on, like the following


21/03/17 (2 Hours)

So ive made a couple of test pieces in blender, each 1x1x0.25, and ive set the proper transforms on them.

They seem to be going together half decently and all line up if they are 0.25 in height apart.
So ive exported these to FBX individually and put them into a Unity layout test scene to see how they looked, and added a mesh collider to each section and also prefabed them too as prototype parts.

Quite happy with that, I did notice that the import settings were a 1 to 1 scale.
I applied transforms in blender to 1, exported the FBX with a 1 scale. When importing to unity they have an absolute scale of 100, need to go back and see whats up with that. Think ive forgotten something. Still looks ok tho., so that will do me for tonight I think.


22/03/17 (1 Hour Spent)

So my next piece of the puzzle, I think will have to be the ball.
I think today I will have a look at how im going to get the direction to hit the ball in.
Im thinking of just using a simple arrow sprite for a direction indicator. And use raycasting to get the direction. See how that pans out over the day.
Made a little arrow in Paint.NET and exported as a PNG, then imported that into unity as a 2D sprite.

Ive put a new ball (just a unity primitive with a scale of 0.1) in the scene to test size (phew hard part done lol). I think for a sort of fun and not too serious look, this appears about right size wise.
If you look at the hierarchy there for the GolfBall, ive added a child empty ‘AimPointer’ this has the ‘Arrow Sprite’ as a child to it. Just to see how it looks. Not sure how im going to use this ‘Aim Pointer’ yet. If I leave it there, its going to just tumble around when the ball rotates since at this point the balls stationary. See how it goes later.

Though: well the ball will be stationary when taking a shot, so it might not matter too much, as its not going to be there when the ball starts rolling just need to make sure it ?? and when the ball is stationary it will be visible and always pointing in a direction . hmm
Need to have a think, either leave it there, or try and lock the rotation to just the Z axis, but don’t know how that’s going to work on a child object… but that’s for another day :slight_smile:


29/03/17 (2 Hour Spent)

The first order of today after housework and a coffee, is getting my mouse input to try and get the firing direction and have the arrow point to where the mouse is at.
I could try and raycast to the parts of the course, but, there may be times where I don’t want to apply a direction at an angle other than on the horizontal. It would also cause issues if the mouse pointer wasn’t always over a part of the course. So ill remove that out of the equation and just use a ground plane.
The only other thing that I might have to think about later on is if the ball is at the bottom of a slope.

do I apply the force in the B, direction or just stick to A to make things simpler and use the same throughout.
If it causes any issues once I get a prototype done, then I’ll have to look over it again and rethink, but for now, ill stick with the horizontal as the force direction.
Ive done something similar in the past with raycasting where a plane is drawn through the player and I get the hitpoint of the ray, like below.

Where I want to find a point on the same Y plane as the ball, and then have whatever im using as a visual pointer look towards it.
Now what I want is this plane to always be straight through the centre of the ball and the plane always horizontal.

Before I go finding out how to rotate anywhere, I need something to rotate.
So heres what im using, and ill explain why and what I was thinking about.

So GolfBall is the main ball and that’s going to do all the rolling about etc.
Ive added a child empty, AimPointer, this is the one that im going to rotate around, so it doesn’t affect how the ball behaves. Not much good in having an empty with nowt in it.
So ive made a little arrow in Paint, and imported and set to a sprite, and added this sprite as a child to AimPointer. Now ive orientated the arrow sprite to point in the same direction as the Z axis of the AimPointer.
Reason? Well, once I find the direction with raycasting, I can use Transform.LookAt() to rotate the AimPointer. And using that lookat(), it always points the forward Z axis to the target, hence the reason the arrow sprite is rotated to point down the Z axis of the AimPointer object. And it wont affect how the ball rotates in case of dodgy physics behaviour.

And to answer another question I had, surely as the ball rolls it will affect the rotation of the arrow?
But, no, not really… because A: the ball will not be rolling when the arrow is visible. And B: the arrow will always be facing towards the mouse pointers raycasted point on the plane so it will always have the normal facing upwards, and the Z axis pointing towards the mouse each frame.

The raycasting bit was ok, the problem I had was how to get the plane to be at the same Y height as the ball and what size to make it, and generally how to draw it.
Well looking at the docs for Plane and how to create one programmatically
Scripting Reference for Plane

Its as clear as mud on first read, with the constructors

Plane(Vector3 inNormal, Vector3 inPoint)
Plane(Vector3 inNormal, float d)
Plane(Vector3 a, Vector3 b, Vector3 c)

I didn’t have a clue what the first lot were the first time, so I went with the the 3 vector points, and created points around the golfball, to what I thought was creating a plane at that size with the corners I specified for the 3 vectors. But testing it it seemed to work no matter how far away I put the mouse.
So I started with this

    Plane groundPlane = new Plane(
        // just need to declare 3 corner points to create the plane, as it iterpolates the 4th corner.
        // doing it this way, creates the plane dead centre of the ball, JUST REMEMBER CW winding for normal.
        new Vector3(transform.position.x + 1f, transform.position.y, transform.position.z-1f),
        new Vector3(transform.position.x - 1f, transform.position.y, transform.position.z-1f),
        new Vector3(transform.position.x + 1f, transform.position.y, transform.position.z+1f)); 

But after more readingup, I read the part again at the top of the scripting ref, where it said that the plane was infinite size, so the 3 point method I used just basically declared its position and normal direction size was arbitrary.
Back to the scripting reference page for another read once I understood it a bit more and ended up realising I could use this instead

Plane groundPlane = new Plane(Vector3.up, transform.position);

Big difference, a lot more readable and a lot more compacted.
But all that messing about and reading took about an hour to suss out.
The rest of the code was fairly straight forward (grabbed a reference to the AimArrowSprite to use for lookat ) so used the following
(excerpt, full code in repo)

// used for raycasting out, logs hit distance
float rayDistance;
if(groundPlane.Raycast(ray, out rayDistance))
    Vector3 point = ray.GetPoint(rayDistance);
    // so i can see the ray
    Debug.DrawLine(ray.origin, point,;
    // since the plane is at same Y level as ball, set the aim arrow to look at the hit point. 
    // (always uses the transforms local forward vector, this way the arrow is always flat)

Works well, so tomorrows job, get the ball to move, and switch on and off the targeting arrow when (if) the ball moves and comes to rest


30/03/17 (3 Hour Spent) (refactoring, what a mess)
Ok firstly to get a more complete test area ive created another couple of blender models for a Tee and a Hole and imported them into Unity. Didn’t take more than half hour to do so that’s cool.

Ok, so as a side thought, need to think about how im going to tie in together the controllers that will look after the Aiming, firing and states (whether stationary, moving, fired etc)
Im just going to go with a point n clik to fire at present, as this should give me enough to work on probably for a couple of days to get physics movement collision working and looking like it should.
Its going to be a bit of a process of trial and error and funky math possibly…
into the rabbit hole we go!!
Ive had a tidy up and a rethink of the Golf Ball and how I will interact with it, I do want the ball to be as self contained as possible, but I want a Controller script for the ball to handle the striking force etc. to be applied, and to track game state and leave the ball as much as possible to handle itself.
Ill refactor and have the ball controller call methods on the GolfBall, and have it handle any instructions down to the aim arrow.
Should have done this already, getting carried away about getting things done easily, I have to say for each new thing that I want to happen “WHO / WHAT SHOULD BE IN CHARGE OF HANDLING IT”.
Wow this took me near two hours to do, definitely PLAN AHEAD, AND PLAN WELL!!
Get thinking about what will be controlling what and work from there, and keep methods tight and focused.
Updated REPO with new and more organised code for the GolfBall, and the Ball controller.
Will be tomorrow now before I look at the ball physics and movement etc. ah well.


man, getting a ball to roll correctly after an initial linear force is a right mare!

ive spent a couple of hours doodling on paper and trying to theroise the physics involved with linear and angular forces to get a picture in my head of the actual problem before i can move forward.

im my head, if i cant understand the problem, there isnt much hope of coming up with a solution.
So ill post my doodles tomorrow since its getting a bit late (11:30pm UK)

this is one of the key mechanics that hindered my progres with the first iteration of this project and I really want to understand the issues underlying it as it seems quite a common issue with most projects and see that just fudge a solution out there that doesnt quite feel right.

so once I understand the problem, I may, either go the way of sorting the physics correctly, or emulate it with raycasting for a more energy efficient solution that will bring its own problems to the table.

need to get this down before I can move forward really. yawn tomorrows job!


in my usual morning procrastination, i fired up youtube…

thought I would go searching for some rolling ball firing physics stuff, but ended up finding this little gem on Quill18Creates. now this is from one of his ludum dare pinball games. but it will be ideal for my minigolf holes.

the premise is that there is a hole object, a depth test object and a box/mesh for the table top.
and with this the hole can be placed anywhere on the surface and rendered accordingly, will save alot of time having to remodel the course part that has a boolean cutout in it. no dodgy meshes and quick iteration and placement time. ill come back to this once ive sorted the ball rolling colliding stuff.

1 Like

oo, been messing about with OBS and youchoob, so might do a quick stream test while messing about this evening just to test.

if it works i might just record each time i intend to sit more than an hour working on it.


Hey Daz, quite nice what you are putting together here! I’ve bookmarked it to make sure to see the updates on this game, looking forward to seeing it ready!
Nice solution regarding the holes by the way!

What’s your channel address?

I havent added anything yet James just a couple of private test recordings to try and get the quality right, theres a bit of tweaking to do.

going to order a heaset / mic this week since the internal laptop ones a bit pants. and got to read through all the howtos etc. and setup a new channel to my may account to store all the vids.

thought it might be a bit of a double edged sword where I can have video diaries, and any video help clips.

back offshore this afternoon, so wont get decent internet till I get back next wednesday.

going to have a proper test that weekend, could be a handy tool.

Once i get branding etc drawn up and uploaded, should be here

this is one of the issues that I have to try and resolve this week when Im away

its quite a common one, but theres no real simple solution that ive found as yet.
but as this little gremlin will make the modular approach unworkable, I need to find a viable solution.

and since my internet is rubbish offshore ill have loads of time in the evenings to tinker about. If i do get anything it will help everyone who has hit this showstopper of a snag.

1 Like

Have you tried to increase the collider beyond the mesh? Perhaps if they overlap each other (with collision off between them) it won’t happen.

Subbed :slight_smile: Good luck with it.

That was one solution that Unity recommended to try. Seemingly it happens but not as much.

Ive just got to think how adding the extra will affect the modularity, but should be ok for the simple design ive went for. Ill try it tomorrow night and see.

Since 5.5 no longer has the penetration penalty in physics it can no longer be 0, so that ideas out the window. There was another thought that gravity and physics timesteps were battling a bit whereby gravity would pull ball down before the collision test.

If all else fails i might try a small raycast down and keep the ball off the ground ever so slightly but keep physics to handle bounce/gravity and the drag. Only downside to that would be having to create a slightly oversized collider out of ground to handle things like sand. So increase drag on enter, then put back to normal on exit…

Ill have a test with that overlap tomorrow night when i finish work tho see how it goes

1 Like

I don’t think it would be a problem, if you overlaps just a little it shouldn’t effect anything else, you can overlaps just one side of the modules too (probably the front so you don’t have peoblems with ramps). Even thought it could be a problem with inverse ramps, ehh… :frowning:

Actually the ramps might not even need because lf the momentum :smile:

I’m curious to see how you will solve this :joy:

Are you using a single concave meshcollider for each section? Could you try using one convex collider for the green section and others for the brown? As I understand it, concave colliders are prone to “weirdness”.

1 Like

Thats one thing i did change but didnt have time to test.
I originally had each section as one mesh. But i realised that i needed separete meshes for the walls and grass which ive put under an empty parent in blender. As i have to have different physics materials for walls and grass.
This way i can make the grass convex and split walls into separate convex colliders. The initial single mesh if i made it convex the entire thing was one box collider with the top spanning across wall to wall. Bit of an oversight on my part, but thats the benefit of quickish prototype and iteration which mikey and ben try to get across and i see the benefit of :slight_smile:

Once its all nailed down i can spent a bit more time on cosmetics.


so my current major issue to overcome is this.

ive turned gravity and mass down just to better illustrate.

I could just create one mesh for the entire grass area… but I eventually want it modular to create an editor.
tried several things to get round it to no avail. so ive gone down the road of grabbing each section of the grass mesh and childing to a new object, say “Hole_1”, grabbing each mesh component of each grass object, combine to a single temp mesh and simplify by rearranging the vertices that are within a certain tiny difference of each other.
then I take that mesh, create a mesh filter and mesh collider component on the new “Hole_1”.
then assign the filter the new mesh, and base the mesh collider on it.
now I have a custom mesh rendered with a custom collider, I can now serialise this and store as a Hole_XX asset for reuse.

well thats the plan, im just at the rearranging vertices stage. man theres alot to it, and alot of reading.
struggling getting the time to research and implement while im out at work.

If I get it sussed, once I get home ill create a vid that walks through the process end to end as if it works it could be handy.

1 Like

Privacy & Terms