Exploration of new game interaction techniques on the iPod

sandpaperleadSoftware and s/w Development

Oct 31, 2013 (4 years and 12 days ago)

168 views

Exploration of new game
interaction techniques on the iPod

Final Dissertation
Martin Pilkington
Supervisor: Daniela Romano
COM3021: Final Dissertation
5th May, 2009
This report is submitted in partial fulfilment of the requirement for the degree of Bachelor of
Science with Honours in Computer Science by Martin Steven George Pilkington
Page
i
Page
i
All sentences or passages quoted in this dissertation from other people’s work have been
specifically acknowledge by clear cross-referencing to author, work and page(s). Any
illustrations which are not the work of the author of this dissertation have been used with
the explicit permission of the originator (where possible) and are specifically
acknowledged. I understand that failure to do this amounts to plagiarism and will be
considered grounds for failure in this dissertation and the degree examination as a whole
Name: Martin Pilkington
Signature:
Date: 4th May, 2009
Page
ii
Page
ii
I. Abstract
The iPhone platform has one of the most rapidly expanding application bases in history
and reached 1 billion sales within 9 months. It also features one of the biggest departures
from standard gaming controls, which also means it is one of the least well explored in
terms of user interaction. The aim of this project is to explore some of these new
interactions and find how users view them compared to the standard controls of a
keyboard and mouse.
A game was produced on both the iPod touch and Mac and participants were asked to
play both and then fill out a short questionnaire. The results showed that people
preferred the keyboard and mouse for many aspects of the gaming experience, though
were inconclusive as to whether this was due to the game or the platform in general. As
such this report should not be seen as a conclusive overview of which platform is better
but as a foundation upon which future studies can be based.
Page
iii
Page
iii
i. Abstract
II. Acknowledgements
Thanks to my dissertation supervisor Daniela Romano for the advice and help producing
this report.
Thanks to Euan Paterson for giving idea for the story and characters behind the final
game.
Thanks to the many participants who acted as guinea pigs for the game.
And finally, thanks to my friends and family for helping to keep me relatively sane
during the course of this project.
Page
iv
Page
iv
ii. Acknowledgements
III. Contents
I.
Abstract ……………………………………………………………………………………………….. iii
II.
Acknowledgements …………………………………………………………………………………. iv
III.
Contents ………………………………………………………………………………………………. v
IV.
List of Tables …………………………………………………………………………………………. vi
V.
List of Figures ……………………………………………………………………………………….. vi
1.
Introduction …………………………………………………………………………………………… 1
2.
Overview of past and present input devices & games ………………………………………. 1
2.1.
Keyboards …………………………………………………………………………………… 1
2.2.
Mice …………………………………………………………………………………………… 1
2.3.
Joysticks …………………………………………………………………………………….. 1
2.4.
D pads ………………………………………………………………………………………... 2
2.5.
Handheld consoles ………………………………………………………………………… 2
2.6.
Nintendo Wii ………………………………………………………………………………… 3
2.7.
Specialised Controllers …………………………………………………………………… 3
2.8.
Conclusions ………………………………………………………………………………… 4
3.
iPod touch platform technology overview …………………………………………………….. 4
3.1.
Hardware …………………………………………………………………………………….. 4
3.2.
Software ……………………………………………………………………………………... 4
4.
Related projects using concepts and technologies similar to those in the iPod touch .. 5
4.1.
SmartSkin …………………………………………………………………………………… 6
4.2.
Microsoft Surface ………………………………………………………………………….. 6
4.3.
Conclusions ………………………………………………………………………………… 7
5.
Methods of input currently used on the iPod touch ………………………………………….. 7
5.1.
Tapping ……………………………………………………………………………………… 7
5.2.
Tilting ………………………………………………………………………………………... 8
5.3.
Dragging/Sliding/Pinching ………………………………………………………………. 8
5.4.
Virtual D-pad ……………………………………………………………………………….. 9
6.
Design of test game for acquiring user reaction to various inputs ……………………….. 10
6.1.
Requirements of the test game …………………………………………………………. 10
6.2.
Game design ……………………………………………………………………………….. 10
7.
Evaluation of test game ……………………………………………………………………………. 11
7.1.
Evaluation plan ……………………………………………………………………………. 11
7.2.
Results ……………………………………………………………………………………… 11
7.3.
Overview of test game …………………………………………………………………… 13
8.
Final game design …………………………………………………………………………………. 14
8.1.
Platform game ……………………………………………………………………………... 14
Page
v
Page
v
iii. Contents
8.2.
Shooter game ……………………………………………………………………………… 17
8.3.
Questionnaire ……………………………………………………………………………… 18
9.
Implementation ……………………………………………………………………………………… 21
9.1.
Platform game ……………………………………………………………………………… 21
9.2.
Shooter game ……………………………………………………………………………… 22
10.
Results ………………………………………………………………………………………………... 26
10.1.
Findings …………………………………………………………………………………….. 26
10.2.
Goals achieved ……………………………………………………………………………. 35
10.3.
Further work ……………………………………………………………………………….. 36
11.
Conclusions …………………………………………………………………………………………. 37
12.
References …………………………………………………………………………………………… 39
13.
Appendix A - Test game results ………………………………………………………………….. 40
14.
Appendix B - Final game results …………………………………………………………………. 41
15.
Appendix C - Sample questionnaire ……………………………………………………………... 46
IV. List of Tables
Table 6.1 - Requirements table …………………………………………………………………… 10
V. List of Figures
Figure 7.1 - Menu of test game ……………………………………………………………………. 13
Figure 7.2 - Screenshot of test game …………………………………………………………….. 14
Figure 9.1 - Screenshot of final game in action ………………………………………………… 23
Figure 9.2 - Screenshot of final game in action ………………………………………………… 25
Figure 10.1 - Participant gender …………………………………………………………………... 26
Figure 10.2 - How easy did you find the movement controls? ………………………………. 28
Figure 10.3 - How easy to learn did you find the movement controls? ……………………. 28
Figure 10.4 - How natural did you find the movement controls? …………………………… 29
Figure 10.5 - How easy to use did you find the shooting controls? ………………………... 29
Figure 10.6 - How easy to learn did you find the shooting controls? ………………………. 30
Figure 10.7 - How natural did you find the shooting controls? ……………………………… 30
Figure 10.8 - How easy to use did you find the brush controls? ……………………………. 31
Figure 10.9 - How easy to learn did you find the brush controls? ………………………….. 31
Figure 10.10 - How natural did you find the brush controls? ………………………………... 32
Figure 10.11 - How easy to use did you find the shockwave controls?…………………….. 32
Figure 10.12 - How easy to learn did you find the shockwave controls? ………………….. 33
Figure 10.13 - How natural did you find the shockwave controls? …………………………. 33
Figure 10.14 - How much did you enjoy the game?…………………………………………….. 34
Figure 10.15 - How easy did you find the game? ……………………………………………….. 34
Figure 10.16 - Overall how would you rate the game? ………………………………………… 35
Page
vi
Page
vi
iii. Contents
1. Introduction
The aim of the project is to explore new game interaction techniques on the iPod and
how they compare to current methods of interaction. To test these techniques a purpose
built game will be produced.
Most methods of input for computer games have been highly artificial and required a
degree of learning. New devices, such as the iPod touch and Nintendo Wii, are offering
technologies that have the potential to make gaming much more natural and easier to
learn. After an initial overview of old and new devices a test game will be produced to
examine the best input types on the iPod touch.
In the second part of this dissertation a purpose built game will be designed and created
for both the iPod touch and the Mac platforms and players will compare the differences
in interacting using the multi-touch screen and accelerometer on the iPod and the
keyboard and mouse on the Mac.
2. Overview of past and present input devices &
games
2.1 Keyboards
Keyboards have been associated with PCs for as long as the modern PC has existed.
Early PCs such as the Apple II and IBM PC were command line interfaces driven
entirely by keyboards. This meant that keyboards were also the input method of choice
for many games. Games such as Space Invaders and Pac Man which could be controlled
using the arrow keys were prevalent, as were adventure games that involved typing in
your actions such as Zork.
2.2 Mice
In 1984 Apple released the Macintosh which was the first consumer oriented system
with a Graphical User Interface and a mouse as an input device. This opened up a new
way of interacting with games as the graphics technologies were a vast improvement
over what already existed on PCs. Games such as Sim City, first person shooters such as
Doom and Quake and visual adventure games such as Myst all started to appear as
games now had much more power in terms of both graphics and interaction techniques.
2.3 Joysticks
One of the oldest forms of gaming input was the joystick. Many of the earliest consoles
used joysticks as a form of movement, often taken from the arcade machines. Joysticks
were prevalent until the mid 1980s when the computer game market crashed. Many of
the most popular game series were originally made for joystick based games consoles,
such as Donkey Kong, Frogger and Breakout.
Page
1
Page
1
1. Introduction
2.4 D pads
After the crash of the computer game market, Nintendo released the Nintendo
Entertainment System (NES). This introduced the Directional pad, or D-pad for short.
This was a 4 way button, shaped as a cross that let the player move up, down, left or
right. This control element has become a staple of console games controllers, even with
the advent of analogue sticks (which go full circle to bring joysticks back to consoles).
[1]
Some of the biggest franchises in gaming history were created during the early years of
this era, including the Mario and Sonic the Hedgehog franchises. As the power of
consoles increased the 2D games gave way to 3D polygon based games such as Crash
Bandicoot on the Playstation.
Over the past 20 years the basic format of controllers has not really changed, with
controls for directional movement on the left of a controller and buttons for performing
actions played on the right. A comparison of the Playstation 3 or Xbox 360 controller
with the original NES controller would show that the only two significant changes have
been the introduction of analogue sticks and the large increase in buttons.
2.5 Handheld consoles
Handheld consoles have followed similar controller designs to the D-pad controllers,
though they have managed to mostly stave of massive increase of buttons that has
happened over the same period of time. The Game Boy was released by Nintendo in
1989 and featured the same controls as their NES console, a D-pad, A and B action
buttons and Start and Select buttons. These same buttons were retained until the release
of the Game Boy Advance in 2001 where L and R shoulder buttons were added.
The Game Boy gave rise to many notable game series, the most successful of which has
been the Pokémon RPG game series.
The Sony Playstation Portable (PSP) didn’t provide a huge amount of difference to the
controls on handheld portables. Besides offering more buttons to make the controls more
similar to the Playstation controller, the only major addition was an analogue stick. It
wasn’t until 2004 and the release of the Nintendo DS that handheld consoles got a major
change in their form of input.
The DS stands for Dual Screen, which is the defining feature of the console. It features
two extra buttons over the Game Boy (X and Y action buttons) but the new input is a
touch screen located between the action buttons and the D-pad. This is accompanied by
a second non-touch screen on the “lid” of the console. The touch screen can be used with
a human finger but a stylus is also provide for more accuracy.
Having two screens and the ability to accept touch screen input has allowed for much
more complex games to appear on the DS. Games such as Theme Park, which were
released in the early 90s or late 80s have been ported over from the PC and make use of
the touch screen to navigate around and perform actions while the upper screen provides
an overview of the map and status of the game when you are navigating menus.
Page
2
Page
2
2. Overview of past and present input devices & games
2.6 Nintendo Wii
In 2006 Nintendo released their 7th Generation console, the Wii. This represented a shift
from the direction the other two major consoles, the Xbox and the Playstation, were
heading. Rather than going for graphical realism mixed with better online play, the Wii
tried to bring a different sort of realism to gaming by revisiting the console remote.
The Wii remote looks much like a TV remote at first glance and is intended to be held in
a similar manner. It also contains a D-pad and the usual assortment of buttons for
performing various actions along with Infrared and Bluetooth communication to remove
the need for wires. What makes the Wii remote different though is that it can detect its
position and movement in 3D space.
This leads to many new ways of interacting with games. The Wii ships with a showcase
game called Wii sports, which allows the user to play tennis, ten pin bowling, baseball,
boxing and golf. Rather than using the D-pad to move and pressing buttons to perform
actions, the user instead acts as though they were playing the actual sport. In tennis you
swing the remote around to hit the ball, in bowling you move the remote as though you
were bowling a real ball and in boxing you combine the remote with the additional
nunchuk controller to punch your opponent.
2.7 Specialised Controllers
While most games fit themselves around the controls provided with a console, some
games are designed around specialised controllers. One of the earliest examples are
arcade guns. These guns are combined with an infrared sensor that detects where the gun
is pointing on a screen when the player pulls the trigger. This allows the user to actually
aim and shoot at targets providing a much more realistic and quick fire experience than
trying to aim with cursor and then shoot.
Another example originating in arcades are dance mats. These are platforms, or mats
when used with consoles for home use, with arrows around a centre point, upon which
the player stands. As arrows appear on the screen the play needs to hit the corresponding
arrow on the mat with their foot.
Building upon the dance mat concept slightly are the recent Guitar Hero and Rock Band
games. These provide special controllers, usually shaped as a guitar, but sometimes with
other controllers such as drums. As a song plays, notes move towards the player on the
screen and they have to hit the correct colour note to play the song. This provides a
much more authentic experience than hitting buttons on a handheld controller or
keyboard as the user can feel as though they are actually playing the instrument.
One of the more innovative specialised controllers is the Eye Toy for the Playstation.
This is a camera that displays the player on the screen and detects where they are in the
room, using their outline to control a series of games. For example, the player may need
to use their arms to guide coloured balls into the correct basket, or to keep a football in
the air.[1]
Page
3
Page
3
2. Overview of past and present input devices & games
2.8 Conclusions
As technology has progressed, games have acquired more natural input mechanisms
which are allowing users to become more immersed in the game they are playing. The
iPod touch represents another step in this direction by providing a platform that foregoes
the standard controls of D-pads, keyboards, mice and physical action buttons, instead
providing just two input devices: a multi-touch screen and a 3-axis accelerometer.
3. iPod touch Platform Technology Overview
3.1 Hardware
There are very few details of the hardware available in the iPod touch. The details that
are available are often based upon guess work from part numbers. It is widely regarded
that the processor in the iPod touch is ARM based and there is 128MB of RAM
available [2] though there is no disk swap space so applications and the OS are limited
to the physical amount of RAM. [3] Networking is provided by the wireless 802.11b/g
standards with support for WEP and WPA encryption. The screen is a 3.5 inch multi-
touch screen with a resolution of 480 by 320 pixel (a density of 163 pixels per inch).
Multi-touch is a technology that has been round for a relatively long time, but is only
just starting to hit mainstream technology. Unlike a regular touch screen which can only
detect a single point on the screen, multi-touch allows for many points to be detected
and tracked simultaneously. This provides wide variety of new ways to interact with
devices. There are several implementations of multi-touch available, but the version
used in the iPod touch uses a capacitive panel that uses electrical fields caused by a
person’s fingers to track touches on the screen. [4]
The other main form of input on the iPod touch is via accelerometers. The iPod touch
contains 3 accelerometers, one along each axis of the device. These work by having a
mass surrounded by springs. As the mass moves, either due to motion or simply the
effects of gravity, it pushes on the springs which then cause an electrical current to vary.
By measuring the electrical current in each accelerometer a developer can calculate the
direction of movement and/or the orientation of the iPod in relation to the pull of gravity.
[5]
3.2 Software
The majority of the power of the iPod touch as a gaming platform doesn’t come from the
hardware, but from the software. The operating system on the iPod touch is a highly
optimised and scaled down version of Mac OS X. It is built upon the Darwin kernel,
which is a UNIX based kernel built upon FreeBSD and the Mach micro-kernel. This
offers a desktop standard OS on a handheld device.
Page
4
Page
4
2. Overview of past and present input devices & games
However, this isn’t simply a scaled down version of Mac OS X. Many parts have been
completely re-written for a mobile environment and many existing parts have been
highly optimised. Being a UNIX OS there is access to UNIX sockets and POSIX threads
along with various other low level UNIX technologies, though these are often wrapped
in higher level APIs to simplify them for developers. These reside in the Core OS and
Core Services layers of the operating system architecture, along with Bonjour zero-conf
networking, the SQLite database and Core Foundation, a C based API providing many
basic functionality and upon which many parts of Cocoa are built.[6]
Above this sits the Media layer which contains various technologies for graphics, audio
and video. The iPod OS uses the Quartz graphics engine for 2D drawing and relies on
OpenGL ES for 3D graphics. Audio is handled by the Core Audio framework which is
built upon OpenAL, with video handled by Apple’s Quicktime.
At the top of the architecture sits Cocoa Touch, which is the primary development
environment on the iPod. Cocoa is a set of APIs that dates back to the mid 1980s with
the NeXTSTEP operating system. Built with the Objective-C programming language it
offers a highly dynamic object-oriented API for rapid application development. On the
iPod Cocoa consists of two main frameworks: Foundation and UIKit.
Foundation handles most low level tasks and is almost identical to the Foundation
framework that exists on the Mac. As well as handling support for data types such as
strings, numbers and collection classes, it also has classes to aid in file management,
networking and threading. UIKit is built upon the same concepts as the AppKit
framework on the Mac, but is a near complete re-write for multi-touch and smaller
screens. It contains all the user interface classes such as buttons, views and text fields.
There are other Objective-C based frameworks that aren’t strictly part of Cocoa for
handling talking to the Accelerometer, animating the user interface, talking to the
address book, embedding an HTML view etc.
4. Related projects using concepts and technologies
similar to those in the iPod touch
The iPod touch isn’t the first device to use a multi-touch display. Indeed multi-touch has
been around since the 1980s as a concept. Up until recently however, most research has
focused on larger table top implementations. Below is an analysis of two such
implementations, which each use different techniques to achieve a similar form of input
to the iPod touch but on a larger scale.
Page
5
Page
5
3. iPod touch Platform Technology Overview
4.1 SmartSkin
SmartSkin is a technology designed at Sony’s Computer Science Laboratories and is
very similar to the multi-touch technology used in the iPod touch. Both use capacitive
sensing to calculate the position of a human hand with respect to the surface. It can be
scaled from a large table top to a small handheld device.
The surface is built from a series of copper electrodes in a grid layout. Those going one
direction are transmitter electrodes and those going in an orthogonal direction to the first
set are receiver electrodes. The areas where these two sets of points cross act as a very
weak capacitor. The magnitude of a wave signal is proportional to the voltage and the
frequency of the transmitted signal, as well as to the capacitance between two electrodes.
This signal is weakened by the presence of a conductive and grounded object, such as a
human hand, and so the signal amplitude can be used to calculate the proximity to the
conductive object. [7]
Because it can sense objects above the surface it allows for a lot more control than the
iPod’s multi-touch screen. For example, the user can hover their hand over the table to
move a “cursor” and then touch the table to “click” an item. This imitates the behaviour
of a mouse, something which isn’t possible on the iPod as there is no concept of
hovering over an item.
The system also allows for entire limbs to be used, which can allow for arms being used
to sweep objects on the surface around, much like you could do with real objects on a
surface. The ability to detect movement above the surface also allows for the “picking
up” of objects from the surface. Using a pinching motion similar to that used for
zooming on the iPod touch, a user can pinch an object and lift their hand to pick the
object up and then move across the screen and do the reverse action to place it down
again.
These interactions show some of the potential of multi-touch systems. However, their
use in a small handheld device may be limited and as such the subset used by the iPod
touch is the most useful subset for a limited screen size. Hovering, sweeping and
“picking up” objects are better suited to large surface areas where those techniques can
be properly used.
4.2 Microsoft Surface
The Microsoft Surface uses many of the same concepts as the iPod touch but on the
much larger scale of a table top. Multi-touch table tops aren’t a new concept and indeed
have been the focus of many experimental multi-touch implementations, but the Surface
is the first commercial implementation.
The mechanism for how Surface works is different to the iPod touch. Whereas the iPod
touch uses a capacitive panel with a regular LCD display, Surface uses a projector to put
the image on the screen and a series of 5 infrared cameras to detect interaction. The use
of cameras allows for the surface to detect a lot more than the iPod touch. Whereas the
iPod touch only detects items that are conductive and grounded, Surface can detect
various real world objects that can be used for interaction, e.g. paintbrushes [8]
Page
6
Page
6
4. Related projects using concepts and technologies
similar to those in the iPod touch
Surface also supports the use of special tags, which act like barcodes to help differentiate
different objects of the same shape, eg two bottles containing different drinks. These
features allow Surface to go beyond the iPod touch and on top of just improving
interaction between users and computers, it improves the interaction of everyday objects
and computers.
The current uses of Surface are often as point of sale devices or in hotel lobbies. In these
places the user can often help themselves to find the information they need without the
need for help from an employee. One example that combines the natural multi-touch
interaction with the object detection is a shop selling electronics. A user could place their
current electronic device, such as a camera or mobile phone onto the top of the Surface
device. Surface could then detect the type of camera or mobile phone and show users
how it compares to models available in the shop, which users can scroll through with
their hands to select and find out more about.
4.3 Conclusions
These two examples show what is possible if there is a lot of space available for the
technology. However, in a mobile device the technology hasn’t yet reached a small
enough size, both physically and economically, to fit into a device the dimensions of the
iPod touch.
In both examples, dealing with objects on a screen is much more natural and shows the
importance of making objects behave as you would expect them to even if, like scaling
up photos, these behaviours don’t exist in the real world. The creation of an artificial
reality, where an action feels as though it is something natural and real to the user, even
though it could not happen in the real world is a key consideration when designing a
game, as it changes not only the method of input to a game, but the style of the game as
well.
5. Methods of input currently used on the iPod touch
5.1 Tapping
The most common form of input on the iPod touch is simply tapping the screen. This is
used to launch applications, hit buttons, change the focus of input, type on the keyboard
etc. It is also used in various places in games. The most common place is the menu
structure of games, but it is also of use during the game play. Games like Sudoku or Lux
Touch (a Risk clone) use tapping to insert a number in a square or move units to attack a
country.
It also is able to be combined with other forms of game play. For example, Crash Nitro
Cart uses tapping to allow the user to make their character jump and to launch weapons.
Used in this way it allows for tapping to become an easy to use form of secondary input
to other controls.
Page
7
Page
7
4. Related projects using concepts and technologies
similar to those in the iPod touch
While this could be done on a regular touch screen with a stylus, the iPod’s hardware
brings two important differences. The first of which is that multiple touches can be
detected. This opens up the possibility of assigning different actions depending on how
many fingers are held down, but also that multiple areas of the screen can be touched at
once allowing simultaneous actions to be performed. The second is that touch targets
need to be much bigger than a stylus would allow as the device used to touch the screen
is a human finger. Depending on how the iPod is held this may be a thumb, so the size of
touch targets needs to take this into account.
5.2 Tilting
As well as the multi-touch screen, the iPod touch features 3 accelerometers that provide
feedback as to the orientation and movement of the iPod through the x, y and z axes of
space. The accelerometer is becoming a common form of moving around in a game on
the iPod, but the implementations vary widely in their scope and quality.
Super Monkey Ball was one of the first games released for the iPod touch and used the
accelerometer to move the character (a Monkey is a plastic ball) around a 3D world.
Unfortunately the controls weren’t very refined and control was often hard. There was
no way to adjust the angle at which the ball doesn’t move and it was easy to lose control,
as moving too far in one direction required a bigger movement in the opposite direction
to try and correct, but which in turn led to the ball travelling too far in the opposite
direction.
Spore Origins was released after Super Monkey Ball and offered a solution to this. It
allowed the user to customise the “relative tilt angle”, allowing the orientation of the
device to be set to what is most comfortable to the user. However, for some games this
isn’t necessary.
One of the earliest games for the iPod touch, released for “jailbroken” iPods before the
release of the official SDK was Labyrinth. This is a virtual representation of the common
wooden labyrinth, through which you have to guide a metal ball baring. As in a real
labyrinth you would be required to keep it level with the ground to keep the ball baring
stationary, the same applies to the virtual game.
While the accelerometer is being used for full motion in many games, some games are
taking a more restricted approach. Games such as Crash Nitro Kart and Cube Runner use
the accelerometer to allow the player to steer their character through a race course, while
taking the speed of the character out of control of the player. This allows for a much
simpler and easier to learn game, but one which requires more skill than a regular racing
game as you cannot simply travel faster than your opponent, you have to out steer them.
5.3 Dragging/Sliding/Pinching
An extension to tapping is to drag or slide a finger on the screen. Combining these
allows developers to take full advantage of the multi-touch display and also provide an
easier to learn and play experience for their game.
Page
8
Page
8
5. Methods of input currently used on the iPod touch
Pool is a virtual pool table that makes extensive use of dragging and sliding. The user
places the cue ball by tapping and dragging it around the table. They then slide their
finger around the cue ball to aim the cue towards where their finger is. After lining up
the shot the user then chooses the power of the shot by sliding their finger down the
power meter and then releasing to play the shot. This style of game allows for a player to
do several complex actions with a large degree of accuracy with just one finger.
Enigmo is a puzzle game in which the user has to guide coloured droplets around a map
and into a jug using an array of drums, springs and ramps. Players move the pieces
around the world by dragging them across the screen to the point they want. They can
then rotate them by using a circular control around them. They hold this and then slide
around the object to rotate, but can also slide out to expand the control giving a greater
degree of accuracy. This is a key element of rotating around a point and used to great
effect in both Pool and Enigmo to allow users to gain a great deal of accuracy in their
rotations.
Enigmo also uses sliding and pinching to allow navigation around the map. By sliding
their finger across the map the user can move around to view different parts of the map.
Pinching is one of the actions made possibly by multi-touch screens, and is where
players place two fingers on the screen (typically their index finger and thumb) and
move them apart or together to scale an area. Enigmo uses this to scale the map so the
user can fit more into the display. The important thing to consider when implementing
pinching is that it should feel realistic, such that the scene zooms with the same speed
and depth as the fingers move, i.e. the two points under the fingers when the zoom was
initiated should be under the fingers when the zoom ends.
5.4 Virtual D-pad
As the overview of gaming input devices showed, one of the most common components
of any gaming device is the D-pad, a cross shaped control that lets a user move in 4, or
possibly 8 direction. The only physical buttons on the iPod touch are the home and hold
buttons (and volume buttons on the 2nd generation iPod touch). As such some games
have started implementing a virtual D-pad on screen.
One of the best examples of this is Real Football 2009. It overlays a D-pad on the
bottom left of a screen, with “A” and “B” buttons on the right side. This allows the user
to hold the iPod like a console controller and control the game with their thumbs. This is
an extension of the tapping, where multiple controls can be overlaid on top of the game
to allow the user to control the action.
Page
9
Page
9
5. Methods of input currently used on the iPod touch
6. Design of test game for acquiring user reaction to
various inputs
Before starting the final game that will make up the majority of the analysis in this
dissertation, a test game will be created and played by a small sample of users to get a
rough understanding of what forms of input work best in certain game play scenarios.
6.1 Requirements of the test game
The test game will be a simple game that allows the player to play the same game using
various forms of input. The game will be required to test different aspects of game play
to see if a certain input is better suited to a certain game play aspect. A score will need to
be calculated for each game play aspect so that the best input for each aspect can be
calculated. A requirements table (Table 6.1) was produced listing all the featured needed
in the test game
No.
Description
Level
1
Block can move around path
Mandatory
2
Speed game mode where players are timed
Mandatory
3
Accuracy game mode where players receive penalties for
touching path walls
Mandatory
4
Combined game mode, where players are timed and receive
penalties for touching walls
Mandatory
5
Tap input mode, where the user taps on the screen where they
want the block to move to
Mandatory
6
Hold input mode, where the user holds on the screen where
they want the block to move to. The block stops moving when
they raise their finger
Mandatory
7
Tilt input mode, where the user tilts the device to move the
block around the screen
Mandatory
8
Drag input mode, where the user drags the block around the
screen. If they move too far away from the block, it stops
moving.
Mandatory
Table 6.1 - Requirements table
6.2 Game design
The basic game will take the form of a simple “maze”, which will consist of a simple
singular path which will be the same each time the game is played. This will help
mitigate any bias arising from the player also having to work out how to get to the end
of the maze. The player will be required to move a block around the the maze as quickly
as possible to reach a goal target at the end.
Page
10
Page
10
6. Design of test game for acquiring user reaction to various inputs
The game will have three types of game play: speed, accuracy and combined.
In the speed mode the player will be required to simply navigate to the the goal through
the maze as fast as they can. This will be to test which form of input is best when the
game play requires just speed of movement around a world.
In accuracy mode, if the user touches the side of the maze they will have a penalty added
to their score. This will help to find which form of input is the best for situations
requiring accuracy of movement.
Combined will be used to find a middle ground, where the user has to get through the
maze as quickly as possible without touching the sides. The results from this test will
likely be the most useful as general movement around a game world often requires a mix
of speed and accuracy at the same time.
7. Evaluation of test game
7.1 Evaluation plan
The game will be played by a relatively small sample size of 10-20 people. Each person
will be shown how to use each of the inputs before they play and have the aim of each
type of game play explained to them before. They will then play each type of game
through with each form of input, with their scores being recorded in a spreadsheet. Each
input for each game play type will then have the scores for all the players will be
averaged to find which is the best input in that situation.
Time permitting each player will complete this multiple times with their times averaged
to provide greater accuracy and help weed out any erroneous scores.
7.2 Results
The game was played by 10 people and their results were collected. The full average
results for each player can be found in the Appendix A. Speed measurements are in
seconds, penalties use an arbitrary unit. Combined scores treats penalties as being
equivalent to 1 second of time.
Tapping:
Tapping was one of the easiest forms of input to pick up. It wasn’t particularly
notable in either of the speed scoring points, but did offer the most interesting accuracy
scores. In straight accuracy it was by far the slowest, being about 8.5 seconds slower
than the next slowest input method. However, it was the only form of input to see an
improvement in accuracy in the combined game mode. This may be due to players being
more used to the input or could possibly show that tapping is more accurate when
players are pressured into making taps faster.
Page
11
Page
11
6. Design of test game for acquiring user reaction to various inputs
Times:

Speed - 13.39s

Accuracy -
14.67 (worst in game type)

Both (Time) - 14.15s

Both (Penalties) - 9.97

Both (Combined) - 24.12
Holding:
Holding was approached by players in two ways. The first was to treat it as a
variant on tapping, holding down where you want the block to go and then lifting your
finger and placing it on another point to carry on. The second was to treat it as a variant
on dragging, by dragging your finger across the path and waiting for the block to catch
up.
In the speed scores it fared quite well, though it did suffer the biggest time increase
when accuracy was included. This was countered in accuracy by the lowest increase in
penalties in the combined game which gave it the best accuracy score when players are
under pressure. As it’s score was over 2 penalties lower than the next input method it
meant that holding was the best combined input overall.
Times:

Speed - 13.21s

Accuracy - 6.13

Both (Time) - 15.22s

Both (Penalties) -
7.87 (best in game type)

Both (Combined) -
23.08 (best in game type)
Tilting:
Tilting was found to be the most natural and most liked form of input. This was
combined with it providing the best scores in both speed scores and straight accuracy.
However, it suffered from the biggest increase in penalties when players were under
time pressure, with players causing 4.5 times more penalties than average.
Given that players often tilted the iPod more when speed was an issue it isn’t surprising
to see this loss of accuracy. When accuracy is the biggest concern players would move
the device much more gently. While no figures were recorded for time during the
accuracy tests, there was a notable increase in time taken to complete the tilt accuracy
game.
Times:

