A GENERIC DEVELOPMENT PLATFORM
FOR ASD THERAPY TOOLS
Lynette van Zijl and Morn´e Chamberlain
Department of Computer Science, Stellenbosch University, Stellenbosch, South Africa
Keywords:
Autism, Assistive technologies, Computerised therapy tools, Virtual environments, Game engines, Games.
Abstract:
We discuss the design and implementation of a generic development platform for 3D virtual environments for
autism spectrum disorder therapy tools. The platform is intended to enable researchers and therapists alike
to quickly develop individual therapy software without having to resort to extensive software development.
The platform includes specific features requested by therapists, such as replays, data capturing and remote
monitoring over a network. We also discuss the implementation of a number of different therapy tools, and
their subsequent evaluation at local schools.
1 INTRODUCTION
Over the past two decades, there has been a world-
wide marked increase in the occurrence of autism
spectrum disorders (ASDs) in children. Assistance to
these children requires highly-trained professionals,
and intensive one-on-one therapies. The accompany-
ing expense is often prohibitive for lower-income par-
ents, and government-supported schools have excep-
tionally long waiting lists. This work aims to alleviate
the problem by providing a framework to fast-track
the development of computerised ASD therapy tools.
ASDs are a complex range of disorders, charac-
terised primarily by a lack of communication, lan-
guage and social skills. In particular, children with
ASD usually interpret language literally, and find
body language and social innuendo extremely diffi-
cult to understand. This immediately means that any
therapies are language and culture dependent, so that
computerised therapy tools from America and Europe
can seldom simply be re-used in the South African
context. There is thus an immediate need for South
African-specific computerised therapy tools.
In addition to the need for therapy tools, re-
searchers investigating ASDs from a medical or psy-
chological perspective often require specific software
to interact with children with ASDs. A generic plat-
form for the development of computerised ASD tools
can be used in this context as well. The advantage
would be that research groups do not have to spend
time on implementation of graphical environments
and avatars, but can concentrate on the specific tools
directly related to their research.
We present in this article the design and imple-
mentation of a generic platform for the development
of computerised ASD therapy and research tools, with
the specific aim to provide free, culture-independent
software, on a generic platform. As additional spec-
ifications, we require our platform to be network-
capable, multi-threaded, have low resource require-
ments, and provide a middleware interface for subse-
quent developments.
The rest of this article is organised as follows: we
give a brief overview of related work in section 2, fol-
lowed by a detailed exposition of our design in sec-
tion 3. We discuss the implemented therapy tools in
section 4, and conclude in section 6.
2 RELATED WORK
One of our motivations for the development of com-
puterised ASD therapy tools is the premise that com-
puterised practise relieves much of the stress caused
by the human interaction necessary in therapy ses-
sions (see for example (Goldsmith and Leblanc,
2004)). However, this is a valid starting point only
if computerised therapy tools would indeed have ben-
eficial results. This had been shown to be the case, as
we briefly point out below.
82
van Zijl L. and Chamberlain M. (2010).
A GENERIC DEVELOPMENT PLATFORM FOR ASD THERAPY TOOLS.
In Proceedings of the 2nd International Conference on Computer Supported Education, pages 82-89
DOI: 10.5220/0002793800820089
Copyright
c
 SciTePress

