2020-01-04
Egregoria (previously Scale) Devblog #1
Introducing Egregoria
My vision of Egregoria 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 Egregoria is not meant to become a video game. Egregoria'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 theggezlibrary for the moment, since I do not want to write a web UI right away. - the
egregoriamodule 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
Open Source
Egregoria is open source, because why not ? I am very open to criticism as I discover new Rust features every day.