Giter Site home page Giter Site logo

Dialogue Text Names about poketcg HOT 5 OPEN

pret avatar pret commented on June 5, 2024
Dialogue Text Names

from poketcg.

Comments (5)

jidoc01 avatar jidoc01 commented on June 5, 2024

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

from poketcg.

xCrystal avatar xCrystal commented on June 5, 2024

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)?

from poketcg.

jidoc01 avatar jidoc01 commented on June 5, 2024

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).

from poketcg.

anmart avatar anmart commented on June 5, 2024

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.

from poketcg.

jidoc01 avatar jidoc01 commented on June 5, 2024

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!

from poketcg.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.