Atlas C++ 0.6.4 released

Posted by admin on July 23, 2017

Atlas-C++ version 0.6.4 has been released and is now available from the WorldForge download site. Atlas-C++ is the standard implementation of the WorldForge Atlas protocol. This release is primarily aimed at developers and users who want to build the WorldForge system for themselves.

Major changes in this version:
  • Removal of deprecated C++ "throws" feature which broke build on GCC 7
  • Addition of a debug output Atlas bridge
Source code can be downloaded from the following locations:

Source Code .bz2
Source Code .gz

AI pathfinding work in progress

Posted by admin on September 28, 2015

Recently I've done some work on adding proper path finding to Cyphesis. This is something we (surprisingly enough one might think) have been lacking for so many years.

The work isn't done yet, but here's a short demonstration of the work in progress.


Ember now conforms to the XDG spec

Posted by admin on September 19, 2015

I've just pushed some changes to the Ember client which makes it conform to the XDG Basedir spec.

The main difference is that the ~/.ember directory isn't used anymore. Instead configuration files are put in ~/.config/ember while data files are put in ~/.local/share/ember.

During startup the contents of ~/.ember will be migrated, and a backup will be made in ~/.emberlegacy.

Many thanks to Olek Wojnar for making the bulk of the changes.

Out-of-process mind code

Posted by admin on May 27, 2015

screenshot_20131026_134526-1024x576.jpgI just pushed a rather large changeset to the Cyphesis server which redesigns the mind code so that all AI code now is handled by one or many processes separate from the server.

This is a big change to how the Cyphesis server works. Previously all world simulation and mind code was handled by the one Cyphesis executable, in one single threaded process. Now the server instead only focuses on world simulation and various house keeping tasks, while separate processes handle all AI code.

There's a new executable, "cyaiclient", which when invoked will use a local socket to connect to the server and act as an AI client. Many such clients can be run in parallell, each one handling one or many minds.

The advantages to this are manifold.

  • It lets us better take advantage of multicore system (which is the norm since a couple of years) without having to rewrite the single threaded nature of the Cyphesis server. Each AI client is single threaded, but multiple clients can run in parallell.
  • It makes the server less complex, since AI execution is handled separately. This makes it easier to reason about and work with.
  • It allows for an improved workflow when developing AI code. The AI code can now be altered and restarted without the server being touched. This allows for more a more efficient iterable approach.
  • More avenues for alternative AI clients are now open. The current AI code uses mainly Python. It's now much easier to implement an AI client in a separate language (Prolog anyone?).
  • The door is now open for letting AI clients run on separate machines. Say, in a cloud. While the current code requires the AI client to connect using a local socket, implementing support for remote connections should be trivial.

When Cyphesis now is run it will by default spawn a child AI process. This behaviour can be tuned through the "--cyphesis:aiclients" flag. Setting it to zero, as such "--cyphesis:aiclients=0" will disable the automatic client spawning, thus allowing you to run your own client process. This is useful when developing.

Entity Query Language

Posted by admin on May 23, 2015

We've now merged the work Yaroslav Taben did last summer on a new entity filtering system. For a lack of better name we're calling it the Entity Query Language.

Why is this needed?

A lot of the AI code in Cyphesis deals with selecting and acting on entities. Consider a "Flee" goal for example. This should be used by weak creatures to flee from dangerous creatures. As soon as a dangerous creature comes within range the creature to which the goal belongs to should turn tail and elope.

But how do we determine what constitutes a "dangerous creature"?

This is where the EQL comes in. As most other query languages it allows you to select a subset of a set of entities, given a number of criteria. The syntax is a bit similar to other query languages such as SQL. For our case we might want to avoid bears. The EQL then becomes

entity.type = types.bear

This would return a positive match for all bears. However, perhaps we only want to avoid those bears that have a mass of at least 50Kg? We'll add another restriction

entity.type = types.bear && entity.mass >= 50

There are of course other dangerous animals. We also want to avoid wolves. These are more aggressive, so we don't want to check their mass

(entity.type = types.bear && entity.mass >= 50) || (entity.type = types.wolf)

In this way we can create more and more complex rules for how the AI will interact with the surrounding. The query code is now pushed to Cyphesis master and most existing goals are being converted to start using it.