Long Post Warning: may not be relevant to most people. Just some wild exploration of possiblities. Please SKIP if it gets too hard to read.
My feel is that the system described above is too complex and probably not feasible for implementation. (I can only speak from a general design/programming point of view though. Radiant programmers/designers may like the challenge?) For one thing, any form of history is messy. Not only storing, maintaining consistency etc. And the use case does not apply to all users. It will make those players whose use cases fits happy, but do not solve the problem in general.
(messy part begins)
TL;DR at the end.
Disclaimer: some concepts are probably already similar to what is being implemented atm. I am just approaching it anew and any similarities will be coincidental. And most of this is just adhoc thoughts which is not organized at all. I.e. may be totally not feasible or have major flaws. (so feel free to attack )
But if I were to do it, I may want to approach it using clear conceptualization of what is the design, space and actual built building.
Firstly, I would separate the concepts of design (intended state of spaces) vs physical (real state of spaces).
E.g. A design is constrcted by changing physical block spaces covered by the design to match what is specified in the design. e.g. design specifies a stone block and physical space has nothing? hearthling should build a stone block there. If design specifies open space but physical space is a terrain block? it means hearthlings needs to dig it. If design specifies a space to be “any”? hearthlings should leave that physical space in whatever state it was in.
It is not necessary, however, to have a design after the physical space has been built once. e.g. after building a design, I could just delete the design. The physical space is still left behind, but there is now no direct way to change the design (since it is abandoned). But similar to current system, we can “generate” a design from what is in a physical space. e.g. by defining a space extent over all or even just a part of a physical building, we can generate the design for that.
(The current game probably start with separate concepts of design and physical space as well, but when the building is “finished”, the two seems to be merged into one, which is why it make some actions, like say removing/changing a selected part of the finished building impossible?)
The main action associated with a design is simply “construct”.
This just means “changing all the physical space covered by the design to match what is specified in the design”. Construction is considered “finished” when there are no unmatched space left.
This generic construction process is actually interruptible. E.g. I can start the construction of a design, then stop it halfway (not just “pause”. totally stop and abandon ALL in-progress transient construction states), change the design or manually change what is physical, then later on start construction again. The processing part will actually make no difference between whether this is a new building or continuing an existing one, and can just compute the “difference” between the design and what is physical there and figure out a way to make the rest of the physical space match the design. (it may actually make building construction more robust? lol… implementation-dependent… )
When “editing” an existing building, we are really editing the underlying design, then “construct” it.
When “removing” a building, it is just replacing the design with a empty one then “construct” it (and auto-abandon the design when it is finished).
Just to recall: changing the design is just one way of changing an existing building. There can be more direct actions/commands which changes the physical space directly without changing the design.
Next comes the management of designs and their spaces. Let us use the example from @genboom above, where we want to build 2 templates (let’s call them template 1 and template 2 as well) with an overlaping walls of 1 block in thickness. I may have the following different requirements:
I want the final thing constructed to:
Build the design according to both templates, but with template 1 taking precedece : i.e. if template 1 and 2 both overlap same block space, template 1 wins.
similar to above, but with template 2 taking precedence.
With the concepts from above, both are possible, and just controlled by the order of “construction”. in the first case, we construct template 2 first, then template 1. Since template 1 is constructed later, it will change the parts of the shared wall already built by template 2 to match template 1. And in the second case, just reversed the order.
But I am not happy: that I actually had to build parts of the shared wall using first template then re-built by the second template. How do I just build the shared wall once?
I’ll create a merged template (which is NOT reversible, though the effects can be… will describe later.). By merging the overlapping templates 1 and 2 into a new template 3 (must specify precedence similar to construction order though), we now have a new single template that spans the combined space of template 1 and 2, and where the “shared” wall was, there is only one specified state for each block space left, there will no longer be cases of build first, changed later for each block space.
But what if I want to “revert”, say back to just template 1? template 3 is created in a non reversible manner. But the process which it is created can be reverted manually. Let’s say I want to remove the design in template 2 and just keep template 1. This is what I can do :
- remove template 3 design (won’t change physical space)
- load back template 1 design (assuming it is unchanged) and place it over the same space that it occupied before (same position, orientation etc)
- Extent the space of the placed template 1 to cover the space which used to be occupied by template 2 (designated empty space).
- Press “construct”.
What this will do is: it will change those spaces defined only by template 2 to empty space, while preserving those that are in template 1. And as a bonus, if any shared space was built according to template 2 which is different from template 1, it will be re-constructed to make it match again.
Think wrote too much lol… and not too well organized as a first unplanned draft.
Reinterpret “construction” simply as changing physical space to match a design, which exists independently from the physical building even after being built once.
Designs can overlap in space. The one that is constructed later will decide the final state of the shared spce, by default.
Designs can be merged. Shared space will end up with the state of one of the designs according to options/preference/priority in merging.
A design can be generated from physical space by defining the extent of the space. (this can be used to easily “break down” a previously atomic design)
“Changing” a building can involve a ad-hoc change by changing the physical space directly, or a change in plan by editing the underlying design then “constructing” it again.
All manners of grouping, management, overlapping etc are specified over the designs rather than physical space, and can be changed simply by putting a different design with different space extent over the same physical space. removal of existing designs over same space is entirely optional.