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

Town name language choice affects number of towns / world population #7059

Closed
nikolas opened this issue Jan 13, 2019 · 14 comments
Closed

Town name language choice affects number of towns / world population #7059

nikolas opened this issue Jan 13, 2019 · 14 comments
Labels
stale Stale issues

Comments

@nikolas
Copy link
Member

nikolas commented Jan 13, 2019

Some town name choices don't have custom generators, but just rely on a fixed list of real names: Latin American, French, Hungarian, Romanian, a few others. These relatively small fixed lists (~85 names) limit the total number of towns created in the world, because duplicate town names prevent random towns from being created in GenerateTowns(). This is related to #6640, #6309, #5864.

Creating a 2048x2048 map with a High number of towns:

English (Original): ~3,300,000 world population
French: ~80,000 world population

Solutions:

  • Make custom generators for the town names languages that lack them.
  • Add more hard-coded real town names.

Adding more hard-coded real town names corrupts old saves: I added a dozen or so more French town names, and the town names had all shifted in my savegame with French towns, and there were a bunch of duplicate town names. I'm not sure how we'll make any changes here backward-compatible with old savegames, because of how random town names are chosen and encoded in the Town struct (i.e. as a simple townnameparts index rather than an actual string). One solution to this problem would be to store each generated town name as a copied string, just like how the custom town name is stored.

@nikolas
Copy link
Member Author

nikolas commented Jan 17, 2019

I think the first step toward solving this problem is by storing the town name as a string on the Town struct, rather than as it's currently done: an index into all the town name possibilities (townnameparts). That will allow us to add more town names to the base set without affecting existing towns. As far as I can see, this will require a savegame format change, though.

I'm working on a branch that makes this change here: https://github.com/nikolas/OpenTTD/tree/town-name-str

Also, here's a nice table I found that lists out possible town names for the different choices, illustrating those languages that are limited: https://www.tt-forums.net/viewtopic.php?f=33&t=75329

@Eddi-z
Copy link
Contributor

Eddi-z commented Feb 24, 2019

I'm not sure that this will be able to comprehensively solve the problem, as we also have NewGRF town name generators, which may also fall short, and we cannot magically fix those. and we have ridiculous map generation parameters that may even exceed the town name generators on the high end of the spectrum.

A more general approach i could think of would be to extend town name generation to differentiate between failure types, so it could behave different if no location could be found, or no name could be found, and appropriate error messages be thrown after game creation if one of those conditions was met excessively often. also, the limits on how often this gets retried might be toyed with, to avoid overly excessive generation wait times.

@James103
Copy link
Contributor

My idea is that when any of the selected town name generators fail to produce a valid town name, warn the user about that and use dummy names in place of the real names. This removes one of the limits (which can be as few as <=100!) on the number of towns in a map, allowing all of the requested towns to generate provided there's enough space on the map.

For example: Town name generator has 100 possible names, but game generates 101 towns. Result: a warning saying that at least 1 town does not have a proper name due to town name exhaustion, and town number 101 getting a dummy name such as "Town 101". The player can then rename that town to whatever they like (optional) and play.

@auge8472
Copy link
Contributor

For example: Town name generator has 100 possible names, but game generates 101 towns. Result: a warning saying that at least 1 town does not have a proper name due to town name exhaustion, and town number 101 getting a dummy name such as "Town 101". The player can then rename that town to whatever they like (optional) and play.

No problem with renaming one or a few towns but what's with big maps, like @Eddi-z mentioned? No one wants to rename hundreds (or in worst case thousands) of towns.

@PeterN
Copy link
Member

PeterN commented Feb 25, 2019

In the real world, towns don't need unique names, so... perhaps we should try as we do but then reuse?

@Berbe
Copy link
Contributor

Berbe commented Feb 25, 2019

Sorry for being candid about it, but isn't there a possibility to mix languages in town names list?
That would greatly increase the available combinations.

