For rein: the TT2 engine discussion thread.

Lilman424 · Post by **Lilman424** » 04 Feb 2003 03:21

I think It should be TRANSPORT EMPIRE. That would include all the industries and such, too.

Raichase · Post by **Raichase** » 04 Feb 2003 03:24

Perhaps, but then we are detracting from the original aim - TRANSPORT TYCOON. If we expand out like that, it could end up as an industry playing game with the transport just another key in the works.

Lilman424 · Post by **Lilman424** » 04 Feb 2003 03:39

Well, we'd have to make sure it was focused on Transport.
Like in the early 1900s, Standard Oil didn't only own the refineries. They also owned the oilfields, the gas stations, the shipping companies, everything they used, they owned. Or as Oliciv would say:
everything they used, they [I am an idiot]. But you can't say they weren't an oil company.

Raichase · Post by **Raichase** » 04 Feb 2003 04:02

You make a valid point. I agree with you. So we could "be" a Transport Company that also owns a factory or two, that it bought out as an aside.

Arathorn · Post by **Arathorn** » 04 Feb 2003 07:24

I think we should start with transport only and leave the option for owning and managing industries open. I think doing everything at the same time is more complicated then necesarry.

Hajo · Post by **Hajo** » 04 Feb 2003 08:23

Hellfire wrote:No limitations? That's almost impossible. Imagine adding too much stuff to the game, and it grows beyond your memory size... Bye bye performance...

I think the key is to use expandable datastructures, not fixed ones. CPU power and memory will put limits, but every user should be able to get the max out of his PC, not any data structures telling him that they cannot store more than X elements.

c.u.
Hajo

Arathorn · Post by **Arathorn** » 04 Feb 2003 08:29

You're right, those fixed nubers are the biggest problem of the current TTD.

Raichase · Post by **Raichase** » 04 Feb 2003 09:20

Hajo wrote:I think the key is to use expandable datastructures, not fixed ones. CPU power and memory will put limits, but every user should be able to get the max out of his PC, not any data structures telling him that they cannot store more than X elements.

Good idea

Hajo · Post by **Hajo** » 04 Feb 2003 09:34

Arathorn wrote:You're right, those fixed nubers are the biggest problem of the current TTD.

There is a slight problem in here: flexible datastructure always come with an management overhead. I think Chris Sawyer chose fixed structures because they are faster and smaller. When TTD was new, the average computer was much slower than nowadays, so he had no other choice.

Also there are other kinds of limits - i.e. how far should a vehicle look ahead when searching it's path? Farther lookahead gives more clever vehicles but needs more CPU power. Should the quality of pathfinding depend on your CPU speed? Complex crossings then might depend on CPU speed - if your computer is too slow, the train might become too stupid (too little lookahead) to find a good path through the crossing.

The developers will have to make decisions here, and there will always be a group of users that is not pleased with that decision.

I.e. Simutrans uses a search depth of 8000 sqaures, but this is so slow that vehicles can't check the path often while driving, only before they start - so the cannot react on changing signals and search althernatives paths while driving (->choose a free platform). Although that deep search ensures that vehicles never get stuck in dead ends or endless loops like they sometimes do in TTD, most player complain about the missing flexibility - flexible routing systems might make wrong decisions sometimes. In TTD the players think this is a challenge for them to build good routes and crossings to overcome the stupid train routing. So even less sophisticated programs can be more fun to play sometimes ...

c.u.
Hajo

rein · Post by **rein** » 04 Feb 2003 09:38

yeah, I think that only the most basic stuff needs to be fixed, examplary
tile size, cos otherwise lots of related things with it will have to be calculated during the play just wasting cpu power - there is solution: declaring and precalculating tons of variables, which would be used across the game

Raichase · Post by **Raichase** » 04 Feb 2003 09:38

I think the faster one would be better, because we can build checkpoint stations to get around this, much like we have now

Arathorn · Post by **Arathorn** » 04 Feb 2003 10:30

If we would have fixed numbers like in TTD, then it will be difficult to change things when PC's get better and faster. We can limit the options from now, but I think the data structure should be as open and changeable as possible.

Post by **uzurpator** » 04 Feb 2003 10:44

