search

adventuregamestudio / ags

AGS editor and engine source code
Other
704 stars 160 forks source link

Allow using a nickname instead of script name for characters in dialogs #1274

Open ericoporto opened 3 years ago

ericoporto commented 3 years ago

A character may have a name with spaces or other characters that are invalid or not convenient for the character script name.

Ideally when writing dialogs I would like to write the character name as is writing in the game script (as in play not in code). This also makes easier to revise the game dialogs since it's similar to the form a writer would have provided the script.

This would give a good logic to follow if the existing logic of today is removed with #1273 .

AlanDrake commented 3 years ago

Non-script names aren't necessarily unique, so using the script name is the pragmatically correct choice. edit: sorry, yes that's why you wrote "nickname" 😅

ericoporto commented 3 years ago

A cSarahOld I could override as OLD SARAH CONNOR so the dialog script looks like:

OLD SARAH CONNOR: The Terminator changed everything...

granted I may not add a nickname to all characters, but making the dialog less code like makes revising the text easier.

ivan-mogilko commented 1 year ago

So, what needs to be specified here: 1) Which property to use? Is it Character's RealName, or a new property called something like DialogName, as suggested in this comment to #1273. 2) If it's a new property, should that property be saved into game data, is there any need for that? Otherwise, it seems it will be enough to keep it purely at the project level, and replace with script name (or rather - character pointer) at the dialog->script conversion stage (as it does now with these generated "name variants"). 3) What to use as a fallback if the property is not set? Pure Script name (without any extra conversions like cutting c off)? 4) Also need to think about project upgrade. Do we need to do anything on update? For example, we could copy a old-style name based on script name into this new property (if there is a new property). 5) Ensuring the "dialog nickname" is unique. I think at least a compilation warning may be necessary if two characters are found having same "dialog nickname".

Frankly, from the first glance this looks like a almost trivial feature. There will be an issue of updating a dialog converter tool though (and probably supporting both old and new style passed as a command arg).

EDIT: I'm almost inclined to close #1273 in favor of this suggestion, but maybe keep both for now, just for the reference? If this feature is implemented then #1273 will be covered automatically.