Suggestions about passenger destinations

[Apostate]

I've got several suggestions as far as passenger destinations are concerned.

1. Capitals (a bit similar to Jackal's idea)

With passenger destinations it will be extremely difficult to fill a transcontinental flight. If we base the demand for transportation on distance as well as town size, obviously few people will want to go to the other corner of the map. If we disregard distance (which is unrealistic) there will be so many destinations, that the stream of passengers will be extremely diluted (1 large city on a normal map would generate an average of 40 passengers a month to each other city). If all passengers consider only the routes that are serviced by the player, we apply the same unrealistic model as in TTD. My suggestion is to make one city on the 256*256 map a capital and a few cities regional capitals. On larger maps there would be several nations with their own capitals (it's similar to the idea of Jackal in the post below, but he concentrated on transport exclusivensess within the borders of one country). Every city would generate lots of passengers to the capital, lots of passengers to its regional capital, some passengers to other regional capitals, some passengers to the neighbouring cities and few (if any) passengers to other cities. Of course it would be wise to take the distance and size of cities into consideration as well. The capital would also be larger at the beginning, grow faster and generate bigger demand for goods (when the concept of demand is introduced). The benefit of this model is that we have a realistic way of employing our transcontinental supersonic flights and state of the art IC trains with passenger destinations. It also seems to have some potential for interesting rail networks (imagine the busy central station in the capital and 6-track lines around it).

2. Coverage areas

It strikes me as weird that a person who wants to board a 1000-tile flight will be discouraged by the fact that he or she lives one tile too far from the airport. In the present system it's also very hard to operate coach services between cities, because every bus stop gathers passengers only from 3 tiles away. With passenger destinations it would be a nightmare to put all the passengers who want to go to city X in one coach. And imagine running dozens of coach services to various cities... My idea is that all passengers to other cities should gather on the appropriate stops / stations / airports / docks as long as they are connected to the road system and are within reasonable range from the city centre. Every tile away could increase the percentage of discouraged customers slightly to encourage careful positioning of stations. Introducing this concept wouldn't mean an abrupt departure from original ttd, as even currently, with large station spreads the distances covered by potential customers WiTHIN stations are sometimes really immense, not to mention disconnected stations. It would also allow for more realistic positioning of airports (a bit outside of town, but connected with a road).

Of course this idea suffers from several problems. For example fast growing cities often effectively merge with their neighbours, which would mean another artificial border (and people from beyond wouldn't board planes...) Firstly, I hope that with the new growth algorithm we won't be able to make a city grow to pop 15000 with 20 - 30 buses. Secondly, we could make the game merge such cities into one, with one name.

3. Demand for luxury

In the simplified economic model of OTTD (which we love) the player has no control over prices. We can safely assume that the price always accurately reflects the quality of service - the only variable the player is in control of. With sufficient distance and number of passengers to a specific destination the town could generate passengers with varying demand for luxury - which in OTTD means speed. There could be 4 groups of passengers' expectations, roughly reflecting: a supersonic flight, a normal flight, an intercity train, a slow train or a coach. If no transport route according to expectations is available, passengers could choose a cheaper one, however some of them would be discouraged by the poor conditions of travel. Passengers would never (or almost never) choose a means of transport more expensive than their expectations - they just can't afford it. The benefits of this concept would be immense. For example the player would be able to introduce cheaper modes of transportation without the fear of cannibalising profits of their fast transport. With enough passengers, like between a regional capital and the main capital, it would be possible to operate 2 types of planes, 2 types of trains (direct intercity and local trains stopping on every station) and coaches.

4. Symmetry

I hope the new system will consider the fact that passenger traffic in both directions should be symmetrical, unless we introduce massive migration. Now in OTTD it's possible to operate an airline between a large city and a small town. Planes go to the small town filled with passengers, but come back almost empty. I guess the passengers walk back home, because they can't afford return tickets...

[Horse]

Passengers changing their lines.
In a large railway station they can take other train or bus.
A large airport not in the city but outside the towns with a railway station to bring the passengers.
even as in real life.

And that you can connect your network on the network of other players. so that passengers can use different companies to reach their destination.

[Pimmeh]

isent this EXTREMELY hard to code?
It reads like an exellent idea but....the coding!

[SpComb]

Ah, only now am I realizing the true complexity of having passangers (mail) with destinations and Bigmaps. When I origionally thought about passangers with destinations, I envisioned a differentiation between Local and 'mainline' passangers (inspired by the DBset passanger coaches). Station catchment areas would behave differently for the different passanger types. Local passangers would behave in a way similar to the current system, with a stricly defined catchment area. Mainline passanger station catchment areas would behave differently, attracting passangers from a far larger area (in an inverse-ish proportion to the distance (per road-tile or as the crow files?) from the station). Depending on the distance of the journey and the availability of stations, passangesr might even come from neighbouring towns, as long as there is a road connection. The destinations of local and 'mainline' passangers would have to depend on the distance. Local passangers would include commuter services in Metropolises, as well as smaller-distance services, e.g. rural areas. The idea is that a passanger take a local service to get a mainline service, and then a local service.

<insert>You are talking about how there would not be enough passangers for long-distance flights. That is not true. Small flows of passangers would take trains&busses (small/local transport) to the airport, wnd then fly across half the map, then take small transport to their specific destination.
What you need is to organize all transport into a heirarchy, you would have the busses on the bottom, and you would have many of them, and then you would have the supersonics and ICE-3s on the top, and few of them. Passangers would start from the bottom, go up, and then come down again. Depending on the distance they would be willing to go higher up the pyramid. You would have merging flows of passangers. However, the idea of capitols fits in with this idea, but it doesnt nescesarily have to be programmed into the game, it would be more of a natural evolution. in the course of time, some nodes of your netowrk would become bigger, and evolve into super-nodes. You would not nescecarily have to fill that superjet with passangers from the town that the airport is in, you would bring passangers from neighbouring regions to the airport.

OK, none of this is very coherent, but this is a complicated idea. Very complicated. But it needs to be thought through. I think that I will try and draw some graphical examples for this.

[Apostate]

isent this EXTREMELY hard to code?
It reads like an exellent idea but....the coding!

I have very limited experience in coding, so the devs would be the right people to ask about it, but I will try to answer nevertheless.

1. The capitals wouldn't be any harder to code than "ordinary" passenger destinations - which still means extremely hard. But it's only a matter of deciding upon a formula which we want to use. The number of generated passengers would be either a function of distance and populations alone or of 3 factors - distance, populations and status as a capital. My method could even prove easier, by greatly reducing the number of potential destinations, which I will write about in my reply to Mr Combustion.

2. Not hard at all.

3. This one seems extremely hard, I admit. It adds complexity to issues already immensely complex. Yet, consider the fact that any algorithm of passenger destinations has to decide somehow if they board a concorde or a train. Of course it could be done in a simplistic way, for example everyone could choose the fastest mode of transport.

4. Symmetry doesn't seem hard to achieve. If 100 passengers go from X to Y you just add 100 passengers from Y to X in the next month(s) according to some simple formula. If for some reason there is no return service, the number of passengers drops rapidly. For a player it would be very easy, because he or she would almost always have vehicles full on the return journey.


Dear Mr Combustion

Your idea of local and mainline passengers is very good. It's the mainline passengers that cause problems. I would advocate shaping catchment areas according to roads, because then the player would be able to influence them. You are right that under some circumstances passengers should come from neighbouring towns (especially with effectively merged towns, which are so common due to the current town growth algorithm).

I understand your idea of transport hierarchy without centres defined by the game. In a standard 256*256 game it would mean up to 50 destinations from each town. If you wanted to take the passengers from one corner to the other with a concorde you would have to gather passengers from 4- 6 towns, which could be done almost automatically if the local transportation system was good. However, managing and optimising it would be a nightmare unless someone came up with a clever solution for a user interface.

In my system 95% of passengers would like to go to: one of 3-4 neighbouring cities, the capital, or one of 3-4 capitals of regions, which means some 8 destinations from every city. You could completely disregard the other 5%. User interface would be simpler, managing transport would be much simpler.

Now, consider a large map - 2048*2048. There can be up to 3200 cities on such a map, if my calculations are correct. It would mean either almost 3200 destinations for each large town (good luck managing it) or no passengers to cities far away. I think we will agree that Concordes are made for flights across large maps, so it would be great to have some passengers for such flights and be able to manage them without scrolling 3200 destinations... In my system each city would generate passengers to a bit more than 20 destinations: a few neighbouring cities, a few regional capitals and some 16 national capitals. Isn't it better than 3200?

Of course we would still have to find some clever ways of managing return traffic from one of the central capitals to 3200 cities (maybe further simplification could be the answer?).

And, BTW, you would have a hierarchical transport system, but it wouldn't appear out of nowhere, but would be guided by the game.

[StavrosG]

I believe things should remain simple:
The passengers that DO show up to the stations should want to go to already serviced destinations, using established routes.

[jungle]

I think it can be made simpler.

It is true that real airports / high speed rail links collect passengers from much bigger areas than on the current version of OTTD, but they don't do this by walking. They use other modes of transport to get there. So the walking-distance catchment area should probably remain - even for airports.

What needs to be enabled is for passengers to be intelligent enough to change to get to their destination. So they'll automatically take a bus from their small town to the nearby city's airport to go to the capital. Passengers would travel only to places on the list of destinations available to them locally, limited by a maximum number of connections.

Maybe as part of each vehicle's list of orders (but invisible to the user), the time it took at last attempt to carry out those orders could be included. That would avoid the need to calculate complex estimates of travel time.

OK, so this would still be horrendous to code - but it might be better than having to explain concepts like arbitrarily allocated capitals and dynamically-changing catchment areas to the end user.

I do like the idea of a proportion of people being poorer than average and thus making a choice not to take the fastest (most expensive) route. However, that would mean introducing varying prices to passengers into the game, which would complicate things a lot.

[Apostate]

I believe things should remain simple:
The passengers that DO show up to the stations should want to go to already serviced destinations, using established routes.

It would be exactly like that in my idea. The passengers to non-serviced destinations would appear in the city screen, so you would know where they want to go. Passengers would appear at the station only if they knew they can get to their destination from there (as in real life).

For example: we have a city A, which generates 1000 passengers a month. 200 want to go the capital of A's region; 200 to the central capital; 50 to each of capital's of other regions (together 150); 150 to each of 3 neighbouring cities. If you make a connection with the regional capital only 200 people appear, not 1000. As the variety of your tranport services increases, the number of passengers will also increase. Yet, people who want to go the capital won't go to some other city, because you offer only such services.

And explain me your idea of destinations. Did I understand correctly, that if you offer only a Concorde to the other side of the map (no other transport) every single passenger will want to go there (1000 people in my example)?

It is true that real airports / high speed rail links collect passengers from much bigger areas than on the current version of OTTD, but they don't do this by walking. They use other modes of transport to get there. So the walking-distance catchment area should probably remain - even for airports.

They wouldn't do it by walking. They would take a taxi, a cab, drive a private car or walk. We shouldn't imagine that the means of transport supplied by the players are the only ones available in the gameworld.

What needs to be enabled is for passengers to be intelligent enough to change to get to their destination. So they'll automatically take a bus from their small town to the nearby city's airport to go to the capital. Passengers would travel only to places on the list of destinations available to them locally, limited by a maximum number of connections.

Of course. They would have to change according to my idea too. The problem is that we have to minimalise the enormous computational needs of such a feature and make it powerful enough at the same time. I think that we have to limit the number of changes to 2. On a large map with many passenger routes it would already mean hundreds of routes to check for main stations and dozens for small stops.

Lets suppose you want to fill a long range IC train with passengers. I presume that according to your idea the number of passengers to a given destination would be inversely proportional to the distance. It means that for a long distance train you have to collect passengers from a large area (say 10 cities) and at the end station of the train supply buses that take them to their final destinations (say 10 cities). It means already 2 changes! You have to deliver your passengers EXACTLY to the station and take them EXACTLY from the station, so you wouldn't be able to use your normal bus network. What is more, your passengers wouldn't be able to take competitors' buses! Players would be encouraged to make gigantic transport hubs, with connected railways stations, bus stations and an airport (which isn't realistic at all). A station in another part of the city would be useful only for local traffic.

On the other hand, according to my idea, passengers from the region would want to go with your IC to a distant capital of another country. They would be able to come to any part of the city with either buses or trains (only one change). It means you would be able to use your normal local trasportation system, because you wouldn't be required to deliver all the passengers to the station + airport + bus station. You would have one change in reserve, so people would be able to go by bus to the local capital, then by train to the national capital and then by plane to another country.

Maybe as part of each vehicle's list of orders (but invisible to the user), the time it took at last attempt to carry out those orders could be included. That would avoid the need to calculate complex estimates of travel time.

Exactly, it's a great idea. A rough estimate would be required only for the first run of a new vehicle. The time could be visible to the user, why hide it.

OK, so this would still be horrendous to code - but it might be better than having to explain concepts like arbitrarily allocated capitals and dynamically-changing catchment areas to the end user.

I would like to hear you explaining these concepts to the end user:

- To operate a profitable airline you have to maintain at least 40 bus routes EXACTLY to the airport, not even one tile away
- So, you thought fast airplanes are great for long distances? Of course they are. You just have to collect passengers from 80 cities in one corner of the map EXACTLY to the airport and in the other corner of the map take them EXACTLY from the airport to another 80 cities.
- Yes, people from this town want to go to 80 (800?) different places. You know, it's well connected to the transport network. Yes, you have to scroll through the list and find the destinations on the map if you want to manage your passenger trains.


The "dynamically changing catchment areas" aren't so hard to explain at all. A station, if it is connected to the road system, collects intercity passengers from the whole city and from neighbouring cities if they are close enough.

I do like the idea of a proportion of people being poorer than average and thus making a choice not to take the fastest (most expensive) route. However, that would mean introducing varying prices to passengers into the game, which would complicate things a lot.

You wouldn't have to introduce varying prices, because they are already in the game. Take a look at cargo payment rates -> passengers. People pay much more for fast travel. As I wrote, I like the simplified economic model in which you don't set prices.

P.S. Your ideas look a bit better if it is computationally feasible to support routes with more than 2 changes. However, it is unlikely. In your idea, with an average of 4 links per station (a rather conservative assumption in the endgame), 2 changes already mean 64 possible routes for every stop, most of which have to be considered (because people want to go everywhere). In my idea it would be more than 64 routes (a town can have multiple stations), but:
1. For every town, not station;
2. More powerful, as I have shown;
3. Most of them can be safely disregarded, because people want to go to no more than 20 places from every town.

[DaleStan]

What needs to be enabled is for passengers to be intelligent enough to change to get to their destination. So they'll automatically take a bus from their small town to the nearby city's airport to go to the capital. Passengers would travel only to places on the list of destinations available to them locally, limited by a maximum number of connections.

Of course. They would have to change according to my idea too. The problem is that we have to minimalise the enormous computational needs of such a feature and make it powerful enough at the same time. I think that we have to limit the number of changes to 2. On a large map with many passenger routes it would already mean hundreds of routes to check for main stations and dozens for small stops.

I believe Simutrans checks for an unreasonably huge number of transfers (vehicle changes, as opposed to stops) before giving up (definitely in the tens, possibly in the hundreds), and I haven't had trouble with it.

[Apostate]

I believe Simutrans checks for an unreasonably huge number of transfers (vehicle changes, as opposed to stops) before giving up (definitely in the tens, possibly in the hundreds), and I haven't had trouble with it.

Correct me if I'm wrong, but in Simutrans you can't have more than 64 cities, can you? It's only a bit more than on a normal map with high number of cities in OTT.

But maybe I've overestimated the complexity of introducing passengers changing vehicles multiple times. It would be best if someone competent could tell us what they think. If it was so, this part of my arguments would be disproved. However, other arguments seem to stand, for example superfluous complexity from the player's point of view.

[DaleStan]

I believe Simutrans checks for an unreasonably huge number of transfers (vehicle changes, as opposed to stops) before giving up (definitely in the tens, possibly in the hundreds), and I haven't had trouble with it.

Correct me if I'm wrong, but in Simutrans you can't have more than 64 cities, can you?

I think you are correct, but IMO, that point is moot.

AIUI, in Simutrans, each passenger wants to go to a certain tile (or possibly some small (<=3x3) area). Said passenger only appears if there is service from the tile he is on to the tile he wants to go to. Otherwise, he's thrown into the "no route to destination" group.

[Apostate]

.
AIUI, in Simutrans, each passenger wants to go to a certain tile (or possibly some small (<=3x3) area). Said passenger only appears if there is service from the tile he is on to the tile he wants to go to. Otherwise, he's thrown into the "no route to destination" group.

Then it seems I must have overlooked some smart, efficient and powerful way of dealing with passenger destinations. And it's a pity that I don't understand Simutrans at all.

[jungle]

Of course. They would have to change according to my idea too. The problem is that we have to minimalise the enormous computational needs of such a feature and make it powerful enough at the same time. I think that we have to limit the number of changes to 2. On a large map with many passenger routes it would already mean hundreds of routes to check for main stations and dozens for small stops.

All the possible destinations and number of changes could be worked out and stored when a station is built, rather than recalculated each time a passenger questions where he/she can go. The game could compile this list from the pre-existing destination lists of the first existing stations it connects to, so it wouldn't have to scan the entire network even every time a new station was built. This would make many more changes than two possible without eating up massive amounts of processor time. However, it would admittedly tend to eat up fairly huge amounts of memory.

You have to deliver your passengers EXACTLY to the station and take them EXACTLY from the station, so you wouldn't be able to use your normal bus network. What is more, your passengers wouldn't be able to take competitors' buses!

This is a very good point. Maybe when building a list of possible destinations for a station (i.e. when it is built), it could also create a second list of 'nearby' stations, which passengers arriving at that station would be able to walk to.

Players would be encouraged to make gigantic transport hubs, with connected railways stations, bus stations and an airport (which isn't realistic at all). A station in another part of the city would be useful only for local traffic.

It is in some cases realistic - if you look at London, there are huge transport hubs all over the place. From my local bus stops I can get to only three or four destinations. However, if I go to Waterloo and change, I can access almost anywhere in London, much of Southern England, and in addition Paris via Eurostar (should ever have the money to use it). If a way is found around the problem of rival routes and walking connections, then it wouldn't be such a problem.

On the other hand, according to my idea, passengers from the region would want to go with your IC to a distant capital of another country. They would be able to come to any part of the city with either buses or trains (only one change). It means you would be able to use your normal local trasportation system, because you wouldn't be required to deliver all the passengers to the station + airport + bus station. You would have one change in reserve, so people would be able to go by bus to the local capital, then by train to the national capital and then by plane to another country.

I see what you're saying, and it probably would be easier in some ways, especially in integrating rival companies' routes - but I do think it's preferable if possible to avoid a rigid structure where you're stuck with one city as the 'capital' of a huge region and all traffic (other than direct single route traffic) has to go through it.

- So, you thought fast airplanes are great for long distances? Of course they are. You just have to collect passengers from 80 cities in one corner of the map EXACTLY to the airport and in the other corner of the map take them EXACTLY from the airport to another 80 cities.

Well - only if the number of changes are restricted to two. With three or four changes it'd be relatively easy, so long as you had built up a local network in the area.

- Yes, people from this town want to go to 80 (800?) different places. You know, it's well connected to the transport network. Yes, you have to scroll through the list and find the destinations on the map if you want to manage your passenger trains.

Well - if people are only allocated between places that they actually can go to that shouldn't be such a big problem. As you said, under this system, the majority of long distance passengers would be getting to their destinations via some sort of 'hub' station. So you'd just have to provide sufficient access to the hub to get a good rating.

I'm not sure there's really a single right answer on how to implement destinations - I can see whoever ends up developing it will have their work cut out, anyway

[Apostate]

All the possible destinations and number of changes could be worked out and stored when a station is built, rather than recalculated each time a passenger questions where he/she can go. The game could compile this list from the pre-existing destination lists of the first existing stations it connects to, so it wouldn't have to scan the entire network even every time a new station was built. This would make many more changes than two possible without eating up massive amounts of processor time. However, it would admittedly tend to eat up fairly huge amounts of memory.

Actually, I think the game would have to recompute the data whenever orders are changed and include a new route (or no longer include an old one). But of course it's almost the same. If the network is sufficiently interconnected and many changes are allowed, the game would have to scan every existing connection, but it seems not to be a problem, as Simutrans accomplishes it. When DaleStan pointed it out, I tried to take another look at Simutrans, but its user interface makes me mad. Allegedly you can get info about preferred passenger destinations by clicking at the town hall, but I couldn't make out anything without a microscope

This is a very good point. Maybe when building a list of possible destinations for a station (i.e. when it is built), it could also create a second list of 'nearby' stations, which passengers arriving at that station would be able to walk to.

Probably it can be done and it's a sensible idea. However, I loathe excessive micromanagent, so I would rather simplify it. People changing trains would generate local traffic with local destinations. Transport from one station to another would be in great demand, but if you didn't supply it the game would assume that passengers managed to get to another station themselves. Of course I can understand the fact that you prefer enhanced control over the whole process.

It is in some cases realistic - if you look at London, there are huge transport hubs all over the place. From my local bus stops I can get to only three or four destinations. However, if I go to Waterloo and change, I can access almost anywhere in London, much of Southern England, and in addition Paris via Eurostar (should ever have the money to use it). If a way is found around the problem of rival routes and walking connections, then it wouldn't be such a problem.

Yes, of course. There are various models of transport. What I meant was that you rarely have one central station within walking distance from an airport (and maybe a seaport). In the area of London you have not only Heathrow, but also Stanstead, which is really far away. But of course if many vehicle changes are enabled, we could model Stanstead very accurately as an airport far from the city but with good bus/train connections.

I see what you're saying, and it probably would be easier in some ways, especially in integrating rival companies' routes - but I do think it's preferable if possible to avoid a rigid structure where you're stuck with one city as the 'capital' of a huge region and all traffic (other than direct single route traffic) has to go through it.

When I proposed it I thought it was inevitable, especially on large maps. Apparently it isn't and my misconception was a result of incompetence in computer science and/or game design. However, I would still like to somehow avoid overly loose structure (as opposed to rigid structure from my proposal) in which everyone wants to go everywhere. With many changes possible for the passengers and a well developed network you would get passengers to every city (some 50 on a standard map with many cities) or even to every station, if you want the system to be that specific. And (I'm sorry that I insist on tackling this problem over and over) you would have to consider even small streams of passengers if you wanted to operate long distance routes.

Well - if people are only allocated between places that they actually can go to that shouldn't be such a big problem. As you said, under this system, the majority of long distance passengers would be getting to their destinations via some sort of 'hub' station. So you'd just have to provide sufficient access to the hub to get a good rating.

But you would have to manage at least the capacities and orders of various means of transport. Insufficient number of local buses in one city could influence the profitability of your transport network 1000 tiles away. Or you could have funny problems, like: Why did these people come to the bus stop? How can they get to Arlington? Answer: With 9 changes they can. I see it as micromanagement nightmare, although I consider myself a passenger destination enthusiast. I wish I could stomach Simutrans, because then I would be able to criticise or approve this approach more competently.

[DaleStan]

Why did these people come to the bus stop? How can they get to Arlington? Answer: With 9 changes they can.

That's why Simutrans reports both where they want to go, and what station they will next change vehicles at.

I suppose I should go get the latest version of Simutrans and construct a passenger network, so you can just load the game and see how it works, instead of having to construct your own.

[Apostate]

I suppose I should go get the latest version of Simutrans and construct a passenger network, so you can just load the game and see how it works, instead of having to construct your own.

Actually, I've downloaded a savegame which is supposed to show a good passenger network. It looks just as I suspected. Everyone wants to go everywhere. You get passengers to dozens of destinations on each station. Although everything is quite interconnected, still 2/3 passengers can't find a route to their destination due to missing bus stops. The map at town hall doesn't convey any useful information. It's just uniformly orange, showing that people want to go everywhere.

But, if this level of detail is achievable and desirable, maybe it's the way to go. I will just have to turn off passenger destination, for example to use fast passenger trains and planes before I build 438 bus stops.

[SpComb]

K.I.S.S
Keep It Simple, Stupid.

I think this is getting very, very complicated.
[Edit]Mabey its just a complicated thing anyways. This post turned out a LOT longer than I intended it to.

Passangers only beign able to change twice? If this is the only possibility, then just forget Passanger with destinations. It would be pointless with passangers only beign able to change twice. Passangers with destinations would only make sense if they can change multiple times (ten would probably be enough, a bit more would be better). Could someone that actually programmes OTTD say wether this would be possible? (esp. with the tile-based destinations discussed below).

Capitols? Forcing that kind of rigid structure on a player is probably not a good idea. These networks should ideally be self-organizing. In my TTDPatch game, I spend a lot of time on my passanger networks, I usually imagine that the passangers have destinations, and build my networks accordingly. I don't make as much money as I could otherwise, but I don't care about that.

The should not be anything wrong with transport hubs. Remember, this is a game, and sometimes gameplay is more important than conforming to the real world.

Now, the main issues that I can see are with station catchment areas, and what algorithim should be used to decide the destination of a passanger.

1. Station catchment areas. When I want to get to town, I bike the 1km to my local tram station. If we want to fly to Finland, we drive the 30km to the airport. This can't really be modeled accurately in OTTD, seeing as how the towns are so small in comparison to the real world (although, this brings up another point for discussion, mabey the scale of everything ought to be changed, now with bigmaps. We could have more realistically sized towns/make all buildings bigger). When this is programmed, it must also be taken into consideration that the system must work for the small 100 pop towns in the beginning of the game, as well as for the 10,000 pop cities in the year 2000. Mabey the destination algoritim should also take into account the current year. Obviously, the current way of doing that is a bit incomplete. However, a possible solution would be that not all stations behave in the same way. It should be possible to construct differentiated "local" and "mainline" stations (my local tram-stop is different from the main station in Munich). Local stations would only generate passangers from a finite (and small) area. They could be used for small towns, as well as inner-city trains. Mainline stations would have a far larger reach, they would generate passangers from the whole town (and possibly neighbouring towns). Also, local "feeder" services would be important. The question is what would stop players from only using mainline stations. Mabey making them horrendously expensive would help. Possibly, a third type of station, a "country" station would be nescecary, it would be used for small towns, and would also attract passangers from the whole of the town it is situated in. So basically we would have three kinds of station, that would all behave differently:
-Local/commuter stations
-Country stations
-Mainline stations

2. Passanger generation algoritim. This is a tough one, as here we come up to all the problems with with there beign only a tiny amount of passangers for each destination. First off, though, we need to decide if destinations are tile-based or just town-based. This is a bit of a problematic situation. In jumbo-cities, only tile-based destinations would work (how else would intra-city services work on the destinatione end?), but in small towns, its not as important. Mabey the best way to do this would be to make destinations tile-based, and then link destinations with the station catchment areas. That would actually take care of that issue, but It would probably use a horrendous amount of RAM. Also, it is important that the destination generation algoritim be influenced by the current date. The game cannot expect the player to take passangers to (nor would the passangers want to go to) towns on the other side of the map. Another important point is wether passangers should also return to where they came from. This is also a important issue. And if so, after what time period?
Fresh paragraph. The destination algorithim should generate very little traffic to small, rural towns, most of the traffic should be generated to the larger cities, and to the "local" towns (towns that are close to the source). The size of the town should be more important than the distance.

OK, I just broke ther KISS rule there myself, so Im a bit of a hypocrit. I havent really said all that I could say there, But I don't want to say any more. I believe that we are now only left with two issues to resolve, the destination generation algoritim and station catchment areas. The idea about capitols sounds nice, but its too rigid to be suitable. It would be simpler, but I am against it.

Please try and keep to the KISS rule, if at all possible. Although this might just be too complicated for that. Oh dear, my mind is in a state of chaos.

[Apostate]

The KISS principle is very dear to me, so I will try to apply it to your ideas

Passangers only beign able to change twice? If this is the only possibility, then just forget Passanger with destinations. It would be pointless with passangers only beign able to change twice. Passangers with destinations would only make sense if they can change multiple times (ten would probably be enough, a bit more would be better).

Actually, it turned out that I was mistaken. In Simutrans passengers are able to change 8 times, and you can set an even higher number in the configuration file if you feel the need to. Of course it could still turn out to be a problem with big maps and thousands of destinations. The game would probably have to run Dijsktra's shortest path algorithm or A* (which is used for new train pathfinding, isn't it?) for a rather complex graph everytime a route is added or deleted.

The should not be anything wrong with transport hubs. Remember, this is a game, and sometimes gameplay is more important than conforming to the real world.

With multiple changes immense tranport hubs would be avoidable. Stations collecting mainline passengers from whole cities would also help.

(snip)
So basically we would have three kinds of station, that would all behave differently:
-Local/commuter stations
-Country stations
-Mainline stations

To keep things simple I wouldn't introduce multiple types of station. Someone already proposed dividing _passengers_ into mainline and local ones. The passengers would behave differently, not stations. Mainline passengers would come to a station from whole town, local from its catchment area. So, if you had a bus station in a city centre, it would collect local passengers to the suburbs from its surroundings, but passengers for a coach to another town from the whole city.

2. Passanger generation algoritim. This is a tough one, as here we come up to all the problems with with there beign only a tiny amount of passangers for each destination. First off, though, we need to decide if destinations are tile-based or just town-based. This is a bit of a problematic situation. In jumbo-cities, only tile-based destinations would work (how else would intra-city services work on the destinatione end?),

I'd like to keep it simple. Cities as destinations would be best. If you want to get cured of ideas about tile based destinations, play Simutrans As far as local services are concerned: if 2000 people a month come to a station in the suburbs, it generates 2000 additional abstract local passengers to various destinations in the city (and of course 2000 return passengers). If you manage to move them with busses, trams or whatever, that's great, as you earn money and _improve your station's rating_. If you don't, we just assume that people get to their final destinations within the city themselves. Come on, if you cover 1000 tiles with an ICE it's not a problem to take a taxi for the final 10 tiles.

Also, it is important that the destination generation algoritim be influenced by the current date. The game cannot expect the player to take passangers to (nor would the passangers want to go to) towns on the other side of the map.

I would just set a max reasonable travel time. People wouldn't even consider bus connections spanning 2000 tiles (which would take 3 years). It would naturally take the current date into account - because available technology influences travel times.

Another important point is wether passangers should also return to where they came from. This is also a important issue. And if so, after what time period?

Yes, they should. Not including return passengers would be ridiculous. They should return within 1 to 3 months in gradually declining numbers, something like 1/x. There is some room for simplification here, but I won't even mention it, because my ideas are already considered oversimplified.

Fresh paragraph. The destination algorithim should generate very little traffic to small, rural towns, most of the traffic should be generated to the larger cities, and to the "local" towns (towns that are close to the source). The size of the town should be more important than the distance.

This is a great idea. It would concentrate passengers to some destinations without the rigid structure of my "capital" idea. But we would have to use an appropriate city growth algorithm. Currently cities change their sizes quite randomly. In my games the biggest city on the map can be in the middle of the list next month, if I don't grow it with busses. I would really hate seeing my 12 platform station become useless because a city decided to shrink this week. One of the possible solutions would be making intercity passenger traffic the most important growth factor. Then growth would be self sustaining. And we would probably have to differentiate city sizes at the beginning a bit more.

[jellyman]

I've played simutrans a lot and quite like its passenger destinations.

Some disadvantages though:

* No signficant calculation based on distance, gives a scaling effect. If you build a network on a small map with 5 cities, you could transport say 85% of all the passengers. If you transplanted this exact same set of cities into the middle of a very large map, you might only be transporting 10% of all the passengers. An algorithm that bases passengers on 1/ distance cubed could get around this effect. With such a formula, and the above five cities, the number of passengers generated would always be bigger than a certain finite minimum, even if you make the map infinitely large (integral over surface from radius=1 to infinity of c/r^3 is bounded)
* Doesn't handle different sized cities well. If one city has 10 000 inhabitants, and another has 1 000 inhabitants, then both cities will have around the same number of passengers arriving.
* Computational expense. I have in past suggested enhancements to the simutrans algorithm. I've been told no as the current calculation is already too expensive. I have found that with 24 cities, my computer cannot cope with the network when it gets to an advanced stage. I have a 1.8 gHz machine, not cutting edge, but faster than a lot of computers that people probably want to play OTTD on.
* It can get a bit fiddly dealing with 20 bus stations in every town to keep the passengers flowing. I sometimes think it would be more fun if each destination was a city, and as long as you took the passenger to the correct city that was enough, instead of having to cover every square within the city.
* Passenger destinations seem to be evenly spread over a square covering the city. If the city is an L shape across three corners of a square then you have to build bus stops in the corner with no buildings if you want to cover all the possible destinations for passengers and not have passengers in other cities that cannot get to destination.

However I love the fact that you have to put a bit of smarts into building a passenger network, and can't just ship a million passengers to any old station. Do you build a large central station with a connection to every city? Or perhaps you try and build a network with a route connecting every possible pair of cities? Or just a spaghetti mess of different routes with several significant hubs?

Basically the simutrans theory is that every possible passenger has a specific destination, and once this is generated, you then try and find a route for that passenger to get there. There may be other ways to give the benefits of passenger destinations:

* For each station calculate X number of passenger trips as per simutrans. Each passenger trip ends up being either to a station, or to 'nowhere'. These trips are then stored, and when a new passenger is generated, pick a random trip to generate. When there are few stations, X can be a bigger number, and the set of possible passenger trips can be updated frequently. As the number of stations increases, X can be decreased and the set for each station can be updated less often. This means that with many stations the set of destinations from each individual station becomes less 'realistic' However with many stations contributing to the network the overall network should still feel about right. This is similar to Simcity 4 where every building has a fixed set of destinations for its commuters that is updated every so often.

* Generate direct destinations only. Each station has a destination value, and a connection value. The destination value depends on the buildings within its catchment. The connection value depends on the destination values of all the stations that the station is connected too, and could be boosted further by the connection value of each station the station is connected to (which is a circular calculation which has to be resolved somehow). Passengers are then generated to directly connected station according to the total connection and destination value for each possible station. When a passenger arrives at a station with a high enough connection value, the passenger may be regenerated to a new destination from that station.