News:

Want to praise Simutrans?
Your feedback is important for us ;D.

Alternate routes

Started by Fabio, January 06, 2009, 01:52:53 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Fabio

It's long time i think of this.

Let's take two cities, A and B, at two corners of the map.

There can be a railways line between them.
There can be a bus line.
And there can be a flight route.

Now, in RL, there can be (and often there are) all three.
In Simutrans, only one of them will be used.
I would like to see different routes competing (maybe run by competing players).

Once one or more routes are found, we could extimate:
  - the fare ticket
  - the extimated time
  - the number of transfers

A 20% of the passengers will always choose the fastest route (Business travellers)
A 30% of the passengers will always choose the cheapest route (Low Cost travellers)
A 50% of the passengers will choose weighting speed, price and number of transfers (Ordinary travellers)

vilvoh

I like the idea. It's simple, reasonable and would give more variety to passengers transport. I support it, although I'm not sure about the percentages. Would be possible to modify them dinamically depeding on the situation of each area or zone?

Escala Real...a blog about Simutrans in Spanish...

colonyan

Of course,,,, this will be ideal simulation.
But I kind of remember this being said that, to do this, it requires heavy calculation each time passengers are
created.

Combuijs

I don't think I like the idea, because this will slow down Simutrans very significantly. Most of the time is spent on route-finding and its quickness is one of the main reasons that Simutrans is a succes. As far as I know route-finding will slow considerably if all possible routes must be examined instead of just one of the best (e.g. one with the least transfers).

Further on, fare ticket price (I think fabio means that) could be revenue/km * tiledistance, but estimated time is simply not known (or do you mean tiledistance / maxspeed, but that is really something different).

By slowing down I don't mean just 2 times slower, but depending on your network it could be 100 times to 10000 times (or worse) slower! Maybe things are easier if you are always looking for the least transfers and then take revenue and/or estimated time in account, but I'm not sure.

Bob Marley: No woman, no cry

Programmer: No user, no bugs



Fabio

@ Combuijs, i perfectly understand your point.

Probably my check could be limited to the 3 to 5 best routes with the least transfers.
The fare ticket price could be revenue/km * tiledistance.
THe estimated time, for our purpose, can be as well tiledistance / maxspeed

@ vilvoh, you're right, my percentage were just to give an idea.
the best solution would be to link the percentage to the level of the building generating the passenger


The Hood

I hope there is a way to make this work.  I reckon choice of top 3-5 routes (by current calculations) should be plenty.

jamespetts

Another interesting idea. As to the speed of the simulation: it could simply be made optional so that people can have a choice between simulation depth and computation speed: after all, some people use much faster computers than others.

However, given that the AI is fairly basic at present, and that network multiplayer is a long way off, this is perhaps not a top priority for the time being.
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.

Fabio

true, but also a single player can make, say, a train connection and a direct flight between two destinations

jamespetts

I have just been looking at the code. The way that it works now is that passengers search for a starting station before looking for a destination. Any station within range that is served by at least one line and is not overcrowded will do. If there are more than one that match, it chooses the first that it finds.

Then the passengers that have a suitable start look for a destination at random anywhere on the map. Then they check to see whether they can get from their origin stop to their destination. If they can, they travel. If they cannot, they turn out as "no route".

To make this suggestion work, passengers would have to be assigned a destination before being assigned an origin stop. They would then check whether there are any stops in the area that are not overcrowded, and then check, for each stop, whether it serves their desired destination. This is what would take the extra computational time: the number of route checks (which are computationally intensive) for each passenger would be equal to the number of non-overcrowded origin stops within range, rather than equal to one.

Now, most passengers do not actually go straight to a railway station or an airport from their origin station. Because the tile coverage of each station is only 2, most passengers start and end their journey on a 'bus or a tram. Passengers will usually determine the best route to get from their origin to their destination (mainly in terms of the number of transfers), and so, every step of the journey after the initial 'bus or tram ride will indeed work in more or less the way suggested in any case (and the speed at which Simutrans runs already takes that into account).

