Installable packages for Windows and Linux

Posted by admin on December 30, 2019

We've extended our infrastructure for building installable packages and now provide a wider variety.

Since before we have used the Open Build Service to automatically build packages for a wide selection of Linux distros. This setup can be viewed here.

This setup has now been expanded with both TravisCI, AppVeyor and Snapcraft.

On TravisCI we have a setup where we build packages for both Linux and OSX, using both GCC and Clang. While we do build for OSX we don't yet provide any installable packages. The result is a both an AppImage and a Snap package of the Ember client.

On AppVeyor we have a setup where we build Ember for Windows using MSVC. This results in an installable package.

On Snapcraft we have a setup where we build the Cyphesis server.

The end result of this is that we now automatically build our code for Linux, Windows and OSX, on both x86, amd64 and aarch64. And we use GCC, Clang and MSVC as compilers. This makes sure that we catch most code incompatibilities rather quick.

In order to make this happened we've embraced the Conan package manager. All packages that we depend on are provided as Conan packages. The process of building Ember is now as simple as just doing "conan install". The sources contain more information on how to use it.

The new binary packages can be downloaded from

1 Comment Read full post »

Adding fishing gameplay

Posted by admin on September 23, 2019

Recently I've performed a major refactoring of how entity interaction happens in the Worldforge system. The basis of it is the new "usages" property which declares the actions that are available for each entity. As an example of how this can be used I've implemented a simple "fishing" task. When fishing you need a "fishing rod", and you need worms (or "annelids" as they are called in the system). You get these by digging in the ground with a shovel and then sifting through the resulting piles of earth with a sieve.

The "fishing rod" type is defined here. It has a "Fish" usage, which has a constraint of "get_entity(actor.attached_hand_primary) = tool and contains(actor.contains, child instance_of types.annelid)". The constraint checks that the rod when activated is wielded by the user, and that there's at least one worm in the user's inventory.
It declares on parameter, a "target" which is of type "entity_location" (i.e. a position on another entity) with a constraint of "entity instance_of types.ocean && actor can_reach entity_location with tool". The target constraints requires that the target is of type "ocean" and that the user can reach the position with the fishing pole (the fishing rod has a reach of 5 meters, as defined in the "reach" property).

By declaring these rules using constraints we can remove a lot of boilerplate code from the actual rule, since the simulation engine will take care of checking these constraints before the rule code is invoked. It's also now possible for clients to check the constraints themselves (and disable the usage if the constraints doesn't match).

The usage defers the rule handling to the handler "". This is a reference to a Python script, to be found here.
The usage handler will immediately create a Fishing task instance, with a "tick interval" of two seconds. The task inherits from StoppableTask, which just means that it will by default have a "stop" usage attached to it. It will otherwise run indefinitely.
Every two seconds the “tick” method is called. It will do a random check to see if there’s a fish on the line. If so, an Imaginary op about this is sent to the client.
If the client stops the task while there’s a fish on the hook a new Fish entity will be spawned, and the worm entity will be consumed.

The gameplay is fairly simple, but it serves as a good example of having the Entity Filter, the Usages and the Task systems all working together to provide gameplay. Since all of the rules are handled by either Python scripts or Type properties the feature can be altered and iterated on in real time without having to restart the server.

3 Comments Read full post »

Autoreload of rules and scripts in Cyphesis

Posted by admin on May 21, 2018

I've done some work in Cyphesis to allow for much more powerful features for live editing of the world, mainly editing rules and scripts.

Cyphesis have since long before had support for live editing of rules. It has been possible to send Atlas operations from clients for editing or installing new rules.
However, this is not really the workflow you would want, since any rule change would be detached from the source code.
Instead you want a workflow where rules are stored in the source tree, using Git, and then updated in the running server when they are installed into the server installation location.
To achieve this I've worked on these areas:
1) Rules are no longer stored in the database (which used to be PostgreSQL, but now is SQLite). Only accounts and entities are stored in the database. The rules are instead stored on disk, as Atlas files (xml).
2) The Cyphesis server process will observe all file changes in the rules directory, and automatically reload any changed files.
3) The server will also observe all file changes for the Python scripts directory, and reload any Python scripts that changes.
This setup works nicely with CMake, since it will by default only install files that have changed.
The workflow is now instead
1) Make edits in the Cyphesis source directory for the rule or script you want to change.
2) Execute "make install" which will CMake copy only the changed files into the Cyphesis installation location.
3) Have Cyphesis automatically pick up on the change and reload or add the changes.
Having tried this workflow I can say that it's a huge improvement compared to the previous one. It's now much more easier add or alter entity types and alter their behaviour.
2 Comments Read full post »

SQLite used in Cyphesis

Posted by admin on May 21, 2018

Our main server, Cyphesis, now uses SQLite instead of PostgreSQL by default.

The main reason for this change is to make the system less complex and to make setup easier. For a long time we've used PostgreSQL as backend for all persisted data. Our persistence needs are however very modest. We only store accounts (created once) and entity state. As such we don't really need a complex database system; it's good enough with a simpler system.

Add to this that a lot of newcomers have had issues with getting postgreSQL properly setup. By switching to a less complex setup with SQLite we hope that it will both make the system easier to reason about and easier to setup.

2 Comments Read full post »

Updated Blender Addon

Posted by admin on April 20, 2018

The Worldforge Blender Addon has been seen a large update, adding some cool features and fixing some long standing issues. In this post I'll describe what's changed.

But first,

What is the Worldforge Blender Addon?

Blender is the designated tool used by the Worldforge project to create 3d assets ("meshes"). It's a fully featured, professional and totally free 3d creation tool. Since all of our assets are provided as Free Software it's important that the source material is in a format which allows anyone to access it. Hence we use Blender.

The Worldforge Addon provides an easy way for content creators to export meshes and armatures from Blender into a format which both the Ember client and the Cyphesis server can understand (the OGRE mesh format).

Worldforge Blender Addon

What's new?

No OGRE addon dependency

We no longer depend on the separate OGRE Blender addon. Previously our addon depended on the OGRE Blender addon also being activated, and delegated the actual export to it. This is no longer the case. It's now sufficient to solely install the Worldforge Addon.

Easier installation

The addon was previously split into two addons which interacted. Not anymore; now everything is contained in one (large) file. This makes installation for content creators easier.

Exporting scaled meshes and armatures

Previously the addon couldn't correctly handle export of scaled meshes and armatures (due to how the OGRE addon worked internally). This is now fixed, so any scaled object will be correctly exported.

Combine multiple meshes in export

If multiple meshes are selected they can be exported as one mesh, with many submeshes. The currently active object will be used as center.

Automatic material name generation

When exporting a mesh the addon will now take care of automatically figuring out the correct OGRE material name to use for submeshes. This is done by looking for which diffuse texture is used, and from it's location in the asset repository deducing the material name.

Automatic skeleton links

Animated meshes will now have the link to the skeleton used automatically deduced.

OGRE material generation

Any missing OGRE Material definition for textures used can now be automatically generated with the push of a button.

0 Comments Read full post »