2.1 Computerised ASD Therapy Tools
The use of virtual environments as teaching tools for
individuals with and without special needs has been
extensively researched – see for example (Cobb et al.,
1998). General consensus is that virtual environments
can be advantageous as teaching tools, given careful
design of the interface and sound underlying educa-
tional principles (Kerr et al., 2002). A number of
studies had also been undertaken to investigatethe use
of virtual environment teaching tools specifically for
individuals with ASDs (Moore et al., 2000; Parsons
and Mitchell, 2002; Parsons et al., 2007; Strickland,
1997). Again, these studies conclude that virtual envi-
ronment teaching tools are advantageous given care-
ful attention to the design.
For example, (Parsons et al., 2007) built two vir-
tual social scenarios, namely, a bus and a cafete-
ria. The scenarios were both goal-based. Participants
had to negotiate a social environment to reach the
goal of, respectively, boarding the bus and obtaining
food. The study showed that structured, goal-oriented
VEs enabled participants to repeatedly practise skills.
Moreover, these skills were transferred to real life sit-
uations with relative ease.
Given supporting evidence that VEs can be use-
ful in ASD therapy, we next consider the technical
challenges faced in the development of such a VE. As
computer game engines typically contain all the com-
ponents required in such a VE, we consider the design
of some existing game engines.
2.2 Existing Game Engines
In our development of a generic VE, we could either
use existing software, or create our own. Since there
are already many open-source game engines avail-
able, our initial approach was to find a suitable en-
gine, and simply build the rest of the project on such
an engine. We therefore evaluate some existing game
engines in this section.
The Open Game Engine (OGE) is an open-source
communityproject that strives to create a powerful 3D
computer game engine (The OGE Community, 2008).
It has several features that we require, such as high-
level scripting language support. OGE makes exten-
sive use of proven open-source projects, such as the
Object-oriented Graphics Rendering Engine (OGRE)
and Open Input System (OIS). The use of OGE for
our research initially seemed promising. However, at
the time of writing the engine is not stable, and is un-
dergoing a complete redesign.
Panda3D (The Panda3D Development Team,
2008) is a 3D game engine originally developed by
Walt Disney Entertainment, but is currently main-
tained at Carnegie Mellon University. Panda3D is an
extensive 3D game engine that has been used in com-
mercial projects, such as Pirates of the Caribbean On-
line.
The Panda3D engine has many desirable features,
including scene graphs, a task oriented structure, an
audio system, collision detection and a physics en-
gine. The Panda3D engine is programmed in C++,
but the engine has a full Python interface that is au-
tomatically generated from the C++ interface. While
Panda3D is a full-featured engine with excellent func-
tionality, we found that it would be difficult to extend.
Also, it is a large and complicated system that would
be difficult to install on older computers. Lastly, the
documentation on the engine was lacking.
The Enginuity Engine (EE) (Fine, 2008) is an
open-source engine implemented in C++. The design
and development of the engine is well-documented.
Game State
Local Communication
Local Communication
Client
Server
Video
Task
Input
Task
Clock
Task
Sound
Task
App State
Task
Current
App State
Task
Manager
Settings
Kernel
Memory
Manager
Logger
Remote
Communication
Remote
Communication
Figure 1: Design diagram of the Enginuity Engine.
The design of the EE is outlined in figure 1, taken
from (Fine, 2008). The design is focused around a
number of tasks that provide services to the engine as
a whole. The core of the engine is called the kernel.
The kernel manages the execution of tasks. A list of
common tasks is given in figure 1. The order of task
execution is determined by the priority of each task.
The EE uses a direct communication model (tasks
call functions from other tasks directly) and favours
a single-threaded engine design.
The design of the EE satisfies many of the re-
quirements for our virtual environment engine as it is
generic and easy to extend or adapt for specific needs.
However, the EE is intended as a technical example
of a design for a good game engine, and not as a com-
plete engine itself. For example, it only includes lim-
ited graphics rendering capabilities, it would require
A GENERIC DEVELOPMENT PLATFORM FOR ASD THERAPY TOOLS
83

