News

Worldforge _finally_ got “movement constraints” implemented. This feature basically allows world creators to declare rules for which entities the players are allowed to move. Previously there were no constraints, so any random player could pick up any random other entity (such as a house, or another player). As with so many other things the main reason why such a seemingly basic feature took such a long time to implement is that we want to make the rules generic and dynamic enough to allow for many different kinds of games.

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.

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.

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.

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.