News:

Use the "Forum Search"
It may help you to find anything in the forum ;).

Thoughts on scale

Started by jamespetts, April 27, 2012, 10:39:03 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

jamespetts

The server game has shown what can be achieved in respect of online games with very large maps: generally, as long as the connecting clients have reasonably decent computers, even very large maps indeed (with trees, as long as the woods are not too dense) with a great number of cities (675, in this case) are perfectly playable. It is also apparent from profiling results and monitoring memory usage that:

(1) the most important restrictions on performance are CPU usage and memory bandwidth, not memory footprint;
(2) the memory footprint is well within tolerances for modern computers;
(3) CPU usage and memory bandwidth scales with the level of player activity (and, to a lesser extent, the number of cities) on a map rather than its absolute size;
(4) memory usage also scales mainly with the level of player activity and number of cities, although is more substantially affected by the absolute size of the map than CPU usage or memory bandwidth.

The server map as it is seems quite crowded, with little spaces between cities and not as much space as one might like for intricate networks, especially local rail networks. Pak128.Britain has recently incorporated some lovely Underground trains which I am hoping to bring to an Experimental release of the pakset soon. The next major release of Experimental will have physical braking, which works better at larger scales.

All this has caused me to consider substantially changing the scale on the next release of Pak128.Britain-Ex. It is currently 250m/tile, meaning that each kilometre takes four tiles in the game. I had considered increasing it to 200m/tile (each kilometre taking 5 tiles), but, in light of the above, I am now considering increasing it to 125m/tile, meaning that each kilometre will take eight tiles.

The idea would be for maps to be twice as big in tile dimensions, but to have the same number of cities as formerly (or perhaps slightly fewer, at least, for the server game - say 600 rather than 675), and for the "city isolation factor" to increase accordingly, meaning that cities are more spaced out. City clustering is likely to work better in this model, too, with more identifiable clusters of towns, and more sparsely spaced towns outside those clusters. One might also consider increasing the default town starting size and growth rate and reducing the passenger factor (and also modifying the growth thresholds accordingly). Consideration will further need to be given about how Richard Smith's parato distribution system of generating towns will work in this model.

I should be very interested in feedback on this suggestion, especially from those who have played the server game (although feedback from anyone is more than welcome).
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Carl

So the proposal is for server maps to be four times as large (E-W and N-S sizes both doubled)?

This sounds good to me -- I agree that cities are comparatively close together in existing maps and that smaller sizes would allow for more intricate networks. I've been playing a single-player map at around 125m per tile recently and have been astounded at the level of detail possible.

However, I speak as someone with a pretty capable system setup (3.40Ghz Quadcore, 8GB RAM). It would be interesting if we could come up with a useful set of "minimum specifications" for running a 4096*4096 server map.

ӔO

we can always experiment with new settings ;)

if it's 125m/tile, then perhaps station coverage should increase accordingly?
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

jamespetts

Carl - yes, indeed, doubled in each direction. Generally, the greatest performance change with a larger map per se is the increased generation time, so this should not be a difficulty for the server game.

Station coverage is an interesting question. Currently it is 3 tiles (that is, 750m). What is a realistic station coverage, I wonder? How far do all of you walk to your local 'bus stops and railway stations? Looking at my own route to a local station with Google Maps, it seems that I often walk about 900m, so perhaps this does need some reconsideration. Any suggestions?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Carl

I seem to remember someone citing research showing that coverage for bus stops is around 300-400m, and train stations around 1km. 750m is roughly in the middle...

jamespetts

Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

jk271

It is very nice to see lowering of values of meter/tile. I am delighted to see others to use values lower than defaults as me.


I am playing pak.64-exp with 100m/tile and station coverage=4 in 1837. I have found that lowering m/tile leads to lower income per month as vehicles travel shorter distance. I have solve it by increasing bits_per_month and playing with higher speed.


It would be useful to have available an alternative configuration file for values of meters_per_tile <= 100 (or 125) as other parameters are affected.

My idea is to have (in pakset) one configuration file optimized for 250m/tile. This configuration file exists now. I assume this file to be balanced for 250m/tile, so do not rewrite it. Preserve it for cases, when lower values of m/tile can not be used: e.g.: small maps due to slow hardware.

Another configuration file (an alternative configuration file) available in pakset would by optimized for e.g. 100m/tile or 125m/tile. Parameters like station coverage, default map size would be affected too.

