A little backstory

Microlandia “the brutally honest city builder” is a pet project that I started several years ago. I can’t pinpoint exactly when, as the project has gone through multiple rewrites and long periods of abandonment.

The idea was to clonemake a game inspired by the original SimCity, but with a totally different approach to the engine: Instead of simplifying the simulation to adapt to small machines and fun gameplay, I wanted the simulation to be as detail-obsessive and precise as possible.

But what’s really going on inside is not as realistic as they would want to believe: because of its nature as a game, and the constraint that it must run on low end home computers, it tries to fool people into thinking it’s doing more than it really is, by taking advantage of the knowledge and expectations people already have about how a city is supposed to work. Implication is more efficient than simulation.

Don Hopkins on the original SimCity

The purpose: to find out what it is like to play a city builder with variables that reflect real world data, like the cost of healthcare, life expectancy of urban citizens, greediness of landlords, or the likelihood of people cheating on their partner with a co-worker. There is a myriad of sociological studies where I can obtain this data from and feed it to the game mechanics.

What is not a goal is creating a commercial product or even a fun game. I want to be as real as possible, and find out if I can finish it without going insane.

The initial approach

The first version was developed in Go after establishing goals:

1. I want to iterate on a lot of data and be as granular as needed. I don’t need the overhead of object oriented programming because the world can be simulated with a nifty pattern of systems operating on plain data.
2. I want to produce an executable file that’s played locally on any computer. If it’s another always-online game for a ridiculous reason I will drag an unforgivable guilt that will make me miserable to the grave. But I do want eventually to have multiplayer, so a client/server hybrid executable that can be played via player-operated servers or LAN, like the good old days of Quake or Minecraft.

As the project advanced I started getting frustrated with implementing anything beyond basic visual features in Go:

1. A good 3D view of the city where I could render hundreds, potentially thousands of buildings. I know this is not a limitation of the language but rather my laziness on figuring out how to do graphics in Go
2. A good UI view for all the insane amounts of data I want to present to the user: Histograms, News Reports, Interactive Maps, Balance sheets and all other sorts of visual representation of the simulation data. There’s no go-to library for doing this and I would need to spend a lot of time implementing all the necessary UI components.

Inside of me, there are two wolves. By this point, one was telling me: “Okay kid, your Go is cute but this is not amateur hour, let’s pull up a real game engine made by a billion dollar company!” I was disgusted by the idea but it does make sense. Thankfully, the other wolf told me: “There’s already open technology you can use that’s pretty decent, it will not be fancy, but it will be cool as fuck!”

After that casual hallucination I made up my mind.

Porting it over to Deno

Our real end product is the mental model in the player’s head

Will Wright

It turns out that ThreeJS performs well enough for my needs, as I don’t want to build anything complicated that gets in the way of a simple city builder experience. Is it too simple? Maybe. But Cities Skylines is made using Unity and can make your laptop so hot that doubles as heating for the winter.

It also turns out that React is a very complete UI toolkit that I can layer on top of the 3D view and is a really good framework to present all the excesses of data visualization that I plan to do.

The problem is that these are web technologies, not made for games, and would also break the goal of having a local, portable game. Or is it? We can write the client and server entirely in Javascript technologies and package it all in a single chunky Electron app sandwich.

But we can do better.

After crying non-stop for a few weeks thinking about how I will miss Go and having to continue my project in ugly Electron and it’s friends the funky Javascript ecosystem, I stumbled upon the compile feature of Deno: It produces a cross platform executable of an app, and in conjunction with the webview_deno library, this same app can open a browser window and run my React. Suddenly, the prospect of porting the game to TypeScript was not so sour.

Yes, I will miss Go, but Deno offered some consolation with its simplicity and its “batteries included” approach that is actually a pretty good toolset for making games:

1. A SQLite client that for saving all the city data
2. Websockets protocol for communication between the simulation (server) and the React interface (client)
3. Like Go, comes with complete tooling: formatting, bundling, linting, testing

This means I can write most of the simulation, by using Deno itself and not a scary inter-dependent web of vulnerabilitiesnpm dependencies.

About 100 cans of energy drink later I had a ported version of the game running in Deno, packaged in a single executable that runs a local server and communicates with a WebView-based interface that is a user-friendly presentation for the infinite source of stress that is playing a city builder such as this.

Once I got into the new development workflow it was clear to me this was a huge win: I can develop using vscode with the Deno extension so the server-portion of the game runs with a full debugger, and with Vite I have a live-updating view of the game right next to my vscode window. Since the game is stateful on every tick I can live reload portions of the code without restarting my current game. Watching your changes go live as you are playtesting is such a heartwarming feeling could not give up now that I’ve tasted it.

Because both the server and client are written in Typescript, even though they are separate worker processes they share the same typings and some of the utilities. This makes it really handy when we need to code through the stack and changes to data structures travel through client and server seamlessly.

Thinking Ahead

I’m sure there will be times when I will feel the shortcomings of the tech stack: This will not run as fast as Go, it does not necesarily break apart from billion dollar companies, and I’m not 100% free of the npm library hell.

But the fast workflow enables me to focus on the insanity that is the foolish endeavor of simulating the world, instead of getting sidetracked on making 3D and UI actually work in Go, or intoxicating my brain with Unity.

If you have macOS or Windows and you are keen to look at a game prototype, please download and try Microlandia, it’s free!!!*

* Donation is encouraged