I've been trying to learn TAB and decided to give my test project's "player" the option to name themself, and at once was faced with the current state of the "name" menu.  It's neat, but I have a suggestion or two ...

Firstly, I think the author being able to decide to leave out some of the options could be beneficial.  For example, in my test project's setting, I don't intend for the player's last name or honorific to be mentioned anywhere, so having to type in a surname and a variation of "Mr." (the game stops me and demands answers if I leave these fields blank) is just a bit of a time waste when only the first name will ever be relevant.  Though for some devs, maybe they'll have the opposite problem and only want the player to choose their surname and title!  Some people might also make games where the player's gender is irrelevant or predetermined, and may not want to give the player the option of being a boy or girl (maybe it's even a secret!) even if they want them to have the option of their own name.

Building off of my previous point in a related direction, I myself would appreciate the availability of more possible gender options for a player.  The engine already supports "it" gender for NPCs after all, so why not players?  Might be useful if one is playing a plant, animal, or a robot, perhaps; though an option for a singular "they/them/their" pronoun set might be preferable for most humanoid characters of less certain sex... or maybe if they contain multitudes.  Anything can happen in a game.
A different game-making programming language I know a solid amount of has sometimes considered adding additional genders to its code options for characters, but has gotten so far now that creating more than the default two would apparently require rebuilding a significant chunk of the source code even though by now most have come to agree that nonbinary options would be useful for undead, magical, bestial, and similar entities both in terms of story and in if/then checks (ex. if you want to make a Siren's song only work on men, you have to painstakingly add several filters to account for, say, all zombies and spiders technically being "male" in the code because that's the default gender given to an entity when its gender is unspecified).  I mention this because I am unsure of how the deep source code of both that language's and TAB's work, but I think it goes to show that sooner integration of such features rather than later could be beneficial regardless of if one's playerbase contains nonbinary-transgender individuals or not.

To conclude, I can work with the current required options and limitations-- am planning on simply rolling with the current two gender options for my test project and putting placeholders in the surname and title fields-- I just think it'd be cool for developers to be able to expand or limit these options more as best fits their game's intended experience.

Hi Somnosa,

Thanks for your observations.

You wrote:
>>>Firstly, I think the author being able to decide to leave out some of the options could be beneficial.  For example, in my test project's setting, I don't intend for the player's last name or honorific to be mentioned anywhere, so having to type in a surname and a variation of "Mr." (the game stops me and demands answers if I leave these fields blank)<<<

I *might* be able to change the player name dialog box so it would be accepted with a first name only (like a  player username or alias). That would mean you would not be able to refer to the player surname or sex tags in coding entries though as the surname string would be empty and the sex value incorrect.

Regarding adding different genders for the player. This would be very difficult to implement now after so long and complicated code.
Again, I could probably allow for the player to ignore selecting either of the male/female checkboxes on the dialog and still have the dialog accepted... This would be simply in case a player did not wish to divulge that information or did not identify with those 2 options.

With the Non-Player Characters there is a possibility that the new Character Prefix facility recently introduced would allow extra things to be printed about an individual character using the character prefix codes in messages. It could be worth looking into that.

You can enter a maximum of 9 extra text/attributes/traits for a character.
That means you might possibly include specified gender names or identity pronouns or other designations if you wished...)

Firstly you would enter your Characters as normal from the Character Editor and fill in all the required fields.

You would then need to make bracketed entries for each Character created like below into System Message 99.

This example shows three Characters 1,2 and 3 who each possess just 2 extra Character prefixes.

Each element number should be filled with similar text that is relevant for that particular character.

System Message 99
================
Character Prefix Table

[Char number.prefix number]

eg: the first prefix number for Character 1 is [1.1]
eg: the second prefix number for Character 1 is [1.2]

[1.1]him/he[1.1]
[1.2]gay[1.2]


[2.1]she/her[2.1]
[2.2]bisexual[2.2]


[3.1]they/them[3.1]
[3.2]gender neutral[3.2]


===============

You can print the text of the character prefixes using tags in a message
eg: %c1.1%  which would print: him/he

eg: %c2.2% which would print: bisexual

Also there are tags to substitute the Character n1 or Character n2 noun for a currently referenced Character Noun number (1-100)

%cn1.1% to %cn1.9%
%cn2.1% to %cn2.9%

eg: %cn1.1% refers to prefix element #1 in Character Noun 1's entry in the Character Prefix Table providing it exists in System Message 99.

Similarly for a general purpose message for a valid character noun2 in the input

%cn2.2%  - print the second prefix for character noun2 in the text.

Depending on the character noun2 typed in the above table could be printed as either
gay
bisexual
or
gender neutral


Heehee Sorry about the gender designations  - but you get the general idea.

Some clever things can be done with the prefix tables but I really couldn't say if this approach would be of any use in your game...

Regards,
catventure (Philip}