Transport Tycoon Forums

Now that we're aiming to define 'unknown variables' I wonder if we need to define bridge types and station designs too. Perhaps it can wait until later, I'm only trying to find out when it should be done.

The problem is, if we leave it untill later it may never get done

In terms of when things "should" be done well I think that there are a number of interconnected concpets which need to be defined ASAP.
For example a train (concept) enters a station (concept), loads (loading is a concept) some cargo (cargo is a concept) that an industry (concept) made, changes its orders (concept) to then head towards a second station, passing over a bridge (concept), and arrives at a second station to unload to another industry which gives a company (concept) some money (concept).

Without proper definitions of...
train
station
loading/unloading
cargo
industry
orders
bridge
company
money
...
there is a danger of having to change code which would have otherwise been "complete" whenever we decide to implement the next thing.

So in my opinion, the time is now

I think it would be a bad idea to define bridges and tunnels like in TTD, means they need special handling. I would like a approach that a track piece can get influenced by surrounding stuff. This means:

A bridge is first a landscape object that allows to build railtracks / road / on it. The bridge influence the tracks for max speed, max weight.

This could be aswell used in cities where you setup a speed limit by influence stuff. This way your pathfinder only sees tracks.

Makeing track on bridges a special thing needs everywhere special handling.

( I can only give advises and comments on the stuff )

You mean building a bridge means only building a bridge and that the player needs to add track to it later 'manually'?

You can build the bridge, then lay ontop the tracks automatical

You mean that internally the bridge consists of the bridge type and that you use a seperate overlay for the deck? It seems that this is a good option to choose to me, you can use the same bridge style for A LOT of things without too much problems and you can make the actual bridge transparent without making the deck transparant .

It would be handy if you can dot something like this (maybe Purno can visualise it):

Bridge Construction

• > Choose bridge type
  • > Choose track type
    • > Choose amount of tracks/lanes

If you can specify bridge type with radio buttons and amount of tracks/lanes with numerical input you might have a neat construction tool.

Well atleast you could remove tracks and say, add new narrow gauge tracks on it without building a new bridge ... I mean that bridges shouldn't be a route itself, but the normal tracks ontop on it should ...

I agree that the tracks on the bridge should be held some what independent from the bridge beneath it.

Hyronymus, I wouldn't expect a bridge construction like that. If you want a bridge for a certain number of lanes, you're going to know what kind of track your building before you choose to build a bridge. If I'm building a line and need a bridge, I shouldn't need to choose the track type again.

I'd like to think of bridges as a change to the landscape, so you can build an empty bridge that goes over a valley and then later on use this flat elevated land to put some rail track on. It's be as if this was just rock and a freak natural occurence. In this way you can have a wide bridge that has a road and a rail track for instance and when you consider flexible bridge types like a brick bridge (think locomotion), the bridge could actually split in two.

There is a drawback of this that you could make an empty bridge which then doesn't have room for the tracks you want to put on it, but this can be handled using the planning stage of construction, you lay a bridge, lay the track all as a plan and then when it works, you build it all. Some bridges like a brick bridge could be extendable later on but not a bridge such as a suspension bridge.

We also shouldn't forget about dual layer bridges.

Okay hows this from an implementation point of view:

A tile may contain bridge start and bridge stop tiles. (Which are objects in the same fashion as buildings etc - that is, only tunnels are allowed under)

Each tile has assigned to it a pointer to an array (a STL vector) which contains the pointers to each "bypass" associated with said tile.

If necessary, each tile also has a Z-buffer component which tells us how high the highest object is on that tile(i.e. building/bridge/etc) [Used for culling purposes]

A "bypass" (either bridge, subway, elevation) describes all things related to this bypass (managed by the BypassManager, much in the same way a vehicle is managed by the VehicleManager).
[Note: A double level bridge would contain two bypasses]

The bypasses have the track information in them and the tracks have the bypass information in them.

Hopefully this way the bypasses will become "virtual" grounds, but only from its own instance point of view (to allow multiple levels). This is also useful from a building point-of-view, so we need only concern ourselves with building on one bypass.

Hyronymus wrote:It would be handy if you can dot something like this (maybe Purno can visualise it):

Bridge Construction

• > Choose bridge type
  • > Choose track type
    • > Choose amount of tracks/lanes

If you can specify bridge type with radio buttons and amount of tracks/lanes with numerical input you might have a neat construction tool.

Hmm... not sure, you might want to have other bridge types for road than for rail, or sth.

Btw, how will bridges be built? TTD style (always straigh) or in Lomo style (any shape, with curves, hills, etc) or something else?
That kinda influences the way it should be programmed, I imagine.

btw, what did you want me to visuale? A GUI?

In all directions, maybe even with a slope in them?! But at least you should be able to drag bridges that are wider than 1 groundtile.

Purno wrote:Hmm... not sure, you might want to have other bridge types for road than for rail, or sth.

Btw, how will bridges be built? TTD style (always straigh) or in Lomo style (any shape, with curves, hills, etc) or something else?
That kinda influences the way it should be programmed, I imagine.

btw, what did you want me to visuale? A GUI?

I imagine we'll need both styles of building. We'll obviously want nice bridges like suspension bridges and these need to be straight and uneditable. And we must admit one of the great features of loco were the flexible tunnels and bridges.

Making bridges purely a landscape change would simplify coding in some areas, but sadly complicate in others. For instance track can just be built normally there, it has no idea that it's a bridge, it just needs to keep aware of any speed restrictions (that any landscape could enforce anyway) and it knows the landscape can't be altered, then everything such as signals, junctions, etc would work without worry.
I'm puzzling in my head how we're actually going to be dealing with the landscape/terrain within the game engine though. I know from earlier discussions people wanted each "dot" of the terrain to have a particular height, but this wouldn't solve problems of multiple terrain levels that my bridge solution would create.

Steve wrote:And we must admit one of the great features of loco were the flexible tunnels and bridges.

Mwah, it's nice for some curves when going uphill, but curved bridges would kinda look ugly (except for stones ones, perhaps). Besides, the AI is terribly abusing the bridges in Lomo.

Besides, curved bridges would need a LoMo alike GUI (if you wanna use tiles) for trackbuilding, I think.

I'm not sure if it's agreed upon, but I always imagine that route building system someone prototyped a while ago, where you can enter a couple of points and let the game draw the curve in for you (or maybe it didn't do that, can't quite remember). Curvy bridges are then just built around that track.

When building a bridge from scratch with any widths and so on, some new way of building would be needed anyway.

Realistically bridges aren't used much, terrain is either avoided or levelled so things can be built on it. I think we agreed on minor terrain levelling being automatic as track is built or perhaps something similar to bridge building could be done. If prices are set right it could be that bridges are rare and only used for those water or valley situations.

Shouldn't we go for the RT solution for building bridges and devise a similar approach for tunnels?

Hyronymus wrote:Shouldn't we go for the RT solution for building bridges and devise a similar approach for tunnels?

Which system does RT use? I never played it.

Steve wrote:I'm not sure if it's agreed upon, but I always imagine that route building system someone prototyped a while ago, where you can enter a couple of points and let the game draw the curve in for you (or maybe it didn't do that, can't quite remember). Curvy bridges are then just built around that track.

We could use this, the player puts a few points on the map, the engine draws a spline through it (done behind the schenes) and shows a bridge prototype for the player, the player can alter hights of certain parts of the bridge by using another tool. This would make bridge building look like Theme Park (World) which is a nice system to work with.

As for storing the bridge, we could use a begin tile and a end tile that both store the bridge ID and have a seperate array (vector) for the bridges, the array could have information about the dots and the heights and other things like where signals are placed. This saves us some space on the map array if we want to use signals on bridges.

XeryusTC wrote:This saves us some space on the map array if we want to use signals on bridges.

But if we keep bridges and track independent like suggested, the signal placement would be dealt with by the track information, not the bridge?

Generally yes, the track should be the responsible. Anyway simple forget what I say, I have influenced to much already, sorry

Steve wrote:

XeryusTC wrote:This saves us some space on the map array if we want to use signals on bridges.

But if we keep bridges and track independent like suggested, the signal placement would be dealt with by the track information, not the bridge?

True, I didn't think about that atm. But we can store the tracks that are on a bridge in the bridge array.
We'll see where we'll end .