Fragments

The following fragments are extracted from various emails about Homemaker over the years, they contain lots of information that doesn't appear anywhere else, so it has been pasted here.

On first results with the software

The project is an evolutionary machine for adaptively designing domestic buildings, it is based on an adaptable form language and uses Alexandrian patterns to drive selection. There are lots of other aspects to it, but one of them is that it validates the theoretical split between form languages and pattern languages. It also, I hope, demonstrates that an adaptive method is quite capable of creating buildings that are indistinguishable from historical domestic buildings.

There is a lot more to be done, I can see myself working on this for a long time to come. I've started documenting the project, if you are interested in reading more, there is a link to a PDF at the bottom of this page at the code repository: https://bitbucket.org/brunopostle/adaptive-design/wiki/Home

On further results

It's getting to the point where it is evolving houses with a sophistication that I would have some difficulty reproducing by hand, though there is a lot more to do. To give you a feel for where this is going there are some images of generated buildings at the end of this updated PDF: https://bitbucket.org/brunopostle/adaptive-design/src/default/urb.pdf

On sharing work in progress

Bear in mind this is all experimental research - The ultimate aim is to find a way to create a humane architecture that actually outcompetes the lazy twentieth century method of designing buildings, but it isn't there yet!

On possibility of being an interactive design tool

Yes definitely it has a potential as an interactive aid, for now I'm concentrating on getting it to stand up as a working 'engine', this wasn't something I knew could even be done when I started. So for now it builds for a generic set of patterns rather than particular people.

To give you an idea where I see this fitting in, I've just read Chris Alexander's Battle for the life and beauty of the Earth, it is full of great stuff: negotiating a list of patterns with the users of the college, insisting on hiring a project manager with a fixed budget to hire subcontractors rather than engaging a main contractor, and laying out the site by walking the landscape and marking it in-situ.

But there is a bit in the middle that troubles me, after doing all this great stuff, the team retreat to a studio in California and design the buildings using scale models - Like an architect - The solution they come up with uses extensive modularisation.

Now I understand this, there is a point with complex or large problems where it simply isn't possible to hold it in your mind unless you break it down into repeating modules - This is the essence of how we do so many things as modern humans, this is how I do software to keep it manageable.

However this is definitely not the process that great cities evolve, where each building is created to best-fit its environment, but where the environment itself consists of buildings that have been created to best-fit their environment - A process of continuous feedback.

So, I don't expect to do better at designing a single one-off house than a 'good' architect, I know people who can do this adequately. I also don't have any grandiose dreams of building entire cities. But there is a place in between, building a group of houses where each one is different, but where they all fit harmoniously to each other and to the city outside - I know that no single 'designer' can achieve this, the evidence is all around, but I think that it is doable through huge amounts of iteration and evolution.

That was longer than I expected, these are all old ideas so I hope you don't mind hearing them again.

On resources

Basically I'm serious about this project, it isn't an academic plaything. Something like this needs to happen for the way we build buildings to change. My situation is that I have a job and a family so this project just gets a few hours a week, if I'm lucky. What I need to do is to take it to a point where it is good enough that it can earn income somehow, then I can give it more time and develop it faster. In the long term I'm very ambitious for it, it's a very practical and scalable system.

On the daylight model

A quick update if you are interested, I need to write this stuff up but need to find the time, some images: https://secure.flickr.com/photos/brunopostle/sets/72157633382704028/

Basically I'm now 'growing' these buildings in a daylight field. So in addition to the other pattern language patterns that drive the evolution, the buildings now adapt to fit the daylight field, but in turn they are changing this daylight field itself by being present, so affecting the growth of surrounding buildings in a feedback loop.

The varying floor heights you can see in the pictures are not random/arbitrary, these are being optimised to catch daylight (interestingly I'm seeing higher ceilings for lower floors, but there is no code in the system intended to make this happen).

More on the daylight model

I've been slowly working on the code and have added a daylight field - each building alters the environment for all the other buildings, in turn each building adapts to fit this changing environment as best it can (like trees in a forest). Anyway the results are quite interesting: https://secure.flickr.com/photos/brunopostle/sets/72157633382704028/detail/

Note that none of the variation you see in these images is 'random' or produced for picturesque effect. The only arbitrary thing here is the plot boundaries, everything else comes from adapting buildings to best-fit the pattern language.

On creativity

Even commentators who have a really good grasp of what is wrong with 'architecture' have this idea that the solution is going to involve lots of mystical voodoo - i.e. If only buildings were designed by the right enlightened people instead of the wrong ignorant people then we will get better cities. My project undermines this kind of thinking by saying that designers are just not very good at this kind of thing.

There is some agreement that the whole problem revolves around this dodgy concept of the 'architect' who manifests his artistic genius into buildings, but the solution is always that the designer needs to become some kind of ego-less all-knowing zen master who will then do the right thing not the wrong thing.

People can't let go of the idea of the 'creative spark' without which a thing is lifeless, but this is a religious concept and doesn't have any basis in reality - Evolution created life through trial and error, there was no creation or genius or designer, life is not a work of art. This idea of an act of creation is a deeply ingrained concept, removing the creator doesn't leave you with something hollow and dead.

On an animation showing evolution of a building

Here is an animation showing a single building evolving over a thousand generations, about 130000 individuals in total: https://www.youtube.com/watch?v=nxBwMdERFxQ

This doesn't show the whole population, what you see here is a procession of the 'fittest' at each stage, so when there is a sudden jump there are ancestors to this event that you can't see.

Also not visible is the environment field shaped by the surrounding buildings that is influencing the growth. When it makes small changes you need to imagine it is trying to find the best shape and location relative to its (unseen) neighbours.

Some pictures of a cluster of buildings that grew within and in turn shaped a daylight environment field (this is actually the environment for the animation above): http://www.flickr.com/x/t/0091009/photos/brunopostle/sets/72157633382704028/

Another introduction to Homemaker

It is basically an evolutionary machine for designing houses and other domestic-type buildings. It uses Pattern Languages as fitness criteria, so it isn't like some fractal geometry generator, the designs are 'real' habitable buildings. More than that, I'm convinced that something like this is how buildings need to be designed in the future - there are all sorts of aspects of architectural design that are much more suitable for a computational approach - i.e. you get better buildings.

I have a paper that has been accepted by an architectural journal, but who knows when that will be published, other than that everything written is very technical. And since this is basically a Free Software project it feels like I ought to put it out there properly.

Some pictures, this is 100% generated, though I did pick the viewpoints in Blender and click 'render': https://secure.flickr.com/photos/brunopostle/sets/72157633382704028/

The code is all on bitbucket: https://bitbucket.org/brunopostle/urb

On BIM/IFC building models

The plan is to get this to produce IFC files since the data model should be compatible, but each time I look at the spec I don't know where to start...

On a modular architecture system

You can find millions of words written by architects on this sort of stuff, modular, pluggable buildings etc...

But it is all aimed at creating fantasy megalomaniac megastructures. Considering or critiquing actual existing modular buildings, i.e. caravans, is beneath them, it's not 'architecture'. If they did look at a caravan, they would realise that its essential and unfixable crappiness is entirely a result of it being modular, so they don't look.

'Architecture' has to be recognisable as such in the pictures, the pictures don't work unless you have these exact features: minimalist detail, bold geometrical shapes, repetition and monumental scale. I know this because I'm good at it, if you leave out more than one of these things people won't notice there is any 'architecture' there - They will literally turn the page or walk on by.

The purpose of this kind of 'architecture' is only to attract attention, and it succeeds with this perfectly.

On P2P urbanism - vernacular architecure in the Alexander tradition

Salingaros co-wrote the great 'architecture as more than the sum of its parts' article.

I collected some links to a series of his articles, worth reading, though long: https://bitbucket.org/brunopostle/urb/wiki/Metropolis

On design patterns in architecture and software

I've been asked to write an article on my (building evolution) software and ended up writing my thoughts on the reasons why design patterns haven't fed back into architecture - Basically: most building problems relate to fitting stuff into finite spaces, and most software design problems are not space limited. https://bitbucket.org/brunopostle/urb/wiki/Patterns

On what kind of thing Homemaker is

Nevertheless the stuff I'm doing doesn't fit into neat externally imposed categories, it isn't graphics and it isn't CAD. It's architecture, but not in the commonly understood sense.

On evolutionary theory, and custom design

I need to explain terms like population and compact city - 'population' is very specific; genes exist within a group, and move around within that group, the individual creatures are not the genes.

I'll look at the 'eugenics' bit, but this kind of where this is at: after all I am breeding houses and exterminating the ones I don't like...

Yes I should add stuff about people building their own houses as this is implicit and very doable. But there is a problem with this: houses last hundreds of years, this is almost a requirement for an ecological architecture. We live in a house that has been home to dozens of people who are now all dead, their needs are irrelevant to us. It is more important that a house is adaptable than that it perfectly suits the first occupant - or at least it should be both, with the emphasis on the adaptable bit. Mas Marguerite is much more adaptable than our house, the original masm occupants had a completely alien culture, but it still works because the rooms are good, fit the climate, and are usefully arranged.

On the word 'eugenics' and technological determinism

I didn't use the word eugenics, which is the idea that directed evolution

• should* happen to *people*. Directed evolution isn't so controversial with growing roses or broccoli for example. Houses are not even alive, and a simulated house is even less so.

The 'somebody knows what is right' bit in this case is the Pattern Language, which is transparent in action; and where each pattern has to be justified and to be open to being disproved.

I'm also wary of being specific about how this technology *should* be used, I have my own ideas of course. But since it is utterly useless for creating battery hen style architecture, I'm not too worried that it can be used to make people into battery hens.

Battery hen architecture is supposedly 'more efficient', but we all know that it isn't when you consider the whole system - I'm considering a larger system in a more scientific manner, and what falls out of the end of the process is not battery hen architecture.

On Christopher Alexander's book, Battle for the Life and Beauty of the Earth

Yes, it's a good book. I'd recommend it as much shorter and more to the point than some of his other stuff. It is basically the story of building a school in Japan, which is clearly an excellent place. I love how the brief from the school head was to just build an 'ordinary' building, something that nobody else was prepared to do.

On the structure of the 'genome' and space constraints in software vs. buildings

Each floor of the house is a binary tree, which makes crossover and mutation really easy. This binary subdivision also incidentally produces buildings that are structurally sound, which reduces the solution space enormously - not having to consider unbuildable buildings saves a lot of time. In biological terms the tree is the genotype and the house is the phenotype. The tree doesn't look anything like a house, it is more like the instructions for unfolding a house.

It does interiors at the level of individual rooms, connections between them, and connections to the outside world - But the evolution stage only provides space for windows and doors, stairs etc... they are actually placed using coded rules.

My ideas about Pattern Languages and Design Patterns come from actually trying to do this stuff (I trained as an architect a long time ago), working with design patterns is so much easier than designing buildings with patterns - Alexander says you have to become some kind of zen master at a higher level of consciousness, and I believe him, it really is that hard.

On the 'great man' view of creativity

What a 'designer' does is something like this: he internalises all available information, he thinks really hard, and he produces a design as a creative act, the better the designer the better the creativity and the better his resulting design.

I guess what I'm trying to show here is that this 'creative act' model of design only works in simplistic situations, hence the prevalence of buildings that work better as gestural sculptures than as buildings.

Our geniuses are not good enough, or they are just not given the opportunity to demonstrate their genius.

This is the architect's view, "if only I was allowed to let my creativity be free". You also hear that the problem is there is not enough "good design", which is ultimately just a sales pitch for the profession as a whole.

On making incremental changes

Another bit of 'agile' wisdom, which at first sight seems illogical, is the idea that when making these incremental changes, it is best to choose the change that makes future changes easier, rather than aiming directly for the goal.

This only makes sense when you look in retrospect at the stages that went into a successful project. Maybe I should have paid more attention to this principle when writing the article.

On Alexander's ideas for software that implements Pattern Languages

"The software is freeing, liberating, allows each person individual control and decision making power to do the right thing, and to create living structure, locally, wherever they are."

These are Alexander's words. This is his vision, but I can't claim my software is already freeing when it hasn't been used yet.

On Homemaker being used to design buildings

I don't know how to put this into words without claiming that this software is ready to go. It is also not as controllable as you may expect - it's a bit like how you might want that rose tree to grow into a particular shape, but then the rose tree has different ideas, it sees the world differently.

On there being no straighforward way to use Homemaker

It is aimed at software people, as I'm not really interested in convincing architects to adopt any of this stuff, from past experience it would be a waste of time.

Also, it is quite appropriate to feel confused by technology, I'm confused and I've made it my business to pay attention to all this computer stuff all these years. Here we are blindly letting ourselves be absorbed into a total worldwide machine designed by Ayn Rand disciples, we should be paying attention.

On pod-architecture that keeps coming up

This 'pod' idea is a recurring theme, it is almost the accepted vision of the future of architecture for a huge number of people. You often see architects proposing structures made out of shipping containers (it doesn't work, I've tried it!). The wikihouse project is interesting, and they do understand the 'open source way', but it is along the same modular lines; I'm all for empowering people to control their own environment, but architectural modularisation is API lock-in.

On the Homemaker/Urb workflow

I tried explaining how it works, but people wanted to know why it is necessary - the assumption is that architects are creative professionals, and a computer could never do better - but I can see the potential for doing a whole range of useful things that an architect sitting in an office can never do.

The Urb workflow is currently a pain: running lots of command-line tools and typing in coordinates manually - does this sound familiar for a free software project? I know what I need to do, it will be quicker to fix the interface than document the old one, but you have probably heard this before too...

Though it does already design credible buildings and generates 3D geometry in Collada and IFC formats. It would be great for creating FPS game levels, something I hadn't really considered.

On the possibility of summarising contemporary architecture

Architecture theory is a horrible confusing mess, I have eventually come around to the opinion that it is basically rubbish - Which is why I think it is such an easy target for replacing wholesale.

It has obfuscated texts, like medieval alchemy; and an institutional hierarchy that enforces conformity to approved ideas, like Lysenkoism. This kind of thing is all very fragile once people outside start doing things in a better way.

So I'm probably not great at introducing 'architecture'. The thread of architecture theory that I think is least crazy is nicely summarised in these links: https://bitbucket.org/brunopostle/urb/wiki/Metropolis

On the reason why Homemaker exists

I wrote this as something that was missing: https://bitbucket.org/brunopostle/urb/wiki/Advocacy

This is the background to the whole project. Housing is such a mess, all the existing models of development are unacceptable to most people for one reason or another. Something this radical is needed to break the logjam.

I was going to call the (incomplete as yet) tool that manages the process 'homemaker'.

On the paper written for the Journal of Biourbanism

It is an academic article so I made it technical, it goes into enough detail that a programmer could reproduce the system.

The paper is mainly a list of all the essential methods, I want them in the public domain so somebody else can't patent them.

I'm not sure what is next. The software needs to be used on real building projects in order to improve it.

"In his An Adaptive Approach to Domestic Design, Bruno Postle discusses the need to design ordinary domestic buildings by use of Pattern Language in order to gain design optimisation. Thus, the author attempts to support the idea that, evolution and mutation in domestic design shows that a Form Language through evolution has developed as Free Software; the results obtained by this software are comparable with historical built environment which followed informal and flexible urbanism and not rectangular and very restrictive grids of master planning. Patterns of informally created cities reveal that these were put in place to suit the day-to-day needs of their citizens; an evolution appears as co-evolution between neighbouring buildings. The author discusses with diligence basic pattern language of ideal domestic design and also provides formulas to measure fitness criteria challenged by human needs against cost of life; he also discusses and explains evolution strategies by possible combinations of typologies seen as crossovers. He provides a series of mathematically supported graphs related to typologies/growth of cities and increase of population. Indeed he provides fine examples of graphs related to a fittest single storey house after 640 generations! This proves that patterns play an everlasting role in urban developments and human life as long as life exists on this planet and beyond." http://journalofbiourbanism.org/2014/05/07/editorial-3/

On the connection with the work of Besim Hakim

I'd really like to make use of Besim Hakim's work. It is interesting that he imagines these codes rescuing existing historical towns, whereas I think that they have potential to guide future development.

Another thing he discusses that I really want to investigate: my software produces an optimal house for its environment, and by iterating, multiple houses form the environment for each other. An analogy would be to trees growing in a forest.

However there is no explicit 'golden rule' here, the buildings are maximising their own benefit and only interacting with the others through feedback. In a real forest trees can grow absurdly tall like this, even trees of the same species compete for daylight and access to the forest canopy.

Now I have a hard 'four storey limit', so this exact process isn't going to happen.

But I can (and always intended to) add a 'golden rule', it would be fascinating to do a controlled experiment to see if we get better cities through being considerate - Because a lot of people seem to believe we should all be like trees in a forest.

Articles written

https://bitbucket.org/brunopostle/urb/wiki/Patterns

https://bitbucket.org/brunopostle/urb/wiki/Homemaker

https://bitbucket.org/brunopostle/urb/wiki/Advocacy

https://bitbucket.org/brunopostle/urb/wiki/Overview

On 'form languages' vs. 'homemaker'

'Form Language' has a very specific prior meaning; it is everything that is part of a 'construction technique' that isn't a 'pattern'. So I can't use it as the name of the software. The software is called 'Urb', but this is mainly so I don't have to type too many letters. I have an automation bit that will be called Homemaker, but this doesn't actually exist yet, I think Homemaker is a good name.

On use of the software

This technique can be used for profit, if some developer wants to build a city using this software then I can't stop them, at least they will be acting in a less destructive way.

But it is resistance to atomisation: buildings are designed in a way that compartmentalises and isolates people; public space is privatised; personal relationships have to happen in a space where you play by rules set by architects, traffic engineers, Costa Coffee or Facebook; any activities that can't be resold or mediated by a third party get excluded.

In this context is it a subversive act just creating houses that have front doors on walkable streets - that are walkable because the buildings are compact - you can't have walkable without some way of designing compact buildings, so this is where we have to start.

On architectural straightness

Straight, square and flat are not necessarily bad at a human scale. But there is a real problem of 'design' replacing domesticity with monumentalism, relentless repetition, bold eye-catching shapes and minimal detail - These are attributes of advertising and propaganda that have colonised the architectural profession.

On describing Homemaker

I can't claim the software is 'rapid', in fact I can only describe it as slow - the good news is there will be lots of ways to speed it up. 'Inputting preferences' is too techy, also though the software is completely customisable I have no idea how this will work in practice.

Is building design destined to forever be the exclusive domain of architects, planners, real estate agents and developers? Might there be a way to sidestep the relentless repetition and tedious forms of 'designer' architecture? Maybe if we were given the ability to design buildings ourselves, we might choose to participate in constructing compact, humane cities that promote community rather than isolating us from each other?

The Homemaker software establishes a new technique for the design of domestic buildings. It lets anybody assemble a Pattern Language that represents both general human needs and specific preferences; and then uses evolution to find a building that best fits this Pattern Language in the context of neighbouring buildings, of daylight and with minimal construction cost. This approach can create ordinary buildings that are diverse, dense, practical, adaptable, humane, ecological, and maybe as a result, simply better.

On evolution requiring no inspiration

I clarified this: evolution in nature happens through small incremental changes, there is no inspiration involved.

On the software being unusable

I'm not being specific about the role of users, because I don't know, and don't want to conjure up some utopian fantasy world of self-builders that totally ignores the economy we live in.

On the definition of a Pattern Language

The pattern language is a way of representing human needs.

On academic publishing

The article has been published in the Journal of Biourbanism: http://journalofbiourbanism.org/2014/05/07/an-adaptive-approach-to-domestic-design/

On running a business with Homemaker

I really want to do it for real, so the MVP is a useful aim, though I might already be there (depending on your definition of viable).

I'm also having trouble finding the words, it's so far out of the common understanding of what 'architecture' is or 'should be'. The typical reaction is polite silence, I may be better off pretending I'm designing them myself.

The overlap between people who can code and people who know about buildings is tiny (also I'm not helping by writing the whole thing in Perl and using a 1970's alternative culture classic as inspiration).

It is not like I haven't thought of it, though I don't know I get from here to there.

There is a clear business offering architectural design as a service. The great thing is that even though the design bit is computationally heavy, the system is completely automated, so it is totally scalable, i.e. just fire up as many EC2 instances as necessary to handle multiple jobs. Also computation is only ever going to get cheaper.

It is also completely priceable - when an architect takes on a job they really have no idea how long it is going to take, but this is predictable (to an extent). Ultimately the construction cost gets priced too, and you can do things like trade-off the (real) cost of running more computation against the benefit of getting a better design.

The main bottleneck is finding clients, getting their requirements, surveying sites and all the other stuff an architect has to do before they start. The other bottleneck is that it doesn't do the detailed design - from picking doors to placing light switches - this is labour intensive and would need to be offloaded, ideally to building contractors. But then I already have the code to create the BIM/IFC files needed to make this offloading as painless as possible.

The risk is that I'm doing this as Free Software written by not the best programmer in the world, and somebody else comes along doing something similar with a better operation and cleans-up. The other risk is that nobody actually wants compact ecological pedestrian cities designed using pattern languages, but then I have to have confidence that this is the right thing to do.

Offering a service on top of free software works for a lot of companies. Though obviously you have to maintain an edge, which initially is solely being the first mover. Ultimately you collect proprietary information, such as construction pricing, which can't be available as part of the shared free software code. Also being the developers of the software puts you at the top of any list.

This isn't going to be the kind of software that you can sell in a box or put in an App store, not without a complete rewrite and a massive investment in a GUI. It is also very slow, so you need access to a computation infrastructure to getting it working in the first place.

The risk is not that somebody takes the code and sets up in competition offering a similar service, there is plenty of design work to go around, taking any appreciable percentage of the architecture market would be spectacular success.

The risk is that someone throws a lot of developers and marketing into building a competitor, which is a problem whatever license it is under. There is nothing magical about the code, I'm not a clever programmer, the innovation is simply with combining evolutionary computing together with pattern languages - Knowing it can be done gets you most of the way there.

It is free software, partly because I need real coders working on it (none yet, hmmph), but also because I think this is important and I don't want it to fail (whether I benefit or not).

Clarifying that, a competitor can only market themselves by saying 'we are doing the same thing as these other guys who invented it' - this kind of marketing works both ways.

On step-by-step instructions

..and finally a walkthrough: https://bitbucket.org/brunopostle/homemaker/wiki/Home

On Professor Besim Hakim

Professor Hakim's work is very relevant. And his observation that the mediterraneam/islamic codes were proscriptive rather than prescriptive, meaning they are not recipes for building houses, rather they tell you when you are doing it wrong - much like a pattern language, there is a lot of overlap here.

The codes that relate to larger scale urban design are fascinating, but I'm not convinced that I want anything to do with a software approach to masterplanning, so this would be out of scope for me.

I also enjoyed discovering that a large proportion of 'sharia' law is what we would call 'building regulations' or 'planning guidelines', and good ones too.

On the use of A Pattern Language

It uses patterns from A Pattern Language as fitness criteria - What this means that the evolution process produces a huge number of different potential buildings which are each compared against the pattern language, 'bad' designs are discarded and 'good' designs (as judged by the pattern language) are used as raw material for further evolution.

I guess what I'm trying to say is that there is no design process here, the software really doesn't understand what it is trying to do, but what falls out at the end is a building that 'fits' the environment of the pattern language, the geometry of site, and the daylight field of the given latitude.

The pattern language it's using is a subset of APL for the time being.

On contrast with Arabic-Islamic cities

To give you an idea, the software I'm working on has so far been concerned with resolving daylight conflicts between neighbours during the adaptation process - This shows my northern European context. The Islamic tradition is much more concerned with privacy, indeed it was interesting to read that there is no principle of right-to-light in the Arabic building codes. So there is lots of work for me to do.

In the old part of Almuñécar. The urban fabric here seems largely intact, the fina areas are very much in use, but there are few sabats - either these never existed or have been removed by some process over the years.

These urban forms are often written off as random and irrational, and their attractiveness is purely romantic and emotional. But actually they are superior, and this superiority can be proven.

I'll try and list some limitations of my approach:

It doesn't arrange plots or streets. I can see how a software approach could simulate the process of creating roads, subdivision, and moving boundaries to expand and contract plots, but I had to start at the lowest level of rooms, and so the software assumes each plot boundary is fixed and given. Adjacent buildings interact with each other and the street, but boundaries don't move.

(It does however work fine with non-rectangular plots, which I think is critical to working with the free-flowing layouts of real towns, the modular approach you used in your paper requires a gridiron city - I hope you agree that these gridiron layouts are inferior - Actually I think this is something else that can be proven with the software eventually)

The interaction between buildings is entirely to do with maximising daylight, I have a plan to do the same thing for privacy and even for 'views' (the Byzantine 'sea view'), but this means that currently the buildings usually look outwards rather than looking inwards - It tends not to produce courtyard forms as a result.

It needs a lot of computation power. This is available and affordable through online services, but my effort currently is with fixing bugs with extending the software, there is so much still to do and I have limited spare time.

On modernity and scientism

I'm taken by the idea that architects are pursuing an imagery of modernity that is largely the result of watching too much science-fiction, that science fiction visionaries are always completely wrong about the future, and that maybe an actual scientific approach to building design that uses real modern techniques doesn't look anything like the modernist fantasy. Obviously these ideas have been developed before, but I can provide some concrete images to go with it. I found an article about how an architect was using some advanced software to design a city in Turkey, but if you delve into it, they are using a tool that was developed to draw flowing hair in computer animations, and then tracing over these pictures of hair to place the streets - Basically they can't really use actual software that designs better buildings, because better buildings wouldn't have the look they are going for.

On selling the software

To change the way that buildings are made, the new way of doing it has to make somebody a lot of money or it will remain just an interesting academic exercise. Although I think the software is an achievement, I'm uncomfortably aware that it has been developed in abstract to my own requirements, and that if it is to be a real commercial tool it needs to be shaped by use on real construction projects. So at some point somebody needs to take-on some architectural design work and use this to force development of whatever necessary changes and features it needs to become something of general use. So the conundrum is that to in order to make money from it, I have to find a way to make money from it first.

On designing building services in Homemaker

The aim is produce resilient buildings that are adaptable for future use, and there is a point where too much fine-tuning of the services produces buildings that can't be changed by the people who live in them. Evolution is also a process of adaptation, so fragile designs like this tend to be evolutionary dead-ends and get overtaken by more flexible forms.

The way the design of services needs to work is similar to the way Homemaker currently designs stairs; the fitness function in the evolution engine checks to see that a stair can be legally fitted into the space, but the actual staircase design of placing treads and risers is done with procedural code afterwards.

Traditionally, houses tend to be designed with the plumbing on one side, so you often get room layouts with bathrooms over kitchens for example, but this is for cost reasons - it doesn't necessarily make the house any easier to use. So the way to deal with this is to assign a cost to all that extra plumbing and let the software allocate resources - maybe other advantages of a particular design outweigh the expense of duplicated plumbing.

On generating Bill of Materials data

It currently does a budget cost in the fitness equation; the areas of walls, floors, roofs etc.. are added together, so designs that use more material are scored down, but there is a better way to dproduce a bill of materials - If we can export a full BIM model that represents the building, this can then be dropped into existing construction industry workflows where this kind of construction information is handled extremely well.

On exporting 3D models

The DXF and Collada geometry export are equivalent as they are created by the same code, this geometry is also used for STL output and is clean enough that 3D printing should just work - I'm so busy doing other things that I haven't got around to printing any houses yet.

The IFC export is much more interesting because you get more than simply a geometrical description: walls are described as an assembly of materials; doors and windows are understood as components with properties. The kind of houses designed by Homemaker are a really good fit with this BIM (Building Information Modelling) technology, but so far IFC export is incomplete, the files are valid, but they are missing some important elements like roofs and stairs.

On the software being rather slow

Everything is written in Perl, so rewriting some or all of it in a more suitable language should vastly increase the speed.

The design of the evolution engine itself is loosely based on my reading of some Wikipedia articles. Amazingly enough it just works, but there is a whole field of Evolutionary Computing representing decades of research that I'm only vaguely aware of - probably we are missing a trick or two.

On future improvements

The form of the buildings is largely determined by access to daylight, but this is a very northern European way of doing things, other cultures place more emphasis on privacy or simply having a distant view. So the same approach taken for daylight needs to be extended.

It is one of those tools that will never be finished. The fitness calculation is based in a subset of Christopher Alexander's Pattern Language, but there are important patterns that haven't yet been implemented.

The 'style' of the exported building geometry, the detail of doors, windows, mouldings etc... is simply copied from my own house. It is a nice, elegant and flexible style that appears all over the UK in historical buildings, and I needed something quick to get the job done, but there are obviously many other ways of doing things - The software needs some sort of way to define building styles.

The evolution engine is currently home-rolled, I plan to experiment with replacing all this code with the Algorithm::Evolutionary module from CPAN.

The placement of windows and doors could be more sophisticated, currently the code just fills a wall with as many windows as it can - which works remarkably well visually, but needs to be more considerate.

There are lots of bugs that need fixing, but what it actually needs is to be tested in real situations, this is the way to uncover important limitations and drive the direction of future development.

Of course the last thing on the road map is to take over the world, or at least most of it :). It isn't just me, there are a lot of us who think that the way we design buildings today is a disaster on multiple levels, that urban sprawl requires ridiculous quantities of energy to maintain, and that a compact architecture that fits itself to the world we have would be better suited to humans too. Maybe Homemaker won't succeed, but something much like it is needed - designing truly modern humane buildings is hard work and we need to create new tools to be able to do it.

On the virtues of organic shaped buildings (in the Valerian comics)

Mézières has a nice eye and clearly doesn't have much time for the international style, but as a prediction of the future it was no more accurate than any of the others.

The Valerian look is quite buildable so long as you accept it requires multiple levels of detail. I get asked by architects to help them build amorphous 'blobby' buildings, since I really know how to make this stuff, but they are fixated on an unobtainable seamless look which ultimately ensures that these projects don't happen. Either way, curved shells like this are fundamentally non-adaptable, there are good reasons why walls are vertical.

I think they get these ideas from CGI spaceships in sci-fi movies, but I'm so detached from architectural fashion I'm not sure where it comes from.

On pattern languages and form languages

The insight [from Nikos Salingaros] that I found most useful in this work, is the distinction between pattern languages and form languages.

So in my project I was stuck with just how to use A Pattern Language, until I realised that there are three classes of patterns in the book:

Forms, these are the shapes that are are reused and adapted, obvious ones are '191 The shape of indoor space' and '50 T-junctions'. These are the words that can be put together into a description of how to build the physical form of a structure, close enough to the concept of genotype. The actual physical form is the phenotype and is something else altogether.

Patterns, these don't tell you how to build anything, they only tell you when you have got it right or wrong. The typical pattern is '159 Light on two sides', this really doesn't tell you how to design a house, all you can do is try layouts/phenotypes and see if they satisfy this light-on-two-sides fitness criteria.

