To give you a short recap, the idea behind ROMVLVS is bridge the gap between SimCity and Civilization - build massive, detailed civilizations on huge maps without having to micromanage (at least not too much).

How does it work? You simply click on the map where you want to build a city, and buildings and roads start to appear. There is a budget, so you have to be smart about where to build.

Currently at version 0.15.4, the main improvements over the last version are:

• massive maps: the default is now 2000x2000 tiles
• user interface: I’ve finally bothered to implement an actual GUI
• responsiveness (60FPS at all times)
• hybrid grid/vector based hydrodynamics
• automatic road building (when adding population to map)

Improvements I want to make down the line:

• make rendering as realistic as possible without resorting to a full blown 3D engine
• have the ability to zoom in and admire cities in detail
• improve the gameplay: the budget should increase based on how prosperous the existing population is
• provide a macOS download

Last but not least: my thanks go out to Sebastian David Lees for some important alpha testing!

From a post I wrote in 2017:

In short, I aim for ROMVLVS to be some sort of SimCity++, taking you from prehistoric to modern times while also invoking some Civ-like concepts such as research and warfare.

ROMVLVS, like the original SimCity, leans heavily on the idea of cellular automata. Basically, simple rules governing the contents of tiles lead to very complex behaviour.

Since the last official update in 2019, I’ve been hard at work at reinventing the whole concept. The underlying philosophy is still based on cellular automata - or, more generally speaking, 2D differential equations - but I’ve simplified the whole user experience. In 2020, I started with an entirely new codebase - why not? - and renamed the project ROMVLVS2020. (And here we are, in 2023!)

In the current version (v0.13.9.2), the building selection menu is gone. The reason: if you want to simulate a gigantic map where a single tile represents 10x10 meters, you’re not going to enjoy micromanaging every addition to your city.

Instead, you dump a cloud of people on the map and let the engine build the city. Here is a short video showing a city being built:

A brief history of ROMVLVS2020

In the new codebase, I originally wanted to have city centers represented by distinct objects, so the engine could automatically create roads between cities. Also, it would help keeping track of city population and the likes. In turn, city population would determine the city limits.

Here you can see the new concept in an early screenshot (version unknown):

Below is an iteration which includes forests and rivers. The roads evolved over time: the closer two cities were together, the bigger the roads were. As a bonus, it has a nice pixely feel to it (v0.7.7):

However, keeping city objects and the map grid as separate entities somehow didn’t work great. For each city, a separate map needed to be kept to indicate the city limits. And what would happen where two cities meet - which city owns which tile?

On top if that, I started noticing performance issues. The more cities, the more pathfinding you have to do to connect them by roads.

No more city centers

Instead, I started to populate the map directly - in a later stage I would have to add a postprocessing layer indicating which blob of people would become a village, town or city.

Immediately you can see the benefit - a 1280x800 map operating at 60fps (v0.9.0):

Notice also the river network - this started to bother me, and needed to fix it.

Rivers

The way I calculated rivers was as follows:

• I randomly selected a point on the map.
• I let a “raindrop” fall from that point to the coastline.
• The resulting path was the river.

This is a nice beginning, but there are some problems:

• Rivers sometimes stop inland and never create lakes; therefore there can never be “buffer lakes” that first fill up after which the river proceeds on its journey to the ocean.
• Rivers always are 1 tile wide.
• “compounding” rivers creates a nice tributary effect, where streams from different origins converge to a big river, but they never grow wider or cause the river flow to behave differently (a small stream will flow through the land different from a big one).
• Rivers don’t influence the global water level.
• Rivers are separate entities from the ocean, creating overhead.
• There is no erosion.

I needed to introduce some kind of hydrodynamical model to solve this.

Hydrodynamics

Long story short, I adapted a freely available model that worked well enough for my needs. You can find my version here.

The benefits of using this model are:

• It integrates very easily into the existing engine.
• It unifies the existing “ocean” and “river” layers into one “water” layer.
• I don’t need to use pathfinding to determine river paths.
• It allows lakes with in- and outflow.
• Rivers can have varying depth and width.
• It allows water velocity, sediment and erosion.

Here you can see the result (v0.13.0) - looks pretty cool:

Performance is an issue right now, but because the hydrodynamical model doesn’t need to run in real time, we can dial down on the computations.

Population, revisited

After implementing the hydrodynamics, I could get back to the actual city/civilization aspect, which had been relegated to the background a bit.

