A Grid Computing for Online Games Rafael García Leiva Ismael Herrero Rodríguez David Muriel Álvaro
Paul Warren Ivan Djordjevic Theo Dimitrakos
Andago Ingeniería SL C/ Alcalde Ángel Arroyo 10, 2-4 28901 Getafe (Madrid Spain) +34 91 601 13 73
British Telecom Adastral Park, Martlesham Heath Ipswich, Suffolk IP5 3RE, United Kingdom +44(0)1473609591
[email protected]
Melanie Biette Atos Origin SA Av. Diagonal 210-128 08011 Barcelona (Spain) +34 93 504 35 68
[email protected]
[email protected]
Matteo Gaeta Nadia Romano CRMPA Università degli Studi di Salerno via Ponte Don Melillo, 84084 Fisciano (Sa) Italy +39 089964230
[email protected] Andago Ingenieria SL has developed the Andago Games Platform, an open source platform which provides the necessary technological base for provisioning online game services based on service strategies like user loyalty, or based on business strategy models like subscriptions or micro payments. By using common accounts, names, user interfaces, and policies for all the games (or from each publisher), a disjointed and confusing experience is avoided.
ABSTRACT Andago Ingeniería SL has developed the Andago Games Platform [1], an open source platform which provides the necessary technological base for provisioning online game services based on service strategies like user loyalty, or based on business strategy models like subscriptions or micro payments. However, the platform requires important investments by operators and portals, limiting the number of possible customers. Grid computing will reduce dramatically the amount of these investments by means of sharing resources among different operators and portals. Also, Grid computing offers the possibility to create virtual organizations, where operators and portals could share games and contents, and even their users base.
However, the platform requires important investments by operators and portals, limiting the number of possible customers. Grid computing will reduce dramatically the amount of these investments by means of sharing resources among different operators and portals. Also, Grid computing offers the possibility to create virtual organizations, where operators and portals could share games and contents, and even their users base.
Categories and Subject Descriptors J.m [Computer Applications]: Miscellaneous.
1.1
General Term
Grid computing is a new distributed computing paradigm to solve large-scale computation problems. Grids take advantage of having many interconnected computers, modeling a virtual computer where the execution of processes can be distributed in a parallel infrastructure. Grid technology uses resources from multiple individual computers, interconnected through a network, to solve large-scale problems in a global environment. Grid computing provides the capacity to manage large datasets, by dividing them into smaller subsets, or the ability to perform multiple calculations simultaneously, by executing jobs in parallel among different processors.
Algorithms, Design, Standardization.
Keywords Online games. CD-ROM based games. Grid computing.
1.
Grid Computing
INTRODUCTION
With the fast growth of the video games and entertainment industry - thanks to the appearance of new games, new technologies and innovative hardware devices - the capacity to react becomes critical for competing in the market of services and entertainment. Therefore it is necessary to be able to count on advanced middleware solutions and technological platforms that allow a fast unfolding of custom made entertainment services.
Grid computing allows to share resources in a coordinated, secure an flexible way, among groups of individuals and institutions that change dynamically. This is normally know as Virtual
1
servers and configure the specific characteristics for each match.
Organizations: a non-fixed group of individuals and institutions that share resources in order to achieve a common goal. The Open Grid Forum (OGF) is the community of users, developers, and vendors leading the global standardization effort for Grid computing. The main standards proposed by OGF are:
x
Advanced statistics: the platform collects advanced statistics of the games played by the users generating rankings and statistics.
x
OGSA (Open Grid Services Architecture [2]): integrates key Grid technologies with web services to create a framework based on distributed services. The OGSA vision is to describe and build a new set of standard interfaces and well defined procedures that constitute a common framework for all the applications and Grid systems.
x
Automatic game launch: the users have information in live time about the matches in existence and can connect to them without having to configure the connection. The platform launches the games in the user's terminal and connects it to the selected server with the correct configuration.
OGSI (Open Grid Services Infrastructure [2]): define mechanisms to create, manage, and interchange information among entities called Grid services. OGSI also introduce new methods and standard interfaces to create and distribute Grid services. Recently, OGSI has been updated to follow a more web services oriented approach, becoming WSRF (Web Service Resource Framework [3]).
x
x
Clans: the users will be able to select enemy users, ignored users or form clans of friends.
x
Championships, downloads, chat, etc.
2.
2.2
Functionalities
Beside to user's services, the platform counts on management tools that will allow operators and system technicians to easily manage the service. Using these tools administrators will be able to:
ANDAGO GAMES PLATFORM
Andago has developed the open source online games platform Andago Games that provides the technological base necessary for the creation of online games services around which the main entertainment sites will be able to establish solid business models.
x
Domain Management: Using the domains, virtual platforms within a physical platform will be able to be created, which will allow resources to be assigned to services and the creation of house branding or ASP games channels.
x
Management of users: The administrator will have access to the list of users and their specific data. Through the administrator restrictions of access, invoicing or platform use will be able to be created.
x
Management of servers and games: The channel manager will be able to decide at any moment what resources should be available and to which players. The administrator will be able to start up or close down servers and matches of the different games supported.
x
Management of events: Events such as championships, tournaments or leagues according to the specifications of contract of services, use or statistics of games will be able to be created.
Figure 1. Andago Games Platform
2.1
Services for the User
The platform Andago Games allows to quickly create online multiplayer games channels with the following services for the final user: x
x
Pay per play / pay per subscription: the system allows the managing of access and connection times of users based on various price fixing policies. Policies for quality of service for different profiles of users can also be defined.
Figure 2. Andago Games Modules
Reserving of gaming rooms or servers and advance management of games: the users will be able to access games
2
2.3
Architecture
2.4
The Andago Games platform is composed of the following elements: x
User access site: The main interface of the user with the platform is the web channel. By means of this channel the user can access the different services of the platform available according to his profile (personal information, rankings, clans, championships, reserves, chat, and servers / games available).
x
Games Launcher: The Launcher, which could be offered as a plugin or as a standalone application, will take care of the initiating, the configuring, and the connecting of the players in the client's machine. This module obtains IP addresses, ports and types of the different matches available on the platform. Likewise it collects data on the games installed by the user in order to start the correct game or to download the necessary patches.
x
Lobby Server: The Lobby Server centralizes the logic of the platform and interacts with the rest of the modules of the platform: User channel, Launcher, Administrators, Watchers and Games servers. The communications with the Lobby Server through Internet are done by means of a communications module, the Console, which gathers commands in a communication protocol (based on SSL and TCP/IP) and converts them in CORBA Platform commands. The Lobby Server can share its data model to integrate the platform with systems of supply, invoicing, CRM, etc.
x
Administration Web: The administration of the platform is done by means of a web-based administration module, with support for different profiles of administrators and operators. This module makes it possible to manage the service defining domains, characteristics of servers, games, matches, reservations, user profiles, tournaments, conditions, billing, statistics, etc.
x
Watchers: The watchers are installed in the games servers. Their function is the advanced management of games and the obtaining of advanced statistics. The watchers can start up or close down games and matches, control the access of users according to profiles and conditions, and gather data on matches, players, and clans for the production of advanced statistics.
Technology
The Andago Games platform is based fundamentally on a distributed development environment based on J2EE, C, C++ and CORBA. The communications over the Internet are made through ACAP protocol (Andago Games protocol) and the internal communications through CORBA. The default version of the platform uses Linux Red Hat or Debian as the operating system, the applications server JONAS and MySQL as the database. The design of the platform allows the distribution of each one of the modules contributing scalability and load management.
3. GRID COMPUTING FOR ONLINE GAMES The main disadvantage of the Andago Games platform is that it requires important investments by operators and portals, limiting the number of possible customers. Grid computing will reduce dramatically the amount of these investments by means of sharing resources among different operators and portals. Also, Grid computing offers the possibility to create virtual organizations, where operators and portals could share games and contents, and even their user's base. Technically, the goal is to be able to share expensive resources between providers and to allow billing based on usage. From a business perspective our goal is to open new commercial opportunities in the domain of online games. A common problem with online games is that operators, portals and games providers would like to share resources and aim at sharing the costs to optimize their businesses. Yet business entities are generally required to play all business roles. The European market is still too fragmented and it is hard to reach the critical mass of users needed to make online games businesses profitable and to ensure resource liquidity. Having a Grid infrastructure makes it possible to divide tasks among different actors and in consequence each actor could concentrate on the business it knows best. Application developers provide the applications, portal providers create the portals to attract users, and Telcos/ISP will provide the infrastructure required. Such Virtual Organizations allow for profitable alliances and resource integration. The outcome of a grid enabled online games platform will be to provide the middleware to make this collaboration happen. The Grid ensures not only decreasing costs for businesses, but allows for creating a global European market as applications, infrastructure and users can be shared independently of political and social borders, smoothly integrated and better exploited. There are also big advantages for users. For example, they will have a larger games offer, better quality of service and certainly cheaper services. Grid centralized portals would provide thousands of games and entertainment content from different providers. Today, if one buys a new game and wants to play it online, the user has to connect to a server (possibly) in the USA, unless a local server was set up. Having a Grid infrastructure would largely ease that process. Users will simply connect to the Grid, play and join the international community of users.
Figure 3. Andago Games Architecture
3
4.
from potentially different ASPs that are can be provided in distinct contexts and distinct federations that meet different security and quality of service requirements, as required.
BEINGRID
BEinGRID, Business Experiments in GRID, is the European Union's largest integrated project funded by the Information Society Technologies (IST) research, part of the EU's sixth research Framework Programme (FP6). The BEinGRID consortium is composed of 75 partners who are running eighteen Business Experiments designed to implement and deploy Grid solutions in industrial key sectors.
x
Internet-based gaming offers challenging features such as interactivity with multi-players, low latency requirements, highperformance servers for game execution. Thus, a gaming platform will be a suitable driver for the technological and commercial impact evaluation of the business experiment.
The mission of BEinGRID is to establish effective routes to foster the adoption of Grid technologies across the EU and to stimulate research into innovative business models. To meet these objectives, BEinGRID will undertake a series of targeted business experiments (BEs) designed to implement and deploy Grid solutions across a broad spectrum of European business sectors (entertainment, financial, industrial, chemistry, gaming, retail, textile, etc). Eighteen business experiments are planned at the outset of the project with a second competitive call for proposals in the latter stages.
The experiment will selectively reuse SOA (Service Oriented Architecture) middleware components and R&D experience of FP5 and FP6 European projects including GRASP [2], TrustCoM [3] and EleGI [4]. Andago acts as an end-user and online games expert, and aims to significantly reduce infrastructure costs and to analyze the viability of a common European base of games users. BT participates in the project as a web services and security design expert, and following the experiment it aims to offer elements of the VHE as common capabilities over a converged network. Atos Origin participates as a technological IT integrator and aims to analyze the applicability of VHE solution to other economical sectors. CRMPA acts as technology provider and Grid expert developer in .NET environments.
The overall result of the project will be a collection of key middleware components, Grid solutions and successful case studies resulting from the real-world pilots and the best-practice guidelines derived from the Grid pilot experiences. The creation of the toolset repository that gathers high-level services, new tools and innovative Grid application solutions will result in a Grid market place enabling individuals and organizations to create, provide and use Grid technologies to meet their business challenges.
4.1
The main technical challenges, to be addressed through use of standards-based Grid and Web Services technologies, are:
Business Experiment 09
Focusing on the leisure and entertainment sector, the Beingrid Business Experiment 09 will build and assess a distributed application hosting environment that enables network-centric Application Service Providers (ASP) to deploy and manage their services in secure and accountable way. In particular internetbased multi-player gaming has been chosen as the targeted application area.
BE09 aims to provide distributed virtual hosting environment (VHE) that allows securely exposing applications as a managed services and enforcing quality of service in dynamic federations of users, application service providers and application hosts.
x
x
From a converged IT and communication services provider's perspective, this innovation has the potential to create a new market of network-hosted infrastructure services that are offered as common capabilities over the network, that enable the VHE operation and life-cycle management.
From an application service provider's perspective, this innovation allows businesses to provide, manage and control own application services, while outsourcing service deployment and management, security, and contact enforcement to the infrastructure services hosted by the network. In addition, they can take advantage of the distributed VHE in order to dynamically scale and load balance by distributing the hosting of their resource intensive or response time constrained application. From an application host provider's perspective, this innovation allows businesses to optimize the use of their resources by accommodating diverse application services
4
x
To architect scalable solution, for efficient and reliable game execution over distribute Virtual Hosting Environments.
x
To implement a Virtual Hosting Environment supporting the operation and life-cycle management for federations of Common Capabilities, Game Servers, and Game Instances, and ensure the applicability of the result across vertical markets.
x
To provide a suitable model for securely aggregating: Groups of gaming servers hosting game instances in virtual hosts; Collections (converged network) services supporting the execution a game instance; Communities of gamers sharing the same game instance; while maintaining the separation of administrative authority and concerns between gamer communities, application service providers, service host providers and the enabling infrastructure.
x
Provision of internet games to the consumer via non-intrusive, secure, pervasive and scalable technology.
x
The business experiment combines several technologies: .NET, Java, CORBA, Web Services, Grid.
5. CURRENT STATE AND EXPECTED RESULTS
6.
ACKNOWLEDGMENTS
BEinGRID, Business Experiments in GRID, is a European Union's integrated project, funded by the Information Society Technologies (IST) research, part of the EU's sixth research Framework Programme (FP6).
The open source Andago Games Platform is a production quality middleware that currently can be downloaded from Andago web page [1]. Andago Games Platform has been used in production environments like the Terra online games web portal.
7.
The next generation of the Adago Games Platform, that will include grid computing capabilities, is being developed in two phases. Phase I (expected in second quarter 2007) will allow to distribute games servers in a grid based environment, allowing different game providers to share resources. Phase II (expected in first quarter 2008) will take full advantage of the concept of virtual organizations. The proposed architecture (still in development) for a grid based online games platform is depicted in Figure 4.
REFERENCES
[1] AGP: http://games.andago.com [2] The Physiology of the Grid: An Open Grid Services Architecture for Distributed Systems Integration. I. Foster, C. Kesselman, J. Nick, S. Tuecke, Open Grid Service Infrastructure WG, Global Grid Forum, June 22, 2002. [3] WSRF: http://www.globus.org/wsrf [4] GRASP: http://eu-grasp.net/english/default.htm [5] TurstCoM: http://www.eu-trustcom.com [6] EleGI: http://www.elegi.org
Figure 4. Grid Based Architecture
5
Scaling Online Games on the Grid Jens Muller ¨ and Sergei Gorlatch University of Munster, ¨ Germany {jmueller|gorlatch}@math.uni-muenster.de
ABSTRACT
Most of the game servers have to be manually set up, started and administrated in a static way, which does not allow for automatic service adjustments with regard to the dynamic user demands.
Massively multiplayer online games (MMOG) require large amounts of computational resources for providing a responsive and scalable gameplay for thousands of concurrently participating players. In current MMOG hosting, large datacenters have to be dedicated to a particular game title. Such static hosting requires a huge upfront investment and carries the risk of false estimation of user demand. The concept of Grid computing allows to use resources on-demand in a dynamic way, and is therefore a promising approach for MMOG service hosting to overcome the limitations of static game provisioning. In this paper, we discuss different parallelization mechanisms for massively multiplayer gaming and Grid computing architecture concepts suitable for on-demand game hosting. The work presented here provides both a state-of-the-art analysis and conceptual use case discussion for the new European project edutain@grid. This project targets at scaling real-time interactive online applications and MMOG, including First Person Shooter (FPS) and Real-Time Strategy (RTS) games, in an on-demand manner using a distributed Grid architecture.
1.
We suggest to transfer the concept of Grid computing from the academic and business area to the realm of distributed interactive applications for making hosting of online games dynamic. The term Grid [7] originates from the conceptual analogy to the power grid, where computational power can be as easily and transparent obtained as electricity by inserting a plug into a power socket. Although there are already some commercial game-related Grid systems like Butterfly [2] or the BigWorld system [1] available, these systems target the MMORPG genre and are barely suitable for running FPS or RTS game sessions. An overall consistent Grid approach not only for hosting the various real-time game genres, but ideally all real-time interactive applications including e-learning, interactive simulation and training applications is still missing. Following the idea of Grid computing, the recently started EU-funded edutain@grid project [3] targets at developing a practical Grid infrastructure for all real-time interactive applications including online games. The project’s topics include improved scalability and dynamic hosting of applications, responsiveness of online games as well as business models for making the Grid environment economically viable.
INTRODUCTION
Online gaming has become a major worldwide trend and experienced a massive growth during the past years. According to the game search service gamespy [4], at least 250.000 users are online playing First Person Shooter (FPS) games on more than 70.000 servers at any time of the day worldwide. The Steam platform reports 140.000 servers with more than 2.8 million unique users a month for the games hosted on that platform [5]. In the area of Massively Multiplayer Online Role-Playing Games (MMORPG), the number of players has doubled over the last three years and more than 12 million users are currently subscribed to the different games [15].
This paper summarises our recent work on scalable network architectures for real-time games and discusses scalability dimensions of different online game genres. We present our scalable concept of multi-server game world replication as a feasible approach to scale FPS and RTS games, which so far have been only played in small-scale game sessions. The proxy-server architecture, which we designed as an operational network architecture for our replication approach, provides the basis for our two demonstrator applications: (1) Rokkatan, a scalable RTS-style game and (2) the QFusion Proxy-Architecture, a port of the FPS Quake 2 using our multi-server replication approach. This replication concept will constitute important parts of the real-time computation and communication framework inside the edutain@grid architecture for scaling a variety of interactive online application classes.
While the number of players drastically increases, the basic concepts and technologies of hosting games on the Internet have not been changed since the beginning of online gaming.
The work described in this paper is supported in part by the European Union through the IST 034601 project "edutain@grid".
6
2.
2.2 Game World Zoning
PARALLELISATION APPROACHES TO SCALING ONLINE GAMES
In the zoning parallelization approach, the game world is partitioned into independent zones. These zones are processed in parallel on several servers, such that the game client has to change the server connection if the user moves his avatar into a different zone. Figure 1 illustrates an example of a game world with four zones.
Small-scale sessions of online games usually run on a single game server. This server runs a game-update loop in a periodic manner, in which it has to receive and process all user inputs, process user-independent parts of the game (compute artificial intelligence of NPCs, respawn items, etc.) and send the resulting new state to all game clients. The frequency of the game state update depends on the particular responsiveness requirements of an actual game and ranges from about 5 updates per second for RTS and RPG up to 35 updates per second in fast-paced FPS action games. The update frequency leaves the server a particular maximum time for processing a single loop (less than 30 ms in case of the responsive 35 updates per second): if the server is not able to finish the calculations in time and send the new state back to clients, then the users will immediately be disrupted in their game immersion due to this computational lag.
Server A
Server D
Game World Zone A
Zone D
Server B
Server C Zone C
Zone B
Game Entities
Figure 1: Game World Zoning The game world zoning is usually incorporated in MMORPGs. Regarding the scalability dimensions discussed above, this approach is very suitable for scaling the total number of users and the overall game world size, as long as the users scatter themselves in the huge game world. However, the third dimension of player density is not being scaled, because a particular single zone is only maintained at a single server. If, as for example in an action-oriented FPS game, a lot of players gather together in a large fight, then the corresponding zone server will be congested, similar to the single server in the conventional client-server architecture. Zoning is therefore a suitable and important approach for MMORPG where users are encouraged to spread out because due to advancing avatar level and proceeding quest lines only a particular subset of zones is interesting for a particular user. For action-oriented PvP games, however, zoning is not feasible because users are interested in fighting other players and therefore gather together, which dynamically increases the player density and congests a single zone.
Because the server has to maintain the update rate of the periodic real-time state processing, there is a maximum amount of data which can be processed in time. The computation power of a server is constant, which makes the single-server architecture approach unable to support MMOGs.
2.1 Scalability Dimensions In order to scale a game application, i.e., to increase particular characteristics like the number of players without violating the real-time constraints of the game update loop, the processing has to be parallelised. Before discussing different approaches to parallelisation, we summarize three main scalability dimensions identified in our previous work for different MMOG genres: 1. The overall number of participating users needs to be scalable in every MMO game. All these users are connected to a single game session and generally able to interact with each other.
2.3 Game World Replication Our concept of game world replication [10] is an alternative parallelization approach for scaling the density of players in a real-time game session. In this approach, each server holds a complete copy of the game state as illustrated in Fig. 2 and the processing of entities is distributed among participating servers: Each server has to process its active entities, while shadow entities are maintained at remote servers. After each entity update, the corresponding server broadcasts a corresponding update message.
2. The game world size needs to be scalable in particular in MMORPGs, where the world usually is very large. Scaling the game world size requires increasing (1) processing power for computing actions for more actively computercontrolled entities filling the world and (2) main memory for storing an increasing amount of static terrain geometry and dynamic entities is required. 3. The maximum player density has to be scalable especially in action-oriented Player-versus-Player (PvP) games like FPS. In contrast to the huge game world of MMORPG, these games are played in much smaller environments; users move their avatars where some action is going on, and thus dynamically create local player clusters with a high density. For MMO versions of such PvP games, the player density has to be scalable in order to provide responsive gameplay for situations with a lot of action.
Game World Server A Shadow Entity update
update
There have been different parallelisation approaches discussed in academia as well as implemented in commercial games to scale some of these dimensions for different types of genres. In the following, we briefly discuss the well-known zoning concept and our own replication approach.
7
Active Entity at B
Server B
Shadow Entity
Server C
Figure 2: Game World Replication
3.1 Grid Computing in the Game Area
The replication concept allows to scale the density of players, because the processing amount available for a particular static region of the game world can be increased this way. If players cluster together in a big fight, then the processing of all the interactions and visibility checks is split up among all participating servers. We implemented this approach in our proxy-server architecture [11] and demonstrated its feasibility in our scalable RTS game Rokkatan [10] which can be played by several hundreds of users in a single session on a small game world.
3.
Regarding the area of online computer games, there have been some academic and commercial Grid-related infrastructures developed and presented. Basically, existing approaches can be distinguished to follow one of the following two different concepts:
3.1.0.1 Grids for Single-Server FPS In the current state of the art of FPS game hosting, users rent servers at a flat rate from hosting companies on a monthly basis. Casual users which do not have control over such a server can only play on public servers and are not able to set up an Internet-based session for a closed group of users with their own rules.
GRID COMPUTING CONCEPTS
A computational Grid allows users to access resources (processing power, storage space, network bandwidth, etc.) in an on-demand fashion. Instead of buying resources and setting them up statically and privately inside of academic or business institutions, resources are shared over institutional boundaries by virtual organisations. If a user asks for a particular resource (for example, an SMP server with at least eight CPUs running at 1.2 GHz or higher), then a Grid infrastructure like the Globus toolkit [8] or Unicore [14] acts as a market broker among the user and resource providers for negotiations of resource characteristics, usage time and prices. After successful negotiations, the user can start own computations on the remote server by running a binary copied over or using pre-installed services.
Grid systems for single-server FPS allow users to start FPS game sessions in an on-demand manner for short durations. Instead of statically renting a server at a particular hoster, users specify the game and related characteristics like number of players, private/public game etc. and the Grid system negotiates these requirements with several hosters participating in this infrastructure. After contracting with a particular hoster, the user can configure game-specific settings like the map being played on, the score or time limit to win. The system then schedules the start of a binary game server featuring the user-specific settings according to the booking. Such a Grid system has for example been discussed in [13] and we also presented a prototype of an infrastructure providing this functionality in [12].
We briefly summarize main functional characteristics of Grid systems in the following:
Such a FPS Grid system does not use the general Grid concept to its full potential. Regarding the general features described in Section 3, only the dynamicity of the Grid approach and potentially its accounting is applied to the hosting of a particular subclass of online games. Such a single-server Grid using the available game server binaries can neither scale a single game session nor migrate it onto a different host for overall load balancing. However, it still provides an improvement over the static server hosting and is a first partial demonstrator of what Grids can provide for online game hosting.
• Dynamicity: instead of statically running services regardless of the actual user demand, a Grid allows to automatically start and stop services with respect to the demand and provides resources in a just-in-time manner when they are actually needed by users. • Scalability: in order to provide a high amount of computational power, the goal of modern Grid middleware is to create a virtual cluster of several servers for a single performance-demanding application.
3.1.0.2 Grids for Multi-Server MMORPG
• Checkpointing and Migration: several Grid infrastructures allow to store the state of running user applications, which can be used to periodically checkpoint the state of a long-time computation and restart it from the last state in case of a server crash or other failures. Additionally, this functionality allows to migrate a computation from one host to another, for example for load-balancing purposes.
The user demand for playing a particular MMORPG is dynamic in several dimensions, the most important are: (1) short-time variation of logged-in users depending on daytime and weekday, and (2) changing total playerbase. The first dimension reflects peak usage times of a constant total subscriber number, while the second dimension usually varies more slowly and reflects the game’s overall lifecyle of release, growth, saturation and finally decrease, possibly restarted with the release of expansions. Following these varying user demands, the game provider has to ensure that sufficient computation resources are available.
• Accounting and Billing: users and service providers usually have their own personal account in the Grid infrastructure, which is used for authentication and billing purposes.
In order to provide the required flexibility regarding the setup of an MMORPG, different Grid infrastructures have been proposed and commercially applied, as for example Butterfly.net [2] or BigWorld [1]. These infrastructures provide a server-side API to define game zones and instances and map them to actual server hosts at runtime. In comparison to Grids for single-server FPS, these infrastructures provide more sophisticated functionality of the general Grid
There are Grid systems and middlewares are available which provide the basis for productive Grid environments especially in the academic area, where for example physicians, meteorologist or geologists run computer simulations in an on-demand manner.
8
application instance and therefore results in a parallelisation architecture generally suitable for scaling all classes of multiplayer games.
concept (as summarized in Section 3) to online gaming: They enable dynamic game services, scale a single massively multiplayer session by providing zones and instances and incorporate accounting functionality. However, these Grids are especially targetting MMORPGs and are barely usable for other online gaming genres for which the built-in zoning concept is not appropriate. Additionally, the servers used by a single MMORPG realm still reside at a particular hoster and there is no option to migrate sessions between data centers for load-balancing reasons and for enabling an open market of MMOG hosting.
4.
5. DYNAMIC SCALING OF GAME ENVIRONMENTS
TOWARDS A COMPREHENSIVE INTERACTIVE APPLICATION GRID
Existing game-related Grid infrastructures mainly target a specific MMOG genre. For optimizing the distribution of server processing power for overall online gaming, a comprehensive approach suitable for all classes of online games is required. The recently started edutain@grid project [3] targets at providing the Grid concept with all its features not only to online gaming, but also to other online interactive multi-user applications like e-learning, training and simulation applications.
While the overall architecture illustrated in Figure 3 combines the different scalability approaches, an enclosing Grid infrastructure is still required to provide server resources for the zones, instances and replicas in a dynamic manner. In the following, we illustrate two main use cases of dynamically mapping game world regions to servers resulting from particular user demand and behaviour.
5.1 Dynamic Clustering of Users In Player-vs-Player scenarios using several zones it can be expected that users dynamically gather in a particular area and fight each other. The corresponding zone then should be replicated using several servers for scaling the density of users as illustrated for the bottom right zone in Fig. 4(a).
11 00 00 11 00 11 1 0 11 00 0 1
00 11 0 1 1 0 00 11 00 1 1 0 1 00 11 00 11 00 11 00 11 1 0 00 11 11 00 00 11 0 1 0 1 0 1 00 11 0 1 0 1 00 11 11 0 0 1 00 1 0 1 0 0 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 11 00 0 1 0 00 11 01 1 0 1 0 1 0 1 0 1 0 1 0 1 00 11 0 1 0 1 0 1 0 1 00 11 0 1 0 1 0 1 00 0 1 0 11 1
In the following, we outline the concept and use cases for a Grid infrastructure which provides dynamicity and scalability for all major types of online games. Our main idea is to scale all the different scalability dimensions introduced in Section 2.1 by combining several scalability approaches suitable for the various game genres. The according architecture has to be practically usable, meaning that the complexity and the dynamicity of the multi-server parallelisation has to be hidden as much as possible to the game developer inside of a convenient API, without restricting optimization possibilities for a specific application implementation. Our concept, therefore, follows the familiar paradigm of game entities and game-loop-centric processing.
(a) Heavy Fight at Bottom Right Zone
In particular, a comprehensive infrastructure has to support zoning, replication and instancing of particular game world regions. The overall resulting concept is illustrated in Figure 3.
(b) Fight Moving to Bottom Left Zone
11 00 00 11
11 00 0 1 0 1 00 11 11 00 00 1 1 0 1 00 11 00 11 00 11 0 1 00 11 11 00 00 11 0 1 1 0 00 11 111 000 00 11 0 1 0 1 00 11 00 11 0 1 00 11 0 1 00 11 00 11 0 0 1 01 1 00 1 00 11 00 11 11 00 0 1 0 1 11 00 1 00 11 0 1 0 1 0 1 0 1 0 1 0 1 1 0 0 1 0 1 0 1 0 1 11 00 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 1 0 1 01 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 11 0 01 01 01 0 1
Figure 4: Dynamic Clustering of Users [..] [..]
instance servers
[..]
In such a scenario of a fight with a high user density, it can be expected that users eventually move over to an adjacent zone. In Figure 4(b), the bottom right zone then becomes less frequented because users move over to the bottom left zone. This zone now has to be replicated in order to scale the density of users, while the replication of the previously frequented zone can be lowered due to decreasing load. Our concept of the comprehensive scalability framework supports dynamic adding and removing of replications, and the overall Grid infrastructure has to dynamically reassign the replication servers to zones according to the user behaviour.
[..]
zone servers
replication servers
Figure 3: Comprehensive Scalability Framework The particular combination of zoning and instancing is already practically used by commercial MMORPGs. However, using replication in combination with zoning is a novel concept which allows to scale the density of players inside of a particular zone. Combining these different approaches allows to scale all three main scalability dimensions for a single
5.1.0.3 Increasing Instance Demand As another example of how our concept of the overall scalability framework can be dynamically orchestrated by a Grid infrastructure respecting the actual user demand, let us imagine that the users are distributed across several zones of the
9
7. REFERENCES
virtual world. Besides the zones, there are particular instanced areas which a only barely frequented in the beginning as illustrated in Fig. 5(a).
[1] Bigworld technology . [2] Butterfly.net .
instance servers
00 11 00 11 00 11 0 1 00 11 1 0 00 1 1 00 1 00 0 111 11 00 110 1100 00 11 00 11 11 00 0 1 00 1 0 11 00 0 11 1 00 11
[3] edutain@grid project . [4] gamespy . [5] Steam platform . [6] W. Cai, P. Xavier, S. J. Turner, and B.-S. Lee. A scalable architecture for supporting interactive games on the internet. In Proceedings of the 16th Workshop on Parallel and Distributed Simulation, pages 60–67, Washington, D.C., May 2002. IEEE.
(a) Low Instance Usage [..]
instance
[..]
servers 00 11 1 0 00 11 0 00 1 [..] 0 0 11[..] 0 10 11 1 0 1 11 0 000 1 0 1 0 11 11 00 11 0 00 1 00 11 00 11 00 11 00 11 00 11 00 11 11 0 00 11 0 0 1 0 1 0 1
[7] I. Foster and C. Kesselmann, editors. The Grid: Blueprint for a New Computing Infrastructure. Morgan Kaufmann, 1998. [8] Globus Alliance. Globus toolkit .
(b) High Instance Usage
[9] B. Knutsson, H. Lu, W. Xu, and B. Hopkins. Peer-to-peer support for massively multiplayer games. In IEEE Infocom, March 2004.
Figure 5: Dynamic Clustering of Users Especially in MMORPG, it is a common scenario that the instance utilization increases drastically during night time, because users pre-arrange groups to adventure collaboratively in such usually difficult areas. As a result, much more instance servers are required as illustrated in Figure 5(b) and the general zoned game world might be less frequented. A Grid infrastructure therefore has to be able to dynamically increase the number of instance servers and possibly combine zones to reassign zone servers to instances.
6.
[10] J. M¨ uller and S. Gorlatch. Rokkatan: scaling an rts game design to the massively multiplayer realm. Computers in Entertainment, 4(3):11, 2006. [11] J. M¨ uller, S. Fischer, S. Gorlatch, and M. Mauve. A proxy server-network for real-time computer games. In M. Danelutto, D. Laforenza, and M. Vanneschi, editors, Euro-Par 2004 Parallel Processing, volume 3149 of Lecture Notes in Computer Science, pages 606–613, Pisa, Italy, Aug. 2004. Springer-Verlag.
RELATED WORK AND CONCLUSION
In this paper, we summarized the main scalability dimensions of online games and gave an overview of existing scalability approaches. The zoning concept [6, 9], which is widely used by existing MMORPG, scales the total number of users and the game world size. For scaling the density of players, however, our replication concept using the proxy-server architecture [11] is more feasible. As a general result of this discussion, we outlined our approach of a comprehensive scalability framework which combines zoning, instancing and replication suitable to scale all classes of online games.
[12] J. M¨ uller, R. Schwerdt, and S. Gorlatch. Dynamic service provisioning for multiplayer online games. In J. Cao, W. Nejdl, and M. Xu, editors, 6th International Workshop on Advanced Parallel Processing Technologies APPT 2005, volume 3756 of Lecture Notes in Computer Science, pages 461–470, Hong Kong, China, October 2005. Springer-Verlag. [13] A. Shaikh, S. Sahu, M. Rosu, M. Shea, and D. Saha. Implementation of a service platform for online games. In Proceedings of ACM Network and System Support for Games Workshop (NetGames), Portland, Oregon, USA,, September 2004.
We participate in the recently started edutain@grid and are currently working on the discussed comprehensive scalability framework to add the required scalability features to the Grid infrastructure. Besides scalability, we outlined the three other functional characteristics of dynamicity, migration and accounting of Grid systems which provide an enormous improvement over the currently usually static online game hosting. We discussed the current state of the art of game-related Grid infrastructures, which target specific game genres and do not provide the full benefits of Grid computing to general online game hosting yet. The two presented use cases of moving player density and increasing instance demand provide, among other scenarios, the challenges for advanced game Grid infrastructures and will be addressed in the edutain@grid project.
[14] Unicore Forum e.V. Unicore-grid, . [15] B. S. Woodcock. Mmorpg chart .
10
How to Fail: Mobile Game Design in a Research Project Involving Software Prototype Development Elina M.I. Koivisto
Mark Ollila
Nokia Research Center Visiokatu 1 33720 Tampere, Finland +358504821630
VITA, Linköping University Norrköping Campus Norrköping, Sweden +4611363000
[email protected]
[email protected]
other methods than software prototyping, and the third one was developed further to a commercial game with a slightly different feature set.
ABSTRACT This paper presents how failure can occur in mobile game design when using software prototype development to demonstrate game concepts. We examine three case studies of mobile game research projects which can be considered as failures because of not finishing the game prototype in time or at all, or not being able to test the game with end users in large scale pilot testing. In every case the game design had an impact to this. The first case study examines a slow-update game, the second a cross-platform pervasive game, the third a strategic persistent world game. All of the projects are relatively large scale involving work effort spent between 2-9 person years. We present our findings and provide recommendations on how to avoid these mistakes in process in the future.
Research often works with the development of software prototypes. When considering the research questions, there are usually two approaches: bottom up or top down. Depending in the context, the top-down and bottom-up approach has different meanings [9]. In this context, in the top-down approach the main research questions are already set in the beginning of the project and the prototype is particularly designed to solve those research questions. The bottom-up approach means that the researchers create a prototype that could potentially evoke interesting research questions and provide data that can be used to solve them. The research can be done also in an iterative manner when the evaluations of the prototype guide the design at each phase of the project. The research method in all of these projects was topdown. All of the example projects used an iterative game design process (see [5] for a mobile game design process that is used in some of our projects).
Categories and Subject Descriptors K.8.0 [Computing Milieux]: Personal Computing – General. Games
The setting of the research is also a consideration with closed research existing and that of open innovation [1]. The closed approach means doing research strictly within one company. The open innovation approach acknowledges that there are good ideas that can be used both inside and outside a company. In practice, this means taking a more open approach and collaborating with external parties on doing research. Of our projects, the second and first case studies are examples open innovation and the third case study is a closed research project.
General Terms Management, Measurement, Design, Experimentation, Human Factors.
Keywords Mobile, Game Design, Process, Failing
1. INTRODUCTION
The length of the research influences the research project. The third case study was a rather short-term research project and it was set up to explore technology that was about to be released in the market. The first and second case studies were long-term research, where completely new kinds of game types and approaches were researched. Long-term research is often more challenging since there are more unknowns and the technologies that are being used are not always available. Sometimes creating a fully functional software prototype is not even an option and alternative prototyping methods need to be used instead [6]. Also, evaluating game prototypes in long-term research projects is, to our experience, more difficult, because the test players are exposed to completely new kinds of concepts and ideas.
It is often the case that only successes are presented in terms of research results. However, often more is learnt from projects that fail. In this paper, we examine three cases of mobile game design using software prototype development where the project can be considered as a failure in a way or another. In the first project, the prototype was finished, but developing it took six times longer than originally planned. The second project did not manage to produce a fully functional software prototype that could have been tested with the end users. The result was close to it, but the project was shut down before the prototype could have been finished. The third project created a fully functional prototype that was tested both in laboratory with potential players of the game and in internal small-scale field testing. However, external large-scale field testing, which was the goal of the project, was not conducted. It must be noted, that none of the projects were complete failures: the first one eventually got finished in the end, the second one managed to produce useful research data by using
The scale of the project has an effect on the game design, project organization, and software development methods that are being used [14]. Games in general are hard to develop and the player’s expectations towards a game are a lot higher now than they were
11
The project was developed mostly within one research organization with help of other parties. The participants in the project were researchers with a lot of experience in game concepting but quite little experience on designing and implementing large-scale game projects.
twenty years ago [1]. This increases pressure to create research game prototypes that have more depth and better looking graphics. Even if the game would be a research prototype, it should keep the players interested long enough to produce data that can be used for research or be appealing enough to demonstrate the game design to customers effectively. The projects presented in this paper ranged from two to nine person years time, and are all rather large scale for research projects.
After the core game concept was created, it was tested out with three physical prototypes. We have very good experiences in using physical prototypes in game design to iterate and test the game design already in the early design phase of the project. Figure 1 shows how a typical physical game prototype may look like. The game design was evolved after each testing round. First, the game theme involved gods and destroying civilizations. Later, the theme was changed to a medieval fantasy theme that is more typical in strategy games. The game designer of the physical prototypes had experience on developing small-scale game prototypes. After the fist versions of the game, a lead game designer was chosen to finalize the game design. He had no experience on designing large-scale game prototypes but was experienced in designing and implementing smaller mobile application projects. The lead game designer got help in form of comments and suggestions for changing the game design from his colleagues. However, instead of being helpful, this lead to adding new features, that could potentially have made the game more fun to play, but at the same time added to the complexity of the game project.
The criteria for success and failure can vary as we can see in the example projects. When a software prototype is developed to demonstrate a game concept, one very clear criterion there is producing a playable prototype that can be evaluated with the end users. All of the projects presented in this paper had problems with this, the first one taking six times more time than planned to finish, the second one never being completely finished, and the third project finishing a playable prototype but due to the immaturity of the technology failing to perform a large scale pilot. There are several reasons for these kinds of failures, and often the project management and the game development process has a big role. Even if the project would fail to produce a game that is enjoyable and fun to play, it could be successful if it could be used to gather meaningful research data or prove that something cannot be done. In our paper, we focus on the problems that are closely related to the game design and can lead to not being able to gather research data with the software prototype. Our paper is organized in the following way. Section 2 describes the research method, with Section 3 presenting three case studies. Section 4 shows our findings followed by conclusions.
2. RESEARCH METHOD The research method was participatory research [4]. The researchers were active participants in the projects. The other methods, in addition to observation, were interviews with other participants in the projects, and analysis of project meeting notes and communication exchanges (when available).
Figure 1: Material used to produce physical prototype.
3. CASE STUDIES
The timing of the project was bad, since there was not reserved enough time for finishing the game design and the game implementation was supposed to start during the summer vacation. The game design is the most important part of the game project, but still surprisingly often underestimated [8]. The game design document ended up being too vague.
We chose three games where the authors have participated in some form in the past as examples of research game development projects that could be considered as failures. The reason for choosing these particular projects was that they all were very different kinds of projects. The projects were organized differently and they all demonstrate different ways of failing. In the following, we describe the game projects, how did they fail, and our view on why did they fail.
A summer trainee was hired to implement the game. The summer trainee was young, only eighteen, but a relatively experienced programmer. He did not have any experience on application development for the software platform that was used for implementing the game.
3.1 Case Study 1: A Slow-Update Game Our first case study is a slow update game that the players play asynchronously. The game is supposed to adapt to different kinds of social situations and play styles. In this game, the players can play the game with their own schedule, during the short moments when they do not have anything else to do, log out of the game, and continue when they have time again. The players can also choose how involved they want to be in the game by taking different kinds of roles. A quite unusual aspect of the game is the way the players join in the game: new players can only join a game instance when they are invited by other players.
The summer trainee worked on the game and in the end, he managed to get together something that barely worked and there was no graphical user interface, the game was text-based only. The purpose of the prototype was to pitch the game concept for a game publisher. The game was pitched to a publisher, however, the prototype at its current state did not help in pitching. The game was not developed further for about a month until there was a need for a similar game prototype in another project. The project decided to finish the game prototype, and at this point, the requirements for the prototype also got somewhat higher. Instead
12
There were stakeholders from five organizations in the project. Each of them had research questions they were interested in. The project had a main research question of finding out how it would be like to play a cross-platform MMOG, but in addition to that, several sub research questions were created. The extra research questions lead to a situation where it was difficult to know if the players enjoyed or disliked the features that were related with the main research question or the other ones. The huge effort that needed to be spent to develop the software platform also restricted the time that could have been used for implementing any extra functionality.
of a prototype that can be tested and demonstrated with some users, the game now needed to be a fully playable prototype that can be tested with the end users as a large-scale field testing. Another, more experienced, trainee was hired to work on implementing the game. However, he did not finish the implementation in time, so in the end, a third, experienced programmer implemented the game. The prototype was eventually implemented, but the project lasted, instead of three months, eighteen months, which was six times longer than originally planned. In this sense, the project can be considered to be a failure. Since the field trial is still on-going, we cannot yet conclude if the prototype failed in some other sense.
In the first design meeting, all the stakeholders were allowed to speak out their personal research goals in the project. This ended up in huge list that included research topics from exploring social systems in games to characterization. This was seen important because some of the researchers were not paid by the project. They needed to get something out of the prototype for their own research as well to be able to contribute. This process created a huge feature creep. There were far more many researchers in the project who took the role of a concept designer than who would have worked on implementing or fine-tuning the game. The approach where the game design is a compromise of several participants’ game ideas or requirements is often called “Design by a committee” [12]. A game that is designed by a committee and compromises often leads to boring or bad gameplay. After the first version of the game design document, the core design team removed many features to make the game more focused.
There were several reasons why the project ended up to be a failure in a way. First of all, the scale of the project was far too big to implement with the people who were allocated for the project and that was not taken into account well enough in the project planning. The game seemed rather simple, and in the beginning it actually was simpler. However, the helpful improvement suggestions of other game designers lead to even more complex design that was in the end far too big. The game design was partly ambiguous which led to problems in the User Interface (UI) design and implementation. There was not enough time for the game design and it was rushed because the designers needed to go to their summer holidays. There was communication to some extend between the design team and the programmer, but because he was not experienced with the development platform that was used, he could not help the design team by protesting against too complex design ideas that cannot be implemented in time.
The game concept attempted to create a large-scale virtual environment. In order it to become a real social environment, a large amount of content would have been needed to keep the players playing it long enough. The project did not have enough resources to implement the content and the final software prototype consisted of graphics that formed simple graphical basic forms, such as squares or balls.
Failing to finish the project in the first place led into more problems. The programmer of the game changed two times, and every programmer had to first familiarize himself with the existing system. This was time consuming and it could have been actually even faster to start programming from an empty table.
The project members were geographically distributed. The core design team was quite isolated from the rest of the team. There was not that much communication between the project members. The project manager did not encourage it either, which made the core team even more isolated from the rest of the project members who did not know what was going on in the project.
3.2 Case 2: A Cross-Platform Pervasive Game The game project in our second case study attempted to implement a cross-platform Massively Multi-player Online Game (MMOG) where the players could play the same game with a mobile phone and a stationary computer. The mobile players were not expected only to access the game with their mobile devices, but also to affect the game world with context-aware mobile gameplay [12] and use location of mobile players to change the game state.
One of the partners in the project was a relatively small game company. The company was going through some major changes which affected badly the implementation of the mobile client that the company was responsible of. The core design team did not feel that they had enough power to require the other partners in the project to deliver what has been agreed on. This lead to a problematic situation when all the stakeholders could not deliver what promised on time.
The scale of the project was a huge problem in the first place. There were very limited resources for the implementation, however, using existing platforms for the mobile and PC client gave some hope that the effort would not be so large. This was found to be not true when the project proceeded and it was noticed that not as much code in the existing platforms could have been used as expected.
One big obstacle for finishing the project to be ready for a field testing with the end users was using a location service provided by a mobile operator. Just before the field testing was going to take place, the operator was not anymore interested at all in providing location data for the project. Changing the location tracking so that it would use some other technology was not possible anymore when the project management found this out. Using GPS (General Positioning System) was considered in the beginning of the project, but rejected by the commercial partners since it was not commonly used by the current users. There was a
In the beginning of the project, it was also considered if the project should take an advantage of an existing MMOG and its user base. However, this approach was not used since the negotiations with commercial partners would have taken too long time to fit the project schedule.
13
The main obstacle for getting the game out in the field testing was both technological and usability one. At the time when the game was finished, SIP was a very new technology. Setting up a SIP account was difficult even for an expert user and getting a SIP account required collaboration with a test laboratory.
conflict between regarding the prototype as a pre-commercial prototype and concept demonstration. The problem with the location service was anticipated earlier by one of the project partners, who had similar experiences in implementing another location-based game, however, these concerns were not listened. The project could be considered to be a failure because the field testing with the prototype could not been done and the project was ended earlier than originally planned. The ending of the project was due to the problems with the mobile developer and other partners in the project not being interested in investing more resources in further development. Some concept testing and focus groups were done on basis the game design but the software prototype was never tested with the end users.
4. FINDINGS Our case studies demonstrated how to fail to design a good game prototype in research projects where software prototypes are developed. This section summarizes the reasons for failing that we found in these projects and gives guidelines for bad mobile game software prototype design.
4.1 Game design Innovate when not needed. Too innovative game concepts may confuse the players and also make it more difficult to gather research data (unless the innovative features are related to the research questions). It is very difficult to explain complex concepts in a small screen real estate to mobile game players. When evaluating the game, the most important thing is the research questions. If other aspects of the game are very innovative they can interfere with the results making it difficult to get data on the research questions. This was noticed particularly in the third case study.
3.3 Case 3: A Strategic MMOG Our third case study is a strategic MMOG for mobile phones. In this game, the players gather game resources, build teams, and duel against other players. A massive amount of players share the same game world, trade game resources together, and communicate with other players, but the battle is a duel between two players. The project was set up to research how Session Initiation Protocol (SIP) can be used to create interesting game features. In practice, this meant that the players of this game could invite other player to duel or trade even if the other player would not be logged in the game at the moment.
Try to solve too many research questions with one prototype. This is related with creating too innovative game concepts when not needed. If one prototype is used to solve several research questions, when evaluating the game, it may be difficult to find how the players liked different features if they interfere with each other. The second case study demonstrates this approach.
The project was done in collaboration with a game developer company. The project itself was quite successful, it was planned well and most of the planned features got implemented in the game. The game itself was generally fun to play, and it was verified in playtesting. However, the project could be considered as a failure in the sense that the large-scale pilot testing, which was planned with the end users, was never carried out.
Set up a committee to design the game. “Design by a committee” (see e.g. [10]) will lead to a compromised game design and extra features that would not be needed in the game. This was clearly demonstrated in the second case study where all the research partners were allowed to put features related to their personal research questions in the game concept. The first case study also had some design-by-a-committee features.
The game design re-used features from popular collectable card games, however, the story of the game world and some features were rather innovative. We found in the project that it is very difficult to explain new innovative concepts or game worlds to the players in the mobile platform. This is due to the limited real estate in the screen and need for relatively short play sessions1.
Add in all the features that could potentially make the game more fun to play. A game that includes all the possible features that one could imagine of is often called a feature creep. A game that does not have clear focus can be confusing for the players. In mobile game research projects the resources for implementing the game are often very limited and that is why a specific caution needs to be used when adding new features, even in the design phase, in the game. Failing to limit the amount of features in the game was one of the most important reasons for the project being delayed in our first case study.
The game was difficult to play and there was a clear need for a tutorial. However, tutorial is something that is often left to be implemented the last, and there was eventually not enough resources left in the project to develop a proper tutorial. The initial test results form the first case study also show that the players would have needed more guidance in the game. The project was funded by a third party that was not used to dealing with game developers, but rather with technical subcontractors. This led to some communication and agreement problems in the game project, which however, were overcome in the end.
1
Design the game so that the implementation needs to use immature technologies. Using immature technologies is very risky both when considering finishing the implementation successfully and evaluating the game. In the implementation, the immature technologies cause a lot of trouble because of missing documentation, functionalities, development tools, and software bugs. When evaluating the game, setting up the test environment can be difficult or even impossible. Particularly in field testing it is often a problem that the players do not have the devices that are needed for playing the game. However, research projects often need to use immature technologies and the only thing that can be done is just to acknowledge this risk.
Actually, in playtesting, we have found that the play sessions are not necessarily always short when playing mobile games. However, it is a good design practice in the design of mobile games to allow interruptions [6].
14
complexity of the device influences the desired complexity and feature creep in the game design.
Choose a game concept that inherently requires creating huge amounts of content. This problem is very relevant in research game projects, since there typically are not enough resources to create large amounts of content for the game. However, there are a few solutions, for instance, utilizing user created content can be in feasible in some cases.
6. ACKNOWLEDGMENTS We would like to thank the following people for useful comments and insight: Craig Lindley, Ciaran Harris, Ari Koivisto, Jouka Mattila, Riku Suomela, Juha Arrasvuori, Jussi Holopainen, Tommy Palm, and Mirjam Eladhari.
Do not learn from the past. As seen in the second case study, valuable information can be learned from previous projects. One of the project partners knew that there might be problems with collaborating with operators to get location data. However, this risk was not taken into account and that was the main reason for failing to test the prototype at all.
7. REFERENCES [1] Blow, J. 2004. Game Development: Harder Than You Think. Queue 1, 10 (Feb. 2004), 28-37.
4.2 Other reasons
[2] Brooks, F. The Mythical Man-Month. Addison-Wesley, Reading, MA, 1975.
Even if the focus of this paper was to point out what in the game design may lead to failing to produce a playable game prototype, our case studies also demonstrate other issues, mainly related with project organization and management. We shortly list those findings here.
[3] Chesbourgh, H.W. Open Innovation: The New Imperative for Creating and Profiting from Technology. Havard Business School Publishing, Boston, MA, USA, 2003. [4] Cornwall, A. and Jewkes, R. What is Participatory Research? Soc. Set. Med. Vol. 41, No 12, (1995), 1667-1676.
Underestimating the size of the project is a typical problem in software projects (see for instance [10]). The same problem was an important reason for failure in the first and second case study. There were problems with communication within the team and providing clear responsibilities for each partner. This can be particularly a problem in open innovation if it is combined with distributed implementation. In the first case study, the ambiguity of the game design document hid the actual complexity of the game and made the implementation more difficult when the game design document needed to be interpreted in the UI design and implementation.
[5] Koivisto, E.M.I. and Palm, T. Iterative Design of Mobile Games. In Proceedings of Game Design & Technology Workshop, Liverpool, UK, 2005. [6] Korhonen, H. and Koivisto, E.M.I. Gameplay Heuristics for Mobile Games. In Proceedings of MobileHCI, Helsinki, Finland, 2006. [7] Manninen, T. 2002. Contextual Virtual Interaction as Part of Ubiquitous Game Design and Development. Personal Ubiquitous Comput. 6, 5-6 (Jan. 2002), 390-406.
It makes a huge difference to have experienced developers to design and implement the game. This difference can be seen between our first and second case study and the third one that was created by a game development company. Also, in the first case study, an experienced programmer could finish coding of the software prototype, where the less experienced ones failed. Switching the programmers in middle of the project will lead to delays since the new programmers have to familiarize themselves with the old code. This can be seen in the first case study, and it is also acknowledged in software engineering literature [2].
[8] Martin, J. and Smith, C. 2002. A cross-curricular team based approach to game development. J. Comput. Small Coll. 17, 5 (Apr. 2002), 39-45. [9] McFarland, G. 1986. The benefits of bottom-up design. SIGSOFT Softw. Eng. Notes 11, 5 (Oct. 1986), 43-51. [10] Pemberton, S. Reflections: the design of notations. Interactions, 8, 2 (March 2001) 126-128. [11] Pressman, R.S. Software Engineering A Practioner’s Approach, Third International Edition. McGraw-Hill, Singapore, 1992.
5. CONCLUSION
[12] Rouse, R, III. Game Design Theory and Practice. World Ware Publishing, Plano, TX, 2001.
We gathered and analyzed data from three projects. Each of them failed in a way, and we focused on the reasons for failure that originated from the game design. Most of the game-design related reasons for failure in the case studies dealt with designing a too complex game for a reason or another. These reasons included innovating when it is not necessary, design by committee, and adding in all the possible features that could potentially make the game more fun to play. Other reasons were design that requires the project to create large amounts of gameplay content and requiring use of immature technologies, which often cannot be avoided, but should be acknowledged as a risk in the project.
[13] Suomela, R. Constructing and Examining Location-Based Applications and Their User Interfaces by Applying Rapid Software Development and Structural Analysis. Ph.D. Thesis, Tampere University of Technology, Finland, 2006. [14] Vazquez, F. Selecting a software development process. In Proceedings of the Conference on Tri-Ada '94 (Baltimore, Maryland, United States, November 06 - 11, 1994). C. B. Engle, Ed. TRI-Ada '94. ACM Press, New York, NY, 1994 209-218.
Future work will involve more detailed analysis of past projects and greater collaboration with commercially developed mobile game design projects. Additionally, we will examine the role of target device and device features in trying to understand how the
15
Alice: Using 3D Gaming Technology to Draw Students into Computer Science Caitlin Kelleher School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213 USA +1 412 268 4074
[email protected] Although many factors are contributing to students’ loss of interest in computer science, one contributing factor is that students often find their first experience with computer science uninspiring. Typical beginning programming assignments such as sorting a list of numbers or performing a simple calculation fail to engage many students. The Alice programming environments are examples of applying 3D gaming technology to improve students’ experience with learning to program computers. In this paper, I will discuss two existing versions of Alice: 1) Alice 2 which targets college introductory programming students and 2) Storytelling Alice which is designed for middle school girls. In both versions of Alice, students learn to program through animating the motions of 3D objects in a virtual world.
ABSTRACT
The goal of the Alice project is to leverage 3D gaming technology to develop programming environments that will provide beginning programmers with a positive first experience with programming. At the college level, usage of Alice 2 helps at-risk computer science majors to succeed in introductory program and almost doubles the number of students who choose to continue in the computer science major. Storytelling Alice, a version of Alice designed to support the creation of animated movies, makes learning to program attractive to middle school girls; more than half of the girls who used Storytelling Alice snuck extra time to continue working on their programs. Keywords
Programming environments, evaluation, storytelling, gender
novice
programmers,
ALICE 2
Alice 2 [2] is a programming environment for novice programmers that allows users to construct programs that control the motions of 3D objects in a virtual world. To create a program in Alice 2, users begin by adding 3D objects to their virtual world. Alice 2 comes with a gallery of more than 700 3D objects including ranging from an amusement park to characters and scenery from ancient Egypt. The object tree contains the list of 3D objects in the virtual world (see Figure 1). To create a simple program, users can click on an object to animate, drag one of its methods into the method editor (e.g. iceSkater move), and select parameter values (e.g. forward and 1 meter).
INTRODUCTION
Despite wide-spread usage of computers and computer technologies, only a small, unrepresentative sample of the population is involved in creating new computer technologies. Broadening and diversifying the group of people who create new computer technologies has two potential benefits: 1) a larger, more diverse group will help ensure that computer science attracts the talent that the discipline needs and 2) a more diverse group of people involved in the design of new technologies will help to ensure that new technologies meet the needs of our diverse society.
Alice 2 makes programming easier for novices in two ways. First, Alice 2’s method of constructing programs through drag and drop prevents users from making syntax errors. Second, programs in Alice 2 are animations of visible 3D objects, so users can watch their programs execute and see mistakes when they occur. Alice 2 allows students to gain experience with the programming concepts and constructs typically taught in a first computer science course. These include looping, conditional statements, methods, parameters, variables, arrays, and recursion. Typical Alice 2 projects include short animations and simple games.
This problem is of particular importance at the current time because student interest in computer science has dropped dramatically in recent years. In the United States, the number of incoming college freshman who intend to major in computer science dropped by 70% between 2000 and 2005 and the number of students enrolled in computer science programs at research universities has dropped by 50% [9]. Despite decreasing student interest in computer science, there is still a strong need for computer scientists. The United States Bureau of Labor Statistics predicts that there will be nearly 1.4 million computer science related job openings between 2004 and 2014 [5].
16
2
1 5
4 3
Figure 1: A screenshot of the Alice interface. 1) The world window provides a view of the virtual world that a students’ program will control. 2) The object tree contains a list of the 3D objects in the virtual world. 3) The details area shows the properties, methods, and functions for the object selected in the object tree. 4) The methods editor shows the code that defines a method a student is working on. To call the IceSkater’s move method in “my first animation”, the user drags the tile “IceSkater move” from the details area into the method editor, drops it, and selects parameters from the pop-up menus. 5) The events area allows students to call methods based on events in the world, such as mouse clicks or changes in the value of a variable. Table 1: Academic performance and retention of students in Java course without and with exposure to Alice
ALICE 2 FOR INTRODUCTORY PROGRAMMING
The mechanical and motivational supports Alice 2 provides can help broaden the pool of CS majors. National Science Foundation-sponsored studies have shown that Alice 2 increases the academic success and retention of at-risk college students (freshmen intending to major in CS who enter college with no programming experience and/or who are not prepared to enroll in Calculus as freshmen). At-risk students who enrolled directly into a Java-based CS 1 class earned an average grade of C and only 47% of them continued on to the second course. After a half-semester Alice course, at-risk students performed as well as wellprepared students in the Java-based CS1 course: they earned an average grade of B and 88% of them continued on to the second course [6].
No Alice class prior to CS1 Alice class prior to CS 1
CS1 Grade
Take CS2?
C
47%
B
88%
ALICE FOR MIDDLE SCHOOL GIRLS
While it is important to retain the students who choose to major in computer science, we may be able to attract a larger and more diverse group of students if we reach them at a younger age. Research has found that many girls decide against pursuing math and science based disciplines, including computer science, during middle school [1].
As of fall 2006, Alice 2 is currently being used in CS1 courses at more than 200 colleges and universities.
Rather than presenting programming as a means in and of itself, we have created a version of Alice that presents programming as a means to the end of creating 3D
17
animated stories: Storytelling Alice. We chose to focus on the activity of storytelling for the following reasons:
Table 2: A comparison of the animations in Storytelling Alice and a version of Alice without storytelling support (Generic Alice).
1.
Given a little bit of time, most girls can come up with a story they would like to tell. 2. Stories are naturally sequential and are unlikely to require advanced programming concepts immediately, making them a good match for beginning students. However, most stories provide the motivation for more advanced programming concepts such as methods, parameters, and loops. 3. Stories are a form of self-expression and provide girls an opportunity to experiment with different roles, a central activity during adolescence. 4. Non-programming friends can readily understand and appreciate an animated story, which provides an opportunity for girls to get positive feedback from their friends. More than 250 girls between the ages of 10 and 16 participated in formative user testing that guided the design and development of Storytelling Alice. To enable middle school girls to create animated stories, it was necessary to make three broad changes to Alice 2:
Storytelling Alice Say, think Play sound Walk to, walk offscreen, walk Move Sit on, lie on Kneel Fall down Stand up Straighten Look at, Look Turn to face, turn away from Turn Touch, Keep Touching
Generic Alice Move Turn Roll Resize Play sound Move to Move toward Move away from Orient to Point at Set point of view to Set pose Move at speed, turn at speed, roll at speed
2. Make the gallery a rich source of story ideas.
One of the factors that impacts girls’ motivation to learn to program in Storytelling Alice is whether or not they can find a story that they want to tell. The gallery of 3D characters and scenery can be a source of inspiration for girls’ stories. In particular, highly caricatured characters with clear roles and giving characters animations that require some explanation within the story (e.g. what made a robot character go crazy) can help spark story ideas. 3. Make the system communicate that it can be used for storytelling.
Initially, the Alice tutorial was designed around examples chosen to demonstrate concepts as simply as possible. However, through user testing we found that it was necessary for the Alice tutorial to introduce the skills and concepts users needed within the context of creating stories similar to the ones they imagined. To enable users to successfully complete story-based tutorials which tend to be more complex, we created an interaction technique called “Stencils” where the online tutorial is spatially overlaid on top of the running Alice application (see Figure 3). Stencils [4] moderates the additional complexity of stories by presenting instructions one at a time in the context of the application and preventing users from accessing user interface components that are not necessary for the current step.
Figure 2: A scene created using Storytelling Alice.
1. Provide high-level animation primitives based on storytelling needs. The animations in Alice 2.0 allow users to perform simple graphical transformations like moving and rotating a character or one of its parts. Using simple transformations, it is often a tedious and frustrating process to create the kinds of animations that girls needed to create their stories such as walking or having two characters hug one another. By analyzing the storyboards girls created for their movies, we identified a high-level set of animations that enable girls to make more rapid progress on their stories without removing the motivation to learn programming constructs.
Evaluation of Storytelling Alice
In a study comparing the behavior of girls introduced to programming using Storytelling Alice with the behavior of
18
girls introduced to programming using a version of Alice without storytelling support (or Generic Alice), we found that storytelling is a promising approach for getting middle school girls interested in learning to program. Girls who used Storytelling Alice spent 42% more of their time programming and 45% less time on non-programming activities like selecting 3D objects and positioning those objects within the virtual world (p < .001). Further, users of Storytelling Alice were almost three times as likely to sneak extra time to continue working on their programs during breaks. Where only 16% of Generic Alice users snuck extra time to work on their programs, 51% of Storytelling Alice users snuck extra time (p < .001).
move to a new place, relationships with boys, and how to find your dog when it has been kidnapped. Average % Time Spent on Alice Activities 60.00% 50.00% 40.00% 30.00% 20.00% 10.00% 0.00% Scene Layout
Editing Program
Generic Alice
Running Program
Storytelling Alice
Figure 4: Users of Storytelling Alice spent 42% more time programming and 45% less time on scene layout than users of Generic Alice.
In addition to motivating girls to learn the basics of computer programming, Storytelling Alice provides motivation for girls to sharpen their communication skills. As girls develop their stories, they are often anxious to share their work with friends. When friends watch the movies, the author observes their reactions carefully to see if they have understood the actions in the story and whether or not they laugh at the jokes. We observed that when the author’s friends do not understand the sequence of events or laugh at the jokes, it provides a strong motivation for the author to revise their story, a process that is often difficult for teachers to motivate. ALICE 3
Both Alice 2 and Storytelling Alice help to make learning to program more approachable and more appealing for college and middle school students. In the next version of Alice, we will continue in the theme of applying gaming technology to improve the experience of learning to program for students ranging from middle school to college and continue to focus on the activity of storytelling. Why not gaming?
In response to decreasing student interest, many computer science departments are considering the use of computer gaming as a context for teaching computer science that may be more attractive for students. Over the past 5 years, the number of video game related majors has risen from less than a dozen to more than one hundred in the United States alone with more in Europe and Asia [8]. While the focus on computer gaming may help to increase the numbers of students who pursue computer science, it may further decrease the percentage of female students in computer science. Video game based curricula will almost inevitably draw inspiration from commercially successful games which do not appeal equally to both genders. Further,
Figure 3: Views of the Alice interface without (above) and with (below) Stencils.
Qualitatively, storytelling seems to be a good approach. Most girls in the storytelling condition readily envision a story they would like to tell. Using the high-level methods in Storytelling Alice, girls are quickly able to make progress on their stories, which helps to build their confidence and enthusiasm. Girls’ stories have addressed a wide variety of topics including how to deal with being unpopular, what to do when your parents force you to
19
computer gaming curricula are likely to be most appealing to students with a strong interest in video games (e.g. hardcore gamers). While one survey by the Entertainment Software Association states that the gaming population is 43% female, this number is potentially misleading because it includes casual play (e.g. games like solitaire and tetris) [3]. Netshelter, a company that provides marketing information, estimates that the hardcore gaming audience (those who devote significant capital to gaming related purchases) is 97.5% male [7].
language like Java, C++, or C# by the end of their introductory computer science class. While Alice 2 helps students to gain an understanding of programming concepts, it does little to help students learn the mechanics of writing syntactically correct programs. To help ease the transition from Alice to a general purpose language, Alice 3 will include both drag-and-drop and Java-based textual editors. Students will be able to begin by generating programs through drag and drop and gradually move toward editing their program in the Java-based textual representation. In this way, students will retain the benefits of animated programs, a consistent API, and the motivation associated with creating animated stories as they learn how to write syntactically correct Java programs.
Leveraging The Sims 2
Based in part on our success in getting middle school girls interested in learning to program through storytelling, Electronic Arts has given us permission to use the 3D characters and animations from The Sims 2 in the next version of Alice. The Sims is the bestselling PC game in history and is one of few videogames to appeal more strongly to female than male players. The addition of The Sims 2 characters enables us to examine the impact of a larger and richer set of high-level animations on students’ motivation and their development of programming skills. Characters in The Sims 2 can perform hundreds of different animations ranging from general-purpose actions like walking to very specific actions like washing a plate or jumping on a bed.
REFERENCES
1. AAUW. Girls in the Middle: Working to Succeed in School. Association of University Women Educational Foundation, Washington DC, 1996. 2. Alice. http://www.alice.org 3. Entertainment Software Association. Essential Facts about the Computer and Video Game Industry: 2005 Sales, Demographics, and Usage Data. Retrieved May 1, 2006 from http://www.theesa.com/files/2005EssentialFacts.pdf 4. Kelleher, C. and Pausch, R. Stencils-based tutorials: design and evaluation. In Proc. CHI 2005, ACM Press (2005), 541-550. 5. Hecker, D. Occupational employment projections to 2014. Monthly Labor Review. November 2005. 6. Moskal, B., Lurie, D., and Cooper, S. Evaluating the effectiveness of a new instructional approach. In Proc. SIGCSE 2004, ACM Press (2004), 75-79. 7. Netshelter. Netshelter reaches: Enterprise Decision Makers and IS/IT Professionals, Technology Enthusiasts, Consumers, and Hardcore Gamers. Retrieved May 1, 2006 from http://www.netshelter.net/media_kit/audience/. 8. Schiesel, S. Video Games Are Their Major, So Don’t Call Them Slackers. NY Times. 22 Nov. 2005. 9. Vegso, Jay. CS Bachelor’s Degree Production Grows in 2004; Poised for Decline. Computing Research News 17, 2 (2005).
Figure 4: A screenshot from The Sims 2 Easing the Transition from Alice to Java
Particularly at the college level, students often need gain to become proficient in writing programs in a general purpose
20
A 2D Car Physics Model based on Ackermann Steering Helmut Hlavacs Institute of Distributed and Multimedia Systems University of Vienna Lenaug. 2/8, 1080 Vienna, Austria
[email protected]
Newton Game Dynamics3 , Havok4 , OPAL5 , or Bullet.6 On the other hand, an engine specialized for the simulation of cars like Racer [12] can be used. In such a case, one is limited to the properties of the repective engine. Furthermore, using the engine might either be very costly, or the result might be restricted to non-commercial use due to legal considerations. Furthermore, the engine of course acts like a black box without insight into the model solution.
ABSTRACT Car physics models are often complicated and require a large effort for understanding them. Additionally, some seem to be incomplete and many open questions remain. In this paper a novel 2D car physics model is presented. The model is based on Ackermann steering and presents closed formulas for forces causing rotation and acceleration of the car and tyres. As a simplification, the model assumes only two tyres instead of four. The paper describes how the equations are derived and how the model can be solved in a game loop.
2. RELATED WORK Basically, there are two types of car physics models found in the literature. The first one is a very sophisticated type of model which takes into account as many parts of a car as possible, like springs, suspensions, 3D landscape, tyre models and elaborate tyre slip models, etc. Implementing such a model requires a large amount of effort, its use is for instance in the car industry or for professional games [6, 11, 9, 21, 2].
Categories and Subject Descriptors I.6 [Simulation and Modeling]: Miscellaneous
General Terms Theory
Keywords Car physics, Ackermann steering
1.
The second type of papers describes very basic 2D models, here mainly taking into consideration engine and centripetal forces [7, 8, 10, 3, 4]. These models are easily understood, yet one has the impression that important parts of the models are missing. Examples for such gaps include breaking forces due to steering, adding rotational forces to the tyre traction budget, or the fact that the engine/break force not only accelerates the car mass (which includes the tyre masses), but parts of it also must cause the tyres to rotate. These issues will be treated later in the paper. Also, their integration and solution is often not obvious.
INTRODUCTION
Car racing games rely on realistic car physics models for simulating the movement and traction of cars and tyres. Such a model may represent a car on a flat surface, as done in this work, or it may include the possibility of uneven ground and car jumps. Professional game studios put a large effort into developing proprietary car physics models for their products, which are of course not accessible for the public. People wishing to develop their own games thus have to rely on publicly available sources, which often are either over-sophisticated or leave open questions.
The aim of this paper is to focus on the second type of publication, i.e., an easily to be understood 2D model, which however tries to catch all forces of a car driving through a 2D plane. The presented model is based on so-called Ackermann steering, and consists of closed formulas, thus allowing to gain insight into the model behavior and solution. Furthermore, the integration and solution of the presented formulas in a game loop is presented.
Alternatively, it is possible to use existing physics engines, for example general physics engines that allow to simulate rigid bodies and spring-mass systems, like ODE1 , Tokamak2 , 1 2
http://www.ode.org/ http://www.tokamakphysics.com/
3. RIGID BODY DYNAMICS In this section those principles of rigid body dynamics which are necessary for understanding the proposed model will be 3
http://www.physicsengine.com/ http://www.havok.com/ 5 http://ox.slug.louisville.edu/∼o0lozi01/opal wiki 6 http://www.continuousphysics.com/Bullet/ 4
21
described briefly. For more detailed introductions in this field refer to [7, 8, 4, 5] or various articles at Wikipedia [17]. In the following, the discussion is restricted to the dynamics of solid cuboids, which are used in this paper to represent car masses. As a further simplification, we assume that the cuboid lies flat on a 2D plane, and its movements are restricted to the movements inside this 2D plane, just like a car may roll on the flat surface of a street. Note that in the following, scalars and scalar operations instead of vectors and vector operations will be used wherever possible, since the forces observed are often at right angles to the main model axes. If used, vectors are explicitly denoted by using bold fonts. Also note that throughout the model, forces and accelerations are kept constant over a short amount of time dt > 0. In fact, dt is assumed to be so small that sin dt ≈ dt. This can always be achieved by letting dt → 0, since it can easily be shown that [18] lim
x→0
Figure 2: A cuboid rotating about an axis through its center (a). A force F is applied to a point A (b). and represents the change of velocity per time unit, i.e., the first derivative of the velocity. Note that generally v and a are either both two-dimensional vectors, or scalars, if the direction is fixed, and only the magnitude is of importance. Also note that in the above scenario, the change in y-position dy of the car after dt is
sin x = 1, x
for instance by using the Taylor series of sin x [20].
dy = v¯(t, dt) dt = v(t) dt +
3.1 Translation
v¯(t, dt) =
F dt = a dt. M
v(t) + v(t + dt) v(t) + v(t) + a dt = , 2 2
(4)
i.e., the mean of v(t) and v(t + dt).
3.2 Rotation The second important movement a cuboid may carry out in the plane is rotating about an axis. In this work we always assume that the rotation axis is perpendicular to the plane. Fig. 2 (a) shows a cuboid rotating about an axis going through its center C. Like in the case for translation, we can define a current state of the object at time t, which is given by the orientation angle θ(t). Additionally, the change of this angle, i.e., the angular velocity, is given by ω = dθ/dt, and angular acceleration is defined to be α = dω/dt. Due to the rotational movement, a sample point A being at a distance of R away from the axis, moves along a circle with radius R. Its velocity vR on this circle is given by
(1)
No matter what velocity v(t) the cuboid is travelling at a time t, when we apply a constant force F to the center of its mass C (see Fig. 1), v(t) is no more constant, and after time dt the total change of velocity is given by dv = v(t + dt) − v(t) =
(3)
due to the fact that the mean velocity v¯(t, dt) of the cuboid in the time interval [t, t + dt] is given by
Assume a cuboid of length L, width W and height H meters, and having a mass of M kilograms. The height however will not be used in the remaider of this paper, its significance is only given in some cases when the mass of the cuboid has to be calculated. Assume also that we observe this cuboid from above, thus not seeing its heigth dimension. Additionally, the car at time t is at position (x(t), y(t)) in the plane and is moving upwards in positive y direction with constant velocity v. This kind of movement is called translation. If no force is applied to such an object, then the velocity will not change, and after a time dt has passed, the car’s change of position dy in the y direction will be dy = y(t + dt) − y(t) = v dt.
a 2 dt , 2
(2)
vR = ωR
The factor a = F/M = dv/dt is called the acceleration
(5)
and likewise its acceleration by aR = αR.
(6)
Acceleration is related to a force F being applied to a point of the cuboid. Fig. 2 (b) shows the case where a force F is applied to a point A. Here, the force vector F = (Frot , Ftran )T must be split into two components. The first −−→ component Frot is perpendicular to the vector CA and results in a rotational force changing ω. The remaining component Ftran is simply a translational force and must be treated as described in (1) to (4). Frot then results in a torque [15] Figure 1: A cuboid is accelerated by a force F .
T = Frot R.
22
(7)
Figure 4: Ackermann steering and centripetal force.
and Ftrac,r,y ), and points into the direction of the respective tyre. This component is mainly responsible for accelerating the car. The second component (Ftrac,f,la and Ftrac,r,x) is the lateral force, which is responsible for keeping the car on the current track.
Figure 3: The base car model with traction forces (a) and the car movement model (b). Similar to (2), this torque is then translated into angular acceleration by T (8) α= , I where I is the rotational equivalent to mass called moment of inertia. For general shapes and axes, I must be described by means of so-called tensors. However, for a cuboid and an axis going through the center of mass C and being perpendicular to the upper cuboid face, IC is defined to be [14]
Steering is modelled by the steering angle β, which defines the current angle between the front tyre and the main car direction (see Fig. 3 (b)). The current velocity of the car is represented by v. Furthermore, due to steering, the car may rotate by an angular velocity ω, the rotational axis here going through point B. However, as later shown in (23), ω can be computed by β, the current longitudinal velocity v, and L.
M (W 2 + L2 ) . (9) 12 An important result is given by the parallel axes theorem due to J. Steiner, which describes the moment of inertia I if the axis is parallel to the one through C, and having a distance of R from it [19]: IC =
I = IC + M R 2 .
4.
4.1 Limitations of the Model The described model is kept simple on purpose and does not implement a number of features. The omitted features, however, are mostly orthogonal to the model and can be added to the equations if so desired.
(10)
First, the model does not implement weight transfer, which happens when the car is accelerated [10, 2]. Second, the model assumes an engine or brake torque to be fed from the engine into the tyres. Elaborated models for computing the engine torque as a function of gear and rpm exist, and can easily be used in addition to this model [21, 10]. Third, the model assumes only two tyres instead of four, thus blurring the possibility of different forces on the two front or rear tyres. Fourth, there is no slip between tyres and the ground, i.e., the slip ratio is set to 1 (see Section 4.6). As a consequence, there are also no applications of Pacejka’s Magic Formula, which models properties of the tyre and the resulting slip [11]. Finally, the presented model does not contain aerodynamic drag and rolling resistance, which impose a breaking force onto a moving car [10].
A 2D CAR PHYSICS MODEL
In the proposed model the car is modelled by a cuboid as described in the previous section, with length L, width W and mass M . As convention we always assume that the car is heading up, i. e., its orientation is along the positive y-axis. Furthermore, as a simplification, the car uses only two tyres instead of four, the tyres being at the middle of the front and rear sides, depicted in Fig. 3 (a) as points A and B. At these points, the major forces are exchanged between the car body, the tyres, the engine and the ground. The figure also shows the traction force „ « Ftrac,f,x Ftrac,f = Ftrac,f,y « „ «„ cos β − sin β Ftrac,f,la (11) = Ftrac,f,lo sin β cos β at the front tyre, and Ftrac,r =
„
Ftrac,r,x Ftrac,r,y
The major source for driving a car is of course its engine. However, once moving, different forces appear and either move the car to the side or reduce its speed. In the following, three major types of force are investigated and described by equations. The integration of these equations into one closed model is then presented in Section 6.
« (12)
4.2 Ackermann Steering For cars there exists a movement model called Ackermann steering [6] (Fig. 4). The car center C moves along a circle,
at the rear tyre. Both forces can be split into two components. The first is a longitudinal component (Ftrac,f,lo
23
vector vB = (0, v)T , whereas point A moves with velocity vA = (ωL, v)T , and point C with velocity vC = (ωL/2, v)T , which is consistent with (13). If the car moves along a circle because of steering, this means that the points move at different circles being concentric, but having different radii. A travels along the largest circle, while C travels along a smaller circle, and B again on a smaller circle, exactly as defined in the Ackermann steering model. Because of (14), (15), and (16) the relations between the different velocities are given by r |c| tan2 β |vC | |vC | = = = 1+ ≥ 1, (17) |b| |vB | v 4
Figure 5: Movement model. the rear tyre moves along a circle being concentric to the first one, but with smaller radius, and the front tyre moves along another concentric circle with larger radius. The center D of is the − intersection of the vectors a = −→ −−→the three circles AD = (ax , ay )T and b = BD = (bx , 0)T , which originate at the tyre centers and which are perpendicular to the tyre orientations. If β = 0 then the two vectors are parallel and meet at infinity. Note that for β = 0 the center of mass C circumvents a larger circle than the one B circumvents in the same time, its velocity vC thus must be larger than the velocity |vB | of B, the same is true for points A and C. For β = 0 it follows that |vB | < |vC | < |vA |.
and |vB | v |b| = = = cos β ≤ 1. |a| |vA | |vA |
4.3 Centripetal Force If the steering angle β is different to zero, then a lateral force is put onto the front tyre, pushing the front of the car to the respective side. For a fixed β, the car then travels along a circle. If an object with mass M moves with velocity v along a circle with radius R, then there must be a centripetal force Fcp pushing the object center C to the circle center. The length of Fcp is known to be [13] (see Fig. 4)
(13)
In the following, these properties are the only premises for the car physics model described in this paper.
|Fcp | =
M |vC |2 . R
Fcp
(14)
=
M (1 +
tan2 β ) v2 4
|c|
2
and
„ a=
bx −L
«
„ =
−L cot β −L
«
= .
(19)
From (16), (17) and (19), and noting that in this case R = |c|, we get
Simple calculation shows that the angle in the left corner of the triangle BDA is also the steering angle β. For given L, it follows that for β = 0 and |β| < π/2 bx = −L cot β
(18)
(15) =
−−→ Similarly, the vector c = CD connecting the center of mass C with the circle center D is given by „ « „ « bx −L cot β c= = . (16) −L/2 −L/2
c |c| 2 „
−M (1 + tan4 β ) v cot β 1/2 L(cot2 β + 1/4) „ « 2 2 −M v tan β cot β 1/2 L
«
(20)
This is the centripetal force pulling the car towards the center of the circle it runs on. Also, it must be poduced by the lateral (cornering) forces of the front and rear tyres which are parts of the overal traction forces. Thus the next step is to split Fcp = Fcp,f + Fcp,r into two cornering forces originating at the front (Fcp,f ) and rear tyres (Fcp,r ), and pointing along the vectors a and b towards D. Since the forces responsible for the car rotation are modelled in Sections 4.4 and 4.5, the forces Fcp,f and Fcp,r treated here do not change the car’s rotation. From the description of rotational forces in Section 3 it follows that the force components −→ − −→ which are perpendicular to the vectors CA and CB must be equal. When the car points up these components are the x-coordinates of Fcp,f and Fcp,r , which therefore must be equal: „ cot β « −M v 2 tan2 β 2 , (21) Fcp,f = 1/2 L
In the presented model, the car is moved in the following way (see Fig. 5). In each time period dt, the car first moves a length of ds = v dt into the direction of the car, then the car is rotated by an angle of dθ = ω dt, using B as rotational axis. At this point it must be noted that it is thinkable that the rotational axis might go through the center or mass C, an assumption being found in many other 2D models. However, the following argument does not support this assumption. Suppose the rotational axis goes through C and not through B. The velocity of point C then is given by vC , point B would also have this velocity component, but additionally, due to the rotation around C, a second velocity component being perpendicular to vC . For β = 0 it follows that |vB | > |vC |. This, however is in contradiction to (13).
and
Due to the rotation, A additionally moves along a circle with speed ωL. As a consequence, point B moves with velocity
Fcp,r =
24
−M v 2 tan2 β L
„
cot β 2
0
« .
(22)
Figure 6: Forces causing the car to rotate.
Figure 7: A force causing a cuboid to rotate (a) and application of two forces additionally causing an acceleration a (b).
It is worth noting that the centripetal forces Fcp,r and Fcp,f depend on the current steering angle β and the current velocity v, but not on the steering change dβ/dt. Also note that both forces approximate the zero vector for β → 0.
to the rotational axis, the only point where such a force might be created is the front tyre. From there, it must point straight down to the rear tyre, i.e., its x-coordinate must be zero. Similar to (19), and by using (23), the y-coordinate of this force then must be
4.4 Car Rotation A car travelling along a circle will also rotate as described in Section 3.2. Assume that the car is travelling with velocity v around a circle with radius R and circumference l = 2Rπ. Since for a complete run around the circle it needs the time dt = l/v and rotates around an angle dθ = 2π, the rotation is carried out with angular speed ω = dθ/dt. Since v is the velocity of point B we set R = −bx and derive because of (14) ω=
2π v v v dθ = = = tan β. = dt l/v −bx L cot β L
Fcp,B,y = −
which is the same as the y-coordinate Fcp,f,y of the centripetal force at the front tyre Fcp,f as given by (21). In fact, this argument proves that the same force Fcp,f that is responsible for keeping the car on its track at the front tyre also is responsible for letting the car rotate around its rear tyre, and not its center of mass.
(23)
Consider the car in Fig. 6. The force responsible for the rotation is Frot,f = (Frot,f,x , Frot,f,y )T caused by the front tyre. To be exact, only the x-coordinate Frot,f,x causes the rotation, the other component Frot,f,y acts as a breaking force.
4.5 A Mysterious Force At this point it must be noted that there is also a lateral force at the rear tyre responsible for the rotation, though this force may not be visible at first sight. Think of a force causing a cuboid to spin. If only one force is applied, then the cuboid must rotate around its center of mass C. However, in the presented model, the rotational axis is the rear tyre, not the center of mass. It follows that there must be a second force, this time a lateral force Frot,r = (Frot,r,x , 0)T at the rear tyre, which shifts the rotational axis to the rear.
Since we assume that the car’s rotation axis goes through its rear tyre, from (10) we know that the car’s moment of inertia is IB = IC + M L2 /4. Thus, if the velocity v or the steering angle β change within a time dt by the amount of dv or dβ, then from (23) we get [16] α=
dω tan β dv v dβ = + . dt L dt L cos2 β dt
Consider the scenario depicted in Fig. 7 (a). A force Frot,f,x induces an angular acceleration
(24)
Following (7) and (8), the force component Frot,f,x of the front tyre must be « „ IB v dβ dv α IB = − 2 tan β + , (25) Frot,f,x = − L L dt cos2 β dt
α=
Frot,f,x L/2 IC
which in turn will cause the cuboid to rotate about the axis going through its center of mass C. The angular acceleration also causes an acceleration l = αL/2 of point B.
and furthermore Frot,f,y
M (ωL/2)2 M v 2 tan2 β =− , L/2 2L
Now consider Fig. 7 (b). Here, B is fixed to an axis and Frot,f,x causes some Frot,r,x to press against this axis, causing an equal force into the opposite direction. The result is that the force causing rotation now is only Frot,f,x −Frot,r,x:
= Frot,f,x tan β « „ IB tan β v dβ dv = − + . (26) tan β L2 dt cos2 β dt
α=
Another aspect of rotation is the fact that the car rotates around an axis going through point B. This rotation also demands a centripetal force Fcp,B , pushing the car against B, since without this force the car would rotate around its center of mass C. As the centripetal force always points
(Frot,f,x − Frot,r,x )L/2 IC
and the acceleration of B is given by l =
25
(Frot,f,x − Frot,r,x ) L2 /4 . IC
force at the front tyre actually is the sum Ftrac,f
= Fcp,f + Frot,f + (30) „ «„ « cos β − sin β 0 + . sin β cos β Facc,f
Here the force Facc,f is used similarly to Ftrac,r,y in (29): Ttot,f
=
Te,f − Facc,f Rw .
(31)
By using (21), (26) and (30), the y-coordinate of Ftrac,f is given by Figure 8: Acceleration forces at the tyres and the car body.
Ftrac,f,y
Additionally, the center of mass C is accelerated by a=
Fcp,f,y =
Now in order that B remains on its position, it follows that
IB − IC Frot,f,x IB
IB tan β . (33) L2 For the car body, the longitudinal traction forces sum up and result in the total longitudinal acceleration force Ftot on the car body: fr :=
(28)
Ftot = Ftrac,r,y + Ftrac,f,y .
which denotes the lateral force Frot,r,x at the rear tyre in case there is a lateral force Frot,f,x causing rotation at the front tyre.
(34)
Note that in (34), the term Ftrac,f,y can immediately be replaced by the right hand side of (32). Equ. (34) is also a good place for adding additional terms for various drag forces, which is not done here. What remains is the coupling between the rotational acceleration of the tyres and the car acceleration, which due to (2), (6), (7), (8), and (18) result in dv Ftot Rw Ttot,r = = , (35) dt M Iw
4.6 Acceleration The last movement component of the presented model is given by the longitudinal acceleration dv/dt of the car body. Recall the basic car force model as depicted in Fig. 3 (a). Also recall the definitions of the traction forces Ftrac,f by (11) and Ftrac,r by (12).
and Ftot |vB | Rw Ttot,f dv Rw Ttot,f = = = cos β . dt M |vA | Iw Iw
Longitudinal acceleration mainly is created by the car engine and the tyre breaks. An engine puts a torque Te,r to the rear axle, which itself forwards this torque to the rear tyre (in this model there is only one central tyre). This torque then results in an angular acceleration of the rear tyre, and a traction force Ftrac,r,y between the rear tyre and the ground. This traction force then accelerates the car body (and the car body then accelerates the front tyre). Alternatively, the tyre breaks would cause negative torques Te,r at the rear and Te,f at the front tyre. In the presented model, there is no slip ratio between the tyres and the ground. If a slip ratio is desired, then the model must be augmented with a corresponding slip factor.
(36)
The meaning of the system of linear equations (29) to (36) is this: if a torque is put onto the rear (front) tyre, this torque is split into the parts accelerating the rear (front) tyre, the front (rear) tyre and the car body. The velocity of the car mass is equal to the rotational velocity of each tyre. However, the velocity of the front tyre must be multiplied by a term which corrects the different movement radii. Additionally, if a slip ratio different to 1 is desired, it can be added to (35) and (36). The above system of linear equations (29) to (36) can be solved analytically. The solution for Ftot is given by “ ” fr v dβ 2 M Rw Fcp,f,y − cos 2 β dt + (37) Ftot = 2 2 Iw + (M + fr tan β)Rw
In order to establish the corresponding equations, we define the radius of a tyre by Rw , and the tyre inertia by Iw . Note that the engine torque is split into two parts, a Ttrac,r,y creating the traction force Ftrac,r,y , and the second part Ttot,r actually accelerating the rear tyre (Fig. 8). By noting (7) we get: Ttot,r = Te,r − Ftrac,r,y Rw .
−M v 2 tan2 β 2L
and
(27)
Simple calculation shows that (27) leads to Frot,r,x =
(32)
here setting
Frot,r,x . M
l = a.
= Fcp,f,y − « „ v dβ dv + + −fr tan β dt cos2 β dt +Facc,f cos β,
+
(29)
M Rw (cos β Te,f + Te,r ) 2 2 Iw + (M + fr tan β)Rw
The first summand of (37) denotes the rotational and centripetal forces, while the second part denotes the engine and
At the front tyre things get more complicated. The traction
26
Parameter W L M Rw Iw
Value 2 4 1500 0.33 2 × 4.1
Unit m m kg m kg m2
Explanation Car width Car length Car mass Radius of tyre Inertia of tyre
InitializeModel(); double lasttime = now(); while( true ) { Input input; GetUserInput( input ); double time = now(); ComputeModel( input, time - lasttime ); RenderTheScene(); lasttime = time; }
Table 1: General model parameters.
break torques. Furthermore, from (37), the other unknowns Ttot,r , Ttot,f , Ftrac,r,y , and Facc,f can easily be derived using equations (29) to (36). Although (37) looks quite complicated, for β ≈ 0 it changes into a much simpler form, because in this case cos β ≈ 1 and tan β ≈ fr ≈ Fcp,f,y ≈ 0: Ftot
Table 2: The game loop.
and the engine/break torques Te,r and Te,f as defined in Section 4.6.
M Rw (Te,r + Te,f ) . ≈ 2 2Iw + M Rw
The game loop, which is executed continuously throughout the game, is shown in Tab. 2. At first the user input is queried from either keyboard or joystick. Then the function responsible for computing the model is called. Its input parameters are the user input, here a structure holding β, Te,r and Te,f , and the time since its last call.
The M in the numerator is of course the car mass, while the denominator represents the inertia of both tyres plus the car mass. Additionally, the numerator just sums up the engine and break torques of the rear and front tyres.
5.
TRACTION
The code for computing the model itself is shown in Tab. 3. The function is called after some time dt has gone by. The function then computes the model behaviour for the last dt seconds, i.e., for the time interval that has passed by. The structure oldinput stores the user input that was recorded at the start of this interval, while the structure input holds the user input at the end of the interval. Engine and breaking forces either can be taken from oldinput and can be kept constant throughout the interval, or the average between the engine and breaking forces of oldinput and input can be used. In Tab. 3 the first alternative is chosen.
The traction forces depicted in Fig. 3 (a) are exchanged between the tyres and the ground. However, there is a limit Fmax to the amount of force that can be exchanged. If the traction force on one of the tyre exceeds this bound, then the tyre looses grip and starts sliding. It follows that the model must continuously check whether the traction forces exceed the maximum. In such a case, the model then must switch to an appropriate sliding model, which is not treated in this work, but for instance in [10]. Following [6], Fmax is determined by the static friction factor µs in the following way. If F denotes the force that presses down the tyre to the ground, then
7. EXPERIMENTAL RESULTS The pseudocode from Tab. 3 has been implemented by using Mathematica 5.2.7 The implementation has been used for running a number of experiments. The purpose of the experiments was to test whether the presented model can be implemented as described in Tab. 3 and yields numerical results that make sense. Also the experiments should show the magnitude of the observed traction forces, including centripetal forces (which are mainly used in other models), but also the additional forces as described in this paper, and furthermore investigate the usefulness of the given explicit formulas for explaining numerical results.
Fmax = µs F. Here, F is the amount of weight force on one tyre, i.e., in the presented model F = 9.81M/2. Values for µs are, for instance, µs = 1.0 for rubber on dry concrete ground, or µs = 0.3 for rubber on wet concrete ground. If the car starts sliding, then the force exchanged between tyre and ground is asssumed to be constant: Ftrac = µk F . Here µk denotes the kinetic friction factor which, for instance is µk = 0.8 for rubber on dry concrete ground, or µk = 0.25 for rubber on wet concrete ground. Other values for µs and µk can be found, for instance, in [6, 1].
6.
In the first set of experiments, the car is only accelerated without steering, i.e., β = 0 and Te,r > 0. Furthermore, it is assumed that acceleration on the front tyre is only done via the brakes, which are not used in the presented experiments. Thus, throughout all experiments, Te,f = 0. Also, the time difference was set to dt = 10 ms. The traction forces and the force on the main car body for acceleration only can be seen in Fig. 9. The figure additionally shows the maximum allowed forces for dry (upper horizontal thin line) and wet (lower horizontal thin line) ground, as defined in Section 5. If the traction force at any tyre exceeds this bound then the car starts sliding. It can be seen that almost all of the
MODEL SOLUTION
The previous sections have presented numerous equations, their integration into a closed model is described in this section. For solving the model, we now define a set of parameters and input variables which define the state of the model and user input. The set of basic model parameters is shown in Tab. 1. The current model state is given by the velocity vB = (0, v)T of point B. User input is given by the steering angle β
7
27
http://www.wolfram.com/
β=0
Force (N )
Input oldinput; double v = 0; ComputeModel( Input input, double dt ) { if( dt > 0 ) { β = oldinput.β dβ = input.β − oldinput.β Te,f = oldinput.Te,f Te,r = oldinput.Te,r Compute ω from (23) if( β = 0 ) { Compute Fcp,f from (21) Compute Fcp,r from (22) } else { Fcp,f = (0, 0)T and Fcp,r = (0, 0)T } Compute fr from (33) Compute Ftot from (37) a = Ftot /M Compute α from (24) Compute Ftrac,r,y , Facc,f , Ttot,r , and Ttot,f from (29) to (36) Compute Frot,f from (25) and (26) Compute Frot,r from (28)
Ftot Ftrac,f,y Ftrac,r,y
0
500
1000
1500
2000
2500
Te,r (N m)
|Ftrac,f | (N)
Figure 9: Forces caused by acceleration only (β = 0, dβ/dt = 0, Te,f = 0).
Ftrac,r = (0, Ftrac,r,y )T + Fcp,r + Frot,r Compute Ftrac,f from (30) Fmax = 9.81 M/2 if( |Ftrac,r | ≤ Fmax && |Ftrac,f | ≤ Fmax ) { Advance the car by ds = v dt + a dt2 /2 Rotate the car by dθ = ω dt + α dt2 /2 v = v + a dt } else { Switch to sliding model }
}
8000 7000 6000 5000 4000 3000 2000 1000 0 -1000
β = 1 deg 16000 14000 dβ/dt = 0 dβ/dt = 1 12000 dβ/dt = 5 10000 dβ/dt = 10 8000 6000 4000 2000 0 0 20 40 60 80 100 120 140 160 180 200 v (km/h)
Figure 10: Front traction force |Ftrac,f | caused by steering only (β = 1 deg, Te,r = 0, Te,f = 0). For dβ/dt = 0, |Ftrac,f | is almost equal to |Fcp,f |.
} oldinput = input;
is caused by the rotational forces Frot,r and Frot,f , which additionally are shown in Fig. 11.
Table 3: Computing the model. The same experiments have been repeated, this time setting β = 3 deg. The results are shown in Figs. 12 and 13. Especially Fig. 12 shows that when the steering angle is that large then the traction forces soon become too large and steering is impossible.
resulting body acceleration Ftot is due to the rear traction force Ftrac,r,y . The front traction force Ftrac,f,y here only is responsible for accelerating the front tyre.
The final experiments investigate which values for β and dβ/dt do not cause sliding when driving with a certain velocity v. In Fig. 14 the maximal allowed steering angle β is shown for dry and wet ground. The thin horizontal lines are drawn at β = 1 deg and β = 3 deg. The results may, for instance, be used to implement a virtual steering assistance system which prohibits sliding by automatically reducing β, in case the traction forces grow too large.
In the next experiments it is assumed that the car is travelling with some velocity v > 0 and a nonzero steering angle β > 0. However, there is no engine or break torque on the tyres. At first, the steering angle β was set to 1 degree, and the steering angle change dβ/dt was set to dβ/dt = 0, 1, 5, and 10 deg/s. The resulting front traction force |Ftrac,f | is shown in Fig. 10. Here it must be noted that if β = 0 and dβ/dt = Te,r = Te,f = 0, then the car body acceleration force Ftot is quite small, but due to the y-coordinate of (21) not zero. It follows that dv/dt is also quite small, resulting due to (24) in a small rotational force Frot,f and Frot,r . Thus, the observed traction forces are mainly caused by the centripetal forces, i.e., Ftrac,r ≈ Fcp,r and Ftrac,f ≈ Fcp,f . If however the steering angle changes, then it can be seen that the traction forces quickly rise. This additional growth
For β = 1 deg and β = 3 deg it has then been investigated how fast the driver may change the steering angle without causing the car to slide. The results are shown in Fig. 15, again for dry and wet ground. The lines end at the points where the traction force is already too large only because of β = 0 (compare to the intersections of the thick lines and the thin horizontal lines in Fig. 14).
28
β = 1 deg
β = 3 deg 10000 |Frot,r | and |Frot,f | (N)
|Frot,r | and |Frot,f | (N)
10000 1000 100 dβ/dt = 0 dβ/dt = 1 dβ/dt = 5 dβ/dt = 10
10 1 0.1 0.01 0.001
0
1000 100 10 0.1 0.01 0.001
20 40 60 80 100 120 140 160 180 200
dβ/dt = 0 dβ/dt = 1 dβ/dt = 5 dβ/dt = 10
1
0
20 40 60 80 100 120 140 160 180 200
v (km/h)
v (km/h)
Figure 11: Rotational forces |Frot,f | (thick lines) and |Frot,r | (thin lines) caused by steering only (β = 1 deg, Te,r = 0, Te,f = 0).
Figure 13: Rotational forces |Frot,f | (thick lines) and |Frot,r | (thin lines) caused by steering only (β = 3 deg, Te,r = 0, Te,f = 0).
Maximum allowed β 100 dry wet
40000 35000 dβ/dt = 0 dβ/dt = 1 30000 dβ/dt = 5 25000 dβ/dt = 10 20000 15000 10000 5000 0 0 20 40 60 80 100 120 140 160 180 200
Max. β (deg)
|Ftrac,f | (N)
β = 3 deg
10
1
0.1
0
20 40 60 80 100 120 140 160 180 200 v (km/h)
v (km/h)
Figure 14: Maximum allowed β (deg) for front traction force |Ftrac,f | caused by steering only (dβ/dt = 0, Te,r = 0, Te,f = 0).
Figure 12: Front traction force |Ftrac,f | caused by steering only (β = 3 deg, Te,r = 0, Te,f = 0). For dβ/dt = 0, |Ftrac,f | is almost equal to |Fcp,f |.
Maximum allowed dβ/dt
8.
Max. dβ/dt (deg/s)
1000
CONCLUSIONS
In this paper a detailed car physics model for Ackermann steering is presented. The model consists of closed formulas which derive all necessary forces and thus accelerations for simulating Ackermann steering. In particular, centripetal forces, rotational forces and acceleration forces are described. An interesting result is given for rotational forces at the rear tyre. Furthermore, the identity of a component of the centripetal force at the front tyre, and the force being responsible for rotating the car about its rear tyre is shown. It is then demonstrated how to use the model in a game loop. Finally, an implementation of this loop is used for carrying out a number of numerical experiments.
β = 1, dry β = 3, dry β = 1, wet β = 3, wet
100 10 1 0.1
0
20
40
60
80 100 120 140 160 180 v (km/h)
Figure 15: Maximum allowed dβ/dt (deg/s) for front traction force |Ftrac,f | caused by steering only (Te,r = 0, Te,f = 0).
The model does not include things like weight transfer, tyre slip or engine power. These have been investigated thoroughly in previous papers and can be included into the model easily.
9. REFERENCES [1] R. Beardmore. Friction factors. WWW, March 2006. http://www.roymech.co.uk/Useful Tables/Tribology/ co of frict.htm.
Future work will focus on sliding models, which will model the case when only the front tyres, only the rear tyres, or all tyres loose traction.
[2] B. Beckman. The Physics of Racing Series.
29
http://phors.locost7.info/, 2002. [3] R. Bower. The Physics of Motorsport. WWW, 1999. Department of Physics, University of Durham. [4] R. Chaney. Simulating Single Rigid Bodies. http://homepage.ntlworld.com/richard.chaney/ index.html, 1999. [5] C. Gerthsen. Physik. Springer, 2006. [6] S. Gsoellpointner. Ein 3-dimensionales Modell zur Simulation von Kraftfahrzeugen in Echtzeitanwendungen. Master’s thesis, Johannes Kepler University, September 2002. [7] C. Hecker. Physics, The Next Frontier. Game Developer, pages 12–20, October/November 1996. http://www.d6.com/users/checker/dynamics.htm. [8] C. Hecker. Physics, Part 2: Angular Effects. Game Developer, pages 14–22, January 1997. http://www.d6.com/users/checker/dynamics.htm. [9] E. M. Lowndes. Development of an Intermediate DOF Vehicle Dynamics Model for Optimal Design Studies. PhD thesis, Department of Mechanical and Aerospace Engineering, North Carolina State University, 1998. [10] M. Monster. Car Physics for Games. WWW, December 2001. http://home.planet.nl/ monstrous/tutcar.html (Web link currently broken). [11] H. Pacejka and E. Bakker. The magic formula tyre mode. Vehicle System Dynamics, 21:1–19, 1991. [12] R. van Gaal. Car physics - reference. WWW, April 2006. http://www.racer.nl/reference/carphys.htm. [13] Wikipedia. Centripetal force. WWW, August 2006. http://en.wikipedia.org/wiki/Centripetal force. [14] Wikipedia. List of moments of inertia. WWW, July 2006. http://en.wikipedia.org/wiki/ List of moments of inertia. [15] Wikipedia. Moment of inertia. WWW, August 2006. http://en.wikipedia.org/wiki/Moment of inertia. [16] Wikipedia. Product rule. WWW, August 2006. http://en.wikipedia.org/wiki/Product rule. [17] Wikipedia. Rigid Body Dynamics. WWW, July 2006. http://en.wikipedia.org/wiki/Rigid body dynamics. [18] Wikipedia. Sinc function. WWW, August 2006. http://en.wikipedia.org/wiki/Sinc function. [19] Wikipedia. Steiner’s Theorem. WWW, July 2006. http://en.wikipedia.org/wiki/Parallel axes rule. [20] Wikipedia. Trigonometric function. WWW, September 2006. http://en.wikipedia.org/wiki/Sine. [21] T. Zuvich. Vehicle Dynamics for Racing Games. WWW, 2000. http://www.gamasutra.com/features/gdcarchive/ 2000/zuvich.doc.
30
Design and Implementation of an Auditory Help System for Computer Games Aidan Kehoe
Flaithrí Neff
Ian Pitt
University College Cork, Cork, Ireland. +353 87 6668609
University College Cork, Cork, Ireland. +353 87 7615315
University College Cork, Cork, Ireland. +353 21 490 2863
[email protected]
[email protected]
[email protected]
presenting game-related help material. Speech technology can be used to present online help to players in games. It can complement the traditional help delivery techniques, and mitigate some of the problems associated with these techniques.
ABSTRACT Traditional methods of providing help are generally applicable to gaming, but have limitations. This paper describes the design and implementation of an auditory help system that can complement traditional online help methodologies and be tightly integrated into games. We consider the cognitive constraints of the user in relation to the presentation of bimodal information in a game environment. With the majority of emphasis placed on visual aspects of game-play, we suggest the integration of an auditory help system. However, there are also significant issues which should be taken into account when utilizing such a system including: technological constraints; perceptual interaction between visual and auditory information; perceptual interaction between speech and non-speech sounds within the help system itself; and interference between game sounds and help system sounds.
This paper describes the architecture and design of a help system for games that was developed to support both traditional online help functionality, and also to provide an optional auditory interface incorporating speech and non-speech sounds. Speech technology is being used in a growing number of fields as a result of increasing capabilities of computing platforms and on-going improvements in speech technology performance. However, speech technology still has performance limitations and the speech-enabled help system has been designed within these current technological limitations. The incorporation of the auditory help system into a visual game environment is not just based on technological factors. It is also based on an attempt to find the most efficient interaction between the machine and a user's cognitive processes. The paper presents a model that explains how the speech-enabled help system operates in the context of the game. This paper describes the types of help information that are suitable for presentation aurally. Guidelines for authoring effective auditory help information are proposed.
Categories and Subject Descriptors H.5.2 [Information Interfaces and Presentation]: User Interfaces – training, help and documentation.
General Terms Documentation, Design, Human Factors.
The focus of the initial implementation was on the development of a working system capable of supporting context-specific help topics. The speech-enabled help system was integrated in a number of fairly basic open source games that run on the Microsoft Windows platform.
Keywords Online help, Speech technology, Sonification.
1. INTRODUCTION Game designers are aware of the risks of games becoming overly complex and difficult to play [35]. Gee [25] identified a number of approaches used in game design that help players to progress through long, complex and difficult games. Also, most game interfaces have direct manipulation style interfaces [51]. This type of interface encourages user exploration and learning.
2. ONLINE HELP IN COMPUTER GAMES Help system technologies have evolved over the past forty years. The latest online help systems make use of enhanced computer capabilities and new technologies. Collapsible table of contents, full text search, popup text and task-oriented help topics are some of the developments. Wizards and tutorials sometimes incorporate multimedia elements for presentation of information to the user. The same techniques used to provide help in general computing applications are also widely used in games.
However, in spite of the best efforts of developers many players Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. GDTW 2006, November 15–16, 2006, Liverpool, U.K. Copyright 2006 ACM 1-58113-000-0/00/0004…$5.00.
2.1 Challenges for Traditional Help in Games Empirical studies show that well designed help material can be effective [26]. However, traditional techniques for providing help to users present a number of significant challenges that are very apparent in the context of games.
will still require help at various stages of a game. Traditional techniques for providing help to users present a number of well known challenges, and these challenges are also relevant when
31
Simple detection of stimulus in a multi-modal environment requires little cognitive processing and is dealt with efficiently by the respective peripheral sensory mechanisms. Therefore the use of aural, visual and haptic stimuli for detection purposes is not an issue of concern and many earcons1 and auditory icons2 plainly do this to draw attention to such things as system warnings or application actions. However, when more detailed, contextual information or source monitoring of simultaneous information streams is required, issues of cognitive overload and divided attention become relevant [46]. It is important to point out that this not only becomes an issue for multi- or bimodal interfaces but also for unimodal interfaces providing several streams of data concurrently to the user. Once past the peripheral sensory mechanisms, a more desegregated central cognitive system takes over.
• Hands/eyes busy: In many gaming scenarios the player’s hands and eyes are busy. To access help information the player may need to pause the game, or perhaps open an additional help window. Pausing the gaming, or the introduction of an overlay help window, can result in a considerable disruption to the player’s gaming experience. • Context switching: Games often use a help window to display information to users. Studies on traditional computing applications show that switching between the application and the help window can be problematic, especially for novice users [33]. • Limited display real estate: Many games make use of popup text help. Hovering with the cursor over an element on the screen causes additional explanatory text to be displayed. However, the amount of space for popup text is very limited. The use of portable gaming devices with small display sizes and limited resolution, including cell phones and PDAs, makes display of text-based help material even more challenging [27].
3.1 Multimodal Streams The Auditory Help User Interface Model proposed by Neff and Pitt in this paper (Figure 1) attempts to take a cognitive snapshot of an instance of game play while using an auditorybased help system. The model incorporates an adaptation of the Baddeley & Hitch Working Memory Model [2, 3, 4] with the integration of some of the theories of Jones et al. [31, 32]. It is the Working Memory component along with the Subtask Attention & Inhibitor Manager that is perhaps the most relevant for this paper.
• Paradox of the active user: Carroll and Rosson [11] explain why users generally start using software immediately, without consulting manuals or other available help material. Also, when users do encounter a problem they are reluctant to break away from their current task, which is their primary focus, and consult the available help material. Use of speech technology to provide help to players within the context of the game can mitigate some of these problems, and complement traditional online help systems. Speech technology can be used to provide help information to players in situations where their hands and eyes are busy. Help information can be presented aurally in situations where effective visual display of help material is not possible.
3.1.1 Visual and Aural Streams The aim of the model is to identify and avoid possible bottlenecks in an environment such as that described in this paper and to accentuate areas that will facilitate the transfer of information to the user efficiently. We hypothesize that the use of an auditory help system relaying information to the user whilst he/she is interacting with a visual display will balance the cognitive load more effectively.
3. AUDITORY HELP SYSTEM MODEL The successful integration of an auditory help system into a largely visual game environment will require efficient interaction between the machine and the player's cognitive processes. This section of the paper describes how that interaction works. An understanding of the cognitive factors involved will help us to avoid design flaws by allowing us to anticipate the data flow of visual and auditory information. This allows us to identify areas of segregation and areas of consolidation of visual and auditory streams, possibly revealing points of perceptual interaction and interference. Unlike visual information, there is an inherent lack of external memory (display) for auditory information. Therefore, we need to maximally utilize the human memory components relating to auditory information and avoid perceptual interaction and interference with the visual content. Although visual and aural data utilize similar and closely related short-term storage components, the user interface model presented here (Figure 1) recognizes the separation of aural and visual information at critical stages within working memory. There is also the issue of segregation between lexical and acoustic content that is conveyed in the model and that has significant implications for our design and implementation of the auditory help system itself. All of these factors (vision, speech and non-speech sounds), though potentially discrete, are highly reactive with each other in most HCI applications. It is the potential discreteness of these factors that we hope to exploit through recognizing the cognitive constraints.
32
1
An earcon is defined as a “….non-speech audio messages consisting of abstract, musical tones that are used in structured combination. As there is no intuitive link between an earcon and what it represents, earcons have to be learnt.” [56]
2
An auditory icon is defined as “….natural, everyday sounds that are recorded in the environment and mapped to system events by analogy. The advantage of auditory icons is that only a minimal learning effort is required to understand the connection between sound and the to-be-represented object.” [56]
Figure 1: Auditory Help User Interface Model. involving the Central Executive, but here specified as a managerial element controlling attention and inhibition (the Sub-task Attention & Inhibition Manager which is labeled “StAIM” in Figure 1).
We hope to achieve this by examining aspects of human working memory, particularly with respect to maximizing its storage capacity by separating auditory and visual information. We also need to look at attention and inhibition aspects of dualtask, bimodal situations.
This attention and inhibition function is a top-down process and cortical regions have been demonstrated to correlate with this functioning [29]. During bimodal auditory and visual tasks, cross-modal interaction occurs between the respective cortices. Johnson and Zatorre [29] showed how during bimodal tasks where attention is focused on one of the tasks, cortical activity associated with the attended sense was increased whereas activity of cortical areas associated with the unattended sense was decreased. Passive attention during bimodal presentation shows balanced activity between auditory and visual cortices and even unimodal tasks display significant inhibition of the cortical areas associated with the absent sense. These observations indicate active cross-modal interaction between cortices depending on the user's attention on tasks. Attention mechanisms therefore force suppression of unattended modalities and this subsequently affects memory encoding.
Unimodal visual dual-tasks exhibit a sharing cost of 15% between both visual streams when the subject is instructed to give 100% attention to the primary task and 0% to the secondary task [8, 54]. This sharing cost does not occur in similar circumstances between auditory and visual streams, therefore it is reasonable to conclude that it is easier to monitor two streams in different sensory modalities than in the same modality [8, 44, 55], or indeed it is easier to concentrate more efficiently on one sensory stream whilst ignoring the other. In cases where auditory and visual information is complementary or where attention is not significantly distracted from either task, simultaneous presentation of auditory and visual information produces little or no degradation in short-term item-specific or contextual data retention [46]. Therefore, with careful consideration to issues concerning divided-attention and inhibition, it may be possible to present auditory help information simultaneously with visual game-play while retaining in some measure discrete pathways of auditory and visual information retention, thus reducing cognitive load or increasing cognitive processing efficiency. Baddeley's Working Memory Model accounts for such a separation between speech based and visual-spatial based information, although visual retention may have some slight degradation in bimodal scenarios if the dual-coding theory of vision is legitimate. Therefore, the bottleneck of concern is not so much memory capacity or organization in this case, but rather the cognitive interface between incoming data and the memory components. This cognitive interface is essentially the process that allocates resources between current tasks, indicated by Baddeley as
Cross-modal errors are a consequence of this attention and inhibition action during dual-task situations in both bimodal and unimodal interfaces. This is particularly so if information is incompatible for both tasks, with complementary information having a positive effect by enhancing the perceptual experience and retention capacity. Cross-modal errors have been demonstrated using haptic and visual tasks [13, 46], and in unimodal dual-task environments involving vision alone [30, 46]. This is primarily a result of divided-attention at time of encoding and not affiliated to storage and retrieval inadequacies. Therefore, the degree of attention allocated to each task is a significant consideration in auditory-visual interfaces, where cross-modal errors are also an anticipated
33
vocalized speech show significant interference in pitch memory, suggesting that there is a single storage system for pitch content of both speech and non-speech input [50]. This is contrary to the belief that, once identified as speech, a signal’s acoustic attributes (including its pitch) are separately stored in working memory and that non-speech content has no access to this store.
possibility. It is important to note that the degree of attention forced on one task over another has a direct bearing on memory retention and that these errors also occur in unimodal environments where dual-tasks are involved. Therefore, in order to take advantage of working memory's separation of auditory and visual information, aspects of attention need to be considered so as to limit cross-modal errors in particular situations.
The notion of a single store for various acoustic attributes, whether for speech or non-speech, seems consistent with the issues raised by Jones and Macken [31] in relation to the Irrelevant Sound Effect. This effect was previously known as the Irrelevant Speech Effect due to the notion that speech significantly interfered with subvocal rehearsal of visually presented text/digits, but non-speech sound did not. However, when matching the acoustic traits of non-speech sound with that of speech, disruption to visually presented text/digits is found to be comparable. Jones et al. [31, 32] determined that it is the changes in composition of the sonic stream that cause the disruption and not the lexical or semantic content of speech the changing state hypothesis. This correlates with the fact that a speech stream typically changes very significantly in terms of its physical characteristics over time.
3.1.2 Speech and Non-speech Sounds Non-speech sounds have several advantages over speech [42]. They can present information quickly. They can be attention grabbing. When cognitive considerations are taken into account, they do not interfere with speech processing. They’re already widely used in computer applications for signifying the success or failure of an operation. Because these sounds are typically shorter in duration than the equivalent spoken language message and easily attract the user’s attention, this feature may also be exploited in parallel with synthesized speech output to provide additional information to the user. For example, they can be used to cue speech, so that the listener is prepared to hear speech and does not miss leading words. They can be used to signify help system structural information such as topic titles, list items, the availability of more detailed help information, hyperlinks and bullets.
The use of very short, unvaried sonic events such as earcons and auditory icons and indeed speech keywords in the relay of information is therefore an important design principle if the changing state theory is valid. Slightly longer but repetitive sonic events also concur positively with the changing state hypothesis. It is our opinion that designers need to restructure help files from the ground up when presentation is implemented using speech rather than a direct text-to-speech implementation of visually designed help topics.
Non-speech sounds, if acoustically diverse from speech, can be used to work around the problem associated with the auditory suffix effect. This problem is encountered when presenting the trailing “related topics” and “notes” type of information that is commonly used in help topics. Studies [e.g. 17] show that presentation of non-speech sounds after speech does not significantly impair recall of the previously spoken words. A non-speech sound could be used to indicate availability of additional information. The user could access this additional information if required.
3.2 Game & Help Flow through the Model The model (Figure 1) represents the interaction between the relevant human cognitive processes and visual game-play cum auditory help system.
Non-speech sounds could also be used to assist in presentation of information that is not very suitable for rendering through speech. This includes items such as an indication of the presence of graphic items. However, care should be taken with the use of non-speech sound to ensure it is not distracting, and that it is correctly synchronized with speech output.
The user encounters a problem during game-play and creates a cognitive representation of that problem. The user’s experience will determine the resolution of such an internalization of the problem and this will have repercussions on various outcomes throughout the model. User-experience is a significant constraint throughout most of the model’s stages.
This brings us onto the perceptual issues associated with the implementation of an auditory help system that integrates speech and non-speech sounds. The original aural component of Baddeley’s Working Memory Model, the phonological loop, does not sufficiently explain the integration of non-speech sounds. Many studies have indicated that non-speech sounds are processed and stored separately in working memory [7, 19, 21] and indeed Baddeley and Salamé [48] indicate that this is a possibility if their theory of a speech detector within working memory is valid. However, many recent studies suggest that speech and non-speech sounds are processed and stored in a single auditory component in working memory [49, 50, 56]. This component may be subsequently subcategorized into various acoustic stores with a stripping of lexical material outside of these acoustic stores.
Having made a cognitive representation of the problem, the user now needs to find advice on the issue. Perhaps the first question raised in this instance is how to find such advice. The user’s long-term memory is now called upon to submit scenarios saved from similar previous experiences, referred to as schemas [14]. Schema-theory promotes the notion of interactive processing between top-down (conceptually-driven & generalizations based on personal experiences) and bottomup (data driven & based on sensory data analysis). Various schemas are tested until the most appropriate one is found for the current problem. As part of the chosen schema, the user has isolated where to find advice for the problem (in this case, locating the help system for the game). Based on the accuracy of the chosen schema (determined by user experience or lack thereof), the problem itself and how to engage with the help system needs to be broken down into smaller units called subtasks. Schema rules apply and therefore schema expectations of particular incoming information act like a sensory filter. In effect, a schema aids in the interpretation of incoming sensory data. This schema filter applies to both incoming visual game-play and auditory help system data.
Such non-lexical acoustic subcategories may follow the psychoacoustic approach of Bregman’s auditory scene analysis [9], but encompassing both speech and non-speech acoustical characteristics. For example, there is evidence suggesting that pitch memory pulls pitch information from both vocal and nonvocal input, but is deaf to other sonic dimensions [50]. Complex, flat tones consistent in spectral content and range as
34
Although for the most part only the expected data is readily noticed and passes through the filtering process, anomalies that particularly stand out are also noticed and allowed past the filter. Unlike the auditory help system, visual game-play has the advantage of external memory, or in other words most of the visual information remains displayed onscreen allowing for detailed reference by the user at a later stage. More important in this case, however, is the allocation of resources for information passing the schema filter. The incoming sensory information is combined with the subtasks and awaits admittance to working memory. Highly sensitive to top-down influences and the overall task scenario, the Subtask Attention & Inhibitor Manager allocates information to working memory. As already mentioned, the degree of attention required for any one task over another at any one time determines the success of data retention in working memory. There is also the issue of inhibition. De Fockert et al. [24] suggest that when working memory load increases, our ability to inhibit irrelevant information decreases. Therefore, an overload of either visual or aural content may lead to effects such as the Irrelevant Sound Effect, again proving the need to strictly evaluate and balance presented material – in our case auditory help files.
Figure 2: Audio Configuration The standard game audio remains directed to the gaming system speakers. The player hears the auditory help system output on the headset earphone. The player can optionally use the headset microphone to issue voice commands to control access to the help system i.e. the player hears normal game audio through the speakers, and interacts with the help system via the headset. Given the location differences between game audio and help system audio (speakers and mono-headset respectively), this reduces the possible interaction and interference between these two sources. That said, it is an important element to consider for future implementations of the auditory help system, especially in relation to games that implement complex 3-D environmental sound effects and orchestrated music scores. The games we have currently chosen are more simplistic in relation to game sonic events for the purpose of more immediate implementation and testing. We are aware of the more complex issues in more elaborate games and we hope to look at these issues in our future work.
However, with the assumption that there is an ideal balance between visual game-play tasks and auditory help system tasks, the user stores critical auditory information separately to visual information. Although there are limits to each individual working memory component, presenting auditory information and visual information as discretely as possible may maximize retention capacity, which may have a knock-on affect on processing efficiency. Since the help topics are auditory only, issues such as subvocal rehearsal which links visual and auditory stores is not an issue. Other sensory data relating to smell, taste and touch are recognized but not relevant to our study. The acoustic attributes of the sonic streams (such as pitch) are saved in their individual sonic dimension stores. Sonic events related to each other, such as music and environmental sonic events are combined in the Episodic Acoustic Store. Separately, and after it has gone through its acoustic stripping, the lexical content of speech is stored in the Speech Lexical Store.
4. DESIGNING AUDITORY HELP As discussed in the previous section of the paper, an effective auditory help system requires an efficient interaction between the machine and a user's cognitive processes. The design of the actual help topics themselves is an equally important consideration. While it is technically possible to present most help information aurally, it may not always be an effective method of presenting the information. Only certain categories of help information can be effectively presented using audio. Also, each help topic should be designed such that it can be presented effectively using speech.
The Universal Episodic Buffer then appropriately contextualizes relevant auditory and visual information, packaging it for the data retrieval routines. Information may also be accessed from external memory depending on the state of working memory and other cognitive processes. Based on the information attained from the help files and the visual data, the user attempts the most appropriate next move in the game. Before this end-goal is acquired however, all necessary subtasks need to have been completed. If not, then the next subtask is attended to. If all subtasks have been completed, then the user makes his/her next move.
4.1 Categories of Help One popular categorization of help information is procedural, conceptual, reference and instructional [26]. These various categories of help differ in terms of suitability for presentation to users through speech and sonification. Procedural help information details a list of steps required to complete a specific task. Conceptual information is used to provide overview, supporting theory and background detail. Procedural help and short conceptual topics with a simple sentence structure can be presented effectively using speech. Instructional help information supports the requirements of users who want to learn and typically includes elements from both procedural and conceptual help. For example, there may be a step-by-step procedure listing, with some supporting conceptual information to explain the details of the procedure. The use of speech output may be especially appropriate for use with instructional help topics. Several studies [38] demonstrate that students learn better with speech and visuals, rather than text and visuals. Application of the minimalist instruction
3.3 Delivery Mechanism The experimental auditory help system uses a mono headset. Figure 2 shows the audio channel configuration. The system has been designed so that it can be integrated in games with minimum disruption to the existing game audio implementation.
35
pronunciation, volume, rate, etc. The appropriate use of markup language elements while authoring help topics can greatly enhance synthesized speech intelligibility.
approach outlined by Carroll [10] typically results in shorter task-oriented topics suitable for presentation aurally. Conceptual help topics targeted at advanced users often contain complex sentence structures and diagrams. Reference information typically includes elements such as lists, tables, etc. This information is difficult to present effectively using speech alone.
Using the markup language to specify prosody can decrease listener fatigue and enhance listener comprehension [43]. Use of the lexicon feature can ensure correct pronunciation of items such as proper names, acronyms, and game-specific terms, etc. Markup language elements can be used to resolve ambiguity with respect to the correct pronunciation of written words and ensure appropriate text normalization. For example, 3/4 may be pronounced as three quarters, 3rd of April or 4th of March depending on the context.
4.2 Authoring Effective Auditory Help Topics To date, most online help material has been developed with the assumption that the material will be read. We are developing a set of guidelines to assist in the creation and testing of help material that is to be presented aurally [34]. These guidelines are derived from a variety of sources including experience in development of speech based devices [43], guidelines used for development of prompts in speech based telephony applications [15] and practical experience in the development of an experimental auditory help system. The guidelines under development incorporate the following elements:
4.3.2 Voice and Persona Persona is defined as the role that one assumes or displays in public or society; one's public image or personality. When people listen to a voice they infer items such as gender, age, ethnicity and much more. Research suggests that while interacting through speech people will perceive a persona, whether this has been designed or not [39]. Care should be taken in selecting a voice so that the speech persona is consistent with the game.
• Cognitive Load: Topics should be kept short and relevant so as to minimize the time required to listen to the topic and reduce the listener cognitive load. Multimodal designs that use small amounts of display space have potential to mitigate some of these problems [41] and may be a useful option for games.
In a gaming context it would also be possible to present help using “conversational agents” or “talking heads”. A viseme is the facial position associated with articulating a certain sound. As a speech synthesis engine produces output it can supply another application with viseme information which can be used to drive graphical facial animations. The use of conversational agents has been shown to improve understanding of speech in certain situations such as noisy environments [42].
• Conversational Language: Information presented using speech should use elements of conversational language. The use of such elements from conversational language can impart naturalness to synthesized speech and facilitate comprehension. Using common words and a simple sentence structure will help the speech synthesis engine produce good quality speech output.
5. HELP TOPIC STRUCTURE There is a growing awareness of the advantages of using a single source for product documentation. The material in this single source repository can be transformed and presented to users in a number of formats, or through different media [47]. Help topics are designed so that the same information can be presented effectively using either traditional help text display methods or aurally.
• Position of Information: The placement of new and focal information in spoken language is important. Application of the End-Focus Principle [45] should result in the placement of such information at the end of a sentence for the English language. • The auditory suffix effect [17] refers to a decrease in accuracy of recall of the last few items in a spoken list if the spoken list is followed by additional speech stimulus. In online help documentation today it is common for help topics to have trailing “related topics” and “notes” type of material at the end of a topic. To avoid auditory suffix effects this trailing material should be omitted from the aural topic presentation.
5.1 Help Topic Elements Streamlined-step [23] help topics are very prevalent in computer help systems and documentation. This style of help topic is in line with much of the best practice relating to design of help information that has evolved over the past 20 years.
• Chunking: Chunking can help users remember information [37]. Certain command, number, letter and keystroke sequences are frequently grouped for easier understanding e.g. numbers, command and hotkey combinations.
4.3 Using Text-To-Speech Output In the past studies have shown that people find synthesized speech more difficult to understand [12]. However, for many online help systems the option of using human speech recordings is not a realistic one since help material can evolve and change over time. The cost of creating and updating human speech recordings can be very significant [18].
4.3.1 Using Speech Synthesis Markup Language The role of Speech Synthesis Markup Language is to give authors of synthesizable content the capability to control and customize a numbers of attributes of the speech output such as
Figure 3: Help Topic Elements
36
help topics that are commonly used in online help systems for software applications.
Such help topics are typically short, have a well defined format and a simple sentence structure. This type of topic can be effectively presented aurally. Figure 3 shows a sample topic. Each speech help topic is constructed from a number of components, some of which are optional.
6. IMPLEMENTATION IN GAMES The auditory help system was integrated in a number of fairly basic open source games that run on the Microsoft Windows platform. The source code was required so that the games could be modified, and re-built, to incorporate the speech help system functionality.
6.1 Speech Technology Selection Standards such as XHTML+Voice and Speech Application Language Tags (SALT) enable multimodal access to web based information and services. These technologies could be used in the future for auditory help systems. However, the Microsoft Speech Application Interface (SAPI) was used for the initial implementation, since it allows for better integration with small standalone games.
Figure 4: Help Topic Structure Each topic has a title. This is followed by some optional introductory text that may be used to supply additional conceptual information relating to the help topic. There may be several subheadings within a single topic. The core detail of a topic is often a list of steps associated with a task-oriented procedure. Topics can optionally end with a trailing notes section that typically outlines some special case information.
6.1.1 Supporting Sonification with SAPI The Speech Synthesis Markup Language (SSML) “mark” element [52] can be used to trigger playback of non-speech sounds in synchronization with the synthesized speech output.
5.2 Unsuitability of HTML-based Formats At present many of the most widely used help system storage formats are HTML-based. Topics are often authored and viewed using HTML editing tools. The resulting topics contain elements that relate to both structure and presentation. For example, the HTML
