Known limitations

This project has never claimed to be finished. There’s an old note in the raw source material listing what needed work at the time, and rather than transcribe it as if it still described the software today, it’s been checked line by line against the current source. Some of it is resolved. Some of it is exactly as open now as it was then.

Resolved since it was written

Building style used to be hard-coded. The exported geometry’s ornamental detail — doors, windows, mouldings — was, at the time, simply copied from Bruno’s own house, with an acknowledged need for “some sort of way to define building styles.” That gap is closed: an inheritable style system exists now, documented in the Homemaker walkthrough and carried through into homemaker-addon, including alternative styles beyond the original default.

At least one specific pattern has since been implemented. 161 SUNNY PLACE was filed as future work at the time; it’s scored in the current source today. See Which patterns does Homemaker score? for the fuller, equally dated list this one correction comes from — the same caveat applies to that whole page.

The evolution engine now runs on Algorithm::Evolutionary. Replacing the home-rolled selection machinery with this CPAN module was proposed years ago, and it’s happened: bin/urb-evolve.pl drives the whole population/selection loop through Algorithm::Evolutionary::Op::CanonicalGA. One narrower piece of the same old plan hasn’t followed it across, and is worth naming precisely rather than folding into a broader “still open” claim it doesn’t support: Urb::Dom::Mutate and Urb::Dom::Crossover remain bespoke classes rather than formal Algorithm::Evolutionary::Op subclasses, which is what both modules’ own documentation still says is the “eventual intention.”

Still genuinely open

A form language for privacy-driven cultures is designed, not built. The compact city describes how the daylight-driven approach could extend to a culture where privacy or overlooking matters more than daylight — the daylight requirement can already be turned down, and outdoor courtyard rooms already participate in the same connectivity graph as any other room, both genuinely implemented. But the actual scoring module for privacy and overlooking, the part that would make this a real second form language rather than a permissive gap in the first one, hasn’t been written. Checked directly against the current source: there’s no privacy or overlooking code anywhere in it.

Building services, and a real bill of materials. See Costing, and where building services fit for both of these in detail — plumbing and drainage design has no code at all yet, and today’s costing is a differentiated but still approximate proxy rather than anything derived from the IFC models the software can already export.

It needs testing in real projects, not just in theory. This was true when it was first written and is still true now: the way to find the limitations that actually matter is to build with this, not to keep auditing an old to-do list.

What this page doesn’t claim

One item from the original note — that window and door placement was crude, simply filling a wall with as many openings as it could fit — wasn’t confirmed either way. The style-and-asset configuration that controls which door or window gets used, and roughly where within a bay, clearly exists and looks more considered than that description; whatever algorithm decides how many openings a given wall gets wasn’t tracked down for this page. Better to leave it unclaimed than repeat an old complaint that may no longer be accurate.

Creative Commons License

Last updated 16 September 2026.