Speed -
12.41s (best in game type)

Accuracy -
2.47 (best in game type)

Both (Time) -
13.70s (best in game type)

Both (Penalties) - 11.13


Both (Combined) - 24.83
Page
12
Page
12
7. Evaluation of test game
Dragging:
Dragging provided the most difficulty for players and led to the worst scores
in all but the accuracy game. The problem was primarily losing control of the block.
Players would move their finger too fast and move out of the dragging target area of the
block. This led to players having to go back much more often, slowing down progress,
but also being unable to get the block away from a collision from a wall as quickly,
leading to more penalties.
Despite this, dragging does provide potential as much more of a skill input. After
training players did start to do better. This provides an opportunity for use in a game as it
provides an element of the game which the player can attempt to master.
Times:

Speed -
15.33s (worst in game type)

Accuracy - 5.77

Both (Time) -
15.93s (worst in game type)


Both (Penalties) -
11.90 (worst in game type)

Both (Combined) -
27.83 (worst in game type)
7.3 Overview of test game
This first screenshot (Figure 7.1) shows the menu screen. From here players can choose
the game type and input type to play with and then press Start Game to play the game.
Figure 7.1 - Menu of test game
Page
13
Page
13
7. Evaluation of test game
The second screenshot (Figure 7.2) shows the game running in accuracy mode. The
score is kept in the top right corner. The player has to move the block around the path to
the red “goal” area at the end. In this mode they are trying to touch the wall as little as
possible.
Figure 7.2 - Screenshot of test game
8. Final game design
8.1 Platform game
A platform game is an obvious choice for the final game as it allows a great degree of
flexibility in the design. Platform games range from Super Mario Bros on the Nintendo
Entertainment System to Rolando, a popular iPod touch game. They offer a wide variety
of game play techniques while operating in a relatively simple space which allows users
to easily pick up the controls.
Many of the varying control ideas would be implemented using a set of puzzles
throughout the game. For example, a user may need to use a selection of movements to
get to a hard to reach place in order to change some part of the scene to progress, e.g.
lowering a bridge. Accompanying these will be standard controls for movement and
dealing with enemies.
The multi-touch screen offers the ability to create a series of natural gestures which
could be used to affect the environment or control the main character. Of course, while
these gestures are available on the iPod touch, appropriate alternatives would need to be
found for the keyboard and mouse. However, the possibilities for using the multi-touch
gestures in a platform game makes it an obvious choice for the final game.
Page
14
Page
14
7. Evaluation of test game
Game and Control Design
The game will follow the standard format of a platform game. The player will control a
character who has to travel from one end of a level to the other, avoiding enemies and
beating obstacles they find on the way.
Movement is a key part of platform games. It needs to be accurate and responsive as
players will often be required to time movement correctly in order to perform certain
actions, such as jumping from one ledge to another. The maze test game found that using
the accelerometer to let the user tilt the device on the iPod touch provided the best
results in both speed and accuracy. However, when combined, holding a finger down on
the screen provided a marginally better result, mostly due to better accuracy when
having to travel quickly.
The standard for movement on platform games on consoles and computers are the D-pad
or arrow keys, so the obvious controls for movement on the Mac is to use the standard
arrow keys. This also leads to the option of looking into a virtual D-pad for the
movement. This wasn’t actually tested using the test app but was detailed on in section 5
of the report.
Looking at games currently on the iPod, it appears that using the accelerometer is
becoming the standard for controlling movement within a game. This fact, combined
with the results from the maze test game makes it apparent that movement should be
controlled with the accelerometer.
Another key component of movement in a platform game is jumping. On a console this
is usually assigned to one or more action buttons, so that one can jump and move left
and right at the same time. On computers where arrow keys are separate, the up key may
be used for jumping, but often it is assigned to a key like the space bar or control key.
The iPod offers various way in which a jump action could be performed. Simply
touching the screen could be a jump action, or providing a button on screen for users to
touch to jump, so that the rest of the screen can be used for other actions, such as
shooting.
However, the multi-touch screen allows for multiple gestures to be used, so the same
area can be used for multiple actions. One such action is sweeping a finger up the screen
to jump. This is very easy to do with one thumb if the user is holding the iPod in both
hands and can be done anywhere on the screen. It also means that simply touching the
screen can be used for other actions.
Shooting for example, would be well suited to touching the screen to fire. On computers,
the mouse is often used for targeting and firing, with the bullet essentially travelling on a
vector between the player’s character and the location of the mouse click. This can be
almost directly transferred to the iPod by having the user touch on a screen where they
want a bullet to be fired.
One issue could be allowing the user to fire and jump at the same time. If a user is firing
with their right thumb and makes a jump gesture with their left thumb, the game engine
needs to ignore the left thumb touching as a firing gesture and instead recognise it as a
jump gesture. One way to do this would be to set a minimum speed for which a gesture
Page
15
Page
15
8. Final game design
is recognised as a jump. This would allow a user to move their thumb up and down to
fire, which shouldn’t require a fast movement, while allowing the brief and fast sweep
up to be registered as a jump.
An alternative would be to make the jump gesture area one side of the screen and the
shooting area another side. This would potentially limit parts of the game but would help
prevent the occasional an inevitable firing movement that gets mistaken as a jump,
which may frustrate users.
To simplify the game development, the gesture area technique is a better alternative. If
there was sufficient time to build and user test the minimum speed technique it could
potentially be a more intuitive technique and also allow for more freedom in designing
levels, but this would require a lot of refinement which the time constraints of producing
this project wouldn’t allow.
A potentially interesting concept would be the ability to resize the player to get past
certain obstacles. This would be accomplished using the pinching motion that is already
used throughout the iPod for resizing. It would allow for puzzles based on resizing the
character to fit through small passages or climb over certain obstacles.
Unfortunately this would require a large amount of engineering work to get the whole
scene to resize in real time. While definitely possible, it is limited by the amount of time
able to be spent on the game implementation.
Game Engine
The nature of the game puts a number of requirements on the game engine. The first of
theses is that it must offer a range of collision detection techniques, for testing player-
scene collisions and bullet-object collision. The bullet-object collisions are relatively
simple as there only needs to be a detection of a collision and no sense of the direction
of the collision. The player-scene collisions are more complicated as the direction of
collision is also important to prevent the player from going through a scene, while
allowing them to move away in a valid direction.
The game also needs a basic physics system with support for movement of objects and
simple gravity. The physics model needs to be simplified, e.g. the player should stop
instantly and not carry on. Gravity should only affect certain objects in the scene, e.g.
the player should fall down due to gravity but a ledge should not.
In order to deal with shooting, a basic bullet trajectory system needs implementing. This
is extremely basic and should not take into account gravity or other forces, simply firing
the bullet in the straight line from the player’s character to the point where the click was
registered.
No 3D graphics will be required as the game will be entirely 2D and sprite based.
However, the graphics will need to be fairly fast as the game will be running on the
relatively limited hardware in the iPod. The game engine also needs to allow for a large
amount of code reuse between the Mac and iPod.
Page
16
Page
16
8. Final game design
8.2 Shooter game
After attempting to implement the platform game it became apparent that implementing
it well was going to take much longer and be much more complicated than initially
anticipated (see Section 9.1 for details). As such a simpler to implement game design
was required, while not sacrificing the ability to collect meaningful results.
The game genre chosen was a simple 2D shooter game. In these games the player
controls a character which has limited movement and shoots at a stream of enemies.
Often power ups appear that give the player special abilities. It is these power ups that
will allow for the testing of various input methods
Game and Control Design
The game will be based around a character created by Euan Paterson called Dave the
Magical Spade. In the game, a stream of enemies will come towards the player. There
will be two types of enemy:

Crabs, which move quickly, but are easy to kill

Lobsters, which move slowly, but are harder to kill and fire back
After a certain number of enemies has appeared a boss will come down, which players
will have to defeat in order to complete the game.
A score will be kept throughout the game. Killing an enemy will add to your score, but
each enemy that gets past the player will subtract from the score. Killing a crab will add
100 points to the score and letting one past will subtract 200 points. Killing a lobster will
add 300 points and letting one past will subtract 400 points. Killing the boss will add
2500 points to the score.
In order to make learning and controlling the game as simple as possible, movement will
be limited to left and right. As with the platform game, movement on the iPod will be
controlled by the accelerometer. The player will tilt the iPod from one side to another in
order to move the character from one side to another. On the Mac the player will use the
left and right arrow keys on the keyboard in order to move.
Shooting will also be the same as with the platform game, though the whole screen will
be used as the target area. Touching anywhere on the screen on the iPod will fire a bullet
from the player’s character to that location. On the Mac the mouse cursor will be used to
target and the left mouse button will be used to fire.
There will be a series of power ups that come down as the game is in progress. Some of
these will automatically come into effect, such as shields to protect the player from
getting hit by bullets or enemies, faster firing which doubles the rate at which the player
can fire bullets and extra lives which add an extra life.
Page
17
Page
17
8. Final game design
Other power ups will need to be activated by players. There will be two of these in the
game. The first will be a brush that comes across to sweep away enemies. The most
natural way to do this on the iPod is to sweep across the screen. Of course, like jumping
in the platform game this could interfere with the shooting. However, unlike the platform
game, this game will be played holding the iPod in portrait mode, making it easier to
hold the iPod in one hand. As such one hand will be free to make more complicated
gestures.
As the screen is multi-touch, it can’t detect multiple contact points. This allows for the
gesture of two fingers sweeping across the screen to enable the brush power up. On the
Mac, a similar sweep gesture would be useful, but again it can’t interfere with the
shooting. The obvious solution is to use a different button than the one for shooting,
such as the right mouse button.
The second power up is the shockwave powerup. This will produce a shockwave which
will throw all enemies currently on the screen off the screen. On the Mac, a similar
gesture to the brush would make sense. As the shockwave travels up the length of the
screen, holding the right mouse button and sweeping up the screen would make sense to
produce the shockwave.
On the iPod, a similar gesture could be used, with two fingers sweeping up the screen,
but it isn’t a very natural way of producing a shockwave. Shockwaves are often caused
by vibrations, so it would make sense to use the iPod’s accelerometer to simulate this. As
the player is holding the iPod in portrait mode, and the shockwave will be travelling
away from them, the natural way to simulate producing the shockwave would be to have
the player tilt the iPod towards their body and then flick it down quickly.
Game Engine
The collision detection in this game is much simpler than the platform game, as it only
needs to find whether there is a collision, not the direction. This significantly reduces the
complexity of implementation of the game engine.
The game doesn’t need any real sort of physics engine beyond basic bullet trajectory,
outlined in the platform game. However, it will need to be fast as it has to deal with a
much larger number of bullets on screen.
Enemies will all be relatively similar, only differing in appearance, speed, lives and
whether they fire or not. The game engine simply needs to be able to create enemies at
random at the top of the screen and have them travel down to the bottom of the screen. It
also needs to keep track of the number of lives each enemy has as some enemies will
take more hits to kill than others.
8.3 Questionnaire
There are very few examples of questionnaires focusing on the area of research of this
report, i.e. comparison of gaming experience across two platforms. The number of
studies looking into what affects a user’s perception of a game are also very limited.
Indeed, Rajanen and Marghescu stated they, “did not find empirical studies that support
the view that usability and user interface plays an important role in game playing
experience.”[9]
Page
18
Page
18
8. Final game design
Because of the relative lack of relevant past studies, the questionnaire for this report was
produced by cherry picking useful concepts from various sources. The result is a
questionnaire that, while it may not look at all possible areas of difference between the
experience on the two platforms, will provide enough data to answer some interesting
questions and provide a foundation for further studies to look into any questions that will
arise from the results.
There is a potential for bias based on which platform a player uses first. Their
impressions of the game on one platform my taint their impressions of the game on the
next. This may be due to the platform, or simply the fact that they are more accustomed
to the game on the second platform. Because of this, players will be split into two
groups: one who played the iPod first, one who played the Mac first. This should help
cancel out any bias caused by using one platform over the other, while at the same time
make collecting results much quicker.
According to the study by Rajanen and Marghescu, past gaming experience plays a
significant role in players formulating opinions about a game. Age and Gender are also
quite significant. These significant pieces of data are collected by the questionnaire as
they will provide an useful set of subgroups which can be subjected to further analysis.
One of the key objective pieces of data will be the score and number of lives a player
has at the end of a game. These won’t be based on a player’s opinion of the game but
instead allow for an objective analysis of how controls on different platforms can affect
a player’s performance.
While the score and number of lives remaining are objective, they will influence the
subjective side of the questionnaire, which makes up the bulk of the game. The
questionnaire will be split up into 3 parts, one for each platform and one for questions
directly comparing the two platforms. Each platform will have a similar set of questions,
asking the player’s opinion of each control based on 3 criteria: ease of use, ease of
learning and how natural the controls felt to the users, i.e. how well the actions they
performed related to the results that appeared on the screen.
The player’s opinion of each control based on different criteria may be different to their
overall preference. For example, a user may find a control to be very unnatural, but they
may prefer the control because of this. The comparison section contains questions to ask
the player which platform they preferred the controls on.
Lastly, while the platform difference are mainly in the controls, these may influence the
overall opinion of the game. They may affect the enjoyment and difficulty of the game,
as well as the user’s opinion of the game in general. These are areas that are of the most
interest as they will help show how well the iPod compares to the desktop computer as a
gaming platform.
Page
19
Page
19
8. Final game design
Final design
Age:____ Gender:
Male / Female
How many hours a week do you spend gaming:___
iPod
Score:____________ Lives:______
How easy to use did you find the following controls:
Movement:
1 2 3 4 5 (1 = very hard, 5 = very easy)
Shooting:
1 2 3 4 5
Brush Powerup:
1 2 3 4 5
Shockwave Powerup:
1 2 3 4 5
How easy to learn did you find the following controls:
Movement:
1 2 3 4 5 (1 = very hard, 5 = very easy)
Shooting:
1 2 3 4 5
Brush Powerup:
1 2 3 4 5
Shockwave Powerup:
1 2 3 4 5
How natural did you find the following controls: (i.e. did the actions you had to perform feel closely related
to the results on screen)
Movement:
1 2 3 4 5 (1 = not natural, 5 = very natural)
Shooting:
1 2 3 4 5
Brush Powerup:
1 2 3 4 5
Shockwave Powerup:
1 2 3 4 5
Mac
Score:____________ Lives:______
How easy to use did you find the following controls:
Movement:
1 2 3 4 5 (1 = very hard, 5 = very easy)
Shooting:
1 2 3 4 5
Brush Powerup:
1 2 3 4 5
Shockwave Powerup:
1 2 3 4 5
How easy to learn did you find the following controls:
Movement:
1 2 3 4 5 (1 = very hard, 5 = very easy)
Shooting:
1 2 3 4 5
Brush Powerup:
1 2 3 4 5
Shockwave Powerup:
1 2 3 4 5
How natural did you find the following controls: (i.e. did the actions you had to perform feel closely related
to the results on screen)
Movement:
1 2 3 4 5 (1 = not natural, 5 = very natural)
Shooting:
1 2 3 4 5
Brush Powerup:
1 2 3 4 5
Shockwave Powerup:
1 2 3 4 5
Page
20
Page
20
8. Final game design
Comparison
After playing both games:
I preferred the movement controls on the:
Mac / iPod
I preferred the shooting controls on the:
Mac / iPod
I preferred the brush power up control on the:
Mac / iPod
I preferred the shockwave power up control on the:
Mac / iPod
How much did you enjoy the game on the:
Mac:
1 2 3 4 5 (1 = didn't enjoy, 5 = enjoyed a lot)
iPod:
1 2 3 4 5 (1 = didn't enjoy, 5 = enjoyed a lot)
How easy did you find the game on the:
Mac:
1 2 3 4 5 (1 = very hard, 5 = very easy)
iPod:
1 2 3 4 5 (1 = very hard, 5 = very easy)
Overall how would you rate the game on the:
Mac:
1 2 3 4 5 (1 = very poor, 5 = very good)
iPod:
1 2 3 4 5 (1 = very poor, 5 = very good)
Are there any thoughts or comments you have?:
9. Implementation
9.1 Platform game
Initially various game engines were looked at to power the platform game. The first of
these was the Unity engine [10]. This is a 3D engine that had recently announced
support for the iPod. However, it was not yet available and also required purchase of the
game engine plus iPod component at $600 which ruled it out.
The next engine looked at was the Cocos2D engine [11]. This is available for both the
iPod and Mac as a free open source engine. It is a 2D sprite based action that offers
many effects. While fulfilling most of the criteria required for the game engine, it would
have required the game be written twice, as the Mac version of the engine used Python
as its language whereas the iPod version used Objective-C.
Ultimately, there were no game engines that met all the criteria required without costing
a large sum of money, so a custom game engine would have to be made. This led to the
requirement of looking at 2D physics engines. The main engine looked at was the
Chipmunk engine [12], which was used in Cocos2D. It is a C based physics engine, so
could be easily integrated into an Objective-C game engine on both the iPod and Mac.
The Chipmunk engine was integrated into a basic Objective-C based game engine to test
collision detection and basic physics operations such as jumping. Initially the results
were promising, but problems arose due to the physics being too realistic. The sparse
documentation also made it difficult to achieve the required effects, such as stopping
immediately upon a key release. Other physics engines were briefly looked at but many
weren’t C based and so disregarded.
Page
21
Page
21
8. Final game design
As the physics the game needed were relatively simple, the physics engine would be
built from scratch as well. This worked well for simple thing such as gravity and bullet
trajectories, but became a problem with collision detection.
The detection method being used was the Separate Axis Theorem. This states that “If
there exists a line for which the intervals of projection of the two objects onto that line
do not intersect, then the objects do not intersect” [13]. A series of axes are produced
which are perpendicular to each line of each shape on the screen. Each shape is then
projected onto each of these lines. The projections on a single axes are compared and if
there is no intersection between them, then the two objects do not intersect, meaning
other axes do not have to be checked.
As with using a 3rd party physics engine, the initial results of this system were good, but
severe problems were found in the implementations. While these would have been
possible to fix, time was running out for implementing and testing the game. A simpler
game was required in order to be able to get some results. For the design of this game
see Section 8.1.
9.2 Shooter game
The shooter game was much simpler to implement, due to the much simpler collision
detection requirements. There was no need to detect the direction of collision, only
whether a collision had been detected. This was simple enough to do by checking the
bounding boxes of each element. While not entirely accurate, the game was moving fast
enough and the images filled their boxes enough for it to be adequate.
The majority of the game was implemented in 3 days, leaving much more time for
testing. It also allowed a simpler game to play which helped later with the player testing.
It was built using Objective-C and Cocoa with the Quartz graphics engine.
The game consisted of 11 classes on the Mac. 8 of these are the game items, such as the
bullets and characters. The remaining 3 are the application delegate, game view and
game area.
The game items are designed to be as portable as possible between the Mac and iPhone.
They all hold the item’s current position, bounds and code to draw the item. Some hold
extra information, such as the number of lives remaining and the points from which
bullets are fired.
The application delegate controls the main window and the loading of the game area
object. The game area is the main controller for the game. This controls the timing,
drawing and logic of the game. Most of the game logic is performed in the
-(void)step

method. This updates the game’s state every time it is called. A timer in the game view
calls it upon each redraw.
Page
22
Page
22
9. Implementation
Figure 9.1 - Screenshot of final game in action
Each item is given a movement vector which is used to update the position of the item.
All items are then checked for any collisions and have their life reduced if hit, and
removed if they have no life remaining.
While the game area is the main controller, it does not deal with any user input. This is
instead handled by the game view, which handles the input and then passes any relevant
information onto the game area. And example of this is the shockwave powerup, the
game view detects the right click swipe and makes sure the swipe was large enough to
be detected, at which point it calls a method on the game area object to create a
shockwave. This is then placed in the game and animated on the next timer call to
-
(void)step
.
Page
23
Page
23
9. Implementation
There are a series of timers running throughout the game. The main one fires every 0.05
seconds to update the game state and redraw the screen. There is also a timer that is used
for firing bullets. This is usually set to fire every 0.2 seconds, but when the fast fire
power up is selected it is invalidated and recreated to fire every 0.1 seconds. The
remaining two deal with time limited powerups. The shield and fast fire powerups only
have a limited period of usage before they wear off. This is set to 10 seconds from when
the powerup was received. If another powerup is received within this 10 seconds then
the timer is restarted to last until 10 seconds from this second powerup.
The game inputs are managed in the game view class. The
-(void)keyUp:
and
-
(void)keyDown:
methods look for the right or left arrow key being pressed and then set
an integer signifying the direction that the character should move (1 for right, -1 for left,
0 for no movement). The movement of the character is updated when the main timer
fires. The reason for this is that there is a delay between an initial key press and the APIs
sending the event again due to a prolonged key press.
The mouse inputs do have a direct impact. The
-(void)mouseDown:
method creates a
new fire timer, while the
-(void)mouseUp:
method invalidates and destroys the current
timer. The target is moved using the
-(void)mouseMoved:
method, though as this is not
called when a mouse button is pressed the
-(void)mouseDragged:
method passes its
event to the
-(void)mouseMoved:
method.
In order to control powerups the
-(void)rightMouseDown:
method records the point at
which the right mouse button was clicked. The
-(void)rightMouseUp:
method then
detects the point at which the right mouse button is raised. If the delta between two
elements of the points are greater than 50 then the powerup is used, otherwise it is
ignored as an accidental swipe.
As the iPod uses very similar APIs, porting the game from the Mac was relatively
simple. There are some extra classes in the iPod version such as the
RootViewController

and
EndGameController
classes, which are the main view controllers. The game area is
made into a
UIViewController
subclass, which is added when the user clicks “Play
Game” in the main menu. There are also two other classes:
M3BezierPath
and
AccelerometerSimulator
.
M3BezierPath
is some open source code that duplicates
NSBezierPath
from the Mac APIs on the iPod. It is simply a wrapper for the lower level
C based graphics APIs.
AccelerometerSimulator
allows for the iPod’s accelerometer to
be used to test accelerometer code in the simulator, allowing for easier debugging.
The biggest issue in porting was the fact that the screen co-ordinate system is inverted
on the iPod touch, meaning (0,0) is in the bottom left rather than top left of the screen.
This was discovered after the Mac version was completed, though if it was discovered
before this, the Mac version’s view co-ordinates could have been inverted to make
porting easier (the iPod’s view co-ordinates are fixed). Most of this was easy to fix,
though it did introduce many bugs which caused the game to slow down due to objects
not being removed after leaving the screen bounds.
Page
24
Page
24
9. Implementation
Figure 9.2 - Screenshot of final game in action
In the iPod version of the game, the movement and shockwave detection code has been
moved to the game area in the
-(void)accelerometer:didAccelerate:
method. The
movement simply looks to see if the tilt in the x axis is greater than 0.1 or -0.1 and then
moves. This allows for a small gap where the character can be kept in the same position
easily.
Page
25
Page
25
9. Implementation
The shockwave detection code checks for a flick of the iPod in the y axis. The user must
lift the iPod to them and then shake it down fast enough to cause the flick to register.
Testing showed that the lower limit of the shake should be -0.1, as the user may not flick
the iPod past a flat positions. The upper limit was set at -0.4 as this was a large enough
angle away from the standard position a user held the iPod in to be a useful limit,
without being that large an angle the user couldn’t use other controls while flicking.
The firing and brush code remains in the game view class. If there is a single touch sent
to the event methods it is recognised as firing. If two touches are detected then it is
checked whether the movement is greater than 50 point in the X axis, in which case the
brush powerup is activated.
10. Results
10.1 Findings
There were 28 participants who took part in the survey. Most of these were students
aged 17-21, though there were a few older participants, as such the average age was
22.64 years. Due to the lack of older participants, discussion of how the age of the
participant affects their opinion of the game will be limited.
The gender distribution was 7 females, 20 males and 1
participant who did not specify their gender. The participants
spent an average 5.41 hours gaming each week, but 8 of the
participants stated they spend no time gaming and an
additional 6 said they only spent 1-2 hours a week gaming.
However, most of those players with 10 or more hours
gaming experience ended up playing the iPod touch first
(simply by coincidence), so any comparisons in experience
would not be very useful with the data set collected.
Half of the 28 participants first played the iPod and the
other half first played the Mac. Any bias caused by their
initial reaction to the game will be discussed relating to
each individual area of analysis
Scores & Lives
The main objective factor for comparing the two platforms are the score and lives each
participant ended with. Participants seemed to perform better on the Mac than the iPod
touch, though the range of results was slightly higher on the mac.
The Average score on the iPod touch was 11968 compared to 13250 on the Mac. The
Mac had a range of 22200 points (-2500 to 19700) compared to 19300 on the iPod touch
(-300 to 19000), though the results on the Mac were most consistent with 75% of values
being within 1 standard deviation compared to 67.9% on the iPod touch.
Participant Gender
Page
26
Page
26
Figure 10.1 - Participant gender
9. Implementation
There is a noticeable difference when the figures are split up into the platform played
first. Both platforms see their average score increase and become more consistent if it is
the second platform played on. The average score for participants playing the iPod touch
first was 10521 with a standard deviation of 5598.10, compared to a mean of 13414 and
standard deviation of 4485.51 if was the second platform they played. The Mac didn’t
see as big a jump in the average going from 13057 for first time players to 13443 but did
see the standard deviation dramatically drop from 6440.34 for first time players to
3795.28.
While the sample size of female participants was relatively small, the difference in
scores between genders give some interesting findings. Both genders had higher scores
on the Mac, though this was far more prominent in male participants with a 2055 point
increase in the average score on the Mac, compared to a 157 point increase with female
participants. The consistency was also an interesting factor, with female participants
being much more consistent on the iPod than the Mac, but the opposite being true with
male participants.
The average number of lives left on the Mac (6.68 lives) was over twice as high as the
iPod touch (3.11 lives), though the iPod was more consistent with 82% of participants
remaining live being within 1 standard deviation compared to just 57% on the Mac.
As with the scores, the remaining lives increases and become more consistent if the
platform is the second one the participant played on. Unlike the scores though, the Mac
saw a much bigger jump than the iPod with the average remaining lives going from 5.43
to 7.93 compared to 2.93 to 3.29 on the iPod.
The split by gender gives interesting results. The gap between the two genders on the
iPod is 0.91 lives, though on the Mac this increases to 4.08 lives. The female participants
were also more consistent than male participants with a much lower standard deviation
on both the iPod (2.06 vs 3.44 for males) and the Mac (3.69 vs 4.02 for males).
Overall, the figures show that participants performed much better on the second platform
they chose, which was to be expected as they had become accustomed to the game
mechanics by that point. The Mac produced much better results than the iPod touch,
which may be due to a better experience of the game on the Mac or possibly familiarity
with the keyboard and mouse as input devices. Objective figures do not give a clear
picture of what causes this, but the subjective questions will help clear this up.
Movement
Movement is a crucial part of gaming and participants overwhelmingly preferred the
Mac for movement, with 20 participants listing it as their preferred platform for
movement after playing on both platforms. However, when this is split by gender 4 out
of the 7 female participants preferred the iPod for movement to the Mac. The initial
platform didn’t seem to make a very big difference, with 3 of the 14 participants who
first played on the iPod preferring the iPod and 5 of the 14 who first played on the Mac
preferring the iPod. The sample size is too small for this to be a significant difference.
Page
27
Page
27
10. Findings
Overall users found the Mac to be easier user than the iPod for movement with an
average of 4.57 vs 3.68 (out of a maximum of 5). Interestingly, those who used the iPod
first rated the ease of use of movement on both platforms higher than those who started
out on the Mac, though this could be simply due to the small sample size. There is little
difference between the two gender’s opinions of the Mac’s ease of use for movement but
the female participant see the iPod as easier to use for movement than their male
counterparts (4.0 average for females vs 3.5 for males).
iPod touch
Mac
Figure 10.2 - How easy did you find the movement controls?
The views on the ease of learning were much closer between the two platforms, with the
iPod touch receiving a 4.3 average compared to 4.89 on the Mac. The initial platform did
have an impact on the averages. Those who played on the iPod first ended up giving the
Mac a perfect average of 5.0, though those who played on the Mac first gave it a smaller
average of 4.79. The opposite effect happened with the iPod touch where those who
played it before the Mac gave it a much higher rating than those who played the Mac
first (4.69 vs 3.93).
iPod touch
Mac
Figure 10.3 - How easy to learn did you find the movement controls?
Page
28
Page
28
10. Findings
The Mac also beat out the iPod in how natural the controls felt for users, though by a
very small margin (4.68 on the Mac vs 4.15 for the iPod). The differences between the
initial platforms was negligible, though those who played the Mac first did find
movement less natural on both platforms. There was a significant difference in the
genders, with female participants finding the iPod much more natural than the Mac, and
male users finding the Mac slightly more natural than the iPod.
iPod touch
Mac
Figure 10.4 - How natural did you find the movement controls?
Shooting
Shooting brought about the biggest number of opinions. Most users found it much easier
to shoot on the Mac (only 3 participants preferred the iPod). The main reason for this
was that the user’s finger often got in the way of where they were shooing so they
couldn’t see the enemy. This view was consistent across gender and initial platform.
When broken down, the ease of use was much higher on the Mac than the iPod touch
with an average of 4.25 vs 3.46. The ease of use did seem to be affected by the initial
platform, with shooting seeming easier on the second platform the player used. Female
participants were particularly critical of shooting on the iPod, giving an average score of
2.71 vs 4.43 on the Mac. Male participants were critical of shooting, but not by as large
a margin (only 0.6 points difference vs the 1.72 points difference from female
participants).
iPod touch
Mac
Figure 10.5 - How easy to use did you find the shooting controls?
Page
29
Page
29
10. Findings
The ease of learning of the two controls was very close, with just 0.17 points difference
between the two averages (4.52 on iPod vs 4.79 on the Mac). The difference between
initial platform was negligible on the iPod touch, though was a little more pronounced
on the mac with a 0.15 point difference. There was no real difference between the two
genders, with both giving an average score of 4.5 for the iPod and scores of 4.86 from
female participants and 4.75 from male participants for the Mac.
iPod touch
Mac
Figure 10.6 - How easy to learn did you find the shooting controls?
Participants also found the Mac was more natural than the iPod for shooting, with a
score of 4.5 vs 3.74 on the iPod. Again, those who played the Mac first found the
controls less natural overall, but this was most significant on the Mac, with those who
played the Mac first giving a score of 4.14 but those who played the iPod touch first
giving 4.86. There wasn’t a huge difference in genders, though female participants did
find the Mac more natural and the iPod less natural than the male participants.
iPod touch
Mac
Figure 10.7 - How natural did you find the shooting controls?
Page
30
Page
30
10. Findings
Brush
The brush was the least popular control item, though most people preferred it on the
iPod (18 out of 27 responses). In the ease of use it scored 3.46 on the Mac and just 2.93
on the iPod touch. Initial platform did not seem to matter too much on the Mac but the
iPod touch fared much worse if it was played second, scoring just 2.64 compared to if it
was played first. There was very little difference between the two genders.
iPod touch
Mac
Figure 10.8 - How easy to use did you find the brush controls?
The ease of learning scores were almost level, though the iPod just edged ahead with an
average of 3.81 compared to 3.79 on the Mac. The iPod score was heavily influenced by
the initial platform, with those playing the iPod first giving an average of 4.23 but those
playing the Mac first giving a score of 3.43. There was a more pronounced difference in
the genders, with female participants finding the iPod touch much easier to learn than the
Mac, though male participants finding them roughly equal.
iPod touch
Mac
Figure 10.9 - How easy to learn did you find the brush controls?
As with the ease of learning, there was little difference in how natural users found the
brush controls to be. The main differences appeared in the game play, with participants
finding their initial platform more natural. Then gender difference was also significant
with female participants again finding the iPod touch better than the Mac, though male
users did find more of a difference between how natural the controls were on the two
platforms, with the Mac getting an average of 3.5 to the 3.21 they gave the iPod touch.
Page
31
Page
31
10. Findings
iPod touch
Mac
Figure 10.10 - How natural did you find the brush controls?
Shockwave
The shockwave powerup was overwhelmingly favoured on the iPod touch, with just 3
participants preferring it on the Mac. There was no real difference between genders and
initial platform.
The shockwave was seen as slightly easier to use on the iPod than the Mac (3.86 average
vs 3.75 on the Mac), though the mode was 4 in both cases. In terms of initial platform,
those who played the Mac first found the shockwave to be easier to use than those who
first played on the iPod, though the difference was minor. The only major difference in
ease of use was between male and female participants on the Mac. Female participants
found the Mac much less easy to use than their male counterparts (3.29 average vs 3.85).
iPod touch
Mac
Figure 10.11 - How easy to use did you find the shockwave controls?
In terms of ease of learning the shockwave was seen as easier on the iPod touch by a fair
margin (4.44 average vs 3.93 on the Mac). Those who played on the iPod first found the
shockwave easier to learn overall than those on the Mac, those the difference was less
than 0.2 points on both platforms. Again, the gender difference on the Mac was
profound, with female participants giving an average score of just 3.57 compared to 4.05
from male participants.
Page
32
Page
32
10. Findings
iPod touch
Mac
Figure 10.12 - How easy to learn did you find the shockwave controls?
The mean score for how natural the shockwave control is was 4.19 on the iPod touch
and 3.54 on the Mac, echoing results in other areas. This was actually greatly influenced
by the initial platform, with those who played the Mac first rating the shockwave feature
much higher than those who played the iPod touch first. Yet again the female
participants disliked the Mac, giving it a 2.71 average score compared to 3.85 from male
participants. Male participants also found the iPod more natural than female participants
but both genders found it better than the Mac.
iPod touch
Mac
Figure 10.13 - How natural did you find the shockwave controls?
Page
33
Page
33
10. Findings
Overall Comparison
In the overall comparison, the Mac fared better then the iPod touch. On the question of
enjoyment of the game the Mac gained an average of 4.11 compared to 3.71 on the iPod
touch. Those who played the Mac first found the difference to be smaller with a gap of
just 0.21 points, compared to 0.57 points difference for those who played the iPod first.
Male participants found the games more enjoyable than their female counterparts by
around 0.3 points.
iPod touch
Mac
Figure 10.14 - How much did you enjoy the game?
In terms of how easy the participants found the game the Mac scored a win by 1 whole
point (4.54 compared to an average of 3.54 for the iPod touch). This was slightly more
pronounced for those who played the Mac first with a difference of 1.07 compared to
0.93 for those who played the iPod touch. The difference was also greater for male
participants than female participants (1.14 vs 0.57).
iPod touch
Mac
Figure 10.15 - How easy did you find the game?
Page
34
Page
34
10. Findings
Finally the Mac outscored the iPod touch in the participants’ overall view on the game
with an average of 3.96 to 3.61. The difference was less pronounced with those who
played the Mac first at 0.29 compared to 0.43 for those who used the iPod touch first.
The gender difference was also less pronounced with females than males with a
difference of just 0.14 for females compared to 0.4 for males.
iPod touch
Mac
Figure 10.16 - Overall how would you rate the game?
10.2 Goals achieved
One of the key goals was to find out whether there is a difference between the keyboard
and mouse controls on the Mac and the accelerometer and multi-touch screen on the
iPod touch. The results are pretty conclusive in showing there is a difference in the two
platforms.
The other key goal was to see if the iPod touch’s input methods were better. This
produced mixed results. Some of the controls were preferred on the iPod touch, some
weren’t, though this could have been due to the implementations in software rather than
any inherent flaw in the input methods. Further analysis would be needed to form any
sort of conclusive answer to whether the iPod touch’s input methods are better for
gaming (these are outlined in the next section).
Page
35
Page
35
10. Findings
10.3 Further work
The biggest problem with the results is the number and mix of participants. A larger
sample size would give a much more reliable picture of the opinions of participants.
While 28 participants is a reasonable number, it means that just 2 or 3 people changing
an answer by one point can change the results quite a bit. A sample size of at least 50
would be much more reliable.
The composition of this sample would need to be more consistent. There were huge
biases that potentially affected the results. One of the key factors was age. There were
only 2 participants over 25 years of age and only 1 under 18 years of age. Ideally there
needs to be a wider range of ages including those in their 30s, 40s, and 50s as well as
younger participants, especially primary school children and teenagers. Having this
range of results would allow analysis for how different age groups respond to the
different controls and if age plays a factor in opinions of the controls.
The gender split also needs to be more balanced, preferably a 50:50 split. These would
also need to be evenly split between the two platforms as in the study 5 of the 7 female
participants opted for the iPod touch as their initial platform. As with the overall results,
the small sample size means each individual participant has a huge amount of power
over the results. While there were just enough female participants to draw rough
conclusions from the results, they are not reliable enough to give a definitive answer to
any questions.
The other area of testing was the previous gaming experience. The participants level of
experience was not enquired about before choosing the initial platform. When the results
collected it turned out that 6 out of the 7 participants with 10 or more hours of gaming
experience a week ended up using the iPod first. This meant that it would be impossible
to distinguish any bias caused by gaming experience from bias caused by the initial
platform (and indeed may have also compromised the results for biased caused by initial
platform). There was also a similar split in gaming experience by gender with only 1 of
the 7 participants with 10 or more hours of gaming experience being female. It is
obvious that any future expansion of the test should enquire about gaming experience
prior to the initial platform being assigned.
The game itself could be improved. As much of the development time was spent on the
failed platform game the shooter game was rushed and would have benefited from more
development time. Exploration of a wider range of powerups would have opened up the
possibility for different sets of controls to be tested.
As well as improving the current game a wider range of games could be developed. If
there were fewer time constraints then a universal game engine could be developed, or if
the constraints on cost weren’t there then a 3rd party game engine that produce games
for multiple platforms could be purchased to allow for this. Other genres that would
provide interesting results would be First Person Shooter, Real Time Strategy, Sport,
Racing, Puzzle and Platform games. This would allow the results to be checked for bias