development(s) -- gaming is a waste of time

From a technical perspective, Second Life offers an advanced game engine that visitors and builders use (implicitly) in their activities. Before discussing how Second Life compares to (a selection of) other game engines and virtual environment frameworks, it is worthwhile to look at an overview of the main functional components of a game engine, which according to  [Ultimate] encompass:

game engine


Although it is possible to build one's own game engine using OpenGL or DirectX, or the XNA framework built on top of (managed) DirectX, in most cases it is more profitable to use an existing game engine or 3D environment framework, since it provides the developer with a load of already built-in functionality. In the following table, we give a brief comparative technical overview of, respectively, the Blaxxun Community Server (BlC), AlphaWorld (AW), the open source Delta3D engine (%D$3D), the Half Life 2 Source SDK (HL2), and Second Life (SL).

comparative overview


BlC AW Delta3D HL2 SL
in-game building -++/--++
avatar manipulation ++++/-+++
artifical intelligence +-+/-+-
server-side scripts +-+/-+++
client-side scripts ++-+/-+-
extensibility +-++++/-
open source --++-+/-
open standards --+/--+/-
interaction +/-+/-+++++/-
graphics quality +/-+/-+++++
built-in physics --++++
object collision --+++++
content tool support +/--+++-
Obviously, open source engines allow for optimal extensibility, and in this respect the open source version of the SL client may offer many opportunities. Strong points of SL appear to be in-game building, avatar manipulation, and in comparison with BlC and AW built-in physics and object collision detection. Weak points appear to be content development tool support, and especially in comparison with
%D$3D and HL2 interaction. For most types of action-game like interaction SL is simply too slow. This even holds for script-driven animations, as we will discuss in the next section. In comparison with a game as for example Age of Empires III, which offers in-game building and collaboration, Second Life distinguishes itself by providing a 3D immersive physics-driven environment, like the 'real' game engines.

modular architecture

participatory deployment


In the beginning, we envisioned the realization of our climate game as a first-person perspective role-playing game in a 3D immersive environment as for example supported by the Half Life 2 SDK, with which we gained experience in creating a search the hidden treasure game in a detailed 3D virtual replica of our faculty. However, we soon realized that the use of such a development platform, would require far too much work, given the complexity of our design. So, instead of totally giving up on immersion, we decided to use flash video, indeed as a poor-man's substitute for real 3D immersion, which, using flash interactive animations, has as an additional benefit that it can be used to play games online, in a web browser. Together with the Flex 2 SDK, which recently became open source, flash offers a rich internet application (RIA) toolkit, that is sufficiently versatile for creating (online) games, that require, in relation to console games or highly realistic narrative games like Half Life, a comparatively moderate development effort. To allow for component-wise development, we choose for a modular architecture, with four basic modules and three (variants) of integration modules, as indicated below.

...


Fig 2. Clima Futura Architecture

module(s)


  1. climate model(s) - action script module(s)
  2. game play interaction - event-handler per game event
  3. video content module - video fragment(s) and interaction overlays
  4. minigame(s) - flash module(s) with actionscript interface
  5. Clima Futura - integration of modules 1-4, plus server-side ranking
  6. adapted versions -- educational, commercial
  7. multi-user version --with server-side support