Well, as for the map structure. True - expandable data structures throw in a performace drop. This however could be minimised by using of semi-fixed structure. I mean you could use a list of tables. Each table consisting a fixed amount of rows. For example for terrain you could use basic 32x32 leaf for terrain and compose the whole map of them. Within the super-tile (the 32x32 one) all manipulatiosn are super fast and between the super-tiles the performace overhead drops in. Ofc - in the the map sizes would be fixed in 32 micro-tiles increments.

As for the pathfinding. A few soputions could be used here:
- using current system expanded on possibility to assign bare track as a waypoint.
- using the current system on the super-tile level, and then on the micro tile level. maybe with possibility to memorize one found route.
- using the graph theory. Divide the track into: Nodes, lines and stations and allow route decisions to be taken only at nodes. This would reduce the overall "lookahead" since there would be multiple less nodes between the source and destination then tiles. This would need to heavily modify the track builing though.

As for the name:
THE Tycoon is the only one and proper ^^.

Hajo · Post by **Hajo** » 04 Feb 2003 10:53

Adam K. wrote: - using the graph theory. Divide the track into: Nodes, lines and stations and allow route decisions to be taken only at nodes. This would reduce the overall "lookahead" since there would be multiple less nodes between the source and destination then tiles. This would need to heavily modify the track builing though.

Goods and passengers in Simutrans do pathfinding this way. It works pretty well. This approach is very fast.

But I see problems with this approach if you add signals and want trains to choose alternative paths dynamically. Changing signals means your graph is changing while the train is on the way ...

c.u.
Hajo

GoneWacko · Post by **GoneWacko** » 04 Feb 2003 17:18

Hellfire wrote:No limitations? That's almost impossible. Imagine adding too much stuff to the game, and it grows beyond your memory size... Bye bye performance...

hmm... limit on trees: Sure go ahead
limit on vehicles: NOOOOOOO!!
Make sure you store the info on your vehicles in a strategic way and you could have a NEAR-NO-LIMITATIONS engine

Here's a wish I wished some time ago

GoneWacko wrote: maybe to make the game durance longer: inter-planetary transport... like a warp speed plane to go to another planet where you see other tilesets (like transfering from temperate to snow) and a new clean map where you can develop trains and stuff... Darn I always get lots of ideas when a new game is planned (even though this one is not planned officially yet)... lemme post my better ideas tomorrow... hehehe

Post by **orudge** » 04 Feb 2003 17:29

Hmmm, maybe for the expansion pack.

"Transport Master: Inter-Galactic Transport".

Heh...

Post by **uzurpator** » 04 Feb 2003 17:40

Hajo wrote: But I see problems with this approach if you add signals and want trains to choose alternative paths dynamically. Changing signals means your graph is changing while the train is on the way ...

Not necesserily.
signals are local event and would only alter train's path locally (within a few squares). Also the graph can be directed (not sure if it is a proper english term) like this:

Code: Select all

node -> line -> node

one direction line

Code: Select all

node -> line -> node
     <-      <-

two direction. Basicly a choice between single and double direction list.

I am not accustomised with the algorithms that internet uses, but they are similar and they do not seem to slow it down at all...

GoneWacko · Post by **GoneWacko** » 04 Feb 2003 17:54

But think of this:

what if

Code: Select all


------------
     \ ->
      \
       -------

becomes

Code: Select all

------------
     \ <-
      \
       -------

A train would want to take the signal that points the wrong way...

Arathorn · Post by **Arathorn** » 04 Feb 2003 17:55

How can that change?

Post by **uzurpator** » 04 Feb 2003 18:42

GoneWacko - you mix local and global events. Locally you can have any structure as long as it allows train flow. Globally it is a different case.

simple

Code: Select all

start station -> node -> line -> node -> line -> node -> station -> node -> line -> node -> end station

At first train checks for a possible link, then checks if signalling at all nodes. if it allows a pass from the current line to a chosen line then a train will use this path. Otherwise it will not use it. At each passing node train will recheck if the path chosen before is accesible through the next node. If not than it will try to find a new way, otherwise it will stop and "Train Cannot FInd A Route. You can modify this model as long as you wish - so train will choose the shortest path, the fastest path, the flattest path etc.
The only drawback will be the fact, that it is a tad constricting on a way how railroads can be built.
Also you think like TTD. On real railroads directions are not given by signalling, but by track layout and prior agreement. Signals jut reflect that and in a perfect game should be build automaticly...

Transport Tycoon Forums

For rein: the TT2 engine discussion thread.

Who is online