How does it really work?
What did it take to get this done?

A number of steps were taken to get this to where it is today.
Started with the Wiimote and GlovePIE scripting
Open source game testing and hard coding
Explored different ways for motion tracking
Climbing the steep learning curve of GtkRadiant

Starting out and GlovePIE

When first starting this project, the Nintendo Wiimote was suggested to be a good solution to accessible head tracking. This was an important stepping stone as it did not take long to discover the huge online community doing similar work with the wiimote.

The Wiimote was often being used as a mouse, since a mouse is typically used to look around in 3d games, it can be used to control the view directly.

The most common tool to utilize it was Carl Kenner's GlovePIE. Scripting in GlovePIE had almost no learning curve, anyone with any basic programming experience will be able to pick this up and understand it. For example, the syntax is very simple and intuitive. There are countless examples of the wiimote being used as a mouse, here is a video. You can compare to my video below which uses the Sony Playstation3 Sixaxis controller.

After some discussion, research and experimentation, I concluded that the wiimote is not suitable for 360 degree yaw tracking. It would take a gyro for such a feat, luckily, the sixaxis controller can do something which the wiimote cannot. To the right you can see my final code/script used in GlovePIE.

You can download this script file right here.
(it can be vied in any text editor)

- back to the top -

Open Source Gaming

Controlling the mouse with the sixaxis works great, and can therefore be applied to any interface that uses the mouse. However, in most 3d games, there is nothing to allow the user to rotate the view (roll). I needed a game engine that gave me access to rolling the view. The best solution was open source. After hypothesizing that the game 'Nexuiz' might be a worthy candidate, I started a discussion here to get help with learning how the coding works. Version 2.3 was used for this project, 2.4 has recently been released.

Since GlovePIE redirects data from one interface driver to another, it was not too much of a problem to use a few of the many available virtual joystick axis that PPJoy has to offer. Eventually it was found that it would be best to interpret the roll and pitch angle values into absolute joystick axis values. In the game, tilting the joystick results in a constant motion, this needed to be changed to a fixed value depending on the position of the joystick.

In GlovePIE, joystick data ranges from 1 to -1 for the 2 extremes on any given axis. By default, the in game motion speed is determined by the value of the joystick. This needed to be changed to position. To be more clear:

default: forward axis of joystick value 0.5 results in looking down at half of maximum speed
modified: forward axis of joystick value 0.5 results in looking down at a 45 degree angle.

Only 1 file really needed to be modified, though there was some extra code in another, but it is not significant.
vid_sdl.c is the main file that reads and interprets the joystick data. This file can be edited in almost any text editor. I used an open source program called notepad2. (The line returns do not show up properly in windows notepad). The areas that were changed were the command line variable defaults (top of the file), and the view angles area, (starting at line 292)
The last significant part of this step was learning how to compile this into a windows executable. This used the SDL (Simple DirectMedia Layer) version of the game, which allowed more flexible use of joysticks. Therefore, SDL libraries were required. A discussion on how to compile is right here.

- back to the top -

Motion Tracking

This is a topic that many people have done a great deal of research on. There are many different ways to tell a computer which direction and how fast the user is moving. After doing my own research, I concluded that because of the limits that I must deal with, that this ball mouse method would be best. (See why section for why not an actual mouse or something else.)

This idea was developed from what was already available and in place; joystick hardware and software. I needed a way to convert physical motion, into a joystick signal that I could use on the computer.

A joystick is simply a potentiometer, an electrical device that changes its resistance depending on the position of the slider. When there is a constant voltage applied to this, a varying voltage can be read that co-insides from the position of the joystick. Starting where the joystick potentiometer was located, and using a volt meter, I probed around on the sixaxis joystick board to find factory set test points that had this voltage available.

The sixaxis joystick reads 0.3V at one extreme, 1.4V at rest, and 2.5V at the other extreme. It runs from a 3 Volt battery.

The idea that DC motors generate a voltage that is proportionate to the speed that it is spun spawned the solution that would allow motion tracking. However, additional circuitry is required to match the voltages from the motors to that of the joystick. Initially hobby car motors were used, they generate voltage that ranged from -0.6 volts, to 0.6volts. Later, low friction motors were found that also were more sensitive. (They were pulled from scrapped playstation CDROM drives). The additional circuitry needed to amplify (or attenuate in this case) the voltage from the motors as well as give an offset voltage so that 1.4V is generated while the device is at rest.

On the right here is the circuit board of the sixaxis controller (bottom view). Marked in RED are the discovered points where the voltage varies according to the joystick position. Wires were soldered onto the 2 points for the right side joystick, and 2 more were connected for power and ground connections.

Below is a thumbnail for the schematic used for the additional circuitry. Since the motors supply a negative voltage when being spun backwards, so positive and negative power supplies are required for this circuit. Thus additional batteries were attached.

The circuit above uses an op-amp, I was reminded of the specifics by simply searching the web for a summing op-amp circuit. Here is an excellent example of various ways op-amps can be used.

The case along with the axils were provided from scraped parts donated by Colin Richards, also special thanks goes to Colin for lending a hand in the construction of the main chassis.

- back to the top -

Map Design

Editing an existing map was a good idea to get familiar with the interface of GtkRadiant; the map editor for games originating from various ID engines. However, in the end, editing an existing map caused more problems than it solved and I had to start from scratch.

To the left here is a screen shot of the map program. It has a steep learning curve as many aspects of it are counter-intuitive. One example is navigating around in the 3d space. It uses the mouse wheel to move forward, and the ctrl button must be held down to move sideways and up/down. All learning issues aside, once learned, a simple map can be quickly thrown together. Another significant disadvantage to this is that there are no pre-existing props. All objects must be created from scratch using the editor.

Version 1.4 is required for Nexuiz, apparently there are issues with the latest version of GtkRadiant. Instructions on adding nexuiz plugins for 1.4 are outlined here.

Basic principles had to be learned to make a successful map, proper application of textures, no map leaks etc. This map is equipped with a teleporter directly below the start point. If the user falls into the chasm, he/she will then walk to the teleporter and end up in the exact same place as the start; both in the virtual world and (ideally) in the real world. The goal for the map was to convert the computer lab where this project is being presented, into a chasm that must be crossed via narrow beam. (see below)

- back to the top -