A collection of trials and the lessons learned when developing our HoloLens2/ROS/Unity game.

Version Control

Unity tends to have a number of files which don't merge cleanly with Git. File locking when working with teams on a game seems to be a vital feature which a distributed version control system like Git does not support. We have largely been able to get around this by working in our own scenes and own prefabs, but occasionally have run into serious issues when multiple people work on the same scene at the same time without telling each other. There have also been issues with managing the Git repository in general; we decided to go with a single master branch, however this caused us a few headaches when people tried to rewrite their commit history. Based on these challenges, and the lessons learned, we recommend the following:

• Never modify the git commit history (git rebase, git commit -amend, etc.) for content which has already been pushed to a shared branch (such as master) unless you first verify the status of the entire team and their local repositories.
• For a team larger than 2 or 3 people, ensure people at least have their own branches that are periodically merged into master. This will make it easier to fix issues before they make it to master. Feature branching is not a hard requirement, but person and/or subteam (2 or 3 people) branching is definitely advisable.
• For Unity games, and likely most other game engines, it is recommended to use a VCS other than Git; file locking is too important of a feature when people are working on lots files which are not really human editable.

Movement, Rotations & Transforms

Rotation Axis Confusion

When attempting to rotate or move Unity objects, be aware of whether you are using the local or world coordinate system and don't mix them in the same objects. If you mix your local and world space in code, you will get weird results. We had issues when rotating objects over time where they would spaz out between two different positions constantly. This was also in part due to mis-aligned definitions of "up" when attempting to rotate about the "up" direction. Be sure that whatever axis you are rotating about is not changing as a result of your rotation, otherwise you will get results like this when you attempt to rotate a turret towards the player:

• World coordinates are accessed through transform.position and transform.rotation while local coordinates are accessed from transform.localPosition and transform.localRotation. They can be converted from one to the other using InverseTransform (world to local) or Transform (local to world).
• Unity uses Quaternions to track rotation of objects. Be aware that if you convert this into Euler Angles, your results will not necessarily be consistent (e.g. -15 deg may be returned as 345 deg) as the same euler angle can be represented with different degrees based on your point of view.

Linear Interpolation & Rigidbody movement

When you use linear interpolation (e.g. Vector3.Lerp(currentPos, targetPos, Time.deltaTime) to move an object combined with Time.deltaTime (time passed since last frame rendered) note that the object will never exactly reach its destination, and will actually slow down as it gets closer to the destination. The 3rd argument of Lerp is the fraction to move between the current and target points, so 0.5 would get you halfway between the two points. Since Time.DeltaTime will almost always be less than one (typically 1/30 for 30 FPS), you will never reach the destination exactly with this method.

If you are moving an object which has a rigidbody with gravity applied, you should not modify the transform directly, but instead apply a velocity, otherwise, if an object is hit by a physics object, the physics system will fight with your movement system, resulting in movement similar to what you see below: