Branch views

[heinezen]

For openage, a way to create arbitrary branches of views would be useful. Arbitrary branching in this context means that the view is not determined from a predefined characteristic (e.g. player civilization), but from an specific event or change during a game. The event can be defined in the API or by a script.

Branching a view can be used to create a fork of a game entity. Both the main view and the branch view will continue to exist, but both can be patched separately.

Example

A scenario script gives 5 specific swordsmen game entities a +2 attack upgrade. This upgrade triggers a fork which leads to a new branch view to be created for these 5 swordsmen. The branch view then receives the upgrades by patching the branch view, but not the main swordsman view. Thus, only the 5 swordsman benefit from the upgrade. Later on, a blacksmith upgrade gives all swordsman +1 attack. Internally, both the branch view and the main view are patched. The 5 specific swordsmen still have 2 more attack than all other swordsmen.

[TheJJ]

I'd like to point out the currently implemented view functionality: We do have views already, and they can be in an inheritance hierarchy. But that hierarchy is totally independent of the timeline, and changes in parent-views are always applied also to its child-views.

Views only carry the state of objects that were patched, the "base state" is stored in Database.

This means a newly created view always has the same state as the base state, even though it is a child of an existing view. Patches applied to the parent view after creating that new child view will then be applied to the child, too. But the child does not "catch up" with the parent view. Views are currently designed to be created before applying any patches: E.g. the "team" views and one view for each player as child of the "team" view.

Now, to implement branch views, we need a different mechanism to create a new branch view. It has to retain all previous state, or rather reference it efficiently:

• We could go full-git and only store full states and implement a delta-compression on top of it.
• Or we continue the current path of storing the history chain directly, and add support for referencing a previous StateHistory from a new StateHistory (i.e. reference everything before the fork-state to the previous StateHistory)

[TheJJ]

It seems for proper monk conversion support in openage we need branchable views to "freeze" database states.
This branched view should, as opposed to the current View logic, not inherit future applied patches from its parent view.

This means we need a flag when creating a view if it "auto-inherits" patches applied in parent views. The Game -> Team -> Player views need auto-inherit, but the Player -> MonkConversion00 should freeze the DB state intentionally.

To simplify things, our storage backend should be a single key-value storage, and not a tree as it is right now.
Then the freeze view is simply a lookup in the "global" state storage history.