Tool for drawing comment blocks in editor

Pyblo commented 1 year ago

Is your feature request related to a problem? Please describe.

I would love to see some more tools for organising passages in the editor.

I usually really like to plan out my story in blocks (separating it into space for chapters, utility passages for scripts, temp passages that i may come back to, or those that need some refining later) first and then flesh it out. This works in the beginning, but as the story grows, it gets somewhat confusing to manage and reorganise the whole workspace.

Describe the solution you'd like.

It would be great to be able to draw comment blocks in the workspace. They would be only for editing with a clear thick border and a title on top that we could edit for adding comments.

The main idea would be to replicate the behaviour of Comment Boxes in Unreal Engine blueprints editor. This should be an editor feature only. Just drawing an empty node, adding coment text to the title bar of it and allow to change its position and size.

That will be useful for story organisation, making easy to understand templates, reusing parts of the game

Additionally it could be extended in the future: make all nodes inside a block comment to be moved when you move around the group node itself, similar behaviour with copy&paste, etc.

Describe alternatives you've considered.

Other example would be Frame Node used in Blender 3D software. Documentation here. It is very similar to UE4 comment boxes but also has ability to change background colors.

Additional context on this suggestion.

No response

Presubmission checklist

[ ] I am interested in working on code that would implement this feature request. (This is not required to submit a suggestion.)
[X] I have done a search and believe that an issue does not already exist for this idea in the GitHub repository.
[X] I have read and agree to abide by this project's Code of Conduct.

hituro commented 1 year ago

I could have sworn I'd opened an issue with the same suggestion before Twine 2 came out, but I can't find any sign of it, so I suspect I must have discussed it on the Twine Discord and never brought it here.

I would adore this feature. I love to organise, and I spent ages moving passages around to try and visually group them, or tag them with otherwise pointless tags just to get related colours on the story map. If I could place groups of passages inside visual rectangles (with a title and free colour choice), I would love that.

I'm adding a quick mockup @Pyblo, is this what you were thinking?

greyelf commented 1 year ago

As all information about the Story Map and the Passages it contains is stored within the meta-data that gets embedded within the generated Story HTML file, a feature such as this would first require updating both the Twine 2 HTML Output and the Twee 3 specifications.

After which the main Twine and Twee compilers would also need updating so that they comply with the new changes made to those specifications.

And depending on how exactly the additional comment block related data gets stored it may also require the updating of the engine of each Story Format.

hituro commented 1 year ago

@greyelf Yes, that may have been the primary objection the last time this came up, though creating a new element with a similar scope to the <tw-tag> element doesn't seem prohibitive. The opinions of others more involved in the standards clearly hold more weight than my opinion, but I don't think fear of modifying the standards should forever prevent the addition of new features to the Twine application.

<tw-annotation name="Intro" color="orange" position="100,100" size="300,400">

Alternatively, the highlight areas could just not be stored in the Story HTML file. There is already some small precedent for this. Although story tags are stored in the <tw-storydata> element, the colours assigned to those story tags are not stored anywhere in a Twine HTML file. Of course, there is an obvious difference (the tag colours are not specific to any given story), but still, there is a possibility space where such things are editor specific, and not stored in story files. It's not the way I would do it, though.

greyelf commented 1 year ago

@hituro I wasn't stating an objection to such a request. I was just pointing out some of the changes that would be required to implement the request, so it would be clear to others that the request is a little more involved than just adding a visual feature to the Twine 2.x application itself.

the colours assigned to those story tags are not stored anywhere in a Twine HTML file

True, which is unfortunate as it means that that colour association will be lost when the generated Story HTML file is imported into any instance of the Twine 2.x application other than the one that was specifically used to originally create that association.

Pyblo commented 1 year ago

I'm adding a quick mockup @Pyblo, is this what you were thinking?

Yeah this is exactly what i have in mind.

The comment node is supposed to be editor only utility. Actually, since it is supposed to be a comment, then it could be kept in form of a HTML comment tag with special parameters inside, that only editor would care about:  In this way nothing should bleed into html functional stuff and should be easily backward compatible with other things.

I don't have much experience with projects terminology and structure so treat it only as a loose suggestion.

klembot commented 1 year ago

This is a dupe of https://github.com/klembot/twinejs/issues/190, but since there's more discussion here I'll close that issue.

hituro commented 1 year ago

Also a duplicate of https://github.com/klembot/twinejs/issues/412

Also a partial duplicate of https://github.com/klembot/twinejs/issues/583, https://github.com/klembot/twinejs/issues/707 (the "chapters" here are visual grouping elements of the same sort but with collapsing), https://github.com/klembot/twinejs/issues/714 (another version of the chapter/group feature), https://github.com/klembot/twinejs/issues/282 (mentions the box-drawing option).

https://github.com/klembot/twinejs/issues/520 isn't quite asking for the same, but the the impulse (more organisation tools in the story map) is the same.

jamesdavidpatton commented 1 year ago

There seems to have been lots of discussion on this and similar issues, as hituro points out. The basic problem is: "How do we keep large stories manageable?" There's been a lot of discussion about whether different chapters, or story "groups", is the answer. Personally I think that makes the whole thing more complicated. Klembot mentioned, in #412, the possibility of adding "sheets" functionality, ala Excel, which might make things more manageable. I think that is an excellent solution.

However, even with the addition of sheets, I think it just makes sense to be able to "comment" or leave labels in the Twine workspace. Commenting is a major feature of eg. coding because it just helps keep everything readable, so I'm honestly surprised that Twine 2 still has no visual commenting feature. It's an amazing tool which I love, but this is a really strange blind spot. For this reason, I think it makes a lot of sense to implement this comment blocks feature. A "sheets" feature can still be implemented later, but I think it seems reasonable to give people access to a commenting feature first (which I imagine would be simpler to implement, since it need only be cosmetic) and then consider the also excellent, but probably more complicated, "sheets" idea.

Note that I say this with very little understanding of how the Twine editor actually works, so I may be completely misinformed. As a user, though, I would deeply appreciate these features.

klembot / twinejs