Structure arcs
Closed this issue · 2 comments
Discussed in #9
Originally posted by peter88213 January 5, 2023
Currently (v4.2.5), you can describe an arc by creating a "Todo" scene, assigning it to the corresponding arc. Then the number of normal scenes assigned to this arc is shown in the "Todo" scene's properties in the right pane. This is optional; you don't have to create a "Todo" scene in order to assign arcs to normal scenes.
It would be nice to break down arcs into several steps that can be connected with scenes. To realize this within the limitations of the .yw7 file format, the following is suggested:
- The arc, consisting of a sequence of steps, is represented by a "Todo" type chapter with scenes representing the steps.
- The steps can be assigned to normal scenes in the same way as characters, locations, and items. This is additional to the arc assignments. If a step is assigned to a scene, the "parent" arc will be assigned too.
- The steps are displayed in a tree column. Open point: How discriminate arcs, if multiple steps of different arcs are assigned to a scene? Coloring is no option here.
- We can think of creating a special view, where the steps are displayed in the tree in a special way, e.g. as plot points, or as sections such as acts. This would be implemented as a a plugin.
Realization
- Chapters get an "arc description" property, consisting of an UID. This applies to "Todo" scenes; if the scene type is changed, the reference must be deleted automatically.
- Scenes of this chapters have this UID as "Arc" reference. For this, the current implementation can be used.
- Additionally to the "Arc" reference as currently existing, scenes get a new relationship: a list of scene IDs pointing to the "Arc step defining scenes". This is the part that might get complicated to implement. If an "Arc step defining scene" is deleted, or changes its type, all scene references must be updated.
Change the way arcs are implemented?
At this point, it would be possible to implement the arcs as elements referenced by IDs rather than tag-like as before.
Advantages:
- Arcs are easier to rename.
- Arcs are uniquely identifiable.
- Arcs are internally processed with the same algorithms as characters, locations, and items.
Disadvantages:
- The code for the tag-like implementation is quite complete. The modification effort would be rather high.
- A conversion routine must be maintained for existing projects. Permanent backwards compatibility would overload the code.
- If the arcs are stored as chapters, several passes are needed to first distinguish arcs from regular chapters and then process the references.
- Properties of chapters representing arcs may no longer be changed easily.
- A conversion routine must be maintained for existing projects. Permanent backwards compatibility would overload the code.
- Other programs that also process arcs, such as aeon2yw, must be modified.
- All plugins will be affected if novelyst gets a new API that is not backwards compatible.
How should the arc points be linked?
- Point IDs per scene.
- Scene ID per point.
- Keep links separately, element-like.
- Dual-linking: Point IDs per scene, and Scene ID per point.
Option 4 promises quick processing, for instance when browsing the tree.
Pitfall: Inconsistencies may occur. On arc checking, Option 2 could be used as a "leading view", or reference.