extensive adaptation to link to libraries like OIS and
OGRE, and it is single-threaded (see our discussion
in section 3 on the advantages of multi-threading).
Crystal Space (The Crystal Space Community,
2009) is a cross-platform graphics and game engine.
It is a mature library with many features. Crys-
tal Space can be extended by plug-ins. Some no-
table plug-ins that have been implemented for Crystal
Space include an audio plug-in and a physics engine
plug-in using the Open Dynamics Engine. The engine
also has a number of wrapper libraries that enables its
use from scripting languages such as Python. Crystal
Space does not have built-in functionality for replays
and data capturing. Furthermore, its existingnetwork-
ing support is not at the level that we require.
The Object-oriented Graphics Rendering En-
gine (Streeting et al., 2009; Junker, 2006) is a cross-
platform open-source graphics rendering engine. It is
a mature library that has been in development for a
number of years. It was designed to have a simple
API. Although OGRE is not a full game engine, it has
an active community that has developed a number of
high-quality add-ons. Examples of these add-ons in-
clude MyGUI, a graphical user interface add-on, Nx-
OGRE, an Nvidia PhysX based physics engine add-
on and OgreOggSound, an OpenAL (Creative Labs,
2009) based audio add-on. Therefore, one could use
OGRE and a number of its add-ons to provide a ma-
jor portion of the basic functionality of a game engine.
The advantage of this would be the fact that it would
offer more control over the interface and the size of
the ultimate platform than if we were to use a com-
plete game engine.
In recent years the online social networking phe-
nomenon appeared. An example of such a system is
Second Life (Linden Labs, 2009). Second Life al-
lows users to connect to an online virtual world. Users
are represented by avatars and can interact with other
users in the virtual world. The Second Life client is
available as open-source, and thus it should be possi-
ble to extend the client to suit our needs. However,
the cost of bandwidth in South Africa makes the use
of an online system prohibitive. Furthermore, in the
case of ASD therapy tools, we require a level of con-
trol over the virtual world that would not be attainable
in an online solution.
We therefore opted to build our platform with
OGRE and its add-ons as the base. We largely base
the design of our platform on the design of the EE,
but with some of the desirable features from OGE,
Panda3D and Crystal Space included.
In the next section we shift the focus of the discus-
sion to the design and implementation of our engine
and virtual environment platform.
3 DESIGN
As stated above, our engine uses OGRE and a num-
ber of its add-ons as a base. The remainder of the
engine design is based strongly on the Enginuity En-
gine (Fine, 2008), with the notable exception that our
engine is multi-threaded. This implies that different
modules and classes in the engine communicate us-
ing a message-passing system, as opposed to the EE
which uses direct communication. Multi-threading
allows for different threads to execute simultaneously
and on different cores. This allows for better synchro-
nization between, for example, video and sound, and
in general improves the reaction times in the therapy
tools.
An engine such as ours is responsible for man-
aging various types of activities. These activities in-
clude: management of input received from input pe-
ripheral devices, playing audio, executing scripts and
game logic and rendering graphics. In order not to re-
invent the wheel, we opted to use a number of proven
third party libraries to manage some of the above
mentioned activities. These include OIS for manag-
ing input and Nvidia PhysX for physics and collision
detection.
In order for the engine to effectively perform its
duties, and remain reasonably generic and extensible,
we opted to use a design paradigm similar to those
found in an operating system (Gagne et al., 2005),
namely, using a kernel and a set of tasks. This ker-
nel and task paradigm is also used and promoted in
the EE (Fine, 2008) (see section 2).
The core of the engine consists of a kernel and a
set of tasks. Tasks are divided into two categories,
namely, sequential tasks and concurrent tasks. The
kernel is responsible for managing the execution of
each task. Sequential tasks are executed in a round-
robin fashion by the kernel and in the same thread as
the kernel. Each concurrent task has its own thread
and is executed in parallel with the kernel thread.
Some common tasks include:
Timer task: keeps track of the amount of time that
has passed during engine execution and between
rendered frames.
Input task: manages the various peripheral input de-
vices.
Video task: the video task is responsible for render-
ing the virtual environment to the screen.
Tasks communicate via a message-passing sys-
tem, primarily to avoid synchronisation issues with
direct communication. The internal communication
model of the engine is discussed in section 3.1.
CSEDU 2010 - 2nd International Conference on Computer Supported Education
84

