Unifying Road & Zoning UI
My abstract, lofty goal for the user interface of Citybound was always that it feels like roads, train tracks, zones, and other things are painted.
My current, concrete task is to extend the planning logic and user interface that so far exists for roads to incorporate zoning. It feels unnecessarily difficult to implement, since many of my assumptions for road planning and construction turn out to be exceedingly complex, yet I need to fit zoning into the existing framework. To make things worse, the things that are actually very similar between roads and zones (drawing shapes onto the map), I have to completely reimplement again. This left a bad feeling in my stomach, but I decided to move on, since I'm already overdue with this prototype.
But inspired by this slight annoyance, my brain starts to wander off and starts thinking more about the current road laying interface... bringing up some long suppressed thoughts... Maybe I was never really that happy with the new interaction paradigm that I tried in the current implementation... Maybe the idea behind it is fundamentally stupid—why should the UI follow how roads are represented internally (thinking only in terms of individual lanes)... only to then require stupendously complicated logic to be able to manipulate bundles of lanes (aka roads)... And why do I create new roads by simple clicks to add control points... only for these control points to be invisible and forgotten afterwards, requiring a horribly complicated system of range selection of lane pieces, and moving these stiff pieces around like undercooked spaghetti... And the game crashes so often because of weird edge-cases in this minefield of geometrical explosions... But even before editing roads, I noticed that test users, both in person and in videos, are struggling with just creating straight, beautiful roads in the first place, because of the lazily simple way road curves are fitted onto the drawn control points...
At this point there is a voice shouting in my head: this is all wrong and it can be much simpler! The voice is waving with the equivalent of mental structure diagrams, rough, but convincing sketches: underlying the tangled mess of the current implementation are the seeds for something much simpler, that promises to be easier to use, easier to implement and much closer to my original vision of "painting" UI.
This kind of revelation is very familiar for me, I've had it many times throughout my programmer life. I respect it, but I learned to trade it off with practical concerns, such as deadlines. I don't need to tell you that I've become wary of re-implementing things.
This time, my past self comes in for my rescue, however, and I am incredibly thankful for that: the current road planning implementation may be tangled, but it does two things right: first, it is extremely modular and loosely coupled, and secondly, it has a very clean interface to the "actual world" part of the game: the simulation.
What that means is that it is feasible to replace only some parts of the road planning logic and interface in a very surgical manner, leaving all of the really hairy parts (road intersection logic) untouched. At the same time, zoning will be much more comfortable for me to implement, and much more familiar and same-ey to the (already road-laying) user.
And this is exactly what I will allow myself to attempt. Thank you for your understanding of the incurred additional delay for the zoning prototype.
I have some free time upcoming, which I will use in full hackathon-fashion to tackle the last bits of this and hopefully already the next prototype (on housing demand). Since both are quite interactive in nature, I think it will be fun material for coding livestreams, which I am planning to do. Expect them from 16th-27th of March and stay tuned for detailed announcements.