News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

Passenger generation, stop exploiting the poor idiots

Started by Borgoth, July 23, 2009, 09:19:29 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Borgoth

Current way: Paul wants to travel from London to Liverpool. I offer him a route via Cape Town, Cairo, Sydney, Tokio and New York that'll cost him his heart and soul. Paul knows no other routes and pays happily, then gets dragged through Amazon jungle and finds out bunch of new diseases during the 3 years his travel takes. Good thing he didn't want a bus ride to nearby supermarket for groceries, considering the morale of this transportation company...

Real world: Paul wants to travel from London to Liverpool. I offer him the same ridiculously long route. Paul tells me to shove the tickets where the sun doesn't shine and won't be coming back until I'm offering something reasonable.

Suggestion: Shortest possible distance (manhattan length in simutrans) from passenger's location to destination is, say, 40 km. He's willing to travel (and pay) for maximum of 40 * X + N kilometers, anything over that and he'll really start considering hoping into his trustworthy Ford T instead.  Balanced numbers are a matter of testing and common sense, but I'd suggest following as a start of discussion: X = 1.5, N = 7. That'd mean for the 40 km trip he'd be willing to travel 67 km and beyond that the chances he'll choose his car goes up, 1% chance per 1% extra length sounds reasonable. In other words, at 67 km he'd use my trans network with 100% probability, and at 134 km the probability would reach 0%.

Reason I added that N component above is local traffic within a city. When distance to destination is only 8 km, given values would give you 20 km of room to route your buses/trams, much more reasonable than just using flat multiplier. And again, in real world, on a 50 km trip you're probably willing to stray to max 80 km worth of total distance, but within a city using bus/tram/metro to travel 4 km, people find it quite normal and acceptable to have to swap and end up traveling 2-3 times the distance. And hey, if it's not realism to strive for, it'd not be called simulation, right?

How to inform the player of such passengers? Adding them to Unhappy or No Route would probably work, or as Simu-Exp does it, another field for "Too long route" could be added.

And yes, I'm aware of the config option 2 that allows me to set the payments to be from start to destination regardless of how long trip it's taken. That admittably comes close to forcing me to make short routes, but on the other hand it's very punishing on local traffic within city and it's just flat out unrealistic: in real world you do pay for the full distance you travel, it's up to passenger to choose whether the detour is worth paying for. If anything, this suggestion makes the config option obsolete as the default works fine and could no longer be exploited.

I do also know about Simu-Exp traveler happiness thing that in some way achieves the same. Would be nice to discuss the benefits and problems of each (I kinda like the simplicity of this suggestion, from gameplay point of view) and whether both would have their place in the game.

jamespetts

Actually, recent versions of Simutrans-Experimental have two further features that address exactly this problem: (1) however long that the journey takes, passengers/goods are only willing to pay for a journey that is X times the straight line distance from their origin to their destination; and (2) depending on how far that passengers want to go, they have a maximum journey time tolerance (which is randomised within set ranges): if the shortest route exceeds that tolerance, they do not travel, and register as "too slow", which is shown on the station graph next to unhappy and no route.

Also, in Simutrans-Experimental, a certain proportion of passengers (the proportion varies as time advances) have access to private cars, and the relative speed of using their cars as compared with the player's transport is taken into consideration when deciding which to use.
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.

Borgoth

Does that time based tolerance limiting actually consider the fact that ferries are slow and trains swim badly? I'd hate to see all my passengers to refuse stepping into ships ever again. And it's not like your private car swims much better.

But yes, overall we're after the same problem with different solutions. As I mentioned in the end of my post, I'm aware of your solution and tossed this out as an alternative for discussion. Well maybe I shouldn't have said traveler happiness since that's yet another thing. Anyways, time of travel is one possible reason to go by your own car, but it's actually separate from deciding based on the price of the trip (=length). And I kinda understood for you the decision based on distance is really on/off thing at the given limit rather than a curve.