There is a third class of patterns in the book that are much more like traditional rules: '200 open shelves', or '239 Small panes', they are all phrased as "in this situation, do this action", most software design patterns are like this. These are generally smaller scale patterns, with buildings these patterns can be safely left until after the overall form has been fixed.

On recreating traditional towns with Homemaker

Although the Homemaker system uses evolution and produces buildings that closely resemble traditional architecture, it doesn't simulate the habitation of buildings over centuries.

If I understand correctly, you would start with an empty landscape, add a road or maybe a crossroads, create some plots of land around this road and build some buildings, then simulate growth of the settlement by subdividing land to create new streets, plots and buildings, replacing buildings as they grow older, and exchanging parts of buildings between neighbours to accommodate household growth. As I see it this is the level of complexity needed to produce a credible result, anything other than this and the result won't show the 'scar tissue' that is the indication of a town that has history.

Homemaker currently just does one of these things, which is use a pattern language to design houses in context for empty plots of land. All the rest of it would need to be done by manually interfering with the model at every stage.

On A Pattern Language being a product of the 1960's

The set of patterns in the book have aged a bit, are not specific enough and there are not enough of them.

There are one or two patterns, say '186 COMMUNAL SLEEPING', that some people might object-to as being a product of the time, but on the whole they are still quite valid. Nikos [Salingaros] mentions a common criticism that says that cities don't need to function for pedestrians any more, and that therefore most of the patterns are irrelevant - but then this criticism itself now seems a bit antique and twentieth-century.

Some of the patterns are nicely specific, such as '167 SIX-FOOT BALCONY', but this isn't enough for my purposes. For an adaptive design method I need a 'five-and-a-half-foot' balcony to be less acceptable than a 'six-foot' balcony, but still not ruled out altogether - Homemaker uses a Gaussian curve to model this gradient, so I need answers to questions like 'how much shallower than six-feet does a balcony need to be to be half as good?' (currently I use 2.5 metres with a sigma of 0.7 and it seems to do ok, but this kind of thing can be done without guesswork).

If we need similar patterns for all aspects of building, then this is a task can never be complete. So it definitely needs to done in the open, collaboratively, using evidence from the real world.

These kind of questions don't seem to get asked much, but my code is full of numbers like this that I have pulled out of thin air.

On Pattern Languages

Regarding pattern languages: Design problems that need to occupy a finite space are 'hard' problems, and trying to use pattern languages at the same time just illustrates how hard they are. Using creative inspiration to solve these kind of problems is fantastically unreliable - so when architects resort to modularisation or a strong overriding 'concept' to gloss over the bits that don't work, it is a very understandable reaction - they need to be able to deliver a 'product'. It is also frustrating to see buildings, say Frank Lloyd Wright's houses, that really do appear to be the successful result of a creative spark - but for me packing the spaces and materials of a building together in a way that satisfies a pattern language is a different kind of thing to writing music or painting or sculpture.

On Alexander's Fifteen pRoperties

Though I have a good feel for how I want to use pattern languages, I don't have any idea how to fit in Alexander's fifteen properties, or even if I should - The properties explain a lot about what I have been trying to achieve with say designing decorative patterns, but they don't seem relevant to the plan/layout of a building, especially since people don't perceive buildings as a plan (Alexander is very vague about whether they are relevant to a building plan). But then I think I see some of the fifteen properties in the results of the evolution process anyway - Maybe the properties are just something that emerge from life-like processes.

On the scope for Homemaker

Regarding the scope of Homemaker: Léon Krier did a useful drawing showing how a city is made from a 'res publica' and a 'res privata'. The work I'm doing is not at all relevant to the 'res publica' bit, unless somebody else notices a connection that I'm not aware of. I also don't have any insight into laying out streets, blocks and plots beyond the rules that people like Alexander and Jacobs have described - So I don't envisage any kind of machine/computational approach to 'masterplanning' - which is probably a good thing.

On the Vision Thing

I'm interesting in describing some kind of vision of the future; for me an ecologically sane world involves people living in walkable compact cities, and the best kind of walkable city has an organic network structure rather than a gridiron or tree structure. But this kind of city topology is very unsuited to modularised repeating buildings - So a tool, perhaps something like Homemaker that handles a situation where every plot is different, is a key technology to make this happen.

But maybe it needs to be framed as a 'superior' technology. I like to dismiss buildings that look like spreadsheets as being designed with spreadsheets, but in reality the reason why they look like this is that the organisations that inhabit them or produce them exist as spreadsheets with people attached. Such an company has to think with this kind of logic: X number of people, => Y floor area, => Z number of identical floors - The 'spreadsheet buildings' fall out of this process.

Homemaker uses a more sophisticated computation and the resulting buildings have a very different character, but ultimately both systems have a 'bottom line' that can be compared.

On architecture theory being impenetrable

I think the approach based on the Pattern Language / Design Patterns connection is a good way in, at least for people who already have a programming background.

On actually using Pattern Languages in building

This bit is at the core of the problem I'm trying to solve: starting a building project by collaborating on a project Pattern Language is clearly excellent, and I like Alexander's approach described in 'the Battle for the Life and Beauty of the Earth' of walking and physically marking out the site - the bit I feel needs fleshing-out is the part where the architect/designer takes all this input away and somehow comes up with a design.

As an aside, I have never been involved in a building project that has been marked out like this, but I have done a similar thing with temporary structures and found that it didn't work - Looking back I can see that the problem was that we had existing modular units of a fixed size and we were trying to fit them into a site, so instead of standing in the corner of a field and saying "this would be a perfect place for a bar area", we were constantly asking "can we put our 10x10m bar structure here?" - This kind of question is a thousand times easier to answer by shuffling outlines on a plan. So if the marking-out in-situ technique is going to work, you can't have any preconceived ideas about the exact sizes of structures you are going to build.

On reducing everything to numbers

If I was trying to critique my project from the outside, this is where it would seem most vulnerable. It is very easy to say that "you can't reduce everything to a number", and I don't have a great response.

On the one hand I'm just trying to be specific where other people just hand-wave or say "pay no attention to the man behind the curtain", numbers are a useful way of looking at the world. On the other hand I would try and rephrase the criticism, I might say that "you can't reduce everything to a transaction" - a house designed with a collection of 'if this then do that' type rules, or a house designed where the fitness criteria was 'market value' rather than a Pattern Language is clearly going to be lifeless.

A difficult question for me might be something like "how do you quantify a 'good view'?", my only answer is that I would give it my best try and see if it works. You can see I'm anticipating criticism here, but I haven't yet really had any negative reactions despite having been doing this for years, I think people are just being polite and not saying anything.

On the subject of Homemaker

Homemaker is an open source project based on the idea that we currently design buildings the wrong way around: When architects create a house design and repeat it, they miss an opportunity to make buildings that actually fit their environment.

This project represents a completely different approach where every design is necessarily unique, where evolutionary techniques of mutation, crossover and selection are used to create compact, high quality buildings that minimize materials and land use. It works already, and the houses are great, but it needs support to be taken to the next level.

There is lots more to it: Christopher Alexander's Pattern Language anchors the design throughout, there is a sunlight model that means every house is arranged to maximize daylight, the designs are structurally sound, and it will be possible to extend the system to work with different climates and construction techniques.

Three things to say about the Homemaker project

One, it turns out that computers are actually quite good at planning and designing buildings. A world where every house is designed individually can happen - This would be a big change for the building industry. The way to get this to work is through massive computation, evolving the design through mutation and crossover hundreds of thousands of times. This is the Homemaker software.

Two, to drive this evolution we need a framework that describes buildings, spaces and how they need to work to meet human needs. This framework can be found in this book, A Pattern Language, by Christopher Alexander, published in 1977. The patterns in the book are a perfect fit as 'fitness criteria' in an evolution engine.

Three, the result of this fantastically ruthless process of evolution, where nothing is considered other than maximising human needs and minimising material and land use, closely resembles the buildings we find in historical cities. This means, and it has been a long journey to get to this conclusion, that traditional architects might have been right all along - A very modern process produces a very traditional result.

Finally, there is a reason for doing this, why I think it is really worth being able design every house individually. Being able to closely fit buildings to small plots and to fit them to each other, while using minimum resources is a precondition for creating compact, walkable, sustainable cities.

Material created for the Buckminster Fuller Institute

My mostly-finished answers to the application questions are here: https://bitbucket.org/brunopostle/homemaker/wiki/bfi

I created a two-minute introductory video, which can be found here: https://drive.google.com/file/d/0B8mSDYtsZVj7V2JYNGlyNGNPMXc/view?usp=sharing

