INTERSTITIAL VIEWER: WORLD

PROJECT CHARTER - DRAFT

PROJECT NAME: Intersitial Viewer: OUT OF SCOPE:
World The project will not seek to include functionality
that would allow a user of the interstitial viewing
Sponsor: Dr. Derek Reilly device to interact, beyond movement, with the
Project Manager: Benjamin DeCoste game environment and/or other game players.
Customer: Dr. Derek Reily Furthermore, there will be no additional user
Updated By: Benjamin DeCoste interface elements, beyond the movement of the
Charter Version 1.0 device, that will serve to update the player’s
Number: position in the game.
Approved By: Benjamin DeCoste
Approval Date: January 20, 2012 The software needed to power the viewer will
not use other device features or interfaces, such
SCHEDULE: as sound output, camera or touch-screen
Start Date: January 20, 2012 interface, unless that feature is required for
End Date: March 29, 2012 generating a current view of the game world
from the perspective of the player.
OBJECTIVE STATEMENT:
The interstitial viewer:world is a proof of concept
design that shows it is possible to integrate an
augmented reality handheld device into the
open wonderland framework, Twin Space, and
D’Acadien. PROJECT TRADE-OFF MATRIX
Resources: Select a different flexibility letter for
S each constraint. Use each letter
only once.
Schedule:
IN SCOPE: L L = Least Flexible
S = Somewhat Flexible
The goal of this project is to show whether or M = Most Flexible
Scope:
not it is possible to implement an augmented
M
reality using GPS, compass, and gyroscope to
track where a player is in the game at any given DELIVERABLES:
time, and track where the user goes depending The following deliverables are required for
on where he or she moves in the real world. successful project completion (not in order):
This project is a proof of concept to show 1. Software (including source code)
whether or not it can be achieved using current 2. User manual
game architecture and framework (ie open 3. Deployment guide
wonderland). 4. Project reports (weekly), including
minutes of project meetings
The player should be able to navigate the game 5. Requirements documents (for client’s
world, using the viewer, wherever he or she is, records)
as long as he or she can be connect to the other 6. Design documents (for client’s records)
players using the game. That player should be 7. Presentation (including software demo)
able to see game objects in real distance from
the player.
.

OSI Admin #8087v1 Project Charter –small project 1

Version 1 – 6/8/09
 INTERSTITIAL VIEWER: WORLD
PROJECT CHARTER - DRAFT
MILESTONES: APPROACH:
Throughout our project we feel that adequate To tackle this project, we will first research any
checkpoints to evaluate our progress could be: remote open wonderland viewers that may have
1. Project plan document been written for iOS or Android devices. Our
2. Design document next step will be to create an application for our
3. Prototype 1: Throwaway chosen to device that will allow us to access the
4. Prototype 2: Implementation device’s environmental monitors (such as its
5. Final Project document GPS and compass) and pass this information to
6. Description and demo of our project a client computer that is logged in to open
wonderland. A server side program will allow us
to interpret this data and transform it into game
controls to move the virtual player around the
space. Our last step will be to combine these
two applications to create an interstitial viewer.
BACKGROUND:
Some Initial investigation will have to be
The primary motivation of this project is to add conducted to decide if the project should be
the feature of an interstitial viewer to an already done with iOS or Android.
functional game called L’Or de L’Acadie. In
order to accomplish this task we are being
provided the source code for L’Or de L’Acadie
from our client and our job is to integrate our
add-on into the existing software. This game
was created using an open source toolkit called
BENEFITS:
Open Wonderland which allows users to create
their own virtual worlds. Our customer benefits are:
1. Comply to the customer’s mandate
For our current situation our client has given us 2. Improved service allowing a more in-depth
the task of creating an add-on that essentially and creative user experience
allows the actual user and virtual avatar to move 3. A broadened audience which includes
in sync. For example, if the user was to walk 20 those with special needs. (E.g.:
meters to the west then the virtual avatar would customers that have disabilities keeping
do the same. The only stipulations our client them from using a standard mouse and
gave us were to provide an enjoyable user keyboard)
experience and, if possible, it should be portable
for outdoor usage. For our desired situation we
would like to create a functional interstitial
viewer using either an Android or an iOS device
such as an iPad where we can utilize certain
features such as the build in GPS. However,
because our project is still in early development
we have yet to decide which platform we will use
to create our interstitial viewer but plan on
making a final decision very soon after weighing
the pros and cons of each device.

