Floating Objects, Git Merge and playable Prototype
Floating Objects
The main objective of this mechanic is to enable certain objects in the scene the ability to behave like floating on a water surface. It will be executed primarily on the player’s boat but should be applicable to every other object like obstacles.
Researching on that topic cost a lot of time, I struggled to get an idea, to begin with. Finally, my main inspiration was this video: https://youtu.be/tOI8jKDsjFM?t=1m18s and this code: http://wiki.unity3d.com/index.php/Ocean
Overall, the ocean code was not that applicable to our project. On the one hand, it is outdated and on the second the game takes place on a river and not on an ocean. These circumstances lead me to the decision to scrap the ocean code and concentrate on the little floating snippet at the end of the document.
I began with a transform that is attachable to an object and is translating a vector information into a physical force. My own essential work was the way to get this needed vector.
At this point, we hadn’t defined our water: What it should be and what it is made of. Accordingly, I abstracted the whole algorithm from a specific object and defined water as a plane with a mesh filter and mesh renderer, because it seems to be the common way to animate water by moving the vertices of the mesh filter directly.
To save up system resources, the algorithm searches for the closest plane that is tagged with “water”, at first, and iterates than through every vertex to determine the closest one to the floating point. This allows us to split up a huge single plane with an incredible number of vertices into a smaller number of planes with much fewer vertices. This closest vertex is then passed to the function that calculates the physical force and applies it to the attached object. This code runs smoothly on our machines, but I have to keep in mind that this is one of the parts in our game that causes a lot of operations with every single floating point in the game. It scales exponentially and is, therefore, a potential spot to invest more time in optimization with a promising outcome, if needed.
I also added a “center of mass” prefab that allows the designer to ease the floating movement a bit for each object.
The code in movement (the water is just for technical demonstration):
Git Structure and Project Merging
The git structure is defined by different branches. The “master” branch will always be the condition of our last reached milestone (somehow a working backup). The “release candidate (rc)” branch will always be a stable condition towards the upcoming milestone. Every team member can use it to test their assets in a playable environment that does not include experimental features with potential bugs and other problems that prevent the game to run. The programmers will create a new branch for every totally new code, the “feature” branches. This is a setup where the programmer can create code independently from the others.
At the end of the week, we gathered every piece of each team member and uploaded it to our git repository. This was the first time that Daniel and I merge our feature branches together back into the “release candidate”. Somehow, we had more complications than expected, because git wasn’t able to execute the order. In the end, we merged the project by hand and experiment with git. Our conclusion is that we will both work on a single feature branch and commit both to it over the vacation days, to see if this results in a better workflow.
Playtesting the Prototype
After merging every piece we have a running prototype. There are some edges here and there but it is the first time that we can actually play the game in its current state and to offer others to play it. Very quickly, we realized that our controller input isn’t intuitive and discussed a lot to improve the concept. The implementation of this will be my task for the next week.
