An Entity-Component Model for Extensible Virtual Worlds

Virt

ual W

orld

Arc

hite

ctur

es

30 Published by the IEEE Computer Society 1089-7801/11/$26.00 © 2011 IEEE IEEE INTERNET COMPUTING

S ince 2007, the realXtend project has developed a freely available open source virtual world plat

form that lets anyone create their own 3D applications. RealXtend began as a collaboration between several small companies coordinating to develop a common technology base that they then applied in different application fields, including virtual worlds, videogames, and educational applications. The realXtend Association was founded in early 2011 to coordinate further, open development.

In this article, we describe the realXtend project and particularly focus on its entity-component-action (ECA) architecture, which provides a general extensibility mechanism for building 3D virtual worlds. (For a generic introduction to the platform and the modules, see https://github.com/realXtend/

doc/blob/master/acm_mult imedia/overview.rst.) The Tundra SDK, which is built entirely using the entitycomponent model, is a true platform that doesn’t get in the way of application developers; they can create anything, from a medical simulator for teachers to actionpacked networked games — and always with a custom interface that exactly fits the application’s purpose. We treat seemingly fundamental elements of virtual worlds (such as support for avatars) as an addin functionality, so the overall architecture can accommodate a wider range of virtual worlds.

To demonstrate the feasibility of our generic scenemodeling approach, we use Tundra to develop a growing collection of example scenes in a directory available on GitHub (https://github.com/realXtend/naali/blob/tundra/bin/scenes).

The open source realXtend project has developed a freely available open

source virtual world platform that lets anyone create 3D applications.

RealXtend is fully implemented in the new Tundra SDK and in an add-on

for the OpenSimulator server. The framework treats fundamental elements

of virtual worlds (such as support for avatars) as an add-in functionality, so

the overall architecture can accommodate a wider range of virtual worlds.

Attribute values are automatically synchronized among the participants in a

networked environment. A core API provides basic functionality for GUIs,

controller input, audio, and means for 3D scene manipulation for application

code.

Toni AlataloPlaysign and realXtend Association

An Entity-Component Model for Extensible Virtual Worlds

IC-15-05-Alat.indd 30 8/18/11 12:26 PM


SEPTEMBER/OCTOBER 2011 31

This article presents two example scenes to illustrate how the ECA model works in practice. In the first example, we implement a Second Lifestyle avatar that runs on both the server and the clients. The second example is a presentation application that lets a presenter control the view for the other participants as the presentation proceeds.

Our approach demonstrates how vir tual world architectures can be simple and practical, yet powerful and truly extensible.

RealXtend Architectural GoalsSimilar to several other 3D virtual world platforms, the realXtend project has taken a client–server approach. A browserlike client called a viewer renders content, enabling end users to see and manipulate a 3D window into a virtual world where the content itself is stored and shared on a (typically remote) server. The realXtend project has developed an open source viewer called Naali (the Finnish word for the arctic fox), which references the project’s Finnish origins and the open source Firefox Web browser because Naali aims for similar widespread availability as a browser for virtual worlds. The Naali viewer can connect to Second Life, OpenSimulator, or realXtend’s own Tundra server and can run on Windows, Linux, Mac, and some mobile platforms.

One architectural goal of the realXtend project has been to build entirely on open standards and open source software to remove the roadblock of proprietary software and pave the way for widely used 3D virtual worlds. To this end, Naali and Tundra use HTTP, Collada (Collaborative Design Activity), Extensible Messaging and Presence Protocol (XMPP), and open source software such as OGRE 3D, Qt, OpenSimulator, and Blender. We can see an immediate benefit in that realXtend supports 3D geometry in the typical polygon mesh format, so existing game characters, CAD models, and building models can be used by exporting them from packages such as 3ds Max, Maya, and Blender. RealXtend has had this capability since the initial prototype. Second Life (a widely used but proprietary 3D virtual world), on the other hand, has been limited to its own special representation using primitive graphical objects (prims) and still only has meshes in beta testing as of summer 2011.

RealXtend also allows reuse of existing models and scripts from Web libraries. Any model asset in realXtend can be included in a scene

via a URL reference, and the Naali GUI supports drag and drop of 3D models from webpages like the Google 3D Warehouse to the 3D virtual world scene. In realXtend, a virtual world can be snapped together from existing components like Lego bricks and viewed instantly.

Another architectural goal of realXtend is flexible editing of virtual worlds — that is, users can edit locally and publish their creations later. In contrast, all edits and additions in Second Life happen on remote servers, and the client application is no more than an interface to serverside functionality. Naali/Tundra is completely standalone, without the complexity of setting up a separate server for local editing as with OpenSimulator (http://an.org/opensim/usbkey). This is similar to how end users can author an HTML webpage locally by just editing the HTML, CSS, and JavaScript sources before publishing them simply by copying the files over to a Web server. Tundra can similarly open scenes from local files to show the 3D view, which streamlines object and scene creation so that changes to texture images, 3D models, and scripts update immediately in the final form without any uploads to a virtual world system.

Our project’s f inal architectural goal is extensibility — the ability to dynamically add or remove functionality to a virtual world platform to meet specific applications’ needs. The approach is similar to Web browsers, which also download both data and executable code from servers so that applications can implement custom behavior in the client. This makes realXtend a generic platform; you can use the same viewer executable to connect to any server, when the scene and associated custom JavaScript code is downloaded from the Web and executed locally to implement a specific behavior.

Extensible Scene ArchitectureThe extensible scene model is independent of any particular virtual world platform implementation. A scene is defined by its entities; nothing is hardcoded about the scenes at the platform level. This differs essentially from the current OpenSimulator paradigm when using the Second Life protocol, where the model is largely predefined and hardcoded into the platform. In Second Life, a certain kind of land (a heightmapbased terrain with altitudebased texturing) always exists, and the sea, sky, and sun are always there as well. And each client

IC-15-05-Alat.indd 31 8/18/11 12:26 PM

Virtual World Architectures

32 www.computer.org/internet/ IEEE INTERNET COMPUTING

connection is always assigned to a single avatar to which the user’s controls are mapped.1 We argue that there is no need to embed assumptions about the world’s features in the base platform and protocols.

Our Naali viewer uses the ECA model as a basis for constructing extensible scenes. We adapted this model from contemporary gameengine architectures.2 Entities are unique identities, with no data or typing. They aggregate components, which can be of any type and store arbitrary data. Applications built using Naali can add their own components so they have the data they need for their own functionality. The code that handles the data exists in preinstalled custom modules or in scripts loaded at runtime as a part of the application data. To get a matching server counterpart where the scene is entirely built with entity components, we added the Tundra server module to the Naali codebase and a new protocol without applicationlevel assumptions. Tundra consists of both viewer and server executables.

The Tundra platform provides basic functionality for all ECAs: persistence, network synchronization among all the participants via a server, and a user interface for manipulating components and their attributes, and eventually will support security. In addition, Tundra introduces the concept of entity actions, a simple form of remote procedure call.

Avatars Aren’t Part of the PlatformAvatars are graphical representations of the user within the virtual world. It might seem at first that the concept of an avatar is integral to 3D virtual worlds. Second Life’s avatar protocol is hardcoded into the platform. Yet, many virtual worlds, simulation platforms, and games don’t have a single character as the locus of control. For instance, map applications or astronomical simulations are about efficient navigation and time control of the whole space, not about moving your presence around, and realtime strategy games involve controlling several units, similar to board games like chess. Thus, we argue that avatars shouldn’t be part of the base platform because many simulations don’t require them. Of course, a generic platform must still allow the implementation of an avatar addin functionality.

Here, we describe a proof of concept implementation of avatars as addins using the realXtend ECA model. Application XML and usage information are available at https://github.com/realXtend/naali/tree/tundra/bin/scenes/Avatar.

We split avatar functionality into two parts (see Figure 1). The first part governs the visual appearance and related functionality to modify the look and clothing as well as the use of animation for communication. The second part gives every user connection a single entity as the point of focus and control. The default inputs from arrow keys and the mouse are mapped to move and rotate the avatar. For this discussion, although we cover the basics of avatar appearance, we focus on the latter control functionality.

To give every new client connection a designated avatar, we implement the serverside functionality in JavaScript (see Figure 2). Upon a new connection, this script creates a new avatar entity and attaches these components to it: EC_Mesh for the visible 3D model and an associated skeleton for animations; EC_Placeable for the entity to be positioned in the 3D scene; EC_AnimationController to change and synchronize the animation states; and EC_Script to implement a single avatar’s functionality. Different parts of the same script are executed on the client, where it adds two additional components: a new camera that follows the avatar and a keybinding to toggle between camera modes.

A second script for an individual avatar (simpleavatar.js) adds additional components: AvatarAppearance for the customizable looks;

Figure 1. Avatar architecture. This example uses a client (green) and a server (brown). The filled boxes represent entity-component-actions on the client, server, or shared by both. The arrows represent network messages made as entity-action calls from the client side to the server.

Entity-actions:move [dir], stop

Client Server

Movement andanimation statesync with ECs

Reads inputApplies animations

InputMapper

Placeable

AnimationController

AvatarAppearance

RigidBody

Creates the AVsPhysics

Movement code

IC-15-05-Alat.indd 32 8/18/11 12:26 PM



RigidBody for physics; and on the client side, an InputMapper for user input. Entity actions ensure the avatar moves according to the user controls. These actions are commands that can be invoked on an entity and executed either locally in the same client or remotely on the server, or on all connected peers. For example, the local code sends the action “move(forward)” to be executed on the server when the user presses the uparrow on the client. The builtin EC_InputMapper component provides triggering actions based on input, so the avatar code needs to register only the mappings it wants. The server maintains a velocity vector for the avatar and applies physics for it. Using ECA attributes, the resulting position in the transform attribute of the component Placeable is automatically synchronized with the generic mechanism, so the avatar moves on all clients. The server also sets the animation state to either “stand” or “walk” based on whether the avatar is moving. All participants run common animation update code to play back the walk animation while moving, calculating the correct speed from the velocity data from the physics on the server.

These two parts are enough to implement basic avatar functionality using the ECA model. This proof of concept implementation includes 369 lines of JavaScript code in two files. The visual appearance comes from a preexisting AvatarAppearance component, which reads an XML description with references to the base meshes used and individual morphing values that the user sets in an editor. Implemented in C++, it uses the realXtend avatar model from an

earlier realXtend prototype that didn’t have the ECA model, but it is reused in this demo as is. A more generic and customizable appearance system could be implemented with the ECAs, but that’s outside the scope of this example.

The division of work between the clients and the server we describe here isn’t the only possible configuration. With Tundra SDK, we use the same core code and API for the server and the clients, making it simple to reconfigure what is executed where. This model of clients only sending commands and the server doing all the movement is identical to that of the Second Life protocol. It is suitable when trust and physics are centralized on a server. A drawback is that user control responsiveness can suffer from network lag. We can already use the physics module on the client end too, which can allow movement code to run locally as well.

Along with the ability to run custom code in the client, it’s easy to extend avatarrelated functionality. For example, in one project for schools, we made it possible for avatars to carry objects around as a simple means for 3D scene editing. Another possibility is to further augment the client with more data that’s synchronized for animations — for instance, the full skeleton for motion capture or machinevisionbased mapping of the real body to the avatar pose. Our open source Chesapeake Bay watershed demo scene includes minigames with customized game character controls, including flying as an osprey with the ability to dive to catch fish. We implemented these using the humanavatar functionality as a starting point,

function serverHandleUserConnected(connectionID, userconnection) { var avatarEntity = scene.CreateEntity(scene.NextFreeId(), ["EC_Script", "EC_Placeable", "EC_AnimationController"]); avatarEntity.Name = "Avatar" + connectionID; avatarEntity.Description = userconnection.GetProperty("username"); avatarEntity.script.ref = "simpleavatar.js";

// Set random starting position for avatar var transform = avatarEntity.placeable.transform; transform.pos.x = (Math.random() - 0.5) * avatar_area_size + avatar_area_x; transform.pos.y = (Math.random() - 0.5) * avatar_area_size + avatar_area_y; transform.pos.z = avatar_area_z; avatarEntity.placeable.transform = transform;}

Figure 2. JavaScript source code. The avatarapplication.js code creates a new avatar entity and attaches several components to it.

IC-15-05-Alat.indd 33 8/18/11 12:26 PM



then modified them according to the different animal characteristics.

A Collaborative Presentation ToolTo demonstrate an entirely different use of the ECA framework, we consider an application that, in its simplest form, implements collaborative presentations in which one user controls sequencing through a collection (of webpages or PowerPoint slides) while others watch. The presentation tool lets the presenter control the position in the prepared material, for example, to select the currently visible slide in a slideshow. In a local setting where everyone is in the same physical space, it’s simply about choosing what to show via the overhead projector. In a remote distributed setting, there must be some system to get a shared view over the network.

A shared, collaborative view of a set of 2D webpages could be implemented without realXtend technology by using regular Web browsers with HTML, JavaScript, and some backend server logic. Our goal here is to illustrate the use of the ECA model and automatic attribute synchronization for developing custom functionality. In a minimal implementation of shared collaborative presentations, we can use ECA without using avatars or geography.

Alternatively, because it’s easy to do, we could add those components back in to build shared presentations such as the one in Figure 3, where different avatars see the presentation from different viewpoints. We could go further

and consider a situation in which we added multiple views for the presentation, such as a slide and outline view, or where we animate the presentation content, add voice and text chat components to let users communicate with other viewers, or add annotations to the presentation. For simplicity, however, we only demonstrate a basic application here.

Regardless of the presentation view, the presenter typically needs the same controls. In Second Life, avatar controls are fixed, and to control a presentation, users might need to create a presentation sequence object with mouse click controls to press virtual buttons. In realXtend, custom controls in the client can directly change the shared scene state.

For the implementation in realXtend ECA, the simplest way to get a shared, synchronized view of the presentation slides is to use a static camera that shows a single webpage view. It then suffices for the server to change the current page on that object for everyone to see it. We could implement this in a 2D GUI, but we do it in the 3D scene here to illustrate its extensibility.

To implement this application, we add a new nonspatial entity called Presentation, an application that’s globally available in the scene. (The Tundra chat application is implemented in a similar fashion.) To display webpages, we need a few basic components: EC_Placeable to have something in the scene, EC_Mesh to have geometry (such as a plane) on which to show the slides, and WebView to render HTML from URLs. For our custom functionality, we add two additional components: EC_DynamicComponent for custom data and EC_Script to implement the user interface for presentation controls. As data, we need a list of URLs and an index number for the current position. This custom data becomes part of the scene data and is automatically stored and synchronized among the participants. The EC_Script component is a reference to JavaScript or Python code that implements the logic.

We have two options for handling the user input: either handle input events and modify the state correspondingly directly in the client code, or send remote actions like in the avatar example. Here, we use remote actions again so we can use the server as a security broker and to get a similar design to compare with the avatar example.

Figure 3. Example shared presentation. Two Naali clients stand nearby and view the presentation stage of the TOY system, an open source learning environment for the Future School of Finland project. The one on the left just added a webpage to the stage and is currently carrying the object.

IC-15-05-Alat.indd 34 8/18/11 12:26 PM



The clientside code maps rightarrow and spacebar keys to SetPresentationPos(index+1) and so forth. The server can then check if the caller has permission to do that action — for example, in presentation mode, only the designated presenter can change the shared view. Then, if the presentation material is left in the scene for later use, control can be freed for anyone.

The index attribute is synchronized for all participants so the outline GUI can update accordingly. To add an outline view, we can add a 2D panel with thumbnails of all the slides and highlight the current slide. For free browsing, clicking on a thumbnail can open a new window with that slide, while the main presentation view remains.

Thus, we have a simple, complete shared presentation application implemented on top of a generic ECA model virtual world platform architecture. Source code of this model’s implementation is available at https://github.com/realXtend/naali/tree/tundra/bin/scenes/SlideShow, with the additional feature that it automatically creates the presentation when a premade slideshow (such as a PowerPoint file) is added to the scene.

Comparing Virtual World ArchitecturesSimulations have long demonstrated that avatars and geography aren’t always required. For example, the open source Celestia universe simulator (www.shatters.net/celestia) lets users view 100,000 stars but doesn’t have any hardcoded land or sky. Nor are we the first to propose a generic component model for virtual world architectures. For example, the NPSNETV system is a minimal microkernel on which arbitrary code can be added at runtime using a Java Virtual Machine.3 A contemporary example is the meru architecture from the Sirikata project, where a space server only knows the object locations. Separate object hosts, either running on the same server or any client/peer, can run arbitrary code to implement the objects in the federated world.4,5 Messaging is used exclusively for all object interactions.6

The idea with the ECA mechanism in Naali, rather, is to lessen the need to invent particular protocols for all networked application behavior when, for many simple cases, using automatically synchronized attributes suffices. In preliminary

talks with some Sirikata developers, we concluded that they aimed to keep the base level clean from highlevel functionality, but that capabilities such as attribute synchronization would be desirable in applicationlevel support scripts.

The Naali ECA model borrows the idea of using aggregation and not inheritance from the gameengine literature.2 Automatically synchronizing attribute data and using the same JavaScript code on both the client and server side is inspired by a gamingoriented virtual world platform called Syntensity (www.syntensity. com). The difference is that the entities in Syntensity exists only on the scripting level, and basic functionality such as object movement is hardcoded in the Sauerbraten/Cube2 firstperson shooter platform.

In Naali, all functionality is now implemented with the ECAs, so the same tools work for graphical editing, persistence, network sync identically for all data, and the like. The document oriented approach of having representing worlds externally as files has precedent in 3D file format standards such as VRML, X3D, and Collada. Unlike those, the realXtend files don’t directly include 3D geometry, but they describe a scene using URL references to external assets, such as meshes in the Collada format. Essentially, these files describing scenes are a mechanism for applicationspecific custom data, which is automatically synchronized over the Internet. They have script references that implement the applications’ functionality, similar to the way HTML documents contain JavaScript references. This isn’t specified in the file format; instead, it’s how the bundled JavaScript component works.

Status of realXtend ImplementationsTwo generations of realXtend technology are currently available. The original prototype, a General Public License (GPL) licensed fork of the Second Life viewer, has become mostly irrelevant as the newer Naali viewer has matured. We built it from scratch, and it’s available under the Apache 2 license and is the modular and extensible platform. Taiga (which combines OpenSimulator and the realXtend addon for it) is a continuation and refinement of the original server project (BSD license). The latest addition to the new generation, Tundra, completes the Naali code base with server functionality and

IC-15-05-Alat.indd 35 8/18/11 12:26 PM



a new protocol built purely on the ECA design. It has the same API on the server and clients, resulting in a powerful toolkit for networked application development. All the functionality is configured by the applications, but the platform has the building blocks, such as playback of 3D skeletal animations and physics collisions in the efficient C++ libraries — Ogre3D for graphics and Bullet for physics. In this way, the JavaScriptdriven logic can still perform well.

The Naali viewer has matured and been deployed to customers by some of the development companies. It’s a straightforward modular C++ application with optional Python and JavaScript support. The Qt object metadata system is utilized to expose the C++ internals automatically. This covers all modules, including the renderer and user interface as well as all the ECs. The QtScript library provides this for JavaScript support, and PythonQt does the same for Python. There is also a QtLua so that Lua support can be added. Thanks to the Ogre3D graphics engine, Naali runs on various platforms, such as the N900 mobile phone with OpenGL ES, and on powerful PCs with multiple video outputs with the builtin CAVE rendering support. An experimental WebNaali client, written in JavaScript to run in a Web browser, does EC synchronization over WebSockets and rendering with WebGL.

The generic ECA architecture is implemented in Naali and is in use throughout in the Tundra SDK, which complements the original Naali code base with a server module (http://realxtend.blogspot.com/2010/11/tundraproject. html). This configuration enables Naali to run standalone for local content authoring or for singleuser applications, but it can also be used as a server instead of using OpenSimulator. Tundra doesn’t use LLUDP; instead, all basic functionality is achieved with the generic EC synchronization.

For the transport, we use a new protocol called kNet, which can run on top of either UDP or TCP (http://bitbucket.org/clb/knet). kNet is similar to eNet, but it performed better in tests with regard to flow control. The Tundra server lacks many Second Life specific features of the more advanced OpenSimulator, such as running untrusted userauthored scripts and combining multiple regions to form a large grid. However, Tundra is already useful for both local authoring and deploying applications with custom

functionality on public servers. It also serves as an example of how a generic EC approach to virtual worlds functionality can be simple, yet practical.

T he generic EC architecture was proposed to the OpenSimulator core and accepted as the

plan of record in December 2009.7 We’ve only begun to experiment with the actual refactoring of OpenSimulator scene code to be built with EC. However, EC can be utilized with the Naali client communicating with the OpenSimulator servers running the realXtend addon (modrex) in a limited fashion. These servers still assume the hardcoded Second Life model, but developers using Naali can add additional arbitrary clientside functionality and have the data automatically stored and synchronized over the Internet via OpenSimulator. Entity actions are currently not implemented in this OpenSimulator realXtend addon.

The realXtend platform doesn’t yet solve all problems related to virtual world architectures. Naali doesn’t address scaling at all, nor does it support federated content from several possible untrusted sources. We started by providing power at a small scale to let end users easily develop rich interactive applications. Another important missing element in our current EC synchronization architecture is security, such as a permission system. Support for permissions was just implemented that is similar to Syntensity where the server can control if and when clients are allowed to modify entity attributes.

In the future, we look forward to continuing collaboration with communities such as OpenSimulator and Sirikata to address trust and scalability issues. OpenSimulator is already used to host large grids by numerous people, and the Sirikata architecture seems promising for the long run.4,5 Also, Intel Research has recently demonstrated how multiple servers can be used to host a single scene for thousands of interacting users using OpenSimulator.8 We will see whether that design can either be easily ported to the Tundra server or better utilized for realXtend as is by using OpenSimulator.

Applications implement functionality against the Naali/Tundra core API. It’s role is similar to the W3C Document Object Model (DOM) standard in HTML browsers. We’re currently freezing the API 1.0 version so that applications developed now will continue to work in

IC-15-05-Alat.indd 36 8/18/11 12:26 PM



upcoming releases. We have documented this work at www.realxtend.org/doxygen. This API will be reviewed for ease of development, for challenges in scalability and security, and with regard to interoperability and standardization.

We hope our approach is taken into consideration both in future OpenSimulator development and upcoming standardization processes — for example, if the IETF Virtual World Region Agent Protocol (VWRAP) or IEEE Metaverse standardization efforts choose to address inworld scene functionality. We’ll continue to develop the realXtend platform and applications on top of it. Anyone is free to use it for their needs, and motivated developers are invited to participate in the effort, which is mainly coordinated online.

AcknowledgmentsWork on this new version of the realXtend platform was

initially led by Ryan McDougall, who was working as

the principal architect in the beginning of the effort. The

Tundra server and protocol is designed by Jukka Jylänki

at Ludocraft Oy, where most of the core development has

occurred. I was initially responsible for the scripting API

development and later for coordinating the overall open

source development. My work for the realXtend Associa

tion is now sponsored by the Center for Internet Excellence

(CIE) at the University of Oulu.

References1. J. Bell, M. Dinova, and D. Levine, “VWRAP for Vir

tual Worlds Interoperability,” IEEE Internet Computing,

vol. 14, no. 1, 2010, pp. 73–77.

2. M. West, “Evolve Your Hierarchy: Refactoring Game

Entit ies with Components,” 5 Jan. 2007; http://

cowboyprogramming.com/2007/01/05/evolveyour

heirachy.

3. A. Kapolka, D. McGregor, and M. Capps, “A Unified

Component Framework for Dynamically Extensible

Virtual Environments,” Proc. 4th Int’l Conf. Collabora-

tive Virtual Environments (CVE 02), ACM Press, 2002,

pp. 64–71.

4. D. Horn et al., “Scaling Virtual Worlds with a Physi

cal Metaphor,” IEEE Pervasive Computing, vol. 8, no. 3,

2009, pp. 50–54.

5. D. Horn et al., To Infinity and Not Beyond: Scaling Com-

munication in Virtual Worlds with Meru, tech. report

CSTR 201001 5/11/09, Stanford Univ., 2010; http://hci.

stanford.edu/cstr/reports/201001.pdf.

6. B. Chandra et al., “Emerson: Scripting for Feder

ated Virtual Worlds,” Proc. 15th Int’l Conf. Computer

Games: AI, Animation, Mobile, Interactive Multimedia,

Educational & Serious Games (CGAMES), 2010; http://

sing.stanford.edu/pubs/cgames10.pdf.

7. A. Frisby, “[Opensimdev] Refactoring SceneObjectGroup —

Introducing Components,” 11 Dec. 2009; http://lists.berlios.

de/pipermail/opensimdev/2009December/008098.

html.

8. D. Lake, M. Bowman, and H. Liu, “Distributed Scene

Graph to Enable Thousands of Interacting Users in a

Virtual Environment,” Proc. 3rd Int’l Workshop Mas-

sively Multiuser Virtual Environments, ACM Press,

2010; www.pap.vs.unidue.de/MMVE10/papers/mmve2010_

submission_7.pdf.

Toni Alatalo is the CTO of Playsign and the current lead

architect of the open source realXtend Association.

His research interests include agile game development

and playful information systems. Alatalo has studied

and worked at the Department of Information Process

ing Sciences at the University of Oulu. Contact him at

[email protected].

Selected CS articles and columns are also available for free at http://ComputingNow.computer.org.

stay connected.

Keep up with the latest IEEE Computer Society

publications and activities wherever you are.

| IEEE Computer Society| Computing Now

| facebook.com/IEEEComputerSociety| facebook.com/ComputingNow

| @ComputerSociety| @ComputingNow

TM

IC-15-05-Alat.indd 37 8/18/11 12:26 PM

Documents

An Entity-Component Model for Extensible Virtual Worlds