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.
Sunday (September 1)
This evening I made some changes to the fresnel code of the low poly shader. I added the ability to make it a solid color instead of it using the skybox reflections, as well as an adjustable strength modifier.
Monday
Today I did some major clean up in my shader GUI scripts. I made the code way more reusable, which in turn made it much easier to read and understand. I also adapted it to work with the new fresnel options.
Tuesday
This morning I started looking into visually removing the water inside the boat. Since the water is a simple plane, its geometry technically cuts right through the hull of the ship. I recently heard about Unity’s stencil buffer, and after experimenting with that for a bit I managed to cut out part of the water.
After working on it for a large part of the day, I put the stencil material on an enclosed object (which I made in Blender), shaped like the ship’s hull.
There’s a problem though. Since the stencil object needs to be rendered (despite being invisible) in order to mask out the water, if the camera is inside the hull—and therefore inside the stencil object—the stencil isn’t rendered. This allows the water to render when a player goes down into the ship.
Wednesday
After a lot of different attempts to get this to work, I came up with a solution. I created a mold of the inside of the ship with blender, and flipped the faces to face inwards. It acts as a sort of “wallpaper” which renders any time the player could see part of the inside of the hull, meaning that the water inside is history. Here’s the result:
There’s a little bit of an issue when looking at the ship through several waves—I think it’s caused by Unity’s rendering system. I’m not sure if it’s fixable in the shader, so I’ll probably just disable the mask unless the player is within a certain distance of the ship.
Since this is only a visual fix, the problem of the player floating inside the ship’s hull still persists. I have yet to come up with a good solution for that issue.
Sunday (September 8)
Today I made it possible to take screenshots from within the game itself. Not only that, but it works at any resolution. Although taking a screenshot sixteen times my normal resolution takes a few moments, it works wonderfully. This means I can get precise resolutions in a more streamlined way, which should help me take nicer shots to share in these posts as well as on the Discord server.
I achieved this by rendering the game at the desired resolution for one frame and outputting the result into a texture. From there, it’s simply saved as a png.
Wednesday (September 11)
This morning I did some server work. My goal was to change the way I’m informing clients about cannonball movement. Currently, the server just sends a packet containing each cannonball’s position thirty times per second—which is seriously inefficient. Once a cannonball is spawned and given a velocity, the only force acting on it is gravity until it collides with something, meaning it shouldn’t be too difficult for clients to predict its trajectory. Doing so would save a lot of packets from needing to be sent over the network.
First, I tried sending only the initial position and velocity, and then letting Unity’s physics calculate the trajectory. Unfortunately, although unsurprisingly, the server and client don’t match up (although they are similar). I’m not entirely sure how I want to proceed with this, so I decided to leave it there for now.
Restructuring the server to send a single packet for cannonballs instead of continuous updates led to the requirement of a method similar to Unity’s Start method. So, after a while, I managed to put together a system that allows me to easily implement methods such as Start and Update into components and have them be called automatically. Although the code behind it is a little “strange,” it works great and it’s quite clean when actually using it.
This evening, I fixed a memory leak warning that occurred every time I shut down the server. I also set up a Trello board to help me better organize the project. If you’re interested in what I’m actively working on as well as what’s coming in the future, check it out to get a good overview!
Thursday
Today, my computer broke. I had left it on sleep mode, and when I came back it was shut off. It wouldn’t turn back on again because it had no power. This happened the other day too, although after some fiddling with the cable and turning things on and off, it worked again. Unfortunately, that wasn’t the case this time.
Considering that my computer is over eight years old, it’s almost a sure bet that the power supply is finally giving up. Although later this evening it had power again, I plan to use it as little as possible to protect the rest of the components. I’ll hopefully have a new power supply by next week.
Sunday (September 15)
After a lot of research over the last few days, I’ve ordered a replacement power supply, as well as the parts for a new computer. I’ll keep the current one around to run servers on and play old games that won’t work with Windows 10, but I figured after over eight years with only a fan upgrade, it was time for something more powerful.
What’s next?
Until that replacement power supply arrives, I won’t be working on the game. Once it does though, I’ll continue working on reducing the amount of packets sent for updating player, ship, and cannonball positions. Once that’s done, I’d like to start working on ship damage (cannonball collisions, sinking, etc).
