Citybound as a Truly Moddable and Educational Simulation

This winter, I had a burst of very visible productivity, with zones, roads and the economy coming together to something that you can interact with for a couple minutes, which culminated in a new homepage with short videos - the first version of the homepage that I felt actually does justice to the vision I have for Citybound, that gives an overview of the crazy stuff that's already in it and that actually has first working glimpses of the core ideas for Citybound.

This homepage made some waves and brought new attention to the project, most notably by being on the front-page of Hacker News for a whole day, a very high-visibility place in the tech industry, reaching many new people. In a happy twist of fate, this indirectly also brought Citybound to the attention of computer pioneer Alan Kay, after whom I named the technology at the core of Citybound's engine, which is in many ways inspired by his original ideas for object-orientedness.

I had a chance to talk to Alan and was surprised that he went much further in his criticism of already the original SimCity, even calling it "anti-educational" in the sense that, yes, it lets you interact with a superficially interesting simulation, but it is absolutely intransparent about its inner workings, let alone allowing you to experiment with its parameters and rules to really learn what's going on.

From its beginnings, Citybound strived to run a qualitatively more in-depth simulation, and with my decision to fully open-source it, offered at least the most naive way of being fully transparent and at least theoretically modifiable by anyone determined enough. In practice, I had to admit to myself, this meant little and it doesn't nearly go far enough to implement my vision of Citybound as a true educational toy.

My proposed solution for this problem, which I'm currently working on, was born out of a very pragmatic necessity, though: the programming language Rust, which most of Citybound is now written in, has done wonders to provide me with a performant and stable platform to build the game on, but it has one major drawback: compile speed. Expressed in practical terms, it means that for any change I do to the codebase, I need to wait at least 1-2 minutes before I can re-run the game with the newest changes in it. This is negligible when I do large overarching changes to whole systems, but gets really annoying when I need to do iterative tweaks, and outright kills creativity when I just want to experiment and try out different possibilities in rapid succession.

Two such examples, which came up are behaviour rules of economic actors, and architecture rules for procedural building generation.

I most recently worked on the latter, developing something like a general architectural language, with which all kinds of architectural styles and considerations could be described precisely enough to generate thousands of diverse, unique and locally-sensible buildings on-the-fly, to fill the cities of Citybound. I just completed the necessary abstractions in code to implement this architecture language, cleanly separating A) a low-level super-fast base which generates the geometry to be rendered from B) a high-level super-meaningful set of architecture language words and combinators in which I can intuitively describe a building type, which is then translated into A) and executed super-fast.

I did this mostly to ensure I would have a tool powerful enough to actually generate diverse and sensible buildings without having to write too much code by hand. But then I realised that I could just pull out the building rules written in that new language, and essentially make them configuration for Citybound, which can be modified at a moment's notice, with the game reflecting the changes immediately. I then understood that this was a pattern that reappeared throughout the game, with the next obvious instance being economic household behaviour.

In programming, this strategy is called "domain-specific languages" and I think they are a recipe that I could apply to all aspects of the game, offering a very clear progression from hacked-together config files as the first approximation (a simple JSON structure, for example) to dedicated graphical editors for rulesets - imagine, for example, having a "building style editor" with a realtime preview of generated example buildings. This should hopefully make Citybound modding and experimentation much more accessible going forward, and should make development faster and more fun for myself.

These domain-specific languages could very effectively open up two new directions for the vision of Citybound that I always had as vague dreams, but never quite knew how to make happen: first, building Citybound as a city-simulation toolkit, which could even be used by scientists, mixing and matching subsystems and tweaking them to run precise experiments, and second as a first point of contact with programming for kids: having learned so much myself by modding games and having that as a big contributor to me getting serious about programming, I think Citybound could be an ideal environment for first programming-like experimentation, offering a huge, organic simulation world in which things are happening, where even slight tweaks (done in friendly modding interfaces) can have extremely interesting, visible effects.

With such languages as a modding interface, Citybound can both perform the magic trick of city simulation, while letting the player peek behind the curtain and taking things into their own hand, leading to a much deeper understanding of how cities work, how complex systems work in general, and the even more fundamental idea of having a model of the real world and approximating life with simulations.

With all that being said, Citybound will still first and foremost strive to be a fun and interesting game, that already offers important insights when just played as-is, while additionally serving as an entry point to this kind of much deeper exploration.

I hope to complete my first version of the architecture language and show it in action soon, and I'm looking forward to your thoughts about the general approach.