Again I think I may have caused a misunderstanding.
I am not saying save every single iteration of a design in a history of additions and subtractions. I am saying simply save the blueprint the building is based on and the current state of the build. Thats it, keep it simple.
I am also not saying place any blueprint within a section of a building and build over that building with the new blueprint. I am saying a blueprint could only be added by combining it to a wall that is shared between the “active building” and the template. This shared wall must not have a floor attached to it on the side you are adding the blueprint and you would still require enough space for the blueprint to be built in the area while being attached to that wall.
The difference in my idea of separating walls and floors to have different states of memory is that you would not be locked into changing the entire build between the “active building” and the blueprint state but you could make the changes with specificity by only selecting a small section of the build relevant to the area.
Now what this means is that new rooms will exist as part of a separate entity that are not saved as a blueprint yet. So you have template 1 which is built, template 2 which is a blueprint and template 3 which is the combination of those two but also the “active building”. That is- any small changes made are kept separated in memory so that the game knows the things that have been added since the combination of template 1 and template 2 in each section respectively.
To make this even more highly organized I think it would be simple to separate each room into sections of floor and wall and designate things as being part of and attached to these two basic things required in a room as everything in the room is dependent on the state of those two things. This means that each wall that is based on a template and then is changed in the “active building” can have a total of four states of memory- the template 1 AND template 2 AND shared wall forming template 3 AND “active building” while the floor would only ever have template 1 OR template 2 AND the “active building”. I see this as a simply keeping a list of object numbers in a set of coordinates on each section of a length of wall or floor. Sure slabs can mess things up but you can very loosely define a floor and wall and still make this work. This would make the blocks have associations in memory just as they do visually and structurally.
This means that unless you extend or shorten a wall section or room, it will still recognize it as being part of template 1 or template 2. However, if you do shorten or lengthen this wall it is now the “active building”. If you change the shared wall that combines template 1 and 2 you break the connection of template 3 and now this section of the building is the “active building” and can still return to any of the three templates.
even better super awesome explanation drawing
To me this is the most logical way to handle the data, it also happens to come with the benefit of being extremely useful. If things are designated separately like this in memory you could then easily select one of these sections and export it as a new template and you suddenly have a library of any wall design or floor plan you could imagine. Then you could select a template of this section of wall or floor to add to an existing building and build with that instead of drawing a blueprint from scratch. This would give you a catalogue of designs to choose from that can be shared using the current template format but designated by “floor” or “wall” with attached decorations to each respectively. Then you could filter each design by dimension, number of doors and windows, and decorations relevant to your search, adjust it sightly to fit your asthetic and repaint it as you see fit.
White squares would be pillars or “anchor points” for defining the building. A wall or floor can be added, removed or combined or cut into sections, forming a new section where the data between those two “anchor points” change and a new template can be formed, represented by combining colors.
The “active building” represents data that has not been saved as a template. The ideal scenario is that I would be able to select any color of floor or wall that is in the “active building” state and restore it to the previous state of the stored template.
So the data of a room is dependent on the “anchor points” that define the wall and that wall defines the floor. By checking the data between those two points you can know if the wall or floor has changed. Adding more anchor points adds more walls and more checks but you don’t need to know the state of every block, only the blocks along these points. No matter how long the wall section is you will either connect by adding a new “anchor point” or connect to an existing one.
This makes me realize you only really need to know the “anchor points” to generate a random building.
If this was a 3D building it would be 1168 blocks with just the floors and walls (assuming 6 blocks tall, with the floor in the ground, and excluding roof design) and it can be defined by 24 “anchor points” and 30 connections between those points in 2D.
This also means that the AI could then prioritize the “anchor points” with the most connections, from bottom to top, as being the core foundation of the building and build those connections first before building a second floor or walls to help the structure support itself if physics ever becomes a thing. If you simply create another floor plan and overlay it for a second floor, you would only need to look at the “anchor points” and their vertical alignment with the floors below it to estimate the amount of deviation between them to know how well it holds its weight.