Events. @event, or a @goal keyword

[marek-lach]

Simply the ability to quickly note down the @ goal of a scene, before writing that particular portion of a scene. This would be a smaller unit than a scene, good for keeping focused and organized (at least for me). Of course then, multiple events, or goals could be denoted throughout a single scene document.

For example:

@ event: John falls down a pit hole.
The narrow passageway has suddenly turned into a massive slope and John, unable to quite steady himself, found himself carried instead...
or
@ goal (I don't mind which keyword would be usable)

I think yWriter uses the goal terminology, Causality uses beats terminology (although that name is not that intuitive...)

[vkbo]

First of all, please put words starting with @ in backticks before writing a post, as you are tagging random GitHub users in your posts if you don't 😃

Do you have a proposal of what novelWriter should do with this information, if anything? If it is not collected by the app and used, there is no need for a special syntax for them using the @ notation. You could just use regular comments. That is in fact what comments are for. I put comments in my scenes to denote flow all the time.

[marek-lach]

First of all, please put words starting with @ in backticks before writing a post, as you are tagging random GitHub users in your posts if you don't 😃
That's true, not sure what brackets tho, so I just edited it and separated the @ from the name.

Do you have a proposal of what novelWriter should do with this information, if anything? If it is not collected by the app and used, there is no need for a special syntax for them using the @ notation. You could just use regular comments. That is in fact what comments are for. I put comments in my scenes to denote flow all the time.

I suppose that makes sense.

[vkbo]

Well, I was hoping you had some more ideas here!

[marek-lach]

Well, I was hoping you had some more ideas here!

I could only think that the event/goal could be a place at which it is easy to split a document into a sub-document through some anchor that event descriptor would automatically get associated if it's used, as an entirely separate new document under a scene, if the author later decides to do so.

I know some functionality like that was already discussed somewhere, or is planned, for example #854 could be related for example to better plan, develop and extend arcs/acts.

[vkbo]

Yes, that's definitely a possibility. Let's leave this open and see if it can be made a part of the visualisation tools.

[tmarplatt]

What can @goal do that @plot already does not?

[marek-lach]

What can @goal do that @plot already does not?

I am thinking of this as an @event, but @plot is more broad, more vague, less immediately actionable, whereas @event is a crude description of the immediate part of the scene to be written down. I would imagine these would not be included in the final compiled manuscript.

Generally, I imagine @event to be helpful to the author by narrowing down the action and its expected result, thus helping to shape the scope of a scene portion that is to be written. It could expect to also specify a duration of the sequence.

[vkbo]

The way I approach this is to add multiple tags in my main plot outline document where each main plot event has a section with a heading and a corresponding tag. That plot tag is then references in the scene corresponding to the event. The events then show up in my outline and I can make sure they're spaced out as intended.

I guess the use case here is slightly different? Something to be used in most or every scene?

[xahodo]

Isn't the @goal or @event covered by synopsis and plot?

[vkbo]

Synopsis or regular comments, and plot, can certainly cover it, yes. So unless the additional information is collected by the indexer and used for something specific, there is no point in adding new syntax. However, when I get around to create a visualisation tool for the story timeline, it may be possible to use this information. I have some ideas to test out.

[marek-lach]

I guess the use case here is slightly different? Something to be used in most or every scene?

Assuming that the writer plans as they go along, rather than knowing exactly each plot point beforehand (having only a general idea as for the theme). The event tag could be used in pretty much every scene (or even multiple times during a scene) as a navigational point for the writer about what to focus on at the moment, what to elaborate into a whole scene.
Not necessarily a major plot-point, but a scene nucleus (like a private, rough scene heading)...

These navigational plot points could then possibly be moved around (split), or merged etc..., as the authors sees fit when the story is more developed at a later stage.

[peter88213]

These are interesting ideas. Basically, we have two systems here: a chain of events, as you could arrange them on a timeline, and the narrative realization in scenes. The proposed @event elements then would indicate the assignment of events to scenes, don't they? Of course, you can also outline events in a backstory that have no direct counterpart in the narrative.

My personal approach is to first outline the events with dedicated timeline software like Timeline, and then either derive the scenes from that, or link existing scenes to the events to synchronize the timeline with the writing program. I wrote a tool for yWriter for this some time ago.

As far as the "goal" of a scene is concerned, however, I know it more as a means of planning the dramaturgical microstructure of the scene. yWriter was mentioned above, which has the three fields "Goal"-"Conflict"-"Outcome", and thus obviously wants to support a certain plotting method, as described here, for example.

[xahodo]

Well, I would love a %conflict: tag for scenes and chapters. Unlike the synopsis (which outlines what happens at a scene), the conflict outlines of what nature the challenge in the scene is, what makes the scene exciting.

[peter88213]

I'm not quite sure, but I think I saw a suggestion elsewhere that would work well here: If the desired categories are to be recognized and processed by the program, you could, for example, define one keyword in the syntax and allow user-defined extensions.

This is how it could look like:
@plot.custom-extension

For the action/reaction scene scheme mentioned above, the customized keywords could look like this:

@plot.goal
@plot.conflict
@plot.outcome
@plot.reaction
@plot.dilemma
@plot.decision

However, if regular comments do the same, this discussion might be superfluous. Comments that follow a user-defined convention can be evaluated at any time using a script. I have used this technique with my yWriter-novelWriter converter.

[vkbo]

This will be implemented as %Story.<whatever>:, as detailed in #1784.

Not sure when the feature itself will be added, but parts of the underlying infrastructure to support it has already been added for footnotes, which uses a %Footnote.<ref-key>: Text syntax. So the parsing and highlighting logic is already there.