THE MOVEMENT SYSTEM

I knew I had to spend a lot of time on the movement system because people are still not too comfortable with motion controls. I had to implement a system that is easy to learn and intuitive so that people can stay immersed in the game play instead of fighting the movement system. I spent the rest of the semester of my Research and Development class developing, optimizing, and tweaking the movement controls. I tried out about five different implementations and tweaks and was able to get feedback from other students, and the teacher, of the class before finalizing which control system was best.

My first instinct was to have the player face the direction that they want to go and then press a button to move forward. Once the button is pressed, the player would have to tilt the controller forward in order to choose the speed that they wanted to go. Using this, I was able to contain the movement system to one button and some rotational data and I wouldn’t have to worry about left and right player rotation because the player’s head is doing that. By holding the button and moving the player’s head, the player would be able to achieve any forward angle that they wanted at the speed they wanted. It was kind of fun and intuitive too. However, there was a major setback: the player would sometimes face away from the monitor, and the PS Eye camera, and the motion controller would be tracked in weird ways because they are not directing facing it. This led to unexpected behavior and had to be scrapped.

So, how do I keep the player’s body facing forward towards the monitor at ALL times while still keeping Oculus Rift’s natural head tracking in place for game play purposes? The player must face forward so that the Playstation Eye camera, which would be in a fixed position, could continually track the motion controllers for the game. This actually took me a while to figure out. Eventually, I came to the conclusion that I had to separate the movement controls into two different buttons for player positioning; one would control the forward/backwards motion while the other would control the left/right rotation that the player would face. This would then leave the Rift’s head tracking to simply monitor what the player could see and would have no impact on movement. The two buttons had to be placed near each other in case the player wants to press both to go forward/backwards at changing angles.

With this in mind, I decided to use a button from the second controller and a button from the first controller for movement and retrieving rotational values for speed. ((I forgot to mention at this point that I am using two motion controllers for my single player thesis game.)) I had to use this combination if I wanted to read rotational values from each controller in order to control the speed at which they move/rotate. Once implemented and tested, it did fix my original problem of always facing forward but it seemed kind of clunky. I was able to get some feedback from the students and teacher and they seemed to say that pressing a button to move or rotate seemed slow and a bit weird. From observing and telling them initially how the buttons are laid out, I noticed that they were slow to pickup on controls and seemed to forget that they had to press a button in order to rotate/move. I had to tweak the controls further.

My next iteration involved moving all movement buttons to the second controller while leaving the first controller empty for combat. I decided to get rid of getting rotational value for speed and hard coding a constant value for the forward/backwards movement. This way, I only need to track one set of rotational values for the left/right rotation speed. Once I was able to script this in, I also scripted in basic attacking with the first controller. I wanted to test how movement was handled while holding a sword to swing at the same time in order to get better results for testing purposes. Again, I got feedback from some students and the teacher but this time, results were better. They picked up on the controls quicker and were able to navigate through a simple path pretty quickly and efficiently. I noticed through observation however, that they had to pause a couple of times to remember what they had to do in order to rotate the camera in order to move forward properly. It was only two or three times before they got the hang of it, but almost everyone that tried out the game did it. It needs to be better.

My current iteration is to utilize a Navigation controller that is usually paired up with a motion controller. Originally, I had wanted to use two motion controllers because I wanted the physicality of swinging both arms around while playing the game. It was brought to my attention when discussing things with an actual programmer that was willing to help with my project that maybe that wasn’t a good idea because people would simply get tired and stop playing after a short while. Which is when the Navigation controller was brought up. Using this new controller paired with the motion controller gave me better options for the intuitive control system that I hoped to accomplish. The Navigation controller came with a joystick but did not have any motion capabilities. I currently have a plan to use this navigation controller’s joystick for movement and using it’s two bumpers for rotating left or right at a constant speed. With this in place, I would be able to dedicate the second controller, the navigation controller, for movement and User Interface interactions and leave the first controller, the motion controller, for any combat related attacks and abilities. I’m pretty happy at how everything is set up, but I need to test it all before I deem it proper for my thesis!