Huge steps to Alpha
This week was a very productive one. We met on Wednesday after the long Christmas break and discussed on our scope in detail. To meet the intermediate presentation deadline, we agreed to finish the Alpha Milestone next Friday, to save up some time to prepare for the presentation.
Controller Calibration Part 2
At first, I worked on the calibration system again, because it was only able to calibrate axes for the thumbsticks. I added the functionality to calibrate the buttons too and store every information in the Game Manager to give Daniel and myself a hookup point for later use (the shooting and the character movement mechanic). After finishing this step, I realize that it is disruptive to calibrate each axis and button every time I hit the play button to check some other code and decided to include the process to store the calibration data in the player profile (PlayerPrefs), too.
The system is still not appealing, but the functionality works very well.
Getting the Water out of the Boat
David convinced me on Wednesday to look into this issue for the Alpha Milestone, because every friend, he showed the prototype to, was asking the same question: “Why is there water inside the boat?” Actually I planned to solve this task for the Beta.
About the issue: the water plane is rendering the water inside the boat, while the boat passes through the water on the y-axis. Gladly, David had researched on this topic, already and explained to me the possible solution to use a “Depth Mask Shader” with reference to this wiki article: http://wiki.unity3d.com/index.php?title=DepthMask
All I needed to do was to update the code to the Unity Version we are working with to get to the following result:
After disabling the option to cast a shadow for each water prefab, my job was done.
Daniel had some problems with the Level Generator. Sometimes, the system spawned tiles on top of each other despite his approach to checking for colliding tiles. To do that the system compared the positions of each tile. I realized that the positions were sometimes not exact enough to be comparable. I suggested to spawn a collision box instead and check for real collisions then. But this approach led to another issue. We worked for several hours on this topic together. It was very refreshing to work with him on the same lines of code, but it also consumed nearly twice the amount of working hours. Finally, he found the solution (more in his blog entry).
Rowing Mechanic Fix
The showcase for the rowing mechanic v1.5 led to a controversial debate on Wednesday. At the end, we agreed to go with this system in its current state for the Alpha Release to collect some responses from others and will talk about a potential change for the Beta Release. The only thing I had to add was a little fix: the axis mapping was no longer mirrored for the other player.
Visual representation of moving Water
This feature was one of those I hadn’t a clear vision for before start researching/working on it. At first, I thought about simple blue planes that are then mixed up with particle and sprite effects to get a feeling of a moving surface. But I didn’t like the idea. While working on the Spline Tool and some discussions with David, he showed a water material to me. The special thing about this material was its UV-Map. The UC Coordinates were stretched on some parts and compressed on other parts what gave the illusion of different speeds for an animated texture. This dynamic of UVs impressed me a lot and created the wish to, at least, try to work with it. I am far away from a final product, but I managed to gather the needed information to access the correct UV coordinates, alter those and save the original information to redo the changes at runtime:
I am very confident with this approach. All that is left is a real algorithm that is about the alteration process, a process that translates the rapid’s capsule trigger dimensions and its force into correct UV coordinate shifting.
This feature should add some action to the game. Its purpose is to move the boat to a direction with a specific force the designer wants to have in this part of the level. In its current state, the prefab is mainly a capsule trigger. While the boat is inside this trigger, it is dragged to the end of the capsule, while its course will be corrected and aligned to the capsules center. The mathematics behind it caused some trouble, especially to differ between a direction vector and a position vector and calculate a force out of it to apply it to the boat. The final result is demonstrated in this video including the UV-Map-Shifting: