Character Movement on the Boat
There are three different positions on the boat: left side of the bench, right side of the bench and the cannon. This system is, therefore, to enable the player to move to each of these positions, but only if the other player is not currently in the desired spot. It also enables, disables or alters certain controls depending on the current location. This task didn’t cause any trouble, but that will potentially change when I have to add the character animations to it.
Controller Calibration System: Use of different Controller on the same Machine
As I plugged in a different controller in my computer, the game prompt a lot of error messages: it couldn’t access the axes that are currently assigned. This bug appeared because the system didn’t recognize this change: the different controller. It was quickly fixable by storing the controller’s name in the PlayerPrefs, too. If this name now changes, the calibration process will restart again.
Sometimes, the system isn’t initialized correctly and the calibration process is therefore not accomplishable. The only fix for that is a restart of unity, right now. As long as I cannot reproduce this issue, I don’t know where to look at but the priority to fix this bug is rather low, anyway.
I introduced Rebecca to my rapids that she is able to create the tile prefabs with them. I do not want to repeat everything she said in her blog post for this week, but my conclusion is a little bit different. I am still not really sure if my entire code is working properly, because we have some problems with a spinning boat, if the turn velocity gets too big. I am still thinking that I apply the force at a wrong location. I made a task for this for the beta.
Game Score and Treasure Animation
The Game Score is represented by the amount of gold that the players have left in the back of the boat. David provided me the model of the treasure in five different states and the transition animations from one state to the other.
The boat consists of a compound collider: multiple colliders of basic shapes that, together, are similar to the real shape of the boat. I had to create an interface for these colliders that reports back a collision to the parent object to trigger the correct behavior. The system is calculating the physical force that appears on impact with another object. And if this force is huge enough, the amount of treasure left will be reduced. The variable that stores the actual treasure state is linked to the animation controller, which then plays the needed animation.
As Rebecca tried to balance the minimum impact force needed, she had some troubles to distinguish a minor to a major collision by the impact value. I will have to investigate the calculation process that leads to the final impact force for the beta.
Water and Boat Physic Balance
I set up a meeting just to balance all the physical systems that are included in the alpha build. The purpose was to let everyone play the current state of the game and make some suggestions to improve the physical behavior. I thought it would be important to do this with everyone at the same time so that we will share the same vision in the end. While they play, I tried to translate the suggestions into values for the system.
Sounds: Rowing, Wood Creaks, Treasure Impact
One important point on our To-Do list for the alpha was to include sound into the project. We lack the time to research heavily for sounds or record those on our own, so that I include only those that we already had or those that I could find, quickly. In the end, I included the impact sound of the treasure, some wooden creaks of the boat that appear on a random time basis and the rowing sounds, when the paddle interacts with the water.
The rowing mechanic allows the player to row at different speeds and in different time spans. It would be good if the sound would represent that, too. To achieve that the rowing sound should be separated into three types: diving the paddle into the water while moving the paddle inside the water and pull the paddle out again. The first and the last one would be a regular audio file, but the moving sound inside the water should be altered by the speed and the timespan. But as long as we do not have the required sound files to do that, I skipped this complexity to the beta.
For the alpha, I just went for a simple system that spawns a 3D sound source to the equivalent paddle location each time the player begins to row. It randomly chooses an audio file out of the assigned folder. I had to write my own method that spawns sound sources because the original method “AudioSource.PlayClipAtPoint” does not return the audio source that it creates. I needed the returned object to changes some attributes on it, like setting the spatial value to be a 3D sound.
Basic Particles: The Bow Wave and the Gold Particle by Impact
This week, I introduced myself to particle systems for the first time. In the end, we choose two to include them in the alpha build. The gold particle effect is more or less a really basic particle system that will be played each time the player losses some gold.
The more interesting effect is the bow wave. This system itself is very basic too: a system that emits lots of balls that collide with the boat, but I tried to translate the boat’s velocity in values that are applicable to the particle system. The effect is not that special, but it is a beginning…
Importing Assets from Blender
Every asset that is done with Blender is miss scaled and rotated wrongly after importing it to Unity.
That’s because Blender uses another coordinate system than Unity. Right now, we compensate this by creating an empty parent Gameobject and attaching the Blender Imports to that. But I discovered another consequence, this week: the Mesh Filter of each object isn’t easily usable anymore because it is still basing on the wrong orientation and scaling. I identify this issue by trying to animate the water plane by altering the Mesh Filter at runtime.
This screenshot demonstrates the position of each vertex inside the Mesh Filter while being converted into an actual world position and multiplied by one hundred (otherwise it would be a pile of yellow lines). I wrote a method that changes the scaling and rotation and overwrites the original mesh filter with this information. The following screenshot shows the result, this time, without any multiplication:
But the vertices are still misplaced. Right now, I cannot say how heavily this issue influences my floating system because it is using the vertices for its calculations, too. Until now, this issue doesn’t draw any attention because I included a fallback system to the floating points right from the beginning: in case the system failed to locate a viable vertex, it uses an imaginary vector positioned at 0,0,0. I will have to investigate into this in case we want to have water within heights other than zero. Right away, I cannot tell if my method mentioned above is the best solution to conquer this issue, but researching on this doesn’t give a clear answer to that.