OSI Admin #8087v1 Project Charter –small project 2

Version 1 – 6/8/09
 INTERSTITIAL VIEWER: WORLD
PROJECT CHARTER - DRAFT
SUCCESSFUL COMPLETION CRITERIA: PROJECT RISKS:
In order for this project to be successful, our One of the highest project risks is the
final product must be: technology that it depends on. For the project to
1. A complete piece (or pieces) of software. be effective it requires accurate use of GPS (or
2. Able to remotely control a player in Or De another tracking) technology in order to
L’acadie using a handheld device’s distinguish where we are on a small playing
environmental sensors. field. A GPS which can be off by about half a
3. Allow the user to view the world in real meter may ruin the game experience. Another
time (or close to depending on problem may be the cross platforms of iOS
networking constraints) on their programs not effectively communicate with the
handheld device. openwonderland software. However if this is the
4. Stable and simple enough to allow an case, technical solutions or workarounds can
enjoyable experience for a user who has be employed but these may have unforeseen
never touched computer code or the flaw in themselves which would put the project
game before. at risk. Finally the project must be able to work
in the final environment it is designed for. If the
project is being deployed in a place that
interferes with the tracking technology or the
equipment is not durable enough to withstand
the conditions, this will also put the project to a
DEPENDENT PROJECTS: halt.
This project is being built on developed software
The strict scheduled may also bring up some
and can be started right away. The software that
problems. The project needs to be completed
this project requires is the source code from the
game Or D’Acadian and the open source
by the scheduled deadline, and this may create
software from openwonderland.org. For this problems if there are any last minute changes.
project to be developed on the iPhone or iPad it Also when group begins scripting the project we
also requires software that can communicate may realize that there may not be enough time
between the main game and the device. to code all of the functionality required in the
given timeline. This also means that any
This project is an add-on to the original game. changes to the personnel on the project could
Therefore nothing depends on this project and it put it at risk because there would not be enough
is very unlikely that another project will build on time to train someone new and all members are
this. needed to complete this project in time.

Finally any miscommunication in the project

details between client and among the creators
could also put the project at risk.
Misunderstanding the priority of the project is a
big concern. For example secondary features
may become the group’s primary concerns, and
the priorities the client was looking for are
flawed in way that ruins the game experience.
This may also lead to the project not fitting into
the overall game. This could be either
technically, as in the protocols do not match the
game, or as in it doesn’t make sense to put it
into the game.

OSI Admin #8087v1 Project Charter –small project 3

Version 1 – 6/8/09
 INTERSTITIAL VIEWER: WORLD
PROJECT CHARTER - DRAFT
ASSUMPTIONS and CONSTRAINTS: SPONSOR SIGNATURE: DATE:
Before beginning this project we are assuming
that the Open Wonderland and other used
frameworks work well with minimal errors.
However, we do anticipate some difficulties
implementing a mobile device to the existing
frameworks.

The biggest constraint that this project will face

will be time and team members academic
workload. Dedicating enough time for
successful completion and fixing any existing
bugs or bugs we introduce.

RESOURCES:
Project Team Team Role Number
Members of Hours
Required
What is their Hours
role? required?
Benjamin Project 10
DeCoste Management,
Developer
Travis Roberts Lead Developer 10
Karl Leuschen QA, Testing, 10
Developer
Bret Schofield User Experience, 10
Developer
Jayde Fanjoy Networking, 10
Developer

BUDGET:
Initial Budget: $     0.00 
Estimated Actual
Ongoing Costs: $     0.00 
Estimated Actual
Cost/Benefit Analysis Required? Yes No

EQUIPMENT REQUIRED:
Android Device
iPhone
iPad
Computers for development
Server

OSI Admin #8087v1 Project Charter –small project 4

Version 1 – 6/8/09