Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dialogue Text Names #63

Open
anmart opened this issue Oct 7, 2019 · 5 comments
Open

Dialogue Text Names #63

anmart opened this issue Oct 7, 2019 · 5 comments

Comments

@anmart
Copy link
Member

anmart commented Oct 7, 2019

Currently, the style guide touches on how to name shorter texts like UI (try to use the words in the text, or shave off a few and use the key words), and Names (use the full name).

I think that it'd be a good idea to come up with a consensus on how longer Dialogue texts should be renamed. They can span many lines, and can't be condensed as easily as UI texts can be.

My idea is that we find some way to describe what's being talked about, but add the speaker to the beginning. Something like Imakuni_IntroductionText or ImakuniAskToDuelText for texts 0467 and 0468 respectively. I personally prefer with the underscore.

Please share any thoughts on how naming texts could work, thank you!

@jidoc01
Copy link
Contributor

jidoc01 commented Oct 15, 2019

I think your idea is nice.
As you said, it's enough to name a text variable with:

  1. Who speaks out.
  2. Which situation it has.

And, I looked at the other repos, like pokered, and they used the same convention.
A little difference, they didn't use the underscore only for splitting the speaker.
One used no delimiter, like: ImakuniIntroductionText.
Another used delimiter, but combined the speaker and prefix, like: ImakuniText_Introduction.

In my opinion, it's good to minimize the count of delimiter for readability.
And at the same time, without delimiter the names could lose their readability.

Combining the speaker and the prefix seems nice, as by combining them they can be considered as a specific postfix(or prefix) including the meaning of a text. In this way, we can put the 'text' before the speaker, for considering the exception where it has no speaker, like: Text_TurnOnPC

@xCrystal
Copy link
Member

I would say the most important thing would be to enforce consistency. I also like the Imakuni_IntroductionText approach since trying to summarize a lot of dialogue into a label is going to be quite difficult to say the least. Other text labels don't use an underscore, so maybe there's no need to use one here either. So between Imakuni_IntroductionText, ImakuniText_Introduction, and ImakuniIntroductionText I'd probably lean the last one (I also like Text at the end).

Actually, I think something like ImakuniIntroductionDialogue could be fine, just like how we use Name or Description as prefixes for other labels rather than Text. Maybe this is awkward if you run into some text of a non-human NPC (like TurnOnPC as in the example above)?

@jidoc01
Copy link
Contributor

jidoc01 commented Oct 15, 2019

I also think that for clarity it would be good to put together the name and the suffix.
The order with
[Content] - [Name] - Text(As a suffix, which can be replaced with Dialogue)
seems reasonable, for the hierarchy from the tail could be applied.

And, I think we can also use different suffixes for different cases like:

  • "Dialogue" for NPC
  • "Text" for Non-NPC
    In this way, we can see immediately if this text has a speaker(NPC).

@anmart
Copy link
Member Author

anmart commented Oct 15, 2019

I personally prefer using an underscore, but I understand and agree that it makes sense not to since text currently does not use underscores to separate things.

I think we should go with Text rather than Dialogue. I know it's a bit less descriptive, but I don't think it's super necessary, and I'm worried the labels are already going to be pretty long with NPCs like Ishihara and Imakuni who have longer names.

I think the general consensus I'm seeing (and agreeing with) is:

[name][Scenario]Text

---- Jidoc's message arrived right as I was hitting comment, so I'm just going to append my thoughts:

If there's an NPC's name attached to the label, we would already know there's a speaker. I do think [Scenario][name]Text is also acceptable, though I like how immediately recognizable having the NPC's name at the beginning is.

@jidoc01
Copy link
Contributor

jidoc01 commented Oct 15, 2019

I agree. With someone's name on it, we can discern easily whether the text has a speaker.
At the same time, it would have more clear meaning with different suffixes. When we look a label from back(assuming that we use the back-to-front convention), you would need to check if it has directly a content or some NPC's name, unless there are no different suffixes between text and dialogue.

Of course, it's easy to recognize if it's a name or somewhat, but with a structural point it could be better to have something to reveal its structure, as the two types(Text and Dialogue) have different structure on label(the former has no name). For example, when the content has some name like PatADogText, we don't know whether the speaker was a dog, or I just pat my dog. Of course, we actually know the speaker isn't a dog, but it still shows its ambiguity. But I think that with a proper underscore this ambiguity could be solved, like PatADog_Text and PatACat_Dog_Text.

And, I also think we can shorten Dialogue to Dialog, as the latter is shorter and also being used frequently.

Actually, I would prefer to using only the "Text", as it's very short, and all the things I said above isn't that critical in real situations lol.

Plus, I think that having a name at the beginning looks more clear!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants