Table of Contents
Start Page » Game Development with the Drag[en]gine » Service Modules
Service Modules
Modules in Drag[en]gine belong to a specific type and have a specific functionality to provide. For this reason they have a specific interface tailored for the functionality they have to provide. Service Modules on the other hand are jack of all trade modules. They have no specific functionality and thus can provide all kinds of functionality to the game engine. For this reason the interface is generic and simple.
Service Object
At the heart of service modules lies the Service Object. A Service Object is a generic object storing a single value of a specific type: boolean, integer, floating point, string, resource, data, list or dictionary.
boolean, integer, floating point and string value do what you would expect.
A resource type value can store any subclass of resource. This allows game engine resources to be handed over to service modules safely.
A data type value stores a memory file. This allows to store arbitrary binary data that can be written using file writer, read using file reader, written and read to and from files as well as sending data over a network.
list and dictionary values provide nesting support to service objects. A list stores an ordered list of service objects while a dictionary stores an unordered map of service objects (value) keyed using a string (real string, not a string type service object).
Service
Each service module can provide 1 or more services. Each service has a unique global identifier which can be used to check if a service module exists providing the required service. If a service does not exist creating the service object fails. Once the service object is created the service can be used. While creating services an optional service object parameter can be specified which typically contains initialization parameters.
A service provide exactly 3 function: run action, start request and event received.
run action accepts a service object as parameter and returns a service object as return value. Actions are synchronous calls returning immediately. The service defines how the input service object is structured. Typically the service object is of dictionary type and contains a function string type service object indicating what action to trigger.
start request accepts a service object as parameter and returns immediately with no return value. Requests are asynchronous calls enqueuing the response to be received by the game engine after the request finished. The response composes of a service object and can be of success or failure type. The game engine delivers enqueued responses during the next frame update. This ensures a response always happens during the next frame update preventing all kinds of asynchronous problems.
event received can be triggered by a service module if an external event is received. The received event is enqueued like a response to be received by the game engine. The event composes of a service object. The game engine delivers enqueued events during the next frame update.
DragonScript Module
The DragonScript module provides support to handle Service using the classes Service and ServiceObject and interface ServiceListener.
To simplify using different services providing similar functionality some helper interfaces are present per group of functionality. It is highly recommended to use these interfaces as they hide a good deal of complexity. You can use castable to determine if a service instance provides the desired functionality group
| Interface | Functionality |
|---|---|
| ServiceUser | Provides support for user management including: login, logout and get user information |
| ServiceStats | Provides support for handling achievements and stats |
| ServiceMods | Provides support for handling modifications |
See the linked documentation (or inside VSCode using the DragonScript Language Extension) for details on how to use these functionalities.
Service Listing
The following official services exist.
