Next steps for the Gusteau architecture, (c) 2021 Nick Porcino
I take a strong philosophical break with many game editors. It's considered in normal in editors that one directly manipulates the representation of objects in the scene, rather than transacting properties of the objects in the scene.
To sidebar that a bit, a really common criticism of C and C++ is the lack of reflection of structs and classes, and the large number of macro and template libraries that attempt to add it in some way are evidence that it's a common way of thinking about user facing data editing. We can also see the prevelance of systems like CapnProto, flatbuffers, protobuf, etc., that all draw a one to one correspondence between an object and its implementation.
That approach ties directly what a program does to what a program represents. It also means that a barrier to portability between systems is that instead of a system functioning, in a conceptual sense, the same as another system, it must instead to the degree necessary to allow import, emulate another system.
Taking that back then, to the question of interactive editing. I don't think of transacted data as the live state of a practical system. I think of the transacted data as the data that is important enough that I would expect to replay them on another machine to reproduce the history and state of the first machine.
In the case of a drag and drop operation there could be any number of potential drop sites, and an artist may think and linger over many of them in the course of deciding what to do. None of those potential operations are editing operations though. Only the final drop target is involved in the eventual edit.
So, how would I deal with this scenario then, in a transacted environment?
Let's say the situation is that I wish to place a flower pot on a window sill in a big city.
Briefly coming back to the sidebar, we often think of the state of the system as the state of the objects in the program. We can instead imagine that what an artist sees is a representation of the transacted system, not the transacted system itself. If there's a city in the background, not being interacted with, from an artists perspective, all that matters is that a buiding can be selected; not that the true transacted data around that building is perfectly reflected in the editor. Your mileage may vary, if I am an engine programmer, yes, I want that. Do my users? Some of them, they get a different tool suite. From the perspective of dropping the pot on the sill though, it makes no difference whether the geometry is meticulously represented as points and faces, or if it's just a picture of a city that behaves as if the geometry was meticulously represented.
So, at the beginning of the operation of dragging the flower pot, I ask the transacted data "what are all the potential drop locations?". I then instantiate, ephemerally, a local drop sandbox that's got nothing in it, except the items necessary for the interaction. I may remove, temporarily all the window geo from the rendered set, and replace the windows with proxies that respond interactively in some way. Then, I run the drop operation as if it were a minigame, so to speak.
At the end of the operation, I shut down the sandbox, restore the rendered set, and validate that the transaction completes. At that point, I update the rendered set as necessary, and eventual consistency in any shared environments lets other participants see where the flowerpot is now. The transacted database has only the location edit and possibly an undo record in it after all that fuss.
A simpler example to kind of drive the point, is, imagine we have a mesh of New York City, with billions of polygons. I may have an optimized real time proxy with HLOD and all sorts of things to make that realizable. I can support mesh edits, on a flower pot on a windowsill, by temporarily making a mesh editing sandbox for that flower pot, and transacting only the final vertices to the global database when done. If I wish to preserve the construction history of that mesh edit sequence, then that's an architectural/design choice as to what granularity of operation is important to preserve in the global history, and what might be appropriately more local. For example, I might sandbox the flower pot, fetch a backing Maya file, and delegate to Maya. In that case the construction history is stored with the Maya file, not the global view.