In order to control a task, or send messages be-
tween tasks, we require a management application
programming interface (API). Thus most tasks have
an associated manager class that is used to control
tasks. An example would be a manager class that
sends a message to the video task, instructing it to
change the screen resolution. Certain classes that are
not tasks, but also require some form of management,
also have manager classes (the kernel is an example
of such a class). The kernel manager provides func-
tions for adding, removing, suspending and resuming
tasks in the kernel.
In figure 2 we give an overview of the design of
our engine with respect to the elements we have dis-
cussed. In the following sections we discuss these el-
ements in more detail.
Kernel
Timer Task Input Task
Physics Task Video Task
Sequential Tasks
Network Transmit
Task
Concurrent Tasks
Network Listen
Task
Audio Task
Messages
Kernel Message
Network Message
Input Message
Managers
Kernel Manager
Notification
Manager
Network
Manager
Figure 2: Design overview of our engine.
3.1 Internal Communication
In the Enginuity Engine (Fine, 2008), a direct com-
munication model is used to facilitate communica-
tion between the various systems and tasks. Although
this approach is simple to implement, it provides no
rules or API to follow when new systems are added to
the engine. Also, with the introduction of concurrent
tasks in multiple threads in our engine, it became es-
sential to have a more robust form of communication.
The message-passing system we designed con-
sists of a notification manager class, various message
queues and various message types. Objects must reg-
ister to receive messages. When registering, the ob-
ject must provide the type of messages it wishes to re-
ceive and provide a function that is to be called when
such a message is received. Objects can register to
receive any number of message types.
Messages can be delivered synchronously or asyn-
chronously. In the synchronous case, the message
handler function for the object is called as soon as
a synchronous message of that type is sent. In the
asynchronous case, all sent messages are queued in-
dependently at each object that has registered to re-
ceive messages of that type. It is then the respon-
sibility of the receiving object to periodically call a
function to process its queue of messages. For each
message waiting in the queue, the message handler
function that the object provided when registering to
receive messages, is called.
Messages of different types are implemented as
classes. Message classes can extend one another. The
only requirement is that all message classes have the
generic Message class as their base class.
3.2 The Game Object Model
The game object model is a hierarchy of classes, start-
ing with a generic and extensible base class, that can
be used to construct any in-game object. We providea
basic set of generic classes in the hierarchy. If the ba-
sic functionality does not satisfy the requirements for
a specific situation, new classes can be derived from
the existing ones. Figure 3 illustrates the hierarchy.
GameObject
Actor
GameActorObject
GameBodyObject
GameCharacterObject
Figure 3: The hierarchy of classes that represent the various
types of objects in the virtual world.
The base class of the hierarchy is the GameObject
class. The GameObject is the most basic class that
can be used to construct representable virtual objects,
such as tables and chairs, for the virtual world. The
GameObject does not provide any mechanisms to al-
low for visualisation. The GameBodyObject is the
first class in the hierarchy to add such functionality.
The GameActorObject extends the GameObject
class to include functionality that is associated with a
so-called actor. The concept of an actor comes from
the underlying physics system that we use, namely,
the Nvidia PhysX engine. The Actor class that is
visible in the hierarchy is merely a wrapper class that
implements the functionality of a PhysX actor in our
engine. Actors in the virtual world can be described
as those objects that have the following properties: a
position, an orientation, a velocity, shape, and mass.
Actors do not have any visualisation associated with
A GENERIC DEVELOPMENT PLATFORM FOR ASD THERAPY TOOLS
85

them: one cannot see an actor on its own. A body
is simply an extension of an actor and includes some
form of visualisation.
Therefore, the GameActorObject class extends
the GameObject class and the Actor implementation
from the physics engine. The GameBodyObject class
then extends the GameActorObject class and adds
the required functionality (support for setting a 3D
model and textures) so that the object can be rendered
by the 3D engine.
During execution of a game or tool implemented
with the engine, many class instances derived from
the GameObject class will be created and destroyed.
In order to manage the creation of these different
GameObjects, we use an abstract object factory.
3.3 Abstract Object Factories
An abstract factory is: “a class that provides an inter-
face for the creation of families of dependent objects
where the concrete class of the object to be created
is not specified” (Gamma et al., 2007). We use an
abstract object factory to manage the creation of in-
stances of objects in the GameObject hierarchy. The
factory keeps a reference to all instances it creates.
This allowed us to extend the functionality of the fac-
tory and allow for searching and destroying of in-
stances that were created by the factory.
3.4 Networking
Our therapy tools are typically single-user applica-
tions, with networking (such as in massively multi-
player online games) not an issue. However, during
our initial research and planning of the project, ther-
apists indicated that optional remote monitoring and
control over the games and tools would be a desirable
feature. For example, in a therapy session, a therapist
might wish to pause a tool at a certain point to discuss
the user’s choices.
The requirements of the network component in
our engine is therefore to allow at least one remote
user to connect and perform some administrative ac-
tions. We hence implemented a simple peer-to-peer
based network model with the intention to keep it as
transparent as possible. Remote players are added to
the game as if they are local players with their own
keyboards or mice. Game and tool implementers only
have to, upon the connection of a new user or dis-
connection of a user, ensure that its unique local data,
such as a player avatar, is created or destroyed on the
remote host. After the connection is established, the
network components in the engine will take care of
communication among peers. All relevant internal
messages are forwarded to all connected peers. The
philosophy is to make all hosts believe that all of the
remote users are actually local.
Such a peer-to-peer model generally does not
work for fast-paced games with a substantial num-
ber of players, since synchronisation problems can
easily occur. In our case we shall generally have no
more than two users in a session and the network in-
frastructure will be at least a 10Mbps reliable local
area network. Thus occurrences of synchronisation
issues should be minimal. A possible extension to this
model would be to assign one of the peers as a quasi-
host that periodically sends a more complete state to
all other peers to ensure that peers remain synchro-
nised. This would enable the engine to easily handle
a classroom-like situation, with ten to twenty users.
3.5 Scripting
One of the objectives of this project is to provide a
platform for the creation of educational games and
ASD therapy tools without the need for extensive pro-
gramming knowledge. A first step necessary to ac-
complish this objective, is to make the lower-level
C++ API accessible in high-level scripting languages.
Our language of choice, for its relative simplicity and
speed, is Lua (Ierusalimschy et al., 2006).
The development of educational games and ther-
apy tools with scripting languages gives some ad-
vantages overtraditional compiled languages (Ouster-
hout, 1998). Scripting languages are generally inter-
preted languages, which means we do not have the
overhead of recompiling the program to change pa-
rameters or fix errors. An added benefit of interpreted
scripting languages is that it allows us to design the
engine to run a level or scenario as a script. There-
fore, new content can be added to a game or tool, as
scripts, without the need to recompile the engine.
In order to offer a versatile scripting component
in the engine, we opted to use the simplified wrapper
and interface generator (SWIG) (Beazleyet al., 2009).
SWIG allows one to link a C or C++ application to
many different scripting languages by using interface
files to define the API of the application. Using SWIG
we have created Lua and Java wrappers for the engine.
Exposing the engine to scripting languages also
paves the way for middleware that can be developed
to simplify the development of games and therapy
tools. The software on this middleware layer can be
used to create a game or therapy tool, and the result
would simply be scripts that would be executed by the
engine. We are currently designing a visual program-
ming environment on this middleware layer.
CSEDU 2010 - 2nd International Conference on Computer Supported Education
86