So, making this change would not have a very big effect on gameplay (because most passengers start their journey on a local 'bus or tram and make the more important decisions about how to travel at a later stage), but would also not have a particularly great overall effect on speed (because there would not be many origin buildings within two tiles of more than one passenger stop that is not overcrowded). Furthermore, it would not be too hard to code.

I am currently working on a patch to make the number of passengers willing to use public transport dependant on the level of private car ownership (defined in a private_car.tab in a similar way to the speedbonus.tab) and the level of local congestion, and I shall see if I can incorporate this change into that patch.
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.

isidoro

I think the point Fabio states is not exactly that.  For Fabio, the problem is not to choose one station or another, there can only be one for example.  The problem is, once in a station, with a destination, to choose one vehicle, line, etc. or another.

There can be a solution not costly (in terms of simulation time).  Calculate for each vehicle an average speed (only an integer updated each time a travel ends).  The passenger is presented three quantities: price of ticket, average speed and time he has been waiting so far.  Based on that, passengers go on or not.

This should be easy to try.  I'll try.

Combuijs

#10
QuoteTo make this suggestion work, passengers would have to be assigned a destination before being assigned an origin stop

No, that's not the root of the problem, James. The problem is: Given a starting station and given a destination, what route will the passengers select. Now it takes the one with the least transfers (and I think that, of the possible routes with the same number of transfers, just one is selected, the first it encounters). If you want to take the most efficient route (in estimated revenue or estimated time or whatever) you have to consider every possible route. That's a lot, I can assure you.

The solution you describe handles another problem: what start station should the passenger take to get to a assigned destination. In fact that's the same kind of problem as described above (given a starting station and given a destination), but then you assume that the position the passenger is on is a station and there are routes (infinitely fast...) to each station in reach.

Quotetime he has been waiting so far

That was not in Fabio's proposal. You want to get rid of the passenger if it takes too long? No one knows how long a passenger is waiting!!!
Bob Marley: No woman, no cry

Programmer: No user, no bugs



isidoro

Quote from: Combuijs on January 06, 2009, 06:06:12 PM
That was not in Fabio's proposal. You want to get rid of the passenger if it takes too long? No one knows how long a passenger is waiting!!!

I know, I know.  I agree with you in that searching for a different/optimal route can be too time consuming, so my starting point is:

  • A passenger is at a specific station with an already chosen destination and a route (with a already chosen transfer)
  • Depending on how expensive is the vehicle there, how fast (in reality, not maximum speed) and how much time he has been waiting, decide to go on or not

I think it doesn't depart too much from Fabio's proposal.  This way you can have competing players for a fair share on passengers.  Some will choose the plane, others, the boat, etc.

What about waiting time then?  There has to be an aging mechanism so that if there are no competing companies, all passengers would end going on...

I know that now nobody knows how much time a passenger has waited, but I have a devil idea in mind...

Edit: grammar

jamespetts

Ahh, yes, the problem of choosing a station at random is easier to solve than the simplistic method of determining the best route, since changing the latter is likely to require a great deal of care, and might make the whole thing much slower. I am currently working on a patch to simulate competition between public transport and private cars that will also de-randomise the start station (will use the existing algorithm to find the best journey between any start station within range (up to a maximum of 5) and the chosen destination. I should be interested to see Isidoro's work on the patch to change the way in which passengers compute their route...
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.

Fabio

Quote from: isidoro on January 06, 2009, 05:48:46 PM
This should be easy to try.  I'll try.

wow, thank you, i'm very glad!

anyway, isidoro and combuijs got my point.

i think the only thing passengers should have when they are generated is a flag which gives the the "business", "lowcost" or "normal" status and, once they choose a destination, the route is chosen according to this.

later, if this works, there could be facilities for business travellers to allow them to use a station (but not a bus or tram stop) and they would take into consideration the catering level of the vehicles in a line.

kierongreen

Just to add a small suggestion... When deciding whether a passenger is business/leisure/ordinary the type of origin tile and destination tile could be taken into account.
So commercial/industrial -> commercial/industrial would always be business.
residential -> commercial/industrial and vice versa would be ordinary (people going to work).
residential -> residential would be leisure.

factories would count as industrial, monuments and attractions as residential for the purposes of these calculations...

colonyan

I   L O V E  that idea kierogreen.....
I   L O V E  it!
I can't remember since when I hoped for that would be possible.
Just being mentioned some one other is happy enough.

Fabio

great! this is the idea i was waiting for!!!

isidoro

Here's a patch that adds waiting time to passengers as well as goods.  In the station window the number of days waiting will appear in parenthesis if greater than zero.  Since I'm playing with it, waiting time is neither saved not restored from saved games and counts from the loading time.

Next: add a real average speed for convois (not max speed), so that passengers can decide on what vehicle they want to get on.

Lodovico

#18
Quote from: fabio on January 06, 2009, 01:52:53 PM
There can be a railways line between them.
There can be a bus line.
And there can be a flight route.

A 20% of the passengers will always choose the fastest route (Business travellers)
A 30% of the passengers will always choose the cheapest route (Low Cost travellers)
A 50% of the passengers will choose weighting speed, price and number of transfers (Ordinary travellers)

We may try to solve this in another way:

If we have various types of cargo, why not to have various types of passengers:
1. passengers preferring trains
2. passengers preferring planes
3. passengers preferring boats and ships
4. passengers preferring buses
5. etc. 

Each passenger will look for his favorite vehicle (yes, you may have passengers preferring particular vehicle/engine/locomotive),
if it is not available then he take another one.

Just an idea ...

Fabio

Quote from: isidoro on January 07, 2009, 03:50:15 AM
Next: add a real average speed for convois (not max speed), so that passengers can decide on what vehicle they want to get on.

What about a commercial speed of a line? i think the whole line should be considered rather than only one vehicle (if a vehicle has no line, its commercial speed will be calculated as half or one third of max speed).
Commercial speed could be calculated as the number of tiles (km) to complete the whole schedule divided by the total time needed to complete it. It should be stored in line infos and possibly displayed in line statistics as well.

jamespetts

It might be good to have some kind of rating system for lines ("service quality" or something similar), which is calculated for each line every month, so that passengers when they try to find a route only need to access that one field, the service quality, and then balance that with the number of steps for the individual journey, rather than each packet of passengers trying to compute all of the service quality metrics each time that they want to travel - otherwise, the speed of the computation could be greatly slowed.
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.

Fabio

True. well, the line could have such parameters as
  - commercial speed (as above)
  - fare ticket price (it should be different for busses, trains, ships, airplanes, etc...)
  - average catering level (when implemented)

every pack of passengers would just use these statistics, stored within the line, to choose their favourite route

jamespetts

One thing about the ticket price, though: how would that be set? Currently in the game (and no doubt deliberately), players do not have to set an individual ticket price. Indeed, there is not a specific "ticket price" factor in the game at all: the revenues are calculated based on a highly abstracted means of working out what the employees of the company would set the ticket price at in order to maximise revenues. However, if there is now a possibility of passengers choosing not to use a particular line because of the ticket price, that would not work, and the player would have to have more control; but is that level of control desirable? Some might perhaps consider it "micromanagement". One could simplify it by giving the player, per line, say, three levels of price (low, normal and high), the low and high variants of which would simply apply a divider/multiplier to the normal price.
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.

Fabio

For sure more expensive means (airplanes) gives more money to the player, so their fare IS higher.

On the other hand, i like the idea fo dividers/multipliers, given by line (maybe a percentage of normal price).

In this case, though, some travellers could decide not to travel (or to travel with their private means) if the ticket is too high and there are no alternative routes.

The Hood

I very much like the idea of service quality.  This would encourage the development of efficient networks (if your network is overcrowded and trains/buses have to keep stopping for congestion, this will lower service quality, and then in turn lower revenue).

Service quality could be based on one or more of the following factors:
- commercial speed as defined above (best as an average for past month or year or last 5-10 completed lines)
- frequency of route (how many services on that route completed the route in a certain timeframe)
- overcrowding on route - if convoy is regularly 100% full, decrease quality
- fares level (probably best just having low-med-high as Jamespetts suggests)
- catering level

Just one question about current behaviour though.  Suppose journey A-B-C-D involves a train leg B-C.  The train route B-C is served by Line 1 (W-B-C-X) and Line 2 (Y-B-C-Z).  In current behaviour, does the game chose line 1 or line 2 before the start of the journey (so that the passenger will only get on line 1 when he arrives at B), or does he get on the first of line 1 or line 2 which arrives at B, as line 1 and line 2 are the same between B and C?

Combuijs

QuoteIn current behaviour, does the game chose line 1 or line 2 before the start of the journey

The system notes that the passenger will go to D, and needs a transfer at B. The passenger takes the first convoi that goes directly to B from A. Having arrived in B, it recalculates the route, and the system notes that the passenger will go to D, and needs to transfer at C. The passengers takes the first train going to C from B.

So in general, passengers travel from station to station, not by line.
Bob Marley: No woman, no cry

Programmer: No user, no bugs



Fabio

Quote from: The Hood on January 07, 2009, 11:34:43 AM
I very much like the idea of service quality.  This would encourage the development of efficient networks

I agree, although i would like to see different passengers evaluating differently these different parameters: business will value the most the speed and the catering, but less the fare; leisure will valuse more the fare than the catering and the speed; ordinare will value the global quality of service.
I would still like to have two different lines both with passengers, and both profitable.

isidoro

#27
My idea is that the "real average speed" is on a convoi basis, since in a line, there can be very different vehicles.  Is a line has 25 nice comfortable buses with sauna and ping-pong table and two donkeys, service of the line can be quite high but when in the station, if you see the donkey, would you go on it?

The second reason in favor of convois is the way I have thought to implement the price of the ticket.  The price of the ticket will be the money I get divided by the number of passengers I have transported.  And that depends on convois, not on lines.

My idea follows like this:  there would be a quality measure per station.  That, and waiting time, would influence the behavior of passengers to ride or not.  And that also would make that a new company opening a new line on a public station with better vehicles will get nearly all passengers while if there are no competitors, passengers would ride at once.

EDIT: below is the second version of the patch.  There will appear a real average speed for convois in the information window.  Some preventions, though:

  • As things are not saved/restored, the speed will not appear until the vehicle reaches two stations after loading a game
  • To calculate speed, the Manhattan distance is used, as it is customary in ST.  This can lead to better average speeds for vehicles running in diagonals, instead of squaring.

I've tried to be as economical as possible.  The convoi stores the time when reaching a station.  When reaching another, the speed is calculated as distance/time.  Distance is known since the position of the last station is already stored.  To calculate the average, a weighed average is used:  new_average= 0.15*new_speed+0.85*old_average.  This allows to have a running average but only store one value.  The price is thus two more integers in the convoi class.

NEXT: devise a QoS (Quality of service) function based on price and average speed and make passengers get on vehicles depending on that.

EDIT2: minor bug correction in patch

prissi

Since you have the route, you can (at least in principle) also get the speed per tile. However, passenger are anyway more interested in the speed between stations.

z9999

One question.
If a line has 1 concord - fast but running once per month - and many standard airplanes - slow but running once per hour, people keep waiting concord ?

isidoro

Quote from: prissi on January 08, 2009, 04:23:57 PM
Since you have the route, you can (at least in principle) also get the speed per tile. However, passenger are anyway more interested in the speed between stations.

And it is less calculations too.


Quote from: z9999 on January 08, 2009, 05:26:06 PM
One question.
If a line has 1 concord - fast but running once per month - and many standard airplanes - slow but running once per hour, people keep waiting concord ?

I'm thinking about a suitable formula now.  The idea is that the concord will have (if price not too high) a QoS higher than standard airplanes.  So, if at the station, passengers will get on the concord at once.  And if not, passengers will wait some time to see if the concord arrives and, if waiting time gets high, they will ride on the vehicle with less QoS.  I will work on it now and see because one thing is theory and another practice...  ;)

jamespetts

Thinking about Isidoro's luxury coaches and donkey example for a moment: generally, passengers decide which route to take based on generalised information about the service on that route, and then stick with the route despite the fact that it might not live up to their expectations (after all, if they are waiting in one company's station, they will not arrive in time if they have to go all the way to another company's station and wait for a train (etc.) there from scratch again). So the people not getting on the donkey is not a particularly good example.

A better way of representing that idea is to take into account whether a line has any obsolete vehicles running on it as a metric of service quality. There is already a specific function to test whether a line has obsolete vehicles, I think, used in setting the line's status colour to blue to indicate the presence of obsolete vehicles. A line with obsolete vehicles could be considered worse than one without. Choices should probably be made per line, since it is a particular set of lines' routes for which passengers search.
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.

isidoro

It all depends on the example, as usual.  You can mix donkeys in a line with ultra-modern buses in ST.  If I'm said that line A has a QoS of luxury buses and I'm presented with a donkey, with all my respects to the donkey, I won't get on and go the consumers' office at once.

But things always get complicated,... that's where I've reached today:

My QoS indicator is average_speed/price_of_ticket.  In the attached patch, you can see the ticket price for passenger convois in their Details window (it is very nice to compare that with cost per km to see how many passengers are needed to make profit).

This QoS is greater when high speed and low fares.

An now, the model:  when a convoi arrives to load passengers, it presents its QoS.  The station has an average QoS.  If the QoS of the vehicle is greater than the average QoS of the station, passengers ride at once.

But, what if less?  Well, it depends.  If passengers have been waiting too long, they are hopeless and will go on.  If they have just arrived, they will wait.  So, I needed a time to compare up to how long they will wait.  And what have we got at hand?  The average interval of convois arriving at the station is a nice time.  After some thought, I came to the following procedure:

  • When a passenger vehicle arrives at a station, this time is calculated: average_interval_of_convois*(average_QoS_of_station/QoS_of_vehicle-1)
  • If a passenger has been waiting more than that time, he goes on; otherwise, he doesn't and wait.

If you apply the patch, you can see the average interval of convois arriving at a station in the details window of the station.

I was so happy...  It seemed to work...  But...

The problem I have not experienced yet but I fear it can happen:
A-B-C, three cities, A-B connection by plane, B-C connection by boat, a transfer station at B.

Average QoS at B is raised by planes but influences passengers trying to go on slower boats to other destination.  They wait for another vehicle to C in the hope there is a quicker one, but there isn't.  That is not a problem of being planes and boats but that the QoS should be measured in connection transfers, instead of whole stations.

And now the question for all of you:  is it worth the effort to work on improving the patch, and (specially to prissi) do you think is it worth the more data added if improved (one float per passenger transfer connection) and do you think performance would be an issue?

In this version of the patch, the overcrowding patch is included, since I'm testing with both activated, but can be separated if need be later.

jamespetts

Isidoro,

very interesting! Have not had a chance to test your patch so far, but it looks promising. It could fit in well with the patch that I am about to release relating to competition between the player's (and the AI's) transport and private cars for passengers, in that your quality of service metric could be used for that, too. Do you think that you could add to your QoS metric the fact of obsolete vehicles on the line?

However, proper competition based on quality of service is an excellent idea, and could substantially enhance gameplay. It might work particularly well if the station radius coverage was increased from 2 to 3 tiles, or, even better, if different stations were given different coverage radii, specified in their .dat files (a large railway terminal therefore having more coverage than a small 'bus shelter).
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.

Fabio

i'm glad of where my proposal is leading. thank you guys, keep on going!

but i can't see if my main point is still considered: can passengers have different needs/tastes/profiles and choose different routes (also with the same company)?