Costing, and where building services fit

The Software Overview mentions a costs configuration file without saying much about what it actually prices, or how far that pricing goes. Two things are worth spelling out: what the current cost calculation actually does, and a genuinely unbuilt idea for handling building services the same way.

Costing today

The fitness score isn’t divided by a single lump cost — it’s a sum of several differently-priced things, checked directly against the current source rather than assumed from an old description. Interior and exterior walls are priced separately (exterior costs roughly 50% more per metre than interior, in the default parameters), inside floor area and outside space are priced separately again, and covered-and-supported outdoor space (a balcony, say) costs more than open ground. A flat rate is added for the plot itself. All of this is summed per storey and then across the whole building, and the total is what the fitness calculation’s value side gets divided by.

That’s a real, differentiated costing model — not just “add up wall and floor area,” which undersells it — but it’s still a proxy, tuned to push evolution toward efficient massing rather than to price an actual construction project. It has no labour cost, no real material unit prices, no schedule. The place that information could eventually come from already exists: homemaker-addon already exports a full IFC building model, and any IFC-consuming BIM tool can derive real quantities and costs from a model like that. But nothing in the current pipeline actually does this yet — extracting an accurate bill of materials from the generated IFC model, rather than approximating cost from wall and floor areas during evolution, is a real gap between what the file format could support and what anything downstream of it currently does.

Building services: an idea, not yet code

There’s no plumbing, drainage, or building-services code anywhere in the current source — this isn’t a documentation gap, it’s genuinely unbuilt. But there’s a specific, well-worked-out idea for how it should eventually fit in, and it’s worth recording even unbuilt: the same split Homemaker already uses for stairs. The fitness function only checks that a stair can be legally fitted into the space available; the actual placement of individual treads and risers is handled afterward by procedural code, outside the evolutionary search. Services would work the same way — the fitness function checking that a run of pipework fits, not evolving its exact route.

The interesting part is the costing logic this idea implies. Traditionally, houses stack bathrooms over kitchens because it’s cheaper — one vertical run of plumbing serves both — not because that arrangement is actually better to live in. Rather than hard-coding “stack the wet rooms,” the proposal is to price the difference: score the extra cost of a duplicated plumbing run same as any other cost, and let evolution decide whether some other advantage of a non-stacked layout is worth paying for. That’s the same general move as the costing model above — turn a rule of thumb into a number the fitness calculation can weigh against everything else, rather than a constraint that overrides it.

Creative Commons License

Last updated 16 September 2026.