Making a Game in Unity 011: Tying Up Loose Ends

Just so you know, this is not a tutorial series! I am writing this series mainly to give you a behind the scenes look at the process of making a game in Unity, and to document the development of this project.

See other posts in this series.

Making a game in Unity 011

I didn’t have time to get as much done as I would have liked over the last two weeks, but I did manage to tie up some loose ends. I finished up cannons and their shooting functionality, and I finally sorted out the character controller. There’s obviously still some fine-tuning I need to do, but I no longer have to directly apply velocities.


Today I added the positioning code necessary to spawn cannonballs in the right location, which led me to discover an issue with my transform system. I also finished editing the last progress update post, since I wasn’t able to get that done yesterday (Mother’s Day).


This morning I found and fixed the problem with the transform system. The issue was that I had been adding the Quaternion rotations of parent objects and their children together instead of multiplying them. It wasn’t noticeable with just one level of children, but once there were several layers, the effect stacked and became very obvious.

Later in the afternoon, I added the ability to aim cannons. The next step will to be to implement the ability to shoot cannonballs.


Today I added the shooting functionality for the cannons. Currently, they still simply drop straight down when they spawn. I was going to give them a velocity when I came home from school, but unfortunately I forgot to upload the progress I made to Unity Collab, so progress will be stalled until tomorrow.


Today I added velocity to cannonballs when they’re shot, so they’re now fully functional. I also added some particle trails to make them easier to track when they’re flying through the air.


This morning I added support for having multiple cannons on one ship. So far I had only set up one for testing, but I’ve now made the system scalable so that it’s very simple to add additional cannons. This afternoon I left for a weekend soccer tournament—I’ll be back Monday evening, so there won’t be any progress to report until Tuesday.


Today I made the ID system for interactable objects scalable. Previously, I was manually setting the IDs of the cannons and the steering wheel, but of course that would break down as soon as I have more than one ship in the world.


Today was a busy day, so I didn’t get a chance to make any progress, although I did some research on how to use Bepu’s built-in character controller.


This afternoon I started working on implementing the BepuPhysics default character controller. There’s quite a bit of code to sift through, but I want to make sure I do this properly, so it might take a few days.


Today I finished implementing the character controller. Unfortunately, I’m having a similar issue as when I initially wrote my velocity based controller—the input is working, but the player won’t move. This time however, the problem isn’t that the physics body is going to sleep, and since I have no other leads, I posted on the Bepu forums again.


This afternoon, after a few forum posts back and forth between Norbo and I, we found the source of the issue with the character controller. It ended up being a tiny oversight on my part while working with structs. I had left out the ref keyword, so the method that was returning the CharacterController struct was giving me a copy, not a reference to the actual thing.

What’s next?

Since I was away for a weekend during the last two weeks, and because I ran into some issues with the character controller, I wasn’t able to get as much done as I’d hoped. Therefore, the next two weeks will consist of more clean up and smaller, miscellaneous tasks. Among other things, I want to rework the ship spawning system to allow for multiple ships, and I need to fine-tune the character controller.

See other posts in this series.