Reviving the blog, new report on the progress - June 2018

3 minute read

I neglected this blog for a few months now! Progress has been slower, though it hasn’t stopped.

There were a few quite significant changes made since last entry.

Performance

I wasn’t happy with the performance.

Leaving Lua/Moonscript scripts

Simple stress tests on the existing system I had - Lua scripts run with Moonsharp on C# in Unity3D - showed it was too slow.

This is not that surprising - there are many things that come in to create a working language such as Lua, many moving parts. To implement an interpreter for Lua in another language, as is the case with Moonsharp, is not an easy task. Higher complexity here means worse performance.

The question for me was: is all this functionality of a language needed?

What I really need for the state-machine-like pieces is to be able to hold instructions and operate on variables. It doesn’t really have to be that sofisticated.

Parsing simpler files and hardcoding as many of the instructions as possible seems to be a better way to approach this.

Restructuring

Thinking more about the possible uses of the kind of simulation infrastructure I’m after with this project, I realized I needed to think more about portability.

Simple data files as input

As mentioned above - leaving Lua scripts behind. The idea now is to use simple json/yaml files as input. The program can interpret the input files and based on them create a structure of objects and instructions that it internally understands. So primitive compiling basically.

Of course there will be work needed to set rules for parsing the files, which wouldn’t be there if I used Lua. But then again - the performance aspect seems to favor this approach, big time.

Separate implementations

Using json/yaml files as input files implementing the base Outcome architecture in other languages easier, as there will be no need to deal with processing Lua.

This opens doors to important options such as

  • implementation in Rust programming language for speed
  • implementation in JavaScript for use within browser

There’s also the original approach with C# for use with games with Unity3D.

Of course the architecture needs to be specified first.

Out with the old

The original prototype implementation in C# was quite messy, also heavily dependent on Moonsharp. Rewrite should be better thought out and organized into a separate package itself, one that could be easily brought into any Unity3D project for example and used out of the box.

The plan for now

The main thing right now is definitely the docs.

Draft the documentation

Actually creating a document outlining how the content for the sim is to be written, and maybe more importantly, how the simulation system itself is to be implemented and what parts it consists of, is something I have neglected up to this point.

Main effort right now will be focused on delivering a coherent “guide” to what I’m after for anyone interested to be able to read it and understand it. It will be easy to read for anyone not experienced with coding and such, at least that’s the goal.

The docs are available at docs.theoutcomeproject.com. It’s still a work in progress, and probably will be for the next few months.

Plan the OutcomeSharp implementation

Plan the implementation details for the C# package.

Learn more about Rust

Implementing the architecture in Rust lang is one of the goals. A fast, gui-less tool for running multiple simulations back-to-back, maybe even on multiple machines, will be an important step towards potentially being able to get some scientific value out of the project.