Dime Design Document

Abstract

This document describes the internal architecture of Dime.
It explains the purpose of services, the central data model, components, scripts, and interface layouts.

Version History

Version Date Author Nick Changes
0.1 2002-02-03 Hans Häggström zzorn Initial version based on IRC discussions.

Introduction

The overall Dime architecture generally follows a Model-View-Controller (MVC) pattern. It is also based on application framework pattern ideas. The figure below shows an overview of the different parts of the dime architecture.

Interface Layouts
Scripts
Components
Central Data Model
Services
External Libraries
Dime architecture.

Services

The services take care of low level interaction with the game server, the clients system (sound, input, etc), and so on. These can be used directly by components, and indirectly by scripts through those properties and functionality that the services publish in the central data model.

Central Data Model

The Central Data Model is a tree of DataObjects that contains various information about the game, the client, available servers, and so on. For example, we keep a list of the different actions, properties, and various streams (like incoming and outgoing speech) associated with each active avatar in the data model. We can then query the central data model for what actions the avatar can do in what circumstance, what actions the avatar can do to different objects, what the health of the avatar is, and so on.

Data intensive things, like querying terrain information and entity positions from game views, are done directly from the low level services or utility libraries, and doesn't happen through the central data model. The central data model might still provide lists of nearby entities for example to scripts and components that could be interested.

Components

Basically a component is a building block of the interface and the functionality of the client. It's not a low level service, and it's used commonly enough and requires enough coding, or needs access to low level services, so that it is not ideal to implement as a script.

There are various components, that range from simple general purpose widgets (gauges, buttons, etc), to more specialized ones (chat window, inventory screen, etc). Many of these have views, although some are not visible (for example sound 'view' type components that play sound effects for events in the game world, and utility components that process information for other components). The component instances loosely represent the view part of the MVC pattern. Each component instance also has its own data model, containing properties and actions that the component provides or can be configured with. This interface layouts to connect it to other components, the central data model, or scripts.

Game views are a subclass of components, and are thus treated as any other component with a visible widget. So it is possible to use multiple game views even at the same time, for example having a 2D overview of the map, and a 3D view of the character from above.

Scripts

It is also possible to create scripts that allow more complicated control over behavior of the user interface and character. It will be possible to use data models and objects from a scripting language. That way we only have to implement a little code, to allow scripts to interact with all the data and functionality in the central data model and data models provided by components. Some candidates for scripting languages are python and lua. We can implement multiple scripting language bindigs also.

It could also be possible to implement a security model that would allow the user to specify what scripts have accoss to what parts of the central data model, or which components they can create and use, and wether they have read/write or read only access.

Interface Layouts

The controller part, that maps input and output from the model and different components to each other, consists of dynamic connections specified in one or more Interface Layout files that are loaded at startup, or can eventually be edited by power users in-game. Interface Layout files are not in a real scripting language, they just contain instructions of what components to create, where to place them, and how to connect their data models with the central data model. Interface Layout files can also create script instances in a similar way, from registered / installed scripts. A visual editor that allows (mainly expert) users to edit interface layouts directly in the client will be implemented eventually.

Different games will need different interface layouts, specialized for that game. Expert users can also create their own interfaces, tuned to different tastes and providing different functionality, and share them through the media repository with other users.

Interface Layouts can be changed on run time too, and different parts of the UI can use different interfac layouts. For example switching between full screen view and a view with a GUI could be done by changing the interface layout for the whole screen. When the avatar uses some vehicle in-game (or other type of control interface that provides it's own properties (fuel gauge, speed gauge), actions, and other data objects) a special interface for it could be added to the current UI, or partly replace the current UI.