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

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.

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.

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.

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

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.

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

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.

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.

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

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.

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.

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

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.