Probably, as passes the time, the "alternative configuration" becomes "standard" and "standard configuration" becomes "alternative". And it is possible, that third configuration file suitable for 20m/tile will be used. I am looking forward to see it.

Carl

One thought: if meters per tile is lowered, should bits per month be raised to preserve month length in hours?

jamespetts

JK,

in principle, the balance should be preserved for different scales, as maintenance costs are also scaled. However, since Pak128.Britain-Ex is not balanced properly yet, it would seem to make sense to decide on the scale before that balancing exercise takes place, rather than afterwards.

Carl,

I was in any event planning to increase the bits per month value by 1 for the next release because the years were passing too quickly. Reducing the meters per tile setting should make time take longer to pass (if I have it the right way around), as vehicles will move the same number of game tiles in the same number of real life seconds, but be treated as having moved less game distance in less game time. The intention, however, is to make time pass more slowly, rather than keep it the same, so this should be sensible.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

Quote from: jamespetts on April 27, 2012, 08:48:19 PM
What is a realistic station coverage, I wonder? How far do all of you walk to your local 'bus stops and railway stations?
Here in Brno (CZ), the average distance between city transport stops (bus, trolley, tram) is roughly 500 m, but it varies a lot.
Sometimes it is only 200m. But I'm used to walk almost 1 km to the nearest tram stop, and 1-2 km to the train station.

ӔO

Quote from: carlbaker on April 27, 2012, 08:53:49 PM
I seem to remember someone citing research showing that coverage for bus stops is around 300-400m, and train stations around 1km. 750m is roughly in the middle...

average bus stop spacing is around 600m
average train station spacing is anywhere from 800m to 1200m

catchment could be up to 1000m
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

Banksie_82

May I suggest this website with regard to catchment area...


http://www.humantransit.org/


Or, more specifically, this page...


http://www.humantransit.org/2011/04/basics-walking-distance-to-transit.html

Carl

Quote from: jamespetts on April 27, 2012, 09:50:06 PM
Carl,

I was in any event planning to increase the bits per month value by 1 for the next release because the years were passing too quickly. Reducing the meters per tile setting should make time take longer to pass (if I have it the right way around), as vehicles will move the same number of game tiles in the same number of real life seconds, but be treated as having moved less game distance in less game time. The intention, however, is to make time pass more slowly, rather than keep it the same, so this should be sensible.

Reducing m/t will make time pass slower, but will also have the effect of (in this case) halving the month length in hours unless bits per month is also increased. So a month would be only 1:40 ish, despite lasting the same amount of real time.

So if you lower m/t to 125 and raise bits per month by 1, months will double in (real-time) length but will remain the same length in in-game hours.

jamespetts

Banksie - very interesting article! I wonder whether there might be some benefit in adding to the journey time computation the distance that people must walk to their local stop at their walking distance? On the other hand, that might be a very difficult task given the complexities of the routing system.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

ӔO

If it's possible, a catchment of 4 or 5 for train stations, 3 for buses and 6 or 7 for airports and maglev stations
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

The Hood

Quote from: ӔO on April 28, 2012, 03:55:25 PM
6 or 7 for airports

People don't walk to airports - they have too much baggage...

Carl

Indeed. However, scale for airports should be at least big enough to allow foot-interchange with nearby bus-stops -- which, if the airport is large, might require a catchment of at least 5 tiles

el_slapper

that excellent blog link makes me think that, ideally, cover shall not be square, but follow the roads. Of course, I guess it is not that easy to do.

sdog

@banksie, i tried to find that article again, when i saw the discussion here, but failed to remember. Thanks for posting it (again?).

neroden

James, my default setup for home games is *already* to quadruple the size of the map (double the north-south distance, double the east-west distance) while maintaining the same number of cities.

QuoteThe idea would be for maps to be twice as big in tile dimensions, but to have the same number of cities as formerly
Pretty much exactly what I've been doing.

It works nicely.  I strongly recommend it.

A couple of warning points: You will have to change a bunch of other map-generation numbers in order to compensate.  Intercity road length should already be in km.  But the numbers for river generation will have to be adjusted (more rivers needed).  And you have to fiddle with the map roughness whenever you change the size.  Also, the units system still hasn't been completely straightened out, so you may have to do some work just to keep the trains going at the same km/hr now that it's more tiles/month.  (Sigh -- I should get back to fixing that.)