AFAIU, it seems town names are using the game language defined by the host. I trust that settings is especially important for UI elements, but maybe that should be decoupled for town names?

The only drawback I see is mixing languages with different alphabets and/or reading direction, as players might not know/be able to how to pronounce/spell them, either orally or writtenly.

@glx22
Copy link
Contributor

glx22 commented Feb 25, 2019

Town names are notre linked to the language. It's a separate setting in the options.

@Eddi-z
Copy link
Contributor

Eddi-z commented Feb 25, 2019

In the real world, towns don't need unique names, so... perhaps we should try as we do but then reuse?

Problem i see with that is the frequency. currently, most "real world" town name sets will have the most notable towns with pretty high frequency, to make sure they appear. but if you're using the same frequencies with the duplicate names, you will get dozens of those, which might be unhelpful and undesired.

@nielsmh
Copy link
Contributor

nielsmh commented Feb 25, 2019

Yet another option might be to have hardcoded fallbacks for town name generators, when they run out. E.g. the Swiss generator which only has a fixed list, could take from the German and French generators at random, and similar rules based on real-world geography.

@glx22
Copy link
Contributor

glx22 commented Feb 25, 2019

Maybe we could enable selection of more than one town name generator, with the player deciding on which order each generator should be picked.

@nielsmh
Copy link
Contributor

nielsmh commented Feb 25, 2019

The dream solution would of course be to improve the generators that only have a fixed list, so they instead become combinatorical and can supply a much larger number of unique names.

An option that would at least make the generators with only fixed names give up fast, would be to let them pre-shuffle the list of fixed names, and return them in shuffled order. That makes it simple to detect when they're exhausted.

@nikolas
Copy link
Member Author

nikolas commented Feb 25, 2019

The dream solution would of course be to improve the generators that only have a fixed list, so they instead become combinatorical and can supply a much larger number of unique names.

Yeah, and I still think there's a place for the "real world" lists, as not all town names can be generated with an algorithm. Some of the generators, like German and Finnish, use generated names in combination with a fixed list of real world names.

I also think it would be nice for these real-world town lists to allow people to add new town names to them, without affecting existing gamesaves. That was the motivation behind my store-townnames-as-strings idea. It's a lot simpler for people to come up with a patch adding a list of town names rather than writing a new town name generator.

Yes, there are town name NewGRFs that everyone's free to use and modify. But then what is the goal of these OpenTTD core town names, especially when many sets, like French, hinder the game in this way? Maybe it's worth considering the removal of these core town name sets, and only rely on NewGRFs, like the graphics and sound basesets.

The ideas here are good: fallbacks, allowing duplicates, but the core problem remains - a low number of town names in the sets that don't have custom name generators.

@Eddi-z
Copy link
Contributor

Eddi-z commented Feb 25, 2019

Yes, there are town name NewGRFs that everyone's free to use and modify. But then what is the goal of these OpenTTD core town names, especially when many sets, like French, hinder the game in this way? Maybe it's worth considering the removal of these core town name sets, and only rely on NewGRFs, like the graphics and sound basesets.

IMHO, two things need to happen if we want to move in this direction:

  1. using town name GRFs must be made easier, i.e. the game must scan all NewGRFs whether they are town name GRFs, and automatically load them (independent from any NewGRF presets or NewGRF file limits)
  2. the old generators must be kept for savegame conversion to the new string-based format, and NewGRF versions of them provided with the game directly

@stale
Copy link

stale bot commented Apr 26, 2019

This issue has been automatically marked as stale because it has not had any activity in the last two months.
If you believe the issue is still relevant, please test on the latest nightly and report back.
It will be closed if no further activity occurs within 7 days.
Thank you for your contributions.

@stale stale bot added the stale Stale issues label Apr 26, 2019
@stale stale bot closed this as completed May 3, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale Stale issues
Projects
None yet
Development

No branches or pull requests

8 participants