..and have assembled my writing on Homemaker and Pattern languages in this PDF document: https://drive.google.com/file/d/0B90VJPxwHVIvY1NmVEhQSXd6Zm8/view?usp=sharing

On tradition

My observation is that this word 'tradition' has so many negative associations, you really need to roll all the way back to the beginning and declare what a 'true tradition' is relative to a 'false tradition'.

None of this is specifically about architecture, it could apply to cooking or be pinned on the wall of a maker-space:

1. In a living tradition, we are allowed to copy what works and that meets human needs.
2. A copy is only a 'fake' when it is fraud - passing off one thing as something else.
3. In a living tradition, copying isn't duplication, we are obliged to remix, to fit, adapt and improve.
4. In a living tradition, we share knowledge in common and pass-on what we have learned.
5. In a living tradition, we are delighted to be copied, but we like to be acknowledged.
6. A false tradition has none of these things, though it may seem to be old.
7. A false tradition is a marketing device concocted to have the illusion of antiquity.
8. A false tradition is usually camouflage for the indefensible.

On concepts that should be elaborated

There is the adaptive/evolution principle, which is interesting to me in that it the result is further adaptable buildings that look nothing like conventional modernist ideas of adaptable structures.

There is the pattern language as fitness criteria principle, which I think works as a standalone idea. None of this is entirely new thinking.

The thing I haven't really written about is the form language I'm using, which is almost a complete (little) architectural theory in it's own right I.e. it is a way of looking at buildings that allows you to classify - I have never heard anyone speak of buildings like this, though I could have skipped that lecture - and clearly there are some architects working in this mode even if they don't express it in words.

On a partial theory of architecture

I'm sure none of this is 100% original, and this is just a different way of expressing existing ideas. But it seems to me that there could be some interesting mathematics found by applying graph theory to building layouts - and I've only scratched the surface.

The thesis is that there is a human building typology that recurs spontaneously much like a bee creates a honeycomb.

The first PDF has some diagrams: Fig. 1 shows a honeycomb; Fig. 2 shows the equivalent human typology, which I'm calling 'Type A'; Fig. 3 shows a contrasting typology, 'Type B'.

To be clear that I'm talking about floor plan layouts, Fig. 4 shows example floor plans for Type A and Type B.

Type A is characterised by nested subdivision of quadrilateral spaces. Type B is characterised by an overarching rectangular grid.

Figures 5-8 show a series of imaginary layouts drawn using an increasing number of 'rooms' as both a Type A and a Type B form. The red lines are the network graphs for the potential connections between 'rooms'. This illustrates that Type A is inherently more connected. The average degree for Type A nodes is consistently higher than with Type B.

Note that the 'wall' segments between the rooms form a dual graph; in Type A this dual graph has every node with a degree of 3, in Type B the dual graph has every node with a degree of 4.

The second PDF is an exercise of fitting an actual house layout to these diagrams by assigning the nine rooms listed on the right to the spaces in the diagrams. Basically it is easy to find lots of very nice house layouts in the Type A diagram, but only a handful of not so nice layouts in the Type B diagram. I can see this as a pedagogical tool, a student who has no experience designing houses might not realise it is all so easy - flashes of inspiration and creative concepts are not required. The exercise can be extended to multiple floors if you allocate an additional 'stair' type that fills the same square at each level.

I observe that domestic buildings that have survived for centuries in England tend to be Type A - They often have a complex history; a house is turned into a blacksmiths, then a stables, then an Inn, then a courthouse, then a shop, and then a house again - This contrasts with the modern architectural understanding that if you want an adaptable structure, it needs to be Type B.

I've also attached some plans of various unrelated historical buildings, note that they are predominantly Type A, though not entirely. If you consider the wall segments as the dual graph of the room network (as above), this dual graph would have nearly all nodes with degree 3, but a small proportion with degree 4. It seems that a full Type A is actually more connected than is necessary for practical purposes.

I could go on, grander public buildings seem to have had a tendency to be more Type B, but I don't have an explanation for this; and looking at the designs of contemporary classical architects, there seems to be a tendency to impose the Type B model on domestic buildings regardless.

The whole reason I'm looking at this is that I'm actually using all this stuff in the Homemaker software. i.e. I have a hierarchical tree graph (the genotype that gets mutated/evolved), this represents the hierarchical nested form language of the subdivided building layout; from this I generate the network graph of the connectivity in the building; then the dual graph of the connectivity graph represents the actual walls that make up the building itself; it is these connectivity and wall graphs (the phenotype) that are evaluated for fitness by the pattern language.

On running an experiment

I noted in the that the archaeological examples were generally Type A, but not entirely - a particular building might have mostly Type A layout, but with a couple of wall junctions that were Type B or nearly so. Homemaker currently forces everything to be Type A by having a rule in the pattern language that scores-down Type B-like forms - I'm beginning to think that this is inappropriate, as the pattern language should be all about human experience and perception - and the Type A/B nature of a building is not perceptible in-person.

So when I have the time to run the computation, I'll run an experiment comparing Homemaker with and without this rule. And since this is an experiment I need to make a prediction first: that most of the connections will be Type A, perhaps 70-80%, but the rest will be Type B, or nearly so - approximately the same proportion as with the archaeology; I would also expect the average score to be higher, since the removed pattern can only serve to lower the score. The alternative is that the evolution process actually needs Type A layouts in order to be adaptable for further evolution, in which case this will show up as lower scores.

On evolving street networks

Some years ago I did play with evolving street layouts but realised that this was a distraction from the house design task, also I don't plan on putting myself in a position where I'll be laying out towns. Here is a flavour of what I was playing with: https://youtu.be/1uJiEb84j1A

I'm very much influenced by traditional street layouts. I'm currently on holiday in a Spanish town where the streets are all no more than 3m wide, and the house is on a lot that is about 30m², we have every kind of shop and facility within 5 minutes walk. What inspires me is that this is a fully functional first world town that is 100% pedestrian. This is the kind of urbanism that requires a tool like Homemaker to pack buildings together reliably in the absence of a traditional owner/builder society.

I should explain what is going on with that animation.

It is an arbitrary network where all nodes always have three connections, this is from Alexander '50 T-JUNCTIONS'.

The code uses Djikstra to calculate travel distances from every point to every other point, the most heavily traveled paths are drawn with a thicker line. The evolution tries to straighten out the junctions into a T shape where the most heavily traveled path is the bar of the T and the secondary 'side street' is the stem of the T.

This produces an 'optimal' network with minimal travel distances, which happens to look a bit like a traditional street network - and not at all like a regular grid.

The flaw with this work is that it assumes the purpose of a street network is to minimise travel time, but this is not likely to be more than partially true.

I hadn't thought about this for years, the reason I stopped work was because I was just proving a point to myself:

Basically it seemed obvious to me that a traditional organic street network is more 'efficient' than a perfect grid because the real world has hills and rivers and trees and coastlines - any of these things are sufficient seed to force the collapse of a perfect grid - unless a planner is bloody minded enough to draw a grid regardless.

This code was me exploring the situation of a featureless plain - even here an organic network is superior to a perfect grid - or at least this is what I showed to my own satisfaction. It isn't a very elegant proof, but I suspect somebody with a good understanding of graph theory could prove this absolutely.

On graph theory applied to buildings

What I'm finding very useful is this way that the network graph of the room connections has a direct relationship with a tree graph that describes the building structure, and with a dual graph that describes the walls themselves.

On street blocks

Block size is a critical feature, I can see this near home, we have a variation of block sizes where all the liveliest bits have a block size around 40m or so. There is a proposed 'retail regeneration' scheme in our city centre that is actually merging blocks, the biggest will be about 200m, so nobody seems to be learning these lessons.

I'm also very aware that some great traditional places match Alexander's '50 T-JUNCTIONS' pattern very closely - though of course you could devise a regular grid that consisted entirely of t-junctions.

My own observation is that modular construction techniques presume a Cartesian block and vice versa. This makes modular construction very problematic if you want density on an existing traditional street pattern. Hence my work with non-modular design.

On the limitations of A Pattern Language

The copyright status of the book makes it difficult to add to the original 253 patterns, so it doesn't have anything to say about lots of common situations, it suffers from 'bitrot'

There is also a practical matter, although the book is full of patterns that feel 'true' to the reader, and that have generally stood the test of time, it doesn't provide a reliable design method. There are no steps to follow, the suggested technique is basically to internalise all the relevant patterns and then think really hard about fitting them together, using a bit of trial and error combined with some full scale mockups in situ.

I would argue that software design patterns are a different kind of thing, as in software there isn't this geometrical constraint of having to fit everything into a finite 3d space, so you can usually deal with one or two patterns at a time.

Where I have seen the book successfully used is in situations where friends have wanted to extend or convert their houses, but don't have a clear idea as to what they need and they ask me for advice. So I ask them to read the book and use it to produce written instructions for an architect - it is a great tool to enable enlightened clients.

It is true that architects just don't want to use pattern languages, and I think there are a couple of reasons: one is that the trial and error design method is too much hard work for a busy architect who has a limited amount of attention, it is much easier to think up a stylish image and then fit it to the requirements; the other reason is that clearly A Pattern Language exists to create humane environments, but an architect has to earn a living and we have an economic system that has no primary interest in enabling humane environments.

Indirectly, there is money to be made from humane environments, somebody should assemble a pattern language for coffee shops, restaurants, bars and pubs, aimed at owners of these places (not aimed at architects).

On patterns clashing with each other

Screen space is most analogous to the situation with buildings. My observation is to do with patterns clashing.

For example, take a classic software design pattern such as 'singleton', you either implement a singleton completely or you don't. If your singleton sometimes isn't, then you are doing it all wrong.

An APL pattern such as 'light on two sides' isn't absolute. If you require that every room in a building matches this pattern then it will conflict with other desirable patterns. It is easiest to implement perfect light on two sides in detached buildings, but this in turn creates a catastrophic urban form.

So APL patterns are merely guidance, buildings may implement all the relevant patterns, but only ever partially.

