2020-01-04

Scale Devblog #1

Introducing Scale

My vision of Scale is a simulation of modern day society, from the bottom-up. Each individual has its own thought model, which means that every action they take has its importance and influences the environment.

The biggest difference with similar project like Citybound or other city building projects is that Scale is not meant to become a video game. Scale's universe should be observed, but not (or hardly) interactive.

Everything is simulated on an expensive big computer, and anyone can connect to a website to see the evolution of the Universe.
Time just goes on, whether or not anyone is watching.

This means that a lot of work can be invested into making it a unique world, with a lot of attention to detail.

Roadmap

Since this project is quite ambitious, I plan to start small. My first milestone is to be able to have a simple world where humans go to work and go home with a somewhat realistic traffic model.

I already did a traffic simulation in Java, which turned out quite satisfying to look at. I even imported data from openstreetmap to generate the roads.
Safe to say I have a bit of experience doing a traffic simulation, so going a bit bigger should not be a hurdle.

The very long term (how to simulate a real society) is not planed however, as it would be too vague and I haven't done enough research.
Although I already have plenty of ideas about what is possible, I will think about it once I finish my first milestone.

Technology

After considering several languages to code the simulation in, such as C++, Java, Go and Haskell, I fell in love with Rust.

Rust is a young (2012) language that is fast and memory-safe, without a GC.
Its type system is flexible while still having "zero-cost abstractions" (monomorphization). Overall, the language is very sweet once you know the quirks, and is deemed as "most loved language" in the annual SO survey.

I also decided to go with an ECS architecture, to separate behavior from data and to have flexibility over what an entity can become.
It should also enable easier interactions between everything, also featuring auto parallelization with the wonderful specs crate.

My first test with this architecture went quite well, where I made some balls do things.

Decoupling rendering and simulation

The final objective is to render everything on a browser by streaming data via a websocket.
This means that rendering things should be completely separated from updating the world and advancing the simulation.
This is why I already split the project into two modules:

  • the engine (graphical engine) module, dedicated to rendering the world. In Rust using the ggez library for the moment, since I do not want to write a web UI right away.
  • the scale module where the ECS stands and the world is updated.

However, to simplify things for now, entities have components declaring how they should be drawn, but that could be left for the engine to decide in the future.

ECS and Events

After spending days going back and forth between different ways to model Events (such as collision events or so), I ended up using an EventChannel as a Resource.
The idea is to have a shared buffer (Resource) of a specific event (an EventChannel). That way, any System can ask for read or write access, and delay between writing and reading is solved by correctly specifying the dependency tree.

Open Source

Scale is open source, because why not ? I am very open to criticism as I discover new Rust features every day.

Github: https://github.com/Uriopass/Scale

< Back to list