Thanks everyone for their comments and explanations--it does help better understand the issues!
First and foremost, I am looking at things with the perspective of "I enjoy this game, and I want to help it grow, be better, and more fun for most--so they keep coming back for more!" Having been a coder on other games, MUDs in particular, I've too often seen development staling and becoming stale because of worries *at the coding level* of preventing player cheats/exploits of game code/mechanics. Personally, I despise cheats/exploits; They ruin the fun of games--even single player games--by taking the fun out of figuring out a solution to a problem, and he rewarding feeling of doing so.
However, I do see that as an administrative problem (especially in multi-player), and not a coding/development problem that can stall or prevent development of game features that add value to the game for many due to the actions of a few. At the other extreme, here's some game code that totally prevents any cheating at all: int main(int argc, char* argv[]) { return 0; /* no one can ever cheat this game because it never does anything! */ } I've seen MUD coders who've written code almost like that, or chose not to implement a much wanted game feature because they worry too much about people exploiting it. Until we have real thinking computers instead of just logical devices, I believe that administrative issues should be kept, and handled, at the administrative level, not the coding level.
On the other hand, there are some issues that can be solved, or at least add some administrative assistance, at the coding level. For example, the idea of using "whole city coverage" to prevent local congestion in order to make long distance transit more profitable; What if instead of calculating everything at once in the game loop (I'm used to calling such concepts a game "tick"), it makes it a two-step process? That is, when goods "hop" on to a station, they do not immediately hop off. But instead, they remain on it until the next game loop. This would mean that when other goods are trying to find a route, they'll see that this station is too crowded, and choose to avoid it. As I understand it, this may not be very much different than what I see/read about the "transit/walking time" concept is supposed to do.
Maybe this is even how it's already done--I'm not familiar with the game code. But that is how I would have done it. Each tick, iterate over all stations/industries/transports, doing a two-step process: First, figure out which goods/transports have to move to their next (or final) destination, and queue them to move there--don't actually move them until the end of the tick processing (the second step). This would including loading/unloading transports as a "destination"; Accounting for moving on/off a transport (convoy), station, or simply a loaded transport moving from one tile to another at speed.
The second step, then, would be to actually move the goods queued for movement. (Alternatively, the code loop can do this step first, processing the queue made during the previous tick. The net effect is the same. As long as there's a clear division point between the two steps.)
Thus, you could have the very realistic simulation of an empty station at which five transport convoys arrive during the same tick, and next tick, that station has gone from being empty to heavily overcrowded. This would make newly generated goods try to avoid that overcrowded station and find an alternate route. I've seen it in the food service industry often enough; A loaded tour bus stops at some food stop, and unloads. Others driving by looking for a place to eat would see the tour bus and decide to go eat elsewhere, because they know there will be long lines of people waiting to order and/or eat. It wouldn't matter if the restaurant had separate parking lots in many places (even with magical instant travel between the lots and the main store); The central store location is still clearly crowded and will be avoided. To me, this is not much different than a transport simulation--just using stations/platforms instead of a restaurant.
That is why it's also important to only queue the goods to move, but wait until the next step/tick to actually move them. If you move them all at once, then it would always "appear" that the station was never crowded because the goods would arrive and depart instantly, leaving the appearance of an empty station. And I think that is the game mechanic here where the problem arises in the first place.
I also think it would simplify the whole "walking time/distance" thing. Every station would be viewed as a whole, with overcrowding affecting the entire station, regardless of which single tile is being considered at the time. So if you use some "cheat" to connect a single station to every city on the map, then every city on the map will share one single, overcrowded station that goods will try to avoid. You do not need to try to calculate the time/distance between station tiles, because it won't matter.
It would also affect "long distance" routes, such as to tourist attractions or inter-city transport, since goods would try to avoid the overcrowded local station(s) regardless.
As it seems to be (in my version running here), I could actually cheat/exploit better without joining nearby stations. Let us say I have a coal power plant near a coal mine. I could put a station at each. But instead of running road/rail in a direct line between them, I could run it in a ring around the entire map, generating revenue for each tile as the convoys travel around the map. These revenues would likely exceed the maintenance costs, keeping it profitable. It would be foolish to try to detect and/or prevent this at the code level, because what if you had to do just this to transport goods around a geographic feature that was in the way? I could even include a "shortest direct" path for empty convoys to return to the first station while empty, by using way points to insure only loaded convoys use the "long" route around. In a multi-player server scenario, that would require a human administrator to look at the map design and determine if it was a legitimate loop, or one artificially created in order to "cheat".
In the end, my original thoughts and purposes for posting is the basic idea that this kind of a tool is a much needed tool to add value to the game. As it is, it takes much more extra work to plan and lay out stations and paths between them, due to game mechanics, than it should. It's also something that is done by the code, rather than something the players can control. This makes the game more frustrating, not more enjoyable. I see the same issue with the way some scream "CHEAT!" at every opportunity. It detracts from the game, without actually preventing cheating or creating an enjoyable game. This is especially true when I believe those "cheats" are more often an "edge case", not a "mainline" issue.
(My apologies if this post seems disorganized/long/jumpy/et cetera. It's partly intentional--Originally, I did not want to explain my every thought process, nor did I want to write a long, carefully organized academic paper that would cause people to just say "TL;DR!" Even as-is here, I've suppressed a lot of details; People can ask if they want those details.)
SavedURI :
Show URLSavedURI :
Hide URLhttps://forum.simutrans.com/index.php/board,33/action,post2.html
