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

Add support for explicitly male/female names? #9

Open
1Hyena opened this issue Mar 1, 2018 · 7 comments
Open

Add support for explicitly male/female names? #9

1Hyena opened this issue Mar 1, 2018 · 7 comments

Comments

@1Hyena
Copy link
Contributor

1Hyena commented Mar 1, 2018

Not sure if this is a generator architecture related issue but since D and d are marked as suitable for a stupid person's name I would expect there to be types of random replacements that indicate the gender of the name to be generated. What say you?

@skeeto
Copy link
Owner

skeeto commented Mar 3, 2018 via email

@1Hyena
Copy link
Contributor Author

1Hyena commented Mar 4, 2018

@skeeto
I have to admit, I have no idea if this is even possible. It boils down to a question what makes some names feminine and other masculine. In Lord of the Rings there is a made-up language and in that language some words mean feminine things, so we get a name such as Shelob . But for generic names, I have no idea. From a game developer's point of view it is crucial to specify for the generator whether the target character is male or female, without that the random name generator (RNG) is not very practical. I guess RNGs that utilize Markov chains would not have this problem but on the other hand they would require a large database of known feminine and masculine names.

@Kronuz
Copy link
Contributor

Kronuz commented Jun 13, 2018

@1Hyena, What you need is a list of name parts for each gender; normally, the gender is in the suffix of the name; you can also have a list of house names for different tribes, for example. Then you would use those tables as the source of the two or four or whatever generators for each gender/tribe combination.

In some implementation you can easily extend the generator tables by adding your custom tables to different symbols:

In c++, you would add your tables to this:

static auto* const symbols = new std::unordered_map<std::string, const std::vector<std::string>>({

In JavaScript, you would add those to:

NameGen.symbols = {

Afterwards, you can then use such symbols in your generator at compile time.
There’s an example of extended tables here:

https://github.com/Kronuz/Xapiand/blob/30004104e3f52b8a9666bacaf15862306557e356/src/namegen.cc#L128

That example adds prefixes “K”, “L”, “E”, “F”, “k”, “l”, “e”, “f” to play with. “K” and “k” have lists of male and female prefixes and suffixes, but they’re mixed. You’d need to split the tables in two symbols (one for each gender) and use them in two or more different generators: a female drow generator, a male drow generator)

@1Hyena
Copy link
Contributor Author

1Hyena commented Jun 13, 2018

@Kronuz
thanks for the example. the solution you provided is indeed compatible with my namegen.cpp. Perhaps the main problem now is to have the actual name formulas for a relatively large number of races, including critters/vermin :D any pointers? It's a shame such public databases aren't easily available

@Kronuz
Copy link
Contributor

Kronuz commented Jun 14, 2018

@1Hyena I have no idea... if you come across such collection of names, or put one together, I’d be very interested. I’d love have there ability to generate names for multiple races.

@AquariusPower
Copy link

AquariusPower commented Jun 16, 2018

For female, this helps !ss(a) !sV,
For male, !ss(o) !sV,
not sure if good tho..
But I understand your question is about changing the code,
I just wonder if it can be accomplished using the existing features?

@1Hyena
Copy link
Contributor Author

1Hyena commented Jun 18, 2018

@AquariusPower
I actually don't know whether a template or a code change is more optimal to solve this issue.

For fantasy flavored names I'm starting to suspect that a template is the best approach as indicated by @Kronuz

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

4 participants