My experience comes from trying to implement architectural design in software, where APL is used as a fitness calculation for an evolutionary engine - if the patterns are hard requirements then the whole thing locks up.

On inhumane architecture

I think this is mostly a matter of scale. When building projects are large, and for some reason only large projects are viable, the human detail is irrelevant and we get the 'spreadsheet architecture' we see around us.

A half-baked plan

I think it is a waste of time promoting APL to architects - with a lot of work we could induce a short lived fashionable revival, but soon enough the profession would revert to past form. Also, certainly here in the UK, architects don't have much relevance, their role is basically space planning and product selection for commercial buildings.

What is needed is for people to demand that pattern languages are used in their own lives, then there is a chance that the industry will provide, even if reluctantly.

Recently I've been observing estate agents valuing property. They look at the site location and floor areas and use a kind of ad hoc pattern language to adjust the price up and down, things like shape of room and ceiling heights - they even value light on two sides, which they call 'double aspect'.

They are also beginning to value 'walkability', and certainly in the USA, the 'walk score' is an important metric.

What if there was a formalised process of scoring a building and its immediate environment using APL? People could demand a 'livability score'. I am actually talking about someone walking around a building with a software tool and inputting the number of storeys, street windows, size of balconies, orientation of bedrooms, stair seats, depth of shelves, size of mouldings - the whole pattern language. The tool could be certified by official sounding organisations and public figures, but have an open engine and process for adjusting the assessment criteria.

Anyway, just an idea, and it doesn't help with the process of actually designing and making these places, my train is nearly at the station so I'll stop right here.

On a reduced pattern language

Architects need tools to deliver the work they are asked to do - they will find all sorts of philosophical and practical arguments to discount anything that says they should be building something different.

I'm thinking of the story in Alexander's 'battle for life and beauty', the significant element in this book for me wasn't so much in Alexander's approach to the project, but that he had a client who was adamant that there is different way to do things.

This for me is the place to apply effort, non-architects are wary of having an opinion on the built environment and defer to architects - you just did it yourself (above) - the professional architectural discourse is so obscure that we fear making basic mistakes and looking foolish.

So this is what a reduced pattern language can be: everything that a layman needs to have an opinion and confidently express it on any aspect of a building project.

On a half-baked plan for a livability index

My idea for a software tool for calculating a 'livability index' from APL is kind of outrageous, since I spend a significant amount of time worrying about secret algorithms making decisions about me (credit scores, "should I buy this item with cash or card", and such like). But something on this scale is needed - we are not getting a humane environment from the existing building industry because nobody is demanding it, or even knows how to demand it.

On the significance of Homemaker

My contribution is in realising that designing buildings in software is very doable using APL as the fitness criteria for an evolution engine. The limitation, if you can call it that, is that the buildings have to be within the range of traditional form languages - There is a basic form language that can be found in historical buildings all over the world, of load-bearing walls, rectangular-ish rooms created by sub-division, and with rooms above sharing walls with rooms below - this is easy to represent as a tree structure that can be computationally evolved.

But this technique is never going to create the grandiose anything-goes forms desired by architects, or the massively repetitive forms desired by finance. Of course I want to create traditional, unarchitected, humane places, that have APL values, but I'm not replacing 'the architect', as these are things that architects generally don't do.

On the subject of Homemaker not being AI

You can be sure that I'm not trying to build an AI architect, such a thing would be a monster, even if it could be constructed.

So I agree about the impossibility of duplicating the architect's design method, but this is because there is no architectural design method - what there is is a collection of superstitions and bravado given the name 'creativity' as a cover for the fact that nobody really knows what they are doing.

Creativity is seen as a kind of magical enchantment, so when something big is required, the solution is to hire an especially creative wizard who can do creativity at an industrial scale.

But this belief in a modern day witchcraft is a terrible way to solve complex problems - as evidenced by the appalling quality of the results.

Alexander's method, I think, is based on the understanding that human imagination works well at a human scale - where you can stand in the actual location and imagine different possibilities around you - combined with iteration, trial and error and full sized mock ups, it is possible to create beautiful and supportive environments one bit at a time.

The idea that there could be an expert Alexandrian who stands and conceives a whole large project as a single insight is as unlikely as a star architect doing the same in their studio.

Most of the patterns in APL are simple geometrical situations, but combining them is a hard problem. Homemaker is just one tool in the toolbox, but it does this particular difficult thing of fitting together spaces so that they maximise the patterns and minimise the material.

I should explain that really I want to enable building the kind of compact urbanism found in historical cities and towns that I find wonderful and sustaining. But nobody builds this stuff anymore, our current toolset is inadequate to the task. To do it requires some new tools and we have to make them because nobody else will.

I wrote on the subject of architectural patterns and software design patterns, basically I think that although they are conceptually the same kind of thing, the nature of software makes implementation very different:

https://bitbucket.org/brunopostle/urb/wiki/Patterns

On being able to design skyscrapers with Homemaker

I have no idea how to evolve skyscrapers, the only form language I can find that is amenable to evolution is this traditional domestic architecture. Homemaker couldn't be used to design theatres or football stadiums either.

On the creative cycle

The cycle in Homemaker:

1. Make random change. 2. Test results using the pattern language as fitness criteria. 3. Accept or undo transformation. 1. Make random change. [ ... ]

...but a simple random mutation approach gets stuck in local minima quite quickly, so I generate a population of 'designs' and use crossover between them as well as mutation.

CAD software has moved in the direction of BIM with products such as Revit where the emphasis is on speeding the design process and reducing errors - ultimately it is about increasing productivity by reducing labour time, the end product is not noticeably better.

I live in the UK where we have examples of nice historic urban fabric, but most new buildings here are not at all good in the APL sense.

On the completeness or not of Homemaker

It started as a proof of concept, as there were lots of good reasons why something like this might not work, but I think I have most of these covered now - it got to the point where I had to implement it to show it can be done.

I have been working on it part time, as I have a day job, family etc... it gets attention from me as and when I can, which is not as often as I'd like. It hasn't been used on any real projects as far as I'm aware, but I don't feel that this is very far away, given some time and a real site to work with I think that I could produce something to the level of a planning application that wouldn't be too difficult to take further using normal techniques.

It can design credible compact multi-level house layouts with internal stairs, arranging rooms for daylight, internal proportions and any other constraints I give it. It optimises building quantities, so it will try to minimise the area of walls etc.. It generates 3D models that can be used for rendering and visualisation without any further processing, it also generates nice IFC models, so there is a route here towards actual construction.

For me the no. 1 problem in architecture is finding a way to build close urban fabric, but in a way that people actually like. A Pattern Language is obviously the key to this, but trying to figure out how to actually do it led me in this direction.

On biologically inspired processes

I use a hard genotype/phenotype split, the genotype bears no visual relationship to the phenotype. Evolution makes use of mutation and crossover in the genotype population driven by a fitness calculation applied to the phenotype.

The genotype represents a heirarchical unfolding of the structure of the building, this is analogous to the incremental construction of vernacular buildings and the incremental growth of individual plants and animals.

The software designs a single building to fit the given environment, however each building in-turn forms the environment for adjacent buildings in terms of daylight etc... So it is possible to co-evolve a group of buildings to form a unified whole, thereby creating urban forms - though the project is not directly concerned with designing street layouts, subdividing land or other urban design stuff as such.

The inspiration was Alexander's Pattern Language, particularly a realisation that it really wasn't 'a way of building', rather a system for judging built forms. And that the process of design can be reduced to trial and error given enough time.

On the Free Software nature of Homemaker

Of course everything, including the code, is public so I'm open to anyone seeing or critiquing it, I want to get these ideas out there after all. Though, from experience, I don't expect many architects are inclined follow my own journey - from a very 'high tech' architectural background to coming to accept that even my own work validates traditional forms.

On recent Homemaker developments

A couple of months ago I embarked on turning the whole thing around to design mediterranean/arab style houses, in part because the 'British trad' architecture I have been targetting is invisible to anybody I show it to - not so much a negative reaction, but a 'nothing to see here' reaction. I figure I need some distance. Actually making this switch has been very productive for finding bugs and hard-coded assumptions in my code, so I'm keen to finish this and merge it back in.

Other than that I am suffering from not having a computer science background, I only recently discovered that my data structure is effectively 'binary space partitioning' - but I didn't know that is what it is called, so I never had the benefit from other people's work on the subject. Similarly, the whole thing is written in Perl which makes it alien to any programmer under forty, and excludes collaborators.

I'm very keen to continue with Homemaker, the approach works - after all these years I still haven't seen a single academic or commercial tool that is anything like as credible - and it works because it is based on a simple traditional/vernacular form language, combined with a pattern language as fitness criteria.

I do still struggle to explain why it is needed: for me the industrial approach to mass-production requires the world to be bent to fit the buildings; whereas with a system like this, the buildings can be fitted to the world we have - but this doesn't resonate with many people, I wish it did.

Having said that, a system like Homemaker can design and fit hundreds of buildings closely together simultaneously on the most complex sites. Given the scale and urgency of this 'mass urbanisation' problem, the solution needs to be scalable and automatable.

On designing Arab/Mediterranean houses

It's a generalisation, but basically the form of northern houses and their relationship to each other is driven by the need to maximise daylight; whereas in a traditional arab context, daylight is less of an issue compared to privacy - so buildings tend to look inwards. The other major driver of form is that courtyard spaces can be used for circulation.

So I can 'turn down' the daylight requirements, and fix it so that outdoor rooms are added to the circulation graph that gets checked for connectedness. I need to write a new module that scores overlooking/privacy, but I can reuse much of the daylight code for this.

On the location of patterns in the code

Currently the various patterns are scattered around the code, but mostly in a huge method called _apply() in Urb::Dom::Fitness which is configurable on a per-house basis with a YAML file like this:

https://bitbucket.org/brunopostle/homemaker/src/373cd3f743e3979d52c09078fa0973d703c7d44e/t/data/nineteen-plots/project/plot-0/patterns.config

This isn't my favourite part of the code, ideally each of the patterns that are checked would be a separate module and this _apply() method would be just a list of modules.

My patterns are mostly lower level, 'houses should have one or more toilets' isn't one of Alexander's patterns, but it is a pattern nonetheless.

On a web front-end for Homemaker

A GUI could be done, but a real problem with the evolutionary approach is that the process is profoundly uninteractive but also non-deterministic. The code can take fifteen minutes to design a lovely house or it can take twenty hours and drive itself into a dead-end. In the long run the job manager just runs again and again until it gets it right, and I know that throwing computational resources at hard problems is OK.

This is another case where my lack of a CS background is limiting, everything I know about evolutionary programming is scraped from a handful of Wikipedia pages - there is far more that I don't know.

On Homemaker being uninteractive

I wanted to explain this 'uninteractive' comment below.

Homemaker can't replace an architect in the sense that it can't explain its logic - it isn't an intelligence and it doesn't have any reasoning (you could say this about architects, but that is another discussion).

Say you put it in the position of an architect with a client for a single house, it designs a house about the right size and it's a 'good' house in that it scores well against the pattern language.

Now the client says that they'd rather have the bedroom on the right and the bathroom on the left - you can dig into the code, but ultimately you can't know 'why' it put the bathroom on the right; it may be because it is nearer the kitchen below (plumbing is cheaper), or it gives slightly better daylight to some corridor at the back of the house, or both, or some other combination of multiple factors - you may as well ask why a bluebird is blue, you can tell a plausible story, but it will just be a story.

The architect in this situation will simply swap the bathroom, they need to eat after all.  The operator of Homemaker could drop in a new pattern/module called bathrooms_on_the_left that forces the issue, but then suddenly it is designing three storey houses when they were all two storey before - this might be a great solution to the 'bathrooms on the right problem', but it may not be explicable, you don't know 'why' it did what it did, only that it worked.

This is a whole different way of working, and it is going to be suited to some situations and not others.

On the free-software nature of Homemaker

This is all free software, so anyone is free to download use, modify, or steal ideas from it - there is no need to ask for permission.

It is currently on bitbucket, which is the same sort of thing as github. There are download instructions here:

https://bitbucket.org/brunopostle/homemaker/wiki/Home

On the adaptive nature of resulting houses

This is an advantage of using a vernacular/traditional form language: these buildings can be extended, modified or partitioned easily without ruining the 'composition' - since they were designed by being extended, modified and partitioned in the first place.

There is a kind of symmetry here, you can only evolve buildings that are evolvable. So even though the result is a local minima, all of the 'ancestors' of the final design are only represented to the extent that they supported further evolution.

I suspect that maybe computational design of buildings may only be possible in a traditional context - which would be ironic.

Regarding allowing architects to modify the designs before construction; one of the output formats is IFC, which is a building industry 'BIM' interchange standard. I'm a bit ambivalent about this, but it is very straightforward to drop these files into conventional building industry software and carry on from there.

On the technological determinism of Homemaker

Thinking about where Homemaker goes from here. Most of the stuff I've written about it so far is theoretical, basically trying to demonstrate how and why it works; but for me this is primarily an environmental project, I'm doing it for my children - we need to transition back to high-density, medium-rise urbanism if there is going to be any kind of a low-energy future, but we need new tools to do it - all our current tools for building high-density are a human and ecological disaster.

The problem with this analysis is that it's clear now that nobody is ever going to spend a significant amount of money or resources on this as an aim - worse than that, most of the money is bet on this not ever happening.

Generally I'm sceptical about following wherever the technology leads, but a tool like Homemaker just isn't going to be any use for designing industrialised buildings - I don't need it if I want to make money building a stack of identical prefabricated pods - the stack of pods has all the advantages in terms of management, time and cost, every advantage except that it sucks as a place to live.

Where Homemaker leads is towards the ability to pack a large number of buildings into awkward sites (i.e. real sites), but in a humane and picturesque manner. This has to have some economic value independent of the environmental value, the question is: how to find this economic value to kick start the whole thing?

I keep saying that Homemaker is fundamentally uninteractive, this has some implications:

It works better designing multiple buildings simultaneously, since it is capable of fitting buildings together, and mutually adapting them to each other. This larger scale of multiple buildings suits a developer mindset. Here we have an advantage over an architect-based approach where designing individual buildings is prohibitively expensive.

I still have this common-sense intuition that everybody should custom-build their own home, this would be the ultimate freedom; but then again we should also expect buildings to last hundreds of years, and people's requirements can change completely several times in a lifetime, so in any credible future the vast majority of homes can never be custom built. This is a case of unexamined assumptions about needs having disastrous effects. What we actually need are pre-existing buildings that are easily adaptable but which come in a vast range of sizes and locations to suit individual lives - and this is what you get out of Homemaker, there is infinite variation: big houses little houses, small kitchens, big kitchens, front yards, back yards, roof terraces etc...

Another trait of Homemaker is that it works best with confined spaces. If I give it a half-acre plot it just thrashes around with too many possibilities. I think this is fine, I actually like the kind of urbanism where none of the plots are big enough to give you off-street parking, but I appreciate that this is a nightmare prospect for some people - they need to be eased into compact cities through personal experience.

Putting all this together, I keep coming back to an off-hand comment from Andres Duany; and I'm familiar enough with how he works that I can see there is a certain amount of bluster here, he says that innovation in urban design "only happens in holiday resorts".

Maybe he's right, this Homemaker system should be prototyped and shaken-out in the construction of a holiday village. Compact buildings, awkward sites, no cars, picturesque, this should work well, a twenty-first century Seaside.

On the distinction between form languages and pattern languages

By the phrase 'form language' I'm using a distinction that Michael Mehaffy and/or Nikos Salingaros made between 'form language' and 'pattern language' that I find very useful.

191 THE SHAPE OF INDOOR SPACE is a design strategy, if you follow this as a rule then it should stop you doing a whole range of stupid things. In this sense it is similar to software design patterns like MVC. In my world a form language is a collection of rules for designing and building, this is all form language stuff.

132 SHORT PASSAGES is a different kind of thing. We know that long corridors are bad - except when they are not - you really have to look at these on a case by case basis. Sometimes they are the result of an unavoidable design tradeoff. These pattern language things are less about how to go about designing and building, more about assessing the quality of result - fitness in evolutionary terms.

So Homemaker is divided into two parts.

The geometrical model is based on rules like 191 THE SHAPE OF INDOOR SPACE, that vastly reduce the range of possible forms, eliminating mostly stupid ones. I found that the floor layouts of practically all vernacular architecture from prehistory to the present day can be described with a simple binary tree - Moroccan riads and Dutch townhouses have more or less the same form language.

This geometrical model is assessed with patterns like 132 SHORT PASSAGES (implemented but not documented, I should do that) that together add up to a pattern language. There is actually a whole other layer of assessment calculating a rough cost in terms of quantities of building materials that has equal importance in the calculation, I don't have a name for this.

Getting eventually to your question about my alternative form language; no I haven't had a chance to work on my Arab/Mediterranean fork, but from my point of view the form language is the same - the main differences are in this pattern language assessment thing - with Arab houses, being able to look inside from outside is generally considered bad (not usually the case with Dutch houses), and outdoor/uncovered spaces are more available for general circulation. My task is to make these tunable on a sliding scale.

On Sabats

The room over a street is called a sabat. Yes it is difficult to imagine one resulting from an adaptive design process, historically they are the result of a negotiation between neighbours, and then it is only possible if the arrangement of windows and walls coincide across the street - I think this is why they are usually sparsely distributed on a street.

A sabat is basically hacking an existing building, e.g. it is unlikely that the floor levels can ever run-through because the head room over the street will need to be much higher than the first floor of the house, so yes this is a tricky one.

The Muslim thing of avoiding having entrance doors (and windows) directly opposite each other is great, this is exactly the sort of thing that I want to add to Homemaker. Currently the rules for placing doors and windows are very simplistic.

On output file formats

The output from Homemaker is primarily in Collada and IFC format. Collada is 3D polygons, suitable for VR, games, etc... IFC is an open 3D BIM format for the building industry. The 3D objects are quite clean, so I can go directly to 3D printing with no hassle - I should print some models, would be fun.

On the amount of fine-tuning of parameters

I haven't done any tuning, other than noticing when the output is really wrong and trying to fix it, but this is more like debugging - evolution gives a different result every time, so it is difficult to see immediate positive effects from tuning.

What I want is to base the parameters on real world evidence rather than my own judgement as an (ex)architect. For instance 167 SIX-FOOT BALCONY is an important pattern, but how hard is it as a rule? I know from experience that a four-foot balcony is essentially useless, but a five-foot balcony kind-of works for some things, and that an eight-foot balcony is notably more useful than a six-foot balcony. I need somebody to do a survey of real balconies and the people who use them and nail this stuff down - you might think this is the sort of thing that happens in architecture schools, but you would be wrong!

On Perl

Even when I started, Python would have been a better decision than Perl, but I wasn't in a position to switch, and it was an experiment that I never really expected to take further than a proof of concept.

It would be possible to swap bits to Python incrementally, but time.

On calculating fitness from a pattern language

I've been through A Pattern Language to extract a list of patterns that I have already implemented, and those that should be implemented but are not.

I'm very interested in how you combine patterns numerically. In my code, I take one room/space at a time, and score various patterns from 0 to 1, then multiply these by the floor area to give a 'room score'; I add these together, then do another multiplication with patterns that apply to the building as a whole; I then do a similar calculation for material costs and use this to divide the result - I have no evidence that this is the right way to do it other than that in some way I am maximising size and quality, and minimising costs.

On porting Homemaker to Python

Embarking on a full scale rewrite of software is exactly the kind of project that never gets finished - especially if it is being done by somebody who is being paid by the line of code.

I could see it working in these sort of circumstances:

Somebody with a need to write a new tool to design buildings, using my code as a reference, and stealing the best bits (I say 'stealing', but this should be encouraged).