3.6 Graphical User Interface
We use a third party library for the creation, manage-
ment and rendering of our graphical user interfaces
(GUIs), namely, MyGUI (Evmenov, 2009). MyGUI
is an add-on for OGRE and is being maintained by an
active community of developers. The MyGUI library
supports many common GUI widgets, such as win-
dows, buttons and text boxes. MyGUI also includes a
so-called layout editor: a point and click application
for creating GUIs.
The appearance of MyGUI widgets is determined
by so-called skins. These skins are customisable.
This customisability is important, since individuals
with ASD might find GUIs with certain traits (such
as flashing icons) distracting and unusable (Lazar,
2007).
3.7 Replays and Data Capturing
Discussion with various therapists and teachers
stressed the importance of feedback from the engine
with regards to the actions of the child working with
one of the therapy tools. We therefore implemented
an extensive specialised action data capturing system
in the engine. On a per-user basis, for each game
or therapy tool, the engine provides a replay mod-
ule. The therapists can use the replay facility to see
the actions that a user took while playing a game or
while engaged in a session with a therapy tool. We
also support the data capturing of certain aspects of a
game or tool, such as how many mistakes a user made
before reaching the correct solution. Our data cap-
turing system can easily define data capturing actions
when creating a game or tool, so that every game or
tool can have fully customised data capturing.
3.8 Multilingualism
Since ASD therapies are language and culture depen-
dent, our engine must support a component through
which games and therapy tools can be made avail-
able in multiple languages. To that end we include a
language localisation component in our engine. This
component operates in a similar fashion to GNU get-
text (GNU, 2009). Files are used to map a phrase from
the default language into a target language. During
run-time the user can then select a desired language
and the component will use the language files to dis-
play all text in the selected language.
3.9 Engine Implementation
We implemented our engine as described in the design
above. From the design it follows that adding new
systems to the engine requires the creation of classes
(that possibly extend some existing base classes in
the engine) and making use of the message-passing
model for communication. Following this approach
to adding new features, the engine was implemented
in various iterations, adding more functionality to
the engine with each iteration. The inclusion of the
physics system is an example. For the physics sys-
tem the actor paradigm was introduced into the game
object model, and a physics task was added to the en-
gine. The success of this iterative approach provides
an indication of the modularity and extendability of
the engine.
After detailed modular testing, we continued with
the implementation of games and therapy tools on the
engine. The aim was to further test the implementa-
tion, and also to make sure that the design was appro-
priate. We briefly describe these test implementations
in the next section.
4 GAME AND THERAPY TOOL
IMPLEMENTATIONS
In order to test our platform we implemented two
therapy tools and one educational game. The first
therapy tool involved the computerisation of a num-
ber of worksheets from a popular workbook for indi-
viduals with ASD, namely I am Special (Vermeulen,
2000). This implementation was completely pro-
grammed in Lua and tested the scripting language in-
terface, GUI and data capturing. A screen capture of
one of the computerised worksheets is shown in fig-
ure 4.
We implemented a basic educational game, aimed
at first grade learners, using our platform. The game
was designed in partnership with a local school. The
game presents learners with a number of exercises,
similar to what they would encounter in a classroom
situation. If the learners successfully complete an ex-
ercise, the story of the game advances. The logic of
the game was implemented in Lua. All text in the
game is available in multiple languages and in audio
for those learners that cannot yet read at a satisfactory
level. A further feature that is tested in the game is
that of data capturing. All of the attempts and answers
learners give to exercises are captured. In summary,
the game tests the rendering capabilities of the engine,
audio playback, input, language localisation and data
capturing.
A GENERIC DEVELOPMENT PLATFORM FOR ASD THERAPY TOOLS
87

Figure 4: A screen capture of the I am Special tool.
A screen capture of the game is shown in figure 5.
The game was tested at a local school for a period
of 20 days during which no failures of the platform
occurred. Teachers were very positive about its use
and indicated that theyfound the data capturing aspect
useful.
Figure 5: A screen capture from the Journey to the Moon
game.
The second therapy tool we implemented is simi-
lar to virtual environments implemented by (Parsons
et al., 2007) that aimed to teach social skills to indi-
viduals with ASD.
We implemented a restaurant scenario where the
user must order food, pay for it and find a place to sit.
A replay of the session is recorded. The tool also sup-
ports remote monitoring over the network, but at this
stage no remote control or administration is possible.
A screen capture of the restaurant scene is shown in
figure 6.
5 FUTURE WORK
We are currently engaged in the design and im-
plementation of a visual programming environment
Figure 6: A screen capture of the restaurant scene.
which will be used to visually create games and tools
based on the engine. The output of the program will
be a set of Lua scripts that can be executed by the
engine. Our visual programming language will be
loosely based on other successful implementations
such as Alice (Cooper et al., 2000) and Scratch (Mal-
oney et al., 2004).
Another current project on the virtual environ-
ment platform involves the creation of an avatar
with definable neurologicalcharacteristics, and a rule-
based reasoning system to control the avatar’s be-
haviour. We envisage the avatar being used in ASD
behavioural research.
6 CONCLUSIONS
In this paper we presented a design and implemen-
tation of a generic and extensible 3D virtual environ-
ment engine that is intended to be used for the creation
of educational games and therapy tools for individu-
als with ASDs. The engine is generic and extensible
and fully supports various scripting languages, sim-
plifying the development of games and tools and also
increasing the general customisability of implementa-
tions created with the engine.
We implemented three different therapy tools with
the engine, to serve as a basic test of the major func-
tionality of the engine. In addition, we are in the pro-
cess of developing a visual programmingenvironment
on top of the engine, to ease the development of fur-
ther therapy tools.
All our results up to now indicate that our intended
goal, namely, to develop a generic open-source 3D
virtual environment platform, has been reached. It re-
mains to develop more middleware, so that the plat-
form can become more user-friendly for the develop-
ment of additional therapy tools.
CSEDU 2010 - 2nd International Conference on Computer Supported Education
88

ACKNOWLEDGEMENTS
The financial assistance of the National Research
Foundation under research grant number 65856 to-
wards this research is hereby acknowledged. Opin-
ions expressed in this paper and conclusions arrived
at are those of the authors and not necessarily to be
attributed to the National Research Foundation. The
financial support of the Wilhelm Frank Foundation is
also gratefully acknowledged.
REFERENCES
Beazley, D., Fulton, W., Betts, O., Lenz, J., Gos-
sage, M., Wang, J., et al. (last accessed in March
2009). Simplified Wrapper and Interface Generator.
http://www.swig.org.
Cobb, S. V. G., Neale, H. R., and Reynolds, H. (1998). Eval-
uation of Virtual Learning Environments. In Proceed-
ings of the 2nd European Conference on Disability,
Virtual Reality and Associated Technologies, Sk¨ovde,
Sweden, pages 17–23.
Cooper, S., Dann, W., and Pausch, R. (2000). Al-
ice: a 3D Tool for Introductory Programming Con-
cepts. In Proceedings of the Fifth Annual Consor-
tium for Computing Sciences in Colleges – Northeast-
ern Region (CCSCNE), Ramapo, New Jersey, USA.
http://www.sju.edu/ scooper/alice/ccscne00.pdf.
Creative Labs (last accessed in July 2009). OpenAL.
http://connect.creativelabs.com/openal/default.aspx.
Evmenov, G. (last accessed in July 2009). MyGUI.
http://sourceforge.net/projects/my-gui/.
Fine, R. (last accessed in March 2008). The Enginuity
Engine. http://www.gamedev.net/reference/program-
ming/features/enginuity1/.
Gagne, G., Galvin, P., and Silberschatz, A. (2005). Operat-
ing System Concepts. Wiley.
Gamma, E., Helm, R., Johnson, R., and Vlissides, J.
(2007). Design Patterns: Elements of Reusable
Object-Oriented Software. Addison-Wesley, Indi-
anapolis, IN.
GNU (last accessed in March 2009). Gettext.
http://www.gnu.org/software/gettext/.
Goldsmith, T. and Leblanc, L. (2004). Use of Technology
in Interventions for Children with Autism. Journal of
Early and Intensive Behavior Intervention, 1(2):166–
176.
Ierusalimschy, R., De Figueiredo, L., and Celes, W. (2006).
Lua 5.1 Reference Manual. Lua.Org, Rio de Janeiro,
RJ, Brazil.
Junker, G. (2006). Pro OGRE 3D Programming. Apress,
Berkely, CA, USA.
Kerr, S. J., Neale, H. R., and Cobb, S. V. G. (2002). Vir-
tual Environments for Social Skills Training: the Im-
portance of Scaffolding in Practice. In Proceedings
of the Fifth International ACM Conference on Assis-
tive Technologies, Edinburgh, Scotland, pages 104–
110. ACM.
Lazar, J. (2007). Universal Usability. Wiley.
Linden Labs (last accessed in March 2009). Second Life.
http://secondlife.com/.
Maloney, J., Burd, L., Kafai, Y., Rusk, N., Silverman, B.,
and Resnick, M. (2004). Scratch: a Sneak Preview. In
Proceedings of the Second International Conference
on Creating, Connecting and Collaborating through
Computing, Kyoto, Japan, pages 104–109.
Moore, D., McGrath, P., and Thorpe, J. (2000). Computer-
Aided Learning for People with Autism – a Frame-
work for Research and Development. Innovations in
Education and Teaching International, 37:218–228.
Ousterhout, J. (1998). Scripting: Higher-Level Program-
ming for the 21st Century. IEEE Computer, 31(3):23–
30.
Parsons, S. and Mitchell, P. (2002). The Potential of Vir-
tual Reality in Social Skills Training for People with
Autistic Spectrum Disorders. Journal of Intellectual
Disability Research, 46:430–443.
Parsons, S., Mitchell, P., and Leonard, A. (2007). Using Vir-
tual Environments for Teaching Social Understand-
ing to 6 Adolescents with Autistic Spectrum Disor-
ders. Journal of Autism and Developmental Disorders,
37(3):589–600.
Streeting, S. et al. (last accessed in July 2009). Object Ori-
ented Graphics Engine. http://www.ogre3d.org.
Strickland, D. (1997). Virtual Reality for the Treatment of
Autism. Studies in Health Technology and Informat-
ics, 44:81–86.
The Crystal Space Community (last accessed
in March 2009). Crystal Space 3D.
http://www.crystalspace3d.org.
The OGE Community (last accessed in
April 2008). The Open Game Engine.
http://www.opengameengine.org.
The Panda3D Development Team (last accessed in April
2008). Panda3D. http://www.panda3d.org.
Vermeulen, P. (2000). I Am Special: Introducing Children
and Young People to Their Autistic Spectrum Disor-
der. Jessica Kingsley Publishers.
A GENERIC DEVELOPMENT PLATFORM FOR ASD THERAPY TOOLS
89