Decision based on speed of travel to me seems like forcing the need for speed on players twice: transporting people slowly is just horrible for your income (ok, ST using theoretical max speed for pricing allows exploiting the speed bonuses like crazy, but you fixed that in ST-Exp already so I'm not getting into that).

prissi

You can enable different modes of payment that forces the player to avoid offering routes with x intermediate stops that are much longer than the original route. Any more difficult routing schemet than is very unlikely to be implemented in Simutrans, as it will require much more memory and processing time. Furthermore poeple have usually problems with easy destinations. Reducing the number of passengers will not change the overall gameplay. (Or did I missed reports on people building different networks with Simutrans Experimental vs. Standard?)

AP

The trick with these rules is they need to take into consideration early time periods too - pre rail and canals, the best routes around britain, and many parts of europe were quite literally around - by river and sea; both much safer and much faster, although certainly also much longer.

The same applies to difficult terrain. I'm quite certain in scandinavia / switzerland there are places which appear rather close on a map, that actually take rather a long time to travel between because there is a range of mountains in the way!

Borgoth

This suggestion isn't aiming to change to current routing scheme at all, it's just a matter of confirming whether even the chosen 'best route' is good enough. And it's not heavy operation, simply adding up route length and comparing it with the acceptable minimum. Compared to the resources spent on finding the route that should be insignificant extra.

Changing to different mode of payment just reduces realism even further. And it leads to unwanted passengers that just cost me money, but there's nothing I can do to avoid getting them. Does the different mode of payment force me to actually make those shorter routes? Not really, I'd just earn less. Is there some kind of indication in the game to show what particular route is the problem that causes me to lose money? None. Losing money doesn't in my opinion hurt enough. Losing customers and city growth hurts more. But that's just the way I play.

AP: the day simutrans has mountains that are an actual obstacle worth taking the long route, I'd start worrying about that. In any case, the multiplier X could easily be adjusted based on time period (modern day passengers are more demanding) or map roughness. And even the suggested value I gave is rather forgiving.

What I'm really aiming for is to avoid the routes with 5x or 10x the necessary distance (e.g. long train route going only clockwise direction around the whole map, so you get dragged around the world just to get to town next door). And a clear way of informing the player when he's failing at providing a reasonable route (rather than just mysteriously getting less profit).

Severous

Hi

I like moving everything on the map. If I can exploit the 'poor idiots' or the inert coal whilst I'm doing it then I probably will. 
Regards
Sev.

jamespetts

Borgoth,

the journey time tolerance does not take into account the relative speeds of different types of transport because that would not be realistic: its aim is to simulate the fact that, for many potential journeys that passengers might make, they will only consider it worthwhile making the journey at all if the time spent is not too great. Consider the people who register as "too slow" to be no more than latent demand. People travel far more now than they did hundreds of years ago precisely because the journey times now are lower than they were (which is why the system specifically does take into account the older time periods - one of the reasons for adopting this in the first place was that I wanted to simulate the fact that, in the days when there were only stagecoaches and canals, far fewer people travelled, so that a Simutrans world filled with stagecoaches and canals would not be drastically overflowing with passengers for what are very low capacity forms of transportation).

Journey time tolerance is not to be confused with competition. If there is a quicker way of getting there, passengers will take that quicker way whether the slower way is within their tolerance or not.
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.

Borgoth

Well, smart time based routing does seem solve the problem, but leaves the question: is routing like that fast/lightweight enough to be viable in ST? Because if it isn't and we're stuck with current routing system, then this max distance check would still be quite useful in achieving similar if not as accurate "too slow" limitation. Or similarly count estimated time of travel for this best route only (or all found routes with equal amount of transfers), and compare it with a time tolerance value.

jamespetts

Quote from: Borgoth on July 25, 2009, 07:55:46 AM
Well, smart time based routing does seem solve the problem, but leaves the question: is routing like that fast/lightweight enough to be viable in ST?

Why don't you try Simutrans-Experimental for yourself and find out? :-) Knightly has done a great deal of good work in optimising the routing system. Any reasonably modern computer should be able to cope with it.
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.

Borgoth

My computer is definitely on the faster side of the scale, and if it works fine on mine isn't enough to convince Prissi to add it into standard ST. Maybe I'll try it on my old computer instead...

In terms of performance btw, am I the only one whose ST gets completely smothered in pause mode? It's so laggy that moving windows around is nearly impossible, as well as track building. Feels kinda odd that with all the animation and calculations off the game gets at least 10 times slower.

Severous

Pause works fine on mine. (Pak64, Pak128, PakGerman)
Regards
Sev.

jamespetts

Borgoth,

trees greatly reduce performance, even on pause mode. Do you find that your problems are worse in forested areas?
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.

Borgoth

#13
That's the thing, I have absolutely no performance issues on normal speed nor even on accelerated time. Only in pause mode. Bizarre. I'll try on another computer next, but it's odd in any case.

Edit: same thing with another computer. Running in maximized screen so I have lot of stuff on the screen ofc. Easiest to test just by dragging a map window around the screen. On pause mode it moves considerably slower. Building track with ctrl down in pause mode is almost out of the question.

Fabio

By the way, in STE, in case a faster route imply one or more transfers, whereas the direct one is (much) slower, which one is chosen?

jamespetts

The quickest route overall is chosen every time. The number of transfers makes no difference. However, the total time for the route is based on travelling and waiting time, so there will be a tendency to go for routes with fewer transfers. Nonetheless, a faster route with more transfers will be chosen in preference to a slower route with fewer transfers.
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.