Me sitting next to a good python programmer and rewriting it together (while I learn python). I could find a day a week to do this, and Sheffield is big enough that this person could be recruited locally. But this would take time, and also have no guarantee of success.

On patterns that have been implemented in Homemaker

Here is my list of patterns from APL. There are basic patterns that are outside APL, like 'all houses should have a toilet', I haven't made a list of these.

Some patterns are implicit in the form language. Everything in Homemaker is nested quadrilaterals/centres with variable height and this arrangement of spaces defines the structure:

    106 POSITIVE OUTDOOR SPACE **
    190 CEILING HEIGHT VARIETY **
    191 THE SHAPE OF INDOOR SPACE **
    197 THICK WALLS **
    205 STRUCTURE FOLLOWS SOCIAL SPACES **

Some patterns are evaluated a single time at the scale of the entire building:

    96 NUMBER OF STORIES *
    112 ENTRANCE TRANSITION **
    118 ROOF GARDEN *
    122 BUILDING FRONTS *
    127 INTIMACY GRADIENT **
    129 COMMON AREAS AT THE HEART **
    131 THE FLOW THROUGH ROOMS
    160 BUILDING EDGE **
    195 STAIRCASE VOLUME *

127 and 129 are currently somewhat broken, they need to be fixed and integrated with these unimplemented patterns:

    114 HIERARCHY OF OPEN SPACE *
    115 COURTYARDS WHICH LIVE **

Then there are patterns evaluated at the scale of individual rooms and spaces, as many times as necessary (for me, 107, 109 and 159 are aspects of the same thing):

    105 SOUTH FACING OUTDOORS **
    107 WINGS OF LIGHT **
    109 LONG THIN HOUSE *
    132 SHORT PASSAGES *
    128 INDOOR SUNLIGHT *
    139 FARMHOUSE KITCHEN **
    159 LIGHT ON TWO SIDES OF EVERY ROOM **
    162 NORTH FACE
    163 OUTDOOR ROOM **
    167 SIX-FOOT BALCONY **

Some similar scale patterns are not implemented, but could be with varying degrees of difficulty (138 would be easy):

    111 HALF-HIDDEN GARDEN *
    113 CAR CONNECTION
    130 ENTRANCE ROOM **
    138 SLEEPING TO THE EAST *
    140 PRIVATE TERRACE ON THE STREET **
    141 A ROOM OF ONE'S OWN **
    144 BATHING ROOM *
    145 BULK STORAGE
    189 DRESSING ROOM *
    199 SUNNY COUNTER *

Then there are patterns that don't need to be part of the evolutionary process. These are dealt with using procedural rules at the final stage, there is room for improvement here:

    164 STREET WINDOWS *
    196 CORNER DOORS *
    211 THICKENING THE OUTER WALLS *
    221 NATURAL DOORS AND WINDOWS **
    222 LOW SILL
    223 DEEP REVEALS

These are broken currently, though they worked at one point:

    110 MAIN ENTRANCE **
    173 GARDEN WALL *

...and these are all future work:

    134 ZEN VIEW *
    133 STAIRCASE AS A STAGE
    135 TAPESTRY OF LIGHT AND DARK *
    161 SUNNY PLACE **
    192 WINDOWS OVERLOOKING LIFE *
    193 HALF-OPEN WALL *
    194 INTERIOR WINDOWS
    198 CLOSETS BETWEEN ROOMS *
    241 SEAT SPOTS **
    242 FRONT DOOR BENCH *
    243 SITTING WALL **

On the inner/outer loop code in the Makefile

The inner/outer loop stuff is an artefact of the way I built the evolution engine. I had no experience of computational evolution and I really needed to see how it worked at a low level, so I strung the whole thing together with Makefiles and a collection of short scripts that each did a specific task (mutate, crossover, reap, score etc...). This made it much easier to follow the process, I could stop and restart at any time, and dig deep into the entire model since it was just files on disk.

The outer loop was there so I could render a graphical representation of the population periodically - it was running on a web-server and I was monitoring it through my phone.

Later I ported the whole thing to use Algorithm::Evolutionary, which is a dedicated CPAN module by another author - I now only need a short script called urb-evolve.pl that takes a single input file (or several representing a population) as input and outputs a single output file - and it seems to be faster and better as you would expect. Though I don't really know what Algorithm::Evolutionary is doing internally, and it has all sorts of options and different strategies that I have never explored.

I would have deleted the old Makefile stuff, except now running everything in a single process exposed a large number of memory leaks, only some of which I have resolved.

The fitness calculation at different scales is done in an over-long method called Urb::Dom::Fitness::_apply(), this needs breaking up.

On Homemaker applying patterns to the design

The evolution process doesn't involve any design decisions, the software doesn't try to change the design to accomodate patterns, it has no intelligence and can't make predictions or decisions.

Patterns are only used to assess the building to construct a single final fitness score for each house design - the higher the better.

So imagine you have a hundred variations on the same design (a population), each will have a different fitness. If you throw away the lowest scoring designs; then create some new designs by swapping fragments between the remainder (crossover), stir in a little bit of mutation, and put the results back into the population - the typical fitness of the population can only increase.

Then you repeat this process until the fitness of the population stops increasing, this takes a long time.

By fitness we mean 'best fit to the environment', these are not intrinsically 'better' designs, they just fit the pattern language and the surrounding buildings better than the others. If the environment doesn't change then you can reach an equilibrium. But usually we are designing neighbouring houses in parallel, so the environment is constantly changing and you get co-evolution of buildings - this also takes a long time.

Some of the patterns, particularly the ones that involve daylight and sunlight, involve a lot of calculation. Others are much more basic, 139 FARMHOUSE KITCHEN simply calculates the floor area of the kitchen and scores-down small kitchens.

On the initial variation

I usually start with an empty plot, a single space tagged as 'outdoors'.

The initial variation in the population then comes entirely through random mutation; dividing rooms, changing use, and shuffling walls; but evolution through mutation only gets you so far. It is very fast at first, but it rarely makes the jump to more complex forms.

The main evolutionary process is crossover; taking two different designs and swapping parts from one to the other. Homemaker uses a hierarchical nested structure, so rooms are contained within groups of rooms, which can be contained within further groups of rooms, which can be contained within a storey. A typical crossover might take a kitchen from one design and swap it with a bedroom and fragment of corridor from another, stuffing each into the space previously occupied by the other.

Mutation is analogous to evolution of bacteria that only occasionally exchange DNA. Crossover is analogous to DNA recombination in eukaryotes, creatures that rarely benefit from mutation. There are probably other evolutionary strategies, it is a vast field that I've only scratched on the surface.

On making the design process interactive

The intention from the beginning with Homemaker was always that it would be software that designs buildings. So everything was developed with this in mind, or at least to demonstrate how all the essential bits can be put together to make it work, I've been pretty single-minded about 100% automation as an aim - and I've been pleasantly surprised that it actually worked - others have tried and failed, and I'd like to think that this is because they haven't accepted the full implications of A Pattern Language.

The motivation was, and still is, the environmental and social necessity of switching to a compact urban form that does less damage to the planet, better 'fitting' buildings that fit people. Hence I've always looked at the ability to scale - there is a lot of stuff in the world that needs fixing after all.

The result should be a tool wieldable by people who can mobilise lots of resources to build big. I can rely on the Pattern Language and adaptive approach ensuring that the buildings themselves will always be humane and individual - this method really can't be used to build repetitive megastructures, but it can be used to house thousands of people in a single swoop.

The nagging doubt is that there is something essentially corrupt or corrupting about big plans. When I see others 'masterplanning', I only see hubris (though of course there are some masterplans that turned out ok). A healthier approach is giving people the 'means to manage their own affairs' and letting them get on with it.

Considering the whole thing, maybe 100% automation isn't the main achievement here. In some ways, the data model that describes a building is the central innovation. Homemaker uses a heirarchical tree to represent the building, a cellular structure where spaces are nested inside each other, centres within centres. This maps very closely to vernacular or traditional form languages, so closely that it always describes a buildable building (I think this data model is the kernel of an actual theory of architecture, but that is for another day).

So putting the 100% automation aims to one side for now, there is potentially another tool that could be created that reuses this data model but tries to make it editable in a graphical way. This would have the following elements:

The model would be represented as a stack of 2D floor plans, these views would be interactive such as to allow rooms to be split or merged, or assigned uses; walls could be slid around or flipped to change the size and arrangement of rooms; floors could be added, deleted, swapped - basically all the mutation operators available to the existing evolutionary engine, though it would need some more sophistication since the current operators are very low-level.

Another view could show a 3D representation of the building, this may or may not be interactive, but would need to follow any changes.

Two things would need to happen continually in the background:

1. The software would need to populate the views with doors, windows, stairs etc...
2. The building would need to be assessed against the Pattern Language, continually offering feedback; highlighting rooms that are missing or too-small or too-big or too-narrow or with not enough light, circulation that makes no sense etc...

Homemaker already does these two things. Perhaps initially they can be supplied by a network service using the existing Perl code.

Further functionality would optimise the precise position of walls etc... This doesn't need to use evolution, it could be done quickly with normal optimisation techniques, potentially as a network service.

The ultimate aim would be to deliver an IFC file representing the building that can then be taken into existing tools like Freecad or Revit for working up into detailed documentation for building. Again this IFC creation could initially be a network service.

I'm dubious that this graphical tool would actually create objectively better buildings than a full evolutionary computation, but maybe that isn't the point.

On the out-of-dateness of the published literature

I did publish a paper on the software, a while ago, the code has gained some features since (notably the daylight model), but the basic mechanism remains the same: https://journalofbiourbanism.files.wordpress.com/2014/05/032_jbu1_13_29_491.pdf

The paper has literally zero citations. I like to think that this is because it denies a lot of the stories that architects tell about themselves, rather than just not being very interesting.

Admittedly I chose an extremely obscure journal that doesn't even have a doi number, but this sort of thing seems normal in architectural academia. At the time I just wanted to get it in the public domain.

ENDS