The eternal question is: where does the user input end, and where does the engine take over? As I mentioned earlier, micromanagement was out - building individual roads and buildings seemed like too much of a chore.

As a starting point, I settled on a pure simulation: seeding the map with some initial population, and let the engine figure out population growth, roads, second order interactions and so on. I would figure out the user part later.

Automatic road building is a relatively easy concept - find a start and end point, and let a pathfinding algorithm determine where the road goes. Like with rivers, compounding roads creates a nice differentiating effect. As you can imagine, if you let population density determine start and end point, your big roads will end up going between big cities, while the smaller ones are between towns, etc.

To take this even further, you can use this approach to build a very realistic “medieval” city grid as shown here (v0.13.7.5):

Brighter colors mean a more densely used road.

Again, there is a drawback: by this point I’d let population influence where roads were built, and in turn roads determined where population would go. This feedback loop meant that the highest population density was on the roads themselves, not in the areas between them!

Therefore, I’m leaving roads out at the moment. I did briefly think of using the hydrodynamic model to simulate roads, but that requires some brainpower to figure out all the analogies. Here’s a “city” as it is right now, without roads:

As for population growth, there is currently none. A user can now just add population by pointing and clicking on the map, like a paintbrush.

Lighting

As you can tell, over time I’ve changed the colors and lighting a lot. Right now, I’m using a very simplified raytracing approach, where each tile (equivalent to 1 pixel) shoots a ray to the sun. If it is blocked, only ambient reflection is shown.

The problem (as you can imagine) comes when we want to determine lighting on a water tile. Again, this is something for later.

Conclusion

I’m very proud of what I’ve achieved so far. But challenges remain.

First and foremost, the boundary between user input and game engine. Am I going to make an entirely passive simulator, or should I bring in some interaction? And where does that end?

Next, population growth - it’s difficult to set parameters where population grows steadily into a nice city, and then reaches some kind of limit. From experience, either it shrinks to nothing or grows out of control.

Also, what determines population growth - food? Where does it come from? And is it in turn influenced by population? I experimented with a concave food production “curve” that was highest at some population level, and then gradually sloped down. As you can imagine, it’s hard to grow food in a city center, but easier on the outskirts.

So for now, I’m going to stick with the population “paintbrush” mode. I think for now the value is in reinventing the road generation algorithm, increasing FPS and working out the graphics layer - have some kind of simple rules that generate a vibrant, complex looking city.

Thanks for reading and until the next post!

Introduction

As a lazy person, I want to achieve the most by doing the least. As a lazy musician, I want to create music out of thin air at the push of a button. But how? I’ve been thinking about this problem for a while and in this post I will show you my initial approach in solving it.

The Creative Process

Creating music is a rewarding but also time consuming process. From personal experience, the problem is mostly one of creative control. It usually boils down to this: everything you can tweak must be tweaked.

From melody to frequency balancing to reverb levels to stereo panning - you always have the feeling that something can be better and the last 1% of perfection takes 99% of effort. This is why it sometimes takes me 10 years to finish a track: it’s good but never good enough.

The Art Of Letting Go

So, in order to speed up the process, why not accept that some things cannot be controlled? And if you take that to its limit, why not let some other process (say, algorithms) do the dirty work?

Generative Music

Algorithmically generated music or generative music is as old as Medieval times and is a well established art form, with Steve Reich and Brian Eno as well-known artists. A very nice introduction to generative music can be found here.

In my personal interpretation, generative music creates sounds that are perceptionally more complex than the seemingly simple rules that generate them.

Still thinking with my lazy cap on, which rules are the simplest yet create an abundance of complexity?

Wolfram and Cellular Automata

The graphics you have seen so far on this page have an interesting trait: the patterns seem to be repetitive yet with a degree of unpredictableness in it. They are technically not random - the images are generated using deterministic rules - but there is no simple explanation for this emergent behavior.

The rules used are elementary cellular automata and were popularized by Stephen Wolfram in his seminal book A New Kind of Science. What they do is the following:

• start with a row of 0s and 1s. These can be chosen arbitrarily;
• apply one of 256 elementary rules to this row;
• you obtain a new row with different 0s and 1s.

Here’s an example of how Rule 30 is applied. In our case we start with a row containing only zeros, except for the middle element:

Initial row:   0, 0, 0, 0, 1, 0, 0, 0, 0 
Iteration 1:   0, 0, 0, 1, 1, 1, 0, 0, 0
Iteration 2:   0, 0, 1, 1, 0, 0, 1, 0, 0 
Iteration 3:   0, 1, 1, 0, 1, 1, 1, 1, 0

As you see, we get a sequence of rows that are not quite repetitive yet also not entirely random. You could say that’s something we want out of music - a limited sequence of sounds that are somewhat repetitive yet not boring.

Music generated by cellular automata is already a thing: on Wolfram’s website there’s this incredible generator that I encourage you to play with.

Now, with me being stubborn and wanting to do things my own way, I decided to create a program from scratch that does roughly the same thing. For lack of imagination I decided to call it: Automatone.

Automatones

So, what is an Automatone? It is a matrix of zeros and ones, generated by cellular automata, where a one triggers a sound and a zero does nothing. For example, in the following matrix, three different sounds are triggered at different time intervals:

0, 0, 0, 0, 1, 0
0, 1, 0, 0, 0, 0
0, 0, 0, 1, 0, 0

If you imagine time going from left to right, and each row representing a different note or instrument, you can kind of imagine what it would sound like. In essence this is just another form of sheet music.

For the time being, I’m using a simple sine oscillator as an instrument, and let each row represent a different frequency of that instrument. To recap: each “one” in the matrix triggers a short sine tone with a specific frequency.

So what does this actually sound like?

Experiments

Going back a bit, I said I wanted to magically create music at the press of a button. The software I wrote can do that - follow the instructions on the main page if you want to experiment yourself!

Here’s a graph of a simple Automatone that applies Rule 30 to a range of 257 frequencies (vertical axis) for 256 time steps (horizontal axis):

You can see that the frequency range is quite large - so large even that apart from the top 30 or so frequencies, the resulting output would be inaudible. Moreover, because I’ve set the rendering sample rate to 96kHz, there are a lot of artifacts. In other words, most inaudible frequencies are going to be rendered at a completely different (audible) frequency.

Not to worry though, because it sounds kinda cool - and to be honest, creepy!

Because there are a lot of tones being triggered together, it still sounds very random and unstructured. So, I included a parameter n_rules. This value indicates how many rules we are applying - if it is 2, then we take two cellular automaton rules and elementwise multiply the results with each other.

Here is another experiment where 5 rules are applied instead of one (we unfortunately don’t get to choose which rules, it’s something I still need to fix). I also limited the tone range to 24. You can see the trigger density is much lower:

And here, some more experiments. You can find the configuration parameters in the description of each link. What struck me is that there is still quite some repetition going on, possibly because of a bad implementation of the cellular automata:

Future work

I have many more ideas on how to proceed. The first is to use different combinations of rules for the left and right stereo tracks. The second is to combine all rules found in the left and right track to create a center track, which will - by definition - contain less triggers. In the next blog post I will try to elaborate on this. Thirdly, instead of multiplying each rule matrix I could also add them up and use the resulting value as a volume indicator.

Next I want to go deeper and use automata to create a change in the frequency spectrum rather than define it.

Ultimately, automata can be applied to any arbitrary instrument or effect setting: tweaking reverbs, phasers, delays, you name it. Even visuals can be manipulated like this.

Looking back, I made a thing that can automatically create “music” - however the sweat is now in creating the software rather than the music itself…

Thank you for your attention,

keepitwiel

Within machine learning (ML), I understand Convolutional Neural Networks (CNNs), but have been struggling a bit with Recurrent Neural Networks (RNNs). So I set out to explore and learn!

Background

The following description by Andrej Karpathy in his seminal blog post stuck with me:

If training vanilla neural nets is optimization over functions, training recurrent nets is optimization over programs.

Combining this statement with my view on ML above, you can say the following:

• with CNNs, the created software is a “stateless” function, where you feed it a single input of fixed size;

• With RNNs you actually create a program with variables that depend on an initial state; that state changes over time by continuously feeding the RNN new inputs.

Karpathy gives an example how to train an RNN on the entirety of Shakespeare’s works - with the goal of generating “new” Shakespeare material. From that blog post, here’s an example of freshly generated “AI Shakespeare”:

PANDARUS:
Alas, I think he shall be come approached and the day
When little srain would be attain'd into being never fed,
And who is but a chain and subjects of his death,
I should not sleep.

