[RFD] Tunnels (what is a tunnel?)

[Arathorn]

He means not horizonal.

[Steve]

Of course, the tunnels should just be track.. underground. Anything that applys to track can apply to track in tunnels.

[Zuu]

I think that's the best approach to it but let's suggest we want a graded tunnel. Is that as possible as graded track?

If there can be sloped structures. Or if tracks can be sloped on flat ground.

[PJayTycy]

I like the idea.

I'm not too found on the roof and surface terms though, but that's only language.

Every building/track is built at a certain height, and has a certain clearance. Different structures (eg: a building and a train track) can only be built when their clearances don't overlap. Compatible structures (eg: 2 tracks, track+road, ...) can either be built without overlapping clearances, or with the same "base height" (level-crossings).

Oh, and I attached an image to make it a show what I wanted to say with:

track follows the ground up to a certain max. slope, if the slope is steeper, it is automatically changed to tunnel/bridge. I don't like this because you don't have enough control, but it can be used as an initial "proposal" that the player can modify. (ie: select 2 points => use 3DTT style between them : transform track to a constant slope, automatily create cuttings/tunnels/bridges)

[Zuu]

/me likes the idea too.

There is one drawback (abit depending on how it would work else):
Only the height of the whole surface of a cell can be changed. Which make diagonal tunnels, and bridges wider than nececcary, I think. We might be able to create structures that is not cell shaped but the shape of the surface will alwas be cell shape.

[Steve]

Looks good. Work will have to be put into the UI so it is clear when a tunnel is the only option and such. Don't force changes and not explain them. I'd prefer it only tried to build a tunnel in extreme cases as they aren't cheap.

/me likes the idea too.

There is one drawback (abit depending on how it would work else):
Only the height of the whole surface of a cell can be changed. Which make diagonal tunnels, and bridges wider than nececcary, I think. We might be able to create structures that is not cell shaped but the shape of the surface will alwas be cell shape.

Why should the land be such strictly cell based? If we use a 360 degree track system, it is better to have a more freeform system for everything else. Especially for things like landscape. If your going cell-based, an isometric view is a better option than the 3d option planned.

[PJayTycy]

Only the height of the whole surface of a cell can be changed. Which make diagonal tunnels, and bridges wider than nececcary, I think. We might be able to create structures that is not cell shaped but the shape of the surface will alwas be cell shape.

The surface can only be modified on a cell basis, that's right (sorry, you'll have to get over it Steve, you can't draw a map without a squares/triangles that make up the ground).

Those "clearance" heights could be checked not for each map cell, but for each track unit (the black dots in my prototype). If you do it on a map-cell basis, you wouldn't even be able to put a track and a building in the same cell.

[Hyronymus]

Late replies but I felt like it. If we stick to triangels we can define terrain in triangles verticaly too right? One rectangle can be split into 2 identical triangles. The way to define diagonal tracks might then be to have 1/2 cell as a tunnel and the other half not. Or is this too simplified thinking by me?

[Steve]

The surface can only be modified on a cell basis, that's right (sorry, you'll have to get over it Steve, you can't draw a map without a squares/triangles that make up the ground).

Those "clearance" heights could be checked not for each map cell, but for each track unit (the black dots in my prototype). If you do it on a map-cell basis, you wouldn't even be able to put a track and a building in the same cell.

Your seem to contradict yourself. I'm saying why use the large map cells when we'll be using smaller units for other things anyway. You say that'll never happen and then go and suggest a similar thing?

I presume we'll be having varying steepness of hills and such? To make a more realistic formed land?

[Zuu]

The pro of having big cells is that you can make bigger maps.

Steve: yes there will be serval steepness. I suggest that there should be just a few, but the FRD says every 5 degree or so.

[PJayTycy]

Your seem to contradict yourself.

maybe a little

I'm saying why use the large map cells when we'll be using smaller units for other things anyway.

As far as I know, we still haven't decided on this. It might seem like that, but we have not yet decided to use a freeform system or a cell-based one.

And I thought you wanted to get rid of cells completely :

Why should the land be such strictly cell based? If ... , it is better to have a more freeform system for everything else. Especially for things like landscape

I read this as "no cells for the landscape". But landscape is exactly the only thing you will always need cells for.

One rectangle can be split into 2 identical triangles. The way to define diagonal tracks might then be to have 1/2 cell as a tunnel and the other half not.

If we stick to a cell-based approach for everything, it would be a good idea to split each square into 4 "corners" and do collision detection on a per-corner base instead of per-cell.

[Hellfire]

Another idea for handling tunnels and bridges:

Each map square has a number of landscape surfaces and landscape roofs. Always at least one surface (the ground.)
Structures can only be built directly on top of a landscape surface. Every structure has a height. There has to be enough space between a landscape surface and the next landscape roof/surface to account for the entire height of a structure built on the surface.

This is of course entirely internal to the game. When the user builds a tunnel, s/he is in fact adding a new landscape surface and roof below the original landscape surface, and probably also filling out the new room that's been made.

Bridges would be similar, except that it just adds a new landscape surface (including decoration) above ground level. Some but not all bridges might have landscape roofs over them.

I didn't realize until last meeting how good this idea actually is. However, I do think the terminology is a bit ambiguous. Also I think it has to be changed slightly to be able to implement it.

So I propose the following setup:

Definitions

• Floor: Objects have to be placed on floors. Each object (bridge, tunnel, building, whatever) provides a new floor, which is directly above itself.
• Ceiling: Objects have to be placed below ceilings to avoid conflicts with other objects. Each object provides a new ceiling, which is directly below itself.

Example: Consider a bridge. The ceiling of the bridge would be the height of the track placed on the bridge. The floor of the bridge (for objects not placed on the bridge itself) would be the area above the clearance area of the bridge.


(I'll post a Locomotion screenshot with the same info if desired.)

Tunnels will work exactly the same, except that they are built underground. The landscape surface can be considered as an object in this scheme. The ceiling will be the value of the lowest corner. The floor will be the value of the highest corner.

Implementation details:
For every tile with objects on it, we need to store a list of floors and ceilings. For empty tiles, this list can be empty, because it would be useless to store that information until something is actually placed on the tile and the list becomes relevant.

In practice, I don't think that people (or AI players) will place more than 10 objects above each other. Hence, we don't need any fancy O(log n) search structures. A linked list will suffice. In fact, I believe that in lists this small, a linked list would be at least as fast a balanced binary search tree, which takes roughly twice as much memory. Remember, the list will only be accessed when something is built on the tile.

In C++ code, this could look like this:

Code: Select all

class CMapTile {
  // other members and methods

private:
  // The linked list to store the floors and ceilings.
  // If empty, this will just take 4 bytes (sizeof(void*)) on 32-bit systems
  CFloorCeilingList* pFloorCeilingList;

public:
  // Check if an objects will fit at the desired location. This is a non-virtual
  // method and will hence not use any memory in the object data.
  bool CheckIfObjectFits(unsigned long floor, unsigned long height);

  // etc.
};

class CFloorCeilingList {
public:
  CFloorCeilingList* pNextItem;
  unsigned long lFloor;
  unsigned long lCeiling;
};

[Zuu]

I think there should be two kind of floors. Floors that you can place objects on (used for bridges) and floors that just tell that the space abouve is free, but the object have to provide some pillars it self.

[Steve]

Meeting Decisions:

- A tunnel can just be a track that is underground
- Some complex thing that jfs suggested on the forums
- To be continued somewhere.

Status: Open to discussion.

Locked until the DD discussion arrives at this issue.