Developer Diary #6: Zoning, Struggling, Parceling
Time flies by, my last dev diary seems like a couple days ago, but it's actually more than two weeks - woops!
Let me tell you what Michael and I did in the meantime and what our plans are.
Zoning is everything
After some brainstorming, we decided to radically simplify the Citybound user interface. Sounds like empty PR lingo, but actually has a great impact on how the game will work, look and feel.
The interface for building roads is already really simple, powerful and versatile and will combine more in a single tool than other citybuilders offer altogether.
Michael had the idea to give the zoning tool as much power - some of the things he suggested I already had played with in my head, but he tied it all together nicely and even came up with a user interface to support that:
Instead of selecting a zone and then drawing it, you first draw some zone shapes and then select which zone types they should have.
Note how I said zone types, plural - this immediately allows to naturally have combined zones at will.
I really wanted to try this out quickly and decided to combine it with my old implementation of a zoning brush that snaps to roads, but this time based on actual geometry and not just bitmaps.
I started working on it in a livestream (livestream review, full livestream) and worked on it for many more days, it still doesn't always work flawlessly, but when it does, it feels really smooth:
The zoning brush will be enhanced later, to allow quick zoning of several shapes at once, of a whole block or freeform zoning away from roads.
But our ideas go further than just comfortably placing zones:
If you want, you will be able to set detailed regulations, ordinances and policies on a per-zone-shape level. This could include stuff like maximum building height, amount of required parking or green, maximum pollution, etc. ...
Furthermore, all city buildings will also be zones - police and fire stations, landfills, schools, airports, everything. You just zone a shape for them, set a budget and maybe additional parameters (prison cells vs. police office space for example) and the civic building will be constructed accordingly. Later you can change those parameters and extend the allotted shape if necessary.
Intermission: Version (out of) Control Systems
(skip this section if you know about VCS and don't want to hear our sob story, don't skip if you want to get an impression of the harsh everyday difficulties of programmers)
In this last time period, it happened two times that we were completely blocked by having to deal with issues with Git. We use Git to collaboratively work on the code for Citybound and to develop new areas of the code in branches, which allow you to work on stuff in parallel, independent of each other, each with their own version of reality.
This is really useful most of the time: Michael could work on his geometry code while I was working on game code, without each of us having to worry about accidentally breaking the code on the other side. From time to time, we would merge changes from one side into the other side (and temporarily have a common reality again).
Unfortunately I did kind of a bad job of keeping track of Michael's progress: I was using an old version of his geometry branch and even started to extend it with my own stuff, so our two realities diverged more and more.
For the zoning user interface I needed some of his most recently implemented geometry features, however, so I was finally forced to merge all of his changes into my branch and deal with the ensuing chaos. It took me 2 or 3 days just to resolve all the conflicts and get everything working again.
A little later Michael wanted to merge some new progress from my side to his, saw that it didn't work immediately, wanted to cancel it to do it properly from scratch, but accidentally made Git think that his old version of my files is actually newer than my new progress.
When we tried to merge his side into mine, Git would overwrite my new stuff with his old stuff. (This sounds really bad, but rest assured that with Git you can almost always undo).
He was forced to create a new fresh branch from my state and then had to reintroduce all of his recent changes manually, which also took quite some time.
I couldn't make the first version of the user interface for zoning work completely, because it would have required some yet-to-be-completed code by Michael, so I decided to move on to the next step and come back later.
The next step was parceling, the process of subdividing a zoned shape into individual building lots, or parcels.
Again, after a couple days I ended up with something that works okay most of the time, but fails completely some of the time.
My subdivision algorithm often produces weird slices, but can already look really beautiful. Here are some animated examples:
(Note that the algorithm is much faster, I slowed it down to make it visually understandable)
(Parcels that are smaller than the requested minimum size end up unallotted)
With that same highly-anticipated yet-to-be-completed code by Michael (hint, hint) and some collaboration on the subdivision, it will look even more reasonable and nice.
Now that parceling is in place, well, kinda, I wanted to start putting buildings in those parcels. This was a good excuse to think about the economy and demand modeling, since that's what causes buildings to appear.
I had a look at my existing implementation of the economy and was kinda disappointed that demand and supply are implemented two times: once for the global macro-economy and once for each individual agent. And from both implementations the concept of localized demand was completely missing.
These are the issues I want to address next, and I already have a couple ideas how to do that. Stay tuned!