Amazing, right? It’s gibberish, but it sure sounds like Shakespeare! I wanted to do the same.

Make your own RNN

Tensorflow has a tutorial that lets you reproduce Karpathy’s work. The good boyscout in me faithfully copied and pasted the provided code into a Jupyter Notebook and let it run. Using the same Shakespeare training set, I generated the following wonderful prose:

ROMEO:
I do pretent to Rome, come; Momed that,
For mirroant-tongued together, to thy lord,
Upon so orperalling me speak to him:
Some hath mother, throw up ta live, that thousand faithant
Well-counio so, without decay: descend at dayman
Citizens doth cry it so well;
No man belseit in fore and Die Richmond!

Enter The Dude

(Side note: if you haven’t read Two Gentlemen of Lebowski, you should. It’s The Big Lebowski written as a Shakespeare play.)

I love The Big Lebowski, the Coen brothers’ 1998 cult film, so what could be better than generating more Lebowski using RNNs?

I took the exact same notebook as above and replaced the source text with the Big Lebowski screenplay. Here’s a few lines from the input:

The Dude, also holding a large plastic cup of Bud, wears
some of its foam on his mustache.

                WALTER
        This was a valued rug.

He elaborately clears his throat.

                WALTER
        This was, uh--

                DUDE
        Yeah man, it really tied the room
        together--

                WALTER
        This was a valued, uh.

Training the RNN

(I will not go into detail on how the training process works or how to generate output - you should really check out the tutorial!)

By training, we teach the RNN to correctly “predict” characters given a set of preceding input text of fixed length. So if the input text is The Dude, also holding a large plastic cup of Bu then the correct prediction would be the character d. If we do this with a large enough set of samples, and train often enough, the RNN should become accurate enough to predict meaningful texts.

Generating new text is really simple:

• you provide the RNN with a prompt - for example, JACKIE TREEHORN;

• it will predict the next character;

• you append that character to the prompt;

• repeat.

After 10 training rounds

Here’s what the RNN comes up with after 10 rounds (“epochs”) of training:

                MABWYOR

Thy in's bonel
        decoutery gam.

                AADTER
        HER LEIBMALSSY?
        Fucke.  Wantee hishe gowt on Beyo
        ar on the I'
        youre, ma.  I dowallyote, Luy full, wo siatlo, Wat mar, uhingeyes.

First off - the model doesn’t fully understand the standard screenplay formatting rules. (Or as Walter would say: This isn’t ‘Nam.)

Secondly - the characters sound like they either had their tongue paralyzed or are regulars in a Scottish pub - or both.

Clearly, the RNN doesn’t “know” the source text well enough to make intelligible predictions.

Here’s some more:

                DUDE
        I told money you one moneys to
everything.  On a fucting exering them's the emblams.  He is the Wobar.  All fitter, and
        they poinet of as he spiph you un, Dude.

                DUDE
        I'm gettink on the rail, rest you're-

                DUDE
        .... uh, but--

                MAUDE
        --word it for you.  That's your vairbox?

After 20 more rounds

It’s getting a bit more readable now - although it all still sounds very “drunk”:

Walter blung some zarmout and will.

                DUDE
        You're gain got about the fucking
        occusior luce?

Walter prudes in to plase, he wnops with flishor is taked open the Dude's car.,
Dieter, it the phone him of geeting in slow motion.  Me and headle askig the Dude turns thrown
outing from the satchel put of his head.
out for it, his irmothing into the three men turn to loen.

                DUDE
        This fucking eaty mininess.

I’m snorting milk out of my nose right now:

DUDE
        What the fuck are you talking about?

                LEBOWSKI
        Well, All you something, is suckeds, I dan from
        which leng git home of Lebowski?

                WALTER
        Huh?  Oh, this fuck is the busi?

        Soothim. I'm not if--

                LEBOWSKI
        You got a whole cates--

                DUDE
        Who the fuck're you talking about?

                DUDE
        Now that fom he mistly handle
        ago?  Dude is Walter Solfbacks!  AM
        SCOKHY BOWLING IS IN WAL, Ar A lar, Alleady!

20 more rounds

Walter bashes him a few more time on ole almonatapal, then quiet.  Laid out now, Franz too is
Bunny Lebowski, falfing at etwing.

                DUDE
        What's your point, Walter?

                WALTER
        You're just looking for a handout
        look, a dos in one hands in take
        forlet my dight.

                DUDE
        No.  Here.

                YOUNGER COP
        Separate incidents?

The Dude steps out to meet Walter's car as it ruds blowing ball.

By this point, I think it shows that the Big Lebowski script is a mere 131 thousand characters long. There’s only so much you can train your RNN on before you start recreating it line by line.

What’s next

To overcome the limited input, I’ve been thinking about combining many different movie scripts set in Los Angeles - Chinatown, The Big Lebowski, Blade Runner, To Live and Die in L.A., Point Break, Falling Down, Die Hard, L.A. Confidential (to name a few) and do the same thing. I predict lots of ins, outs, what-have-yous all set in a dreamscape meta retro-futuristic Los Angeles…

Also, to make the text more meaningful, the RNN should have some notion of “attention” - there needs to be some kind of character and environment persistence.

On that note:

                VOICE-OVER
        sometimes there's a man. . . sometimes
        there's a man.
        
        Wal, I lost m'train of thought here.
        But--aw hell, I done innerduced him
        enough.

• Cursor: you can now see what you’re building, and whether it’s possible to build, using the cursor.

• Message panel: any important messages will appear in the message panel at the bottom of the screen. For now, it’s mostly warnings and welcome messages.

Here’s a video of the latest development build containing these features:

I promise there will be releases for Windows and Linux as well in the future :)

My handle is now keepitwiel as opposed to CaptainHennessey. I am now the proud founder of Keepitwiel Studios!

I’ve moved the blog/website to Github Pages, but the older blog still lives at Tumblr. I might move that content here at some point.

I’m putting the finishing touches on a new alpha release (v0.1) that can be freely downloaded.

Yeah the GIF takes a while to load, but at least you get a sense of what the engine is capabe of at the moment. I use Numpy to handle all the low level storing of data which is pretty fast - even at this size, I haven’t had any scaling issues so far.

ROMVLVS, like the original SimCity, leans heavily on the idea of cellular automata. Basically, simple rules governing the contents of tiles lead to very complex behaviour.

The original concept popularized by Conway is very binary (either life exists on a tile or not); SimCity made use of difference equations in order to increase or decrease the quantity of e.g. population on a tile. This is the same in ROMVLVS. A simplified set of equations might look like this (x and y are quantities to be increased/decreased, t is time, t+1 is the time at the next turn):

x(t+1) = x(t) + C1 * x(t) + C2 * y(t)
y(t+1) = y(t) + C3 * x(t) + C4 * y(t)

In SimCity you were free to build wherever you wanted, as long as you had enough money to do so. The existing infrastructure generates taxes, which fills the city coffers.

In ROMVLVS, there is no money. Or, at least, not centralized. If you don’t have resources available in a specific tile to build something, you can’t build it, even though it’s available on other tiles.

So how do resources spread around? This is where dispersion comes in place. Think of an inflatable pool in your back yard. When you pierce it, it will empty out in rapid pace, flooding its surroundings. The more time goes by, the more dispersed the water is, eventually flooding your entire garden with a thin layer of water.

In ROMVLVS, dispersion works as follows: if you have a farm producing 1 unit of food per turn, a small percentage of that (say 10%) gets dispersed to the four surrounding tiles. Your farm will be left with 0.9 units while its neighbors get 0.025 units each. Those neighboring tiles will disperse 10% of 0.025 to their neighbors in the next turn.

In order to keep infinitisemally small amounts of resources spreading around the map, there’s a dispersion threshold.

At the beginning of a game, you start with a Settlement and 5 people (all living in the Settlement). The Settlement produces Culture (quite an abstract resource) which starts spreading outward over time. The difference equation governing the growth of people is such that Culture is a positive factor - i.e.:

Humans = Humans + CULTURE_FACTOR * Culture

Now, resources like Food have also a similar positive influence whereas proximity to enemies, extreme temperatures etc. will negatively impact human growth.

This basically describes the ROMVLVS engine. The trick is to balance out all the different resources: adjusting growth and dispersement parameters, adding buildings that modify growth even further, and adding resources that counterbalance other resources. So far, only Culture, Humans, Food and Wood are “active” resources that can be altered; I’ve thought about adding things like Disease, Fear, Stone, Bronze, Meat, Fruit, etc. etc.

Hope you enjoyed this behind-the-scenes look!

New in ROMVLVS: farms. The food they produce increases the population significantly. Here’s a GIF to show you how it works!