Turn to Port and Set Sail! (Ship Mechanics)
While working on the ship sailing mechanics we had great results using Unity’s Rigidbody physics, the ship would coast realistically using the AddForce command, giving us the slight drifting motion that would be fitting for a water bound craft.
Unfortunately, we ran into issues once we attempted to have players and objects onboard. Every object needed to have a Rigidbody component otherwise they would fall through the ship, players included.
Enabling Rigidbody worked for objects, but players would slide around and eventually go overboard. For now we are implementing a technique to limit the amount of physics involved by having the ship and its contents remain stable and move the environment around the boat. This method may not be our final implementation, but allows for us to solve more important issues, such as testing the server limits on player physics interactions. Using a ship controller script, the environment provides a wind direction vector and speed, and the ship responds to that wind information by taking in values from the ship helm (wheel) which controls the “rudder” making the ship drift left or right. Currently, the ship can not turn (it only rotates) as a result of how we handled the large environment, coupled with the design decision to move the world and not the ship.
These have led to complications that we are trying to work out so the physics does not toss all players and items onboard around as the ship pivots. We can pivot the world, but the landscape uses a tile system and this does not respond the way we imagined, even when all the tile pieces are the child of a single parent object.
More Hands Make Less Work (Multiplayer)
Building from last week’s player position and animation synchronicity, we set sail towards implementing VR interactive object synchronicity as well. PUN offers basic scripts for syncing rigidbody features and object transformations between clients, and after a little bit of extra effort, we managed to implement basic object ownership transferring between clients when they begin interaction with the objects, properly allowing different players to sync their interactions with objects between different player instances.
While we have the main concepts figured out, some fine tuning is still necessary for perfectly synced objects. With this next step in multiplayer synchronicity complete, we can now plot out our course for ship wide synchronicity. Future effort should not have to be bottlenecked by our understanding of PUN, and instead we can focus on new challenges like ship movement across the world in relation to object and player placement aboard the ship.
As Far As The Eye Can “Sea”
Finally, we have come to a solution to our water problem. It came down to two options in the end with converse tradeoffs. After playing around further with the settings for Crest, we got the framerate to a playable level, although still jittery. We also tried out a shader solution using the Universal Render Pipeline package and the ShaderGraph tool to create a dynamic material that is placed on planes. Shaders allowed us to use and animate a normal map on the plane to add the shimmering water effect, as well as add waves to the plane by manipulating the normal. The framerate within the Quest device for this solution was also much better, although unfortunately the visual quality of the shader did take a hit. So it came down to choosing better looking water with worse framerate with Crest or worse water with max framerate with URP. Ultimately, water is only a part of our product so we chose to sacrifice its quality to keep the rest of the experience more enjoyable. Shaders on, haters gone.
Land Ho!
We were originally by the Puget Sound when starting this product and wanted to have environments that have a realistic feel.
Discovering a tool called L3DT, the Large 3D Terrain Generator, we were able to get a height map and texture map to import into Unity.
Within the editor, the large terrain is broken up into smaller tiles. With a script attached to a player, tiles sections that are far away are not rendered, saving on rendering overhead.
- Work Log -
Everyone: Presented MVP progress in lecture on Tuesday and prepared for Thursday’s demo in lab
James: Found tutorial on handling large scale environments and created first prototype environment. Created basic ship controller script for sailing mechanics incorporating wind speed, wind direction, ship heading, and placeholder value for the amount of sails (unfurled sails to catch the wind). Created these placeholder assets to develop the correct world building approach to reserve the most network and processing overhead we can get from the quest.
Patrick: Created slides and videos for Tuesday’s presentation and contributed to the ship’s steering wheel mechanics as well as grabbing objects
Abhinav: Tinkered with Crest settings again to get as optimized as possible, as well as trying out a water solution with shaders. Finalized water solution to the shader option.
Julian: Implemented functioning interactive object synchronicity between players through ownership transferring. Built upon prior investigation in Remote Procedure Call usage and network optimization research.
- Work Plan -
Everyone: Re-research assets and pick ones for the project going forwards, rebuild ship frontend using new assets and migrate backend
James: Continue to work on how to handle the large landscapes as we implement the synchronization scripts for all objects in the scene, the ship, and the environment. Work on more in-game mechanical devices such as hand cranks, ropes, and a boarding plank.
Patrick: Rebuild ship frontend on new ship asset and implementing more realistic representations of sailing mechanics, from being able to raise/lower the sails, to using ropes to change their directions.
Abhinav: Experiment with land generation with new assets and how to simulate ship rotation. Help out with ship mechanics such as sails and ropes.
Julian: Dive into ship movement interaction: See how feasible it is to have something in the like of a rigidbody implementation for the ship, or if the scene should continue to transform around the ship. Apply PUN object interaction functionality to ship interactables. Fine tune the accuracy of object placement synchronicity.