The final update

The last changes and additions have been made to the engine. Let’s take a look at what has happened lately.
To start with, the server no longer transmits all attribute changes to the clients. The reason for this is, of course, that the clients do not need to know of every change. To achieve this, an object’s attribute are split into distributed and regular attributes. Only distributed attributes are synchronized with the client. In order to not inconvenience the developer, only regular attributes have to be created for custom games, as game logic runs on the server. The client mostly deals with objects transformations and graphics, these things are distributed by the engine.
Another big improvement is adding more messages sent by the server to the client. These messages tell the client to do things that it can do on it’s own, while guaranteeing a synchronized result with the server. For example, one such message tells the client to clear all game objects. Previously, this would be done on the server and the server would then send a ‘removeObject’ message to the clients for each removed object. Being able to send just one ‘clearObjects’ message is much better for our network performance.
Client-exclusive objects is another big addition. Such an object will only have a copy on one client, allowing the game to show different information to different players. This is perfect to, for example, create a HUD element.
The engine now also has support for a camera. The camera is client-side, which means that different player can have different views of the game. The camera can be instructed to follow an object.
Image object have been very simple in the past, but now a lot more of Pixi.js power has been unlocked, with new Image object attributes that map directly to Pixi.js sprite attributes. Have fun transforming your images!
Finally, a different form of visual representation has been added, the Text object. This object also uses Pixi and can support the same transforms.

Check back next time and we take a look at a demo game made with Ophelia!

The Ophelia Interface

When we create games with Ophelia, we utilize the Ophelia Interface. To access the interface, we must include the file containing the interface. This is done with Express, like this:


Naturally, we will have to adapt this path to where the engine in located relative to our game project.
There are three primary functions to the interface: methods calls, trigger definitions and event callbacks. Methods calls are very straightforward. We invoke a method from the interface that will affect the game state. Trigger definitions we have looked at in the previous post. Event callbacks look like this:

Ophelia.registerCallback('onUpdate', function(data){
	// Code that is invoked with each update

Using the above we can put together a file such as this:

var Ophelia = require('../../../../server/ophelia');

/* Objects conrolled by players */
var playerObjects = {};

/* When the game starts */
Ophelia.registerCallback('onGameState', function(data){

	/* Get a list of the players in the game */
	var players = Ophelia.getPlayersInGame();

	/* Assign each player a player object */
	for(var i = 0; i < players.length; i++){
		playerObjects[players[i].id] = Ophelia.createObject('player');

/* When a player joins */
Ophelia.registerCallback('onPlayerJoin', function(data){

	var id =;

	/* Give the new a player an object */
	playerObjects[id] = Ophelia.createObject('player');

/* When a player leaves */
Ophelia.registerCallback('onPlayerLeave', function(data){

	var id =;

	/* Remove the leaving player's object */

/* Behavior for player objects */
Ophelia.defineTrigger('onPlayerUpdate', function(data){

	var player = data.updatedObject;

	/* Move the object */


When we are creating objects for a game, templates are useful. A template is a blueprint for a certain type of object, when we want such an object we can use the same template to always get an equal object. The template will specify which modules that the object use and how the object’s attributes will be configured. Finally, a template can also define scripts, called triggers, linked to local events. When the local event occurs for an object of this type, the trigger is invoked.
Templates in Ophelia ware defined in XML files.
A template looks like this:

<!-- Always start with the Template tag-->
	<!-- Give the template a name -->
	<!-- Which components does this object use? -->
	<!-- Which default attribute values does the object have? -->
	<!-- Which scripts will trigger on which events? -->

To finish defining this object, we also need to define the scripts that make up the template’s triggers. This will be done in JavaScript and can be written anywhere in the project. It looks like this:

Ophelia.defineTrigger('onPlayerCollide', function(data){
	var player = data.collidingObject;
	// Code that is invoked when the player collides

Ophelia.defineTrigger('onPlayerUpdate', function(data){
	var player = data.updatedObject;
	// Code that is invoked when the game updates

My very own object module

An important part of Ophelia’s design is the ability for users to define their own object feature modules. But what is an object feature module? It is a relatively small, self-contained module that can add new functionality to game objects. Almost all of the core game object functionality in Ophelia, such as Movement and Collision, have been written in the form of object feature modules.
Let’s take a look at what we need to do to define our own modules:

/* Import the base Object module */
var ObjectModule = require('../../../server/game objects/object module');

/* This contains the interface that will be imported by other files */
module.exports = {
	*	A module must define 'create'
	*	Creates an instance of this module
	create : function(gameObjects){
		/* Create a module 
		/* gameObjects is a reference to the instance of
		/* the gameObjects manager that this module is in */
		var Module = ObjectModule.create(gameObjects);
		*	A module must define 'onAttach'
		*	It is invoked when an object is attached
		*	This is the place to add attributes and events
		*	to objects that attach the module
		Module.onAttach = function(obj){
			/* Register new attributes */
			obj.addAttribute("exampleAttribute", 0, 'float');
			/* Register new local events */
			/* Register callbacks to local events */
			obj.registerCallback('onUpdate', function(){
		/* Return the module */
		return Module;

/* We have to register our module with the manager */
GameObjects.registerModule('example module', module.exports);

As we can see, the only requirement is a function ‘create()’ that creates an object module and returns it, an onAttach() method for the module that adds it’s attribute, events and logic, and finally; a call to GameObjects.registerModule() to have the module registered with the engine. Once this is done, we can start using our module, we can even define object templates that include it. We will get to know more about creating your own templates, as well as other content files, in an upcoming post.


For many game scenarios, it can be fine to simply send data back and forth as soon as possible, letting the server and connected clients deal with it as they find time to do so.
But sometimes, we want may some actions to be synchronous. Let’s say that there is a larger group of objects that we want to move, all at the same time, retaining their relative distance to each other. In the simple described above, the server would just iterate over the object’s updating their position and notifying clients and it went. This creates a problem; when the number of objects grow, the server might no longer be able to send all the data to the clients during the same client-side frame. This means that on the client, it would look like we first moved half the objects and then the other half on the next frame. Not exactly the synchronous movement we intended.
To solve problems such as this, we need to be able to guarantee that events which occur on the same frame on the server to also be updated for the same client-side frame and for this, Ophelia has a queue system. The queue system works by storing all changes made to game state during a game update, called a ‘tick’. When the server begins to update the game anew, the previous tick is sent to the network module, where it will be distributed to the server. This means that clients will only receive complete ticks of updates, never stray updates to single objects.