Posted by admin on May 27, 2015
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.
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.
Posted by admin on August 24, 2014
During the summer three students have worked on Worldforge as part of Google Summer of Code. With this year's program now coming to a close we would like to highlight these three students and the work they've done.
Céline Noël, Smartbody integration in Ember
Céline has been working on integrating the Smartbody system into Ember. Smartbody is a comprehensive system for simulating human behaviour, with all of the subtle body movements that natural motion entails.
Since Smartbody is such a large system, and deals with so many different facets of human motion, a large part of the work done by Céline involved integration with Ember on the code level. Once this was done further work was done with modifying the Ember structure so that human entities use Smartbody for their underlying animations and movement.
The work can be seen on Github. It's not merged into Ember master proper yet as there are some outstanding issues, but will be during the coming months.
Péter Szücs, Android support for Ember
Péter has been working on adding support for Android to Ember. This work has mainly involved getting the whole Worldforge stack to build for Android, and then adding support for multi touch to Ember.
The main difficulty initially was getting the Worldforge stack to build for Android, using the existing Autoconf build system. Péter has done changes to most of the Worldforge libraries, as well as to the Hammer build tool. The Hammer build tool now has built in support for cross platform builds, and will setup an Android toolchain by itself.
We're not yet where we can provide Android builds of Ember, but expect this to happen during the nearest months. Keep an eye on this space for more announcements ragarding Android support. The coming weeks we'll start moving Péter's work into the main repositories.
Yaroslav Taben, Cyphesis Entity filters
Yaroslav has been working on adding entity filtering to Cyphesis. This project is a little harder to explain for someone who haven't worked with Cyphesis, but it can basically be described as "functional filtering of entities using a query language". This is very useful for things like the AI code, since world authors then can more easily write rules for entity behaviour using a query like language.
The areas where Yaroslav mainly worked were both with defining the rules for the query language, and implementing this in an efficient way in the code. We used a iterative process for the language definition, where we during the summer tried out various syntaxes until we found one that fit our specific use case better.
The code can be seen on Github and we plan to start integrating it into Cyphesis within the coming weeks.
All of the students worked hard during the summer, and produced excellent results. As before we're very happy with the program, and would like to thank Google for providing us with this opportunity.
Posted by admin on August 17, 2014
The new Worldforge site is now finally online!
As you probably can see, since you're reading this post, we now have a shiny new web site. The old one was creaking at the seams, and had been for a couple of years. The new one runs on Concrete5, a very competent CMS system. We'll try to keep the amount of pages down, as not to incur a maintenance debt. We'll probably also be updating the site the nearest couple of days.
Posted by admin on June 15, 2014
I've recently done some work on adding proper pathfinding to Worldforge. For this I've chosen the Recast/Detour library. While this approach, using voxel rendering to create navmeshes from arbitrary geometry, is both complex and resource expensive, I'm convinced it's absolutely required to allow us to properly support the dynamic and changing worlds in Worldforge.
I've done the initial implementation in Ember, mainly because it's easier to visually debug. But the main benefit will come from integrating this work into Cyphesis, so that it can control AI movement.
This is an area sorely in need of improvement. See, currently there's no path finding or obstacle avoidance at all for the AI characters. The result of this is that NPC characters always move in a straight line towards their target, causing them to inevitable become stuck on other entities. No good. No good.
With proper path finding and obstacle avoidance we can instead implement more advanced AI behaviour.