Tech Specs for Huge Maps/Games

[ebla71]

The size difference is mostly due to added debugging/symbol information for annotating crash logs.

So, in general, one could comment that out and then obtain a smaller binary?

I do not think that vanilla has any interest in maps larger than 4k x 4k, it's not a purely technical limitation.

Would increasing the map size simply be changing a global constant or involve more significant code changes?

[andythenorth]

Would increasing the map size simply be changing a global constant or involve more significant code changes?

It imposes further constraints on how and in what direction the game can be developed.

The current 4k x 4k maps introduce (to varying levels) friction for the basic map array, landscape generation, multiplayer performance, and in the development of the NewGRF and script APIs.

Large maps such as 4k x 4k also introduce significant friction for NewGRF and GS authors.

It would be my preference to not have to deal with 8k x 8k maps in vanilla.

[AntoninKyrene]

Maybe we shouldn't be dealing with 4k x 4k in vanilla...

[LaChupacabra]

Maybe we shouldn't be dealing with 4k x 4k in vanilla...

You don't have to

4k x 4k maps are still the largest maps that conditionally make sense in this game without major changes.

Some obvious problems with 8x8 and larger maps:

• very long loading and map generation times,
• slow game pace, which may not even reach the basic level of x1.0,
• a huge number of vehicles needed to handle very long connections, which will slow the game down even more,
• insufficient zoom (even in the JGRPP version) and the resulting difficulty in orienting yourself on the map, on which it is very easy to get lost, especially in the case of random maps,
• the time it takes a vehicle to travel from one end of the map to the other, which can take up to several dozen years in the game and several real hours,
• creating one route lasting several/a dozen/dozens of hours (does anyone here live 300 years and can spend, for example, 40 on the game?)
• the economy and payment system are not adapted to such large or even smaller maps (since version 14.0, any transport over 500 days has become completely unprofitable)

[Josso]

With a dedicated server what's the rough recommended spec for running a 4k? Trying to determine right now whether to run one from home or not and/or which hardware to use

[kkidslogin]

With a dedicated server what's the rough recommended spec for running a 4k? Trying to determine right now whether to run one from home or not and/or which hardware to use

Any modern processor (8th gen intel/any Ryzen or later, though Mobile CPUs may need 11th gen or later), 8 gigabytes or more of RAM, whatever disk space size you want, but preferably fast. It's something with more RAM and decent network hardware if a lot of people will get on it, or if it's going to be public.

[jfs]

It's worth keeping in mind that for OpenTTD multiplayer, it's risky to have the server be better specced than the players. In general, OpenTTD servers will run the game at the speed they can (up to full speed), but if any clients can't keep up because the map is too large, they will fall behind on simulation speed, and the server will not wait for them. Slow clients will end up getting kicked off the server for being too slow.
For that reason, it can actually be advantageous to have the server for OpenTTD games be a slow computer. Then the game will just run equally slow for everyone.

Oh yeah, and do keep in mind that the savegame data for a 4k map can easily begin at 30 MB for a fresh world, and go well beyond 50 or even 100 MB for a world that has been built up. Any time a new client connects, they need to transfer the entire game.

[kkidslogin]

It's worth keeping in mind that for OpenTTD multiplayer, it's risky to have the server be better specced than the players. In general, OpenTTD servers will run the game at the speed they can (up to full speed), but if any clients can't keep up because the map is too large, they will fall behind on simulation speed, and the server will not wait for them. Slow clients will end up getting kicked off the server for being too slow.
For that reason, it can actually be advantageous to have the server for OpenTTD games be a slow computer. Then the game will just run equally slow for everyone.

Oh yeah, and do keep in mind that the savegame data for a 4k map can easily begin at 30 MB for a fresh world, and go well beyond 50 or even 100 MB for a world that has been built up. Any time a new client connects, they need to transfer the entire game.

Interesting. I always forget about this even though it used to happen to me all the time back when all my computers had low-end pre-Ryzen AMD APUs that were about as unideal for OpenTTD as seems to be possible.

This makes me wonder if a better way to handle this is server-side-only simulation with client-side prediction, like how Luanti/Minetest handles multiplayer. However, I'd imagine that, in addition to the massive changes to the codebase that this would take, this would run into the same issue as multithreading: namely, that the game state is so massive and complex that transferring it would take an obscene amount of bandwidth. To remedy this we would need some at least fairly accurate way of predicting whether part or all of the client sim was out of date, which would probably have to be client-side and thus eat up a sizeable amount of system resources. Even if it could be put on a separate thread (unlikely), it would probably just slow the game further, making it no improvement for the client.

Perhaps, then, it would be simpler to just add an option to throttle the server sim rate if a client is out of date, although I suspect this has its own problems. It would have the added benefit of being backwards-compatible.

[jfs]

It might be the most realistic to add a way for network clients to indicate, "hey please slow down, I can't keep up with that" - it's just that I could imagine it also being abused for griefing.

[kkidslogin]

It might be the most realistic to add a way for network clients to indicate, "hey please slow down, I can't keep up with that" - it's just that I could imagine it also being abused for griefing.

If the "please slow down" ask is done automatically by either the client or server then I don't see how it can be used for griefing.

[Redirect Left]

If the "please slow down" ask is done automatically by either the client or server then I don't see how it can be used for griefing.

I am guessing if you know what the net packet looks like, you could send it to the server and slow it down at will.

It is a bit weird that currently the server is unaware of it going faster than clients, but fixing it is likely to have issues. Explains why my old server from yeaaaars ago that was just a reused Intel Core2Duo actually did pretty good in its task of being an OTTD server.

[kkidslogin]

If the "please slow down" ask is done automatically by either the client or server then I don't see how it can be used for griefing.

I am guessing if you know what the net packet looks like, you could send it to the server and slow it down at will.

It is a bit weird that currently the server is unaware of it going faster than clients, but fixing it is likely to have issues. Explains why my old server from yeaaaars ago that was just a reused Intel Core2Duo actually did pretty good in its task of being an OTTD server.

Hmmm, that's true. But that could also be said of other packets.

[Josso]

With a dedicated server what's the rough recommended spec for running a 4k? Trying to determine right now whether to run one from home or not and/or which hardware to use

Any modern processor (8th gen intel/any Ryzen or later, though Mobile CPUs may need 11th gen or later), 8 gigabytes or more of RAM, whatever disk space size you want, but preferably fast. It's something with more RAM and decent network hardware if a lot of people will get on it, or if it's going to be public.

Thanks, got an old desktop kicking around that would be perfect

[mauried]

Theres nothing wrong at all with big maps from a technical perspective.
There is however an economic problem due to the way the game is designed.
Most of the vehicles in the game are slow and designed for small maps.
As the cargo payments are non linear, but the running costs are linear there is a distance limit after which all the vehicles lose money.
Too get the best out of larger maps needs the economics to be changed.

[ebla71]

As the cargo payments are non linear, but the running costs are linear there is a distance limit after which all the vehicles lose money.
Too get the best out of larger maps needs the economics to be changed.

If you care about that at all

Would assume that there is a substantial amount of players who just like to build networks but have no interest in working against an economic model thanks to "unlimited money"