Typically when we try to represent rotation we use Euler angles, roll, pitch and yaw (x,y,z) and although it is relatively easy to understand and visualize this system has some instances where it becomes flawed. This flaw is known as Gimbal lock which occurs when two of the axis run parallel to each other, therefore removing a degree in freedom. And although in some cases the end result of the rotation is the expected one, the rotations occurring between the starting position and the end position can lead to some undesired effects. Similarly, even if the rotations are always done in a specific order this problem is completely negated through the use of quaternions. In some cases quaternion notation is not necessary, for example; in a scenario where only 2 axis are needed, a 2D game. As Gimbal lock will not occur.

The introduction of quaternions resolves this issue by utilizing four dimensional vectors, typically represented as [w, x , y ,z]. Quaternions also make it easier to make rotations smoothly and directly. This rotation on quaternions is done through multiplication. In Unity the information regarding an objects rotations is internally stored as quaternions but through the inspector it is represented with Euler angles. This is done so that the user can understand the rotation and visualize it, as it is difficult to visualize a rotation when given in quaternion form. It is important to note that when attempting to manually change a quaternion rotation to a new one it should be done through matrix multiplication.

Understanding how rotation is managed in various programs is important and can potentially solve problems, it is also important to note how to make rotations with quaternions. Quaternions have become more common in various programs when handling rotation to avoid the issues with Euler angles, but at the same time in order for the user to understand or visualize the rotation Euler angles are still used; one example of this is Unity where rotation is stored with quaternions internally while it is shown to the user through Euler angles in the editor window.

With regard to project progress we have completed the game design document and finalized our ideas so that we are clear on what we expect to make. I believe that it is very likely that we will make some changes to the document and the final product. We are leaning to wards using RAIN AI in our project but we are deciding on what we should leave for us to program. Also we have not made much progress on the game itself so far, we just have a few small pieces between the team members. For the following week we should have integrated our current work and have it working with our prototype, also I the animators sort of have an idea of what the game will be like and what they will be making but we have made many changes since our initial pitch so I should give them the design doc as it may be helpful to them to clear up any concerns.