I guess I’ve made quite a few updates to the Golf Mode of Goblin Rules Football since my last post. I mentioned dealing with the player going out of bounds, and preventing them from aiming out of bounds, and I did all that! I kind of forgot about it since I did it a while ago and didn’t make a post about it…
I’ll talk about the out-of-bounds stuff soon, but right now, I’m going to talk about the most recent thing I added, lightning! When there is rain, there will be a random chance for lightning to start in the area. Players would then be prompted with the choice to play on or skip their turn for a +1 stroke penalty. If they played on, there would be a chance the player could be struck by lightning, receiving a +10 stroke penalty, and forfeit the remainder of the hole.
The likelihood of being struck by lightning would be based on the distance of the storm to the players. The distance is indicated by the brightness of the flash, brighter meaner closer to the player. I will also add in later a “thunder” sound that will play after a delay from the flash based on distance (1 “mile” = 5 second delay). I don’t have it playing sound yet, instead just printing out to console when the sound would have started.
So, here’s a video where you see a player struck by lightning!
Wow! That’s a long video. Check out this picture of the skeleton
I tried to draw “real bones” but basically ended up just making random things white and random things black. I think the little guy looks cute, though.
The lightning “effect” is just a spot light that flashes on and off. To make the effect work, I also created a global light. Based on the weather, the global light intensity increases or decreases. Clear is full brightness, and heavy rain being the darkest. There can be no lightning if it’s clear, only if it is raining.
Enough about the lightning, out of bounds! I made it so the game prevents the player from aiming out of bounds
To do it, I have a virtual camera with a Cinemachine Camera Confiner 2d. This means there is a polygon collider that the camera is “contained” within. I reuse that polygon collider to be the “bounds” of the golf hole. When the player aims, I calculate what their new position would be, and then check if that point is within the bounds of the confiner collider with Collider2D.OverlapPoint(). If the new position was out of bounds, the game rejects it and the player can’t aim to that position.
Then I added detection to the ball to check if it landed out of bounds after a hit. Doing the same thing as above, check if its final position is within bounds through OverlapPoint(), and if so, mark the ball as out of bounds. If the ball is out of bounds, a ray will be cast from the final position toward the player, and returns the point it collides with the confiner collider. The ball is then moved along the line toward the player from the collision point a bit inward to give the ball space from the very edge. The player then gets a +1 stroke penalty, same as a water trap penalty.
I copied the material I used for my trajectory lines to make an out-of-bounds border. I needed a copy of the material because as a player aims and changes their trajectory, the material itself is updating its tiling value to increase/decrease the number of dashes. So, when the player changes aim, it also makes it look like the out-of-bounds border is moving. Anyway, that wasn’t really important to discuss.
You can also see the border when zoomed out! I don’t remember if I had that done in my last post…
To make the border I just put a line renderer on the virtual camera, had a script grab the points of the confiner collider from the Cinemachine.Confiner 2D component, and then draw a line around those points. It looks nice imo!!!
Oh, and one last thing that I did since my last post, there is a “two hole” demo of Goblin Rules Golf on itch!! Here is the link. The second hole is just a copy of the first hole, but the hole/flag location is moved to the left side of the green, and there are fewer trees.
When I was making my demo I had noticed that it took a while to load a new hole, and by a while I mean 4-5 seconds. Based on my testing it appeared to be from when I was clearing the ground tilemaps, which occurs at the start of loading a new hole before the new tiles are placed. The issue was that there were 10’s of thousands of “deep rough” tiles that had to be cleared. So, what I did was remove most of those deep rough tiles, keeping only the “edge” tiles that bordered other tile types, and then behind all the tiles created one large “sprite” object that would tile the deep rough tile. This made the clearing of tiles for a new hole happen much faster (basically instantly), and seemed to have no effect on the game itself either. It ran at it’s usual 400+ FPS for me.
Next Steps…
I think that’s all I’ve done since the last update? Idk. My next plan is that along with lightning I want to add in tornados that can occur in storms. They move between turns and if they collide with a player’s ball they hit it in a random direction. Players can avoid it by predicting the tornados path, and eventually I want some sort of ritual minigame to ward off bad weather and stuff.
Smell ya later, nerds!