This weekend I continued working on the prototype for decision modding. There's isn't much to talk about it. Nevertheless, I wanted to spend a few paragraphs explaining a major change to modding coming for 0.3.4.

One of the original design goals for modding in Worlds was to keep things as simple as possible. I wanted mods to load very quickly and to execute as fast as possible to avoid slowing the game too much. I also wanted mod files to be very easy to read and understand for people who have little to no experience with programming languages. For those reasons, I chose JSON, which is a very simple data structure format, as the base mod file format. 

To compensate for the fact that JSON is not a scripting language, I added a very simple expression system to construct logical conditions, modifiers and effects which can be inserted as object attribute values. Is in this regard that I encountered some severe restrictions when designing the current prototype for decision modding... I was having a hard time trying to translate the current C# game code using the current mod expression model due to its very ambiguous sentence format and the clunkiness of its logical operators. Because of that, I decided to redesign the expression language used in conditions, modifiers, and effects, to allow for the creation of sentences more similar to those that you would find in standard programming languages. To illustrate, here is an example written using both the old expression evaluation system and the new one...

Here are the current discovery gain conditions for 'boat making':

"gainConditions": [
  "[NOT]group_has_knowledge:shipbuilding", 
  "[ANY_N_CELL]cell_biome_type_presence:water", 
  "cell_biome_trait_presence:wood,0.3"
],

And here's how they would be expressed in the new system:

"gainConditions": [
  "!group.has_knowledge(shipbuilding)", 
  "group.cell.neighborhood.any(member.biome_type_presence(water) > 0)", 
  "group.cell.biome_trait_presence(wood) > 0.3"
],

As you can see, each condition expression is very similar to code instructions you would find in a regular programming language like C++ or Javascript, and each one of them can unambiguously be resolved into a true or false statement. Additionally, individual expression elements, like 'group' or 'cell', can have property accessors and functions: Instead of having to define unique statements to evaluate or modify the properties of an object, one can just access their properties directly using the dot '.' operator. This last feature in particular, if implemented correctly, would add a great deal of flexibility and power in contrast to the old model. The biggest drawback of this new expression model though is that it is possibly going to be a little bit harder to use and get into. Though it won't be a big deal for anybody with some basic programming experience. 

Keep in mind this is still just an incomplete prototype. I'm still figuring out some of the details, and I have yet to start working on the new expression parser. If things turn out to be too complicated I might reduce its target capabilities or even roll everything back to the current  model...

Just a note for people that have already created mods for the current version of the game: My plan is to support the old expression system as much as possible so that current mods can still be used in the next version. I will try not to break any of the current modding functionality. Though I hope it will be easy to update the current mods to the new system.