Representation of trains on a simplified rail grid

Question

I'm working on a hobby game, basically about train dispatcher's job.

(stack: Typescript, phaser.js)

My map is based on a grid, each tile can hold 1 rail tile (well, except junctions, but we can simplify it for now, since junctions are just multiple tiles, from which only one is active).

Example (black is grid, white is rail):

As you can see, we have basically three different tiles: straight rail, 45 degree turn and diagonal rail (which can be also considered straight rail). I don't plan to add more tiles, as you can already build pretty complex setups from these tiles.

On these rails, trains would drive. Each carriage has two "wheels" - positions, where it snaps to a track. This may be seen on the following example from my prototype:

However the existing system (see below) has some issues:

• when a train travels diagonally, sometimes it's x and y coordinates fit in a field than it should (example: traveling from 1|1 to 2|2, but at one point the train's coordinates correspond to the field 1|2 or 2|1).
• axles sometimes get closer or futher away from each other. This has almost no effect on resulting simulation (as the carriage is centered between those two axles), but may cause carriages to be closer or futher away from each other (this effect is visible on the prototype as weell)
• moving the train in a certain direction is handled by a big chunk of code that essentially lists all possibilities of directions and handles it. I'm interested if there's a better way to do it, so I could simplify the code.

I decided that I would improve the core. I'm wondering, what would be the best way to do this?

What I am looking for:

• how to save the rail pieces on the map?
• how to move train (I know it's x, y, speed and acceleration)?
• how to have the train continue to the next piece on the grid?

Current solution (broken in some edge cases, also not ideal):

• each rail piece has it's class (CurvedRail, StraightRail)
• each rail piece class has method movePoint, that accepts x, y, direction and distance and returns new point (that is distance away from the original point, but also considering track turns). It may also return delta, if the movement reached edge of the tile and it needs to be moved futher (on another piece). This is handled by a separate class, that finds the following rail piece and calls movePoint with the delta instead
• it has issues, because sometimes trains passing diagonal connection don't exactly follow the diagonal, so they instead of ending up on the next diagonal piece, they end up on neighboring horizontal or vertical piece and derail.

One of the issues I may be facing is that tiles are 32x32 pixels, so it's hard to travel exactly in the "middle" of the piece, because it's "between two pixels", and although I'm using decimals, it may be a problem. Is it better to have a grid from odd-sized tiles?

Answer 1

On tracking

Your current simulation behaves pretty well, I would say. Because a rail wagon that is halfway a sharp bend, will indeed exhibit the behaviour that the wagon's center is no longer above the track, but next to the track.

Center of the tile

Traveling over the exact middle of a 32x32 tile: This is easily accomplished if you were to draw the rails with 2-pixel wide lines. (And the trains as 4 pixel or 6 pixels wide.)

Encoding

Encoding the tiles... You need to make a choice on whether your network is directional or not. If all tiles can be traversed in both directions, then there is no distinction between entrances and exits to the tile.

An entry/exit point can fall on any of the four tile corners, or any of the four tile edges.

You can then define a tile with an 8-bit value where a one-bit means a gate is present, and a zero-bit means there is no exit/entry for that location.

If you consider only single-track per file, not all 8-bit values would be valid, only the ones that have 2 bits set to one, and of those, only if the turn is not too sharp.

Take, e.g. the tile below. It would have encoding 00010010b which is decimal value 34.

In the example network you provided, you would filter out the cases where the turn is too acute. So if there is a gate at bit 1, you only allow the other gate at 4, 5 or 6.

This gives you ( 8 * 3 ) / 2 possible encodings, so just 12 of them. Or 24 if you define your tracks to have a direction (explicit entrance and exit.)

possible encodings:

 // 3 cases with gate at 0:
 00001001
 00010001
 00100001

 // 3 cases with gate at 1:
 00010010
 00100010
 01000010

 // 3 cases with gate at 2:
 00100100
 01000100
 10000100

 // 2 remaining cases with gate at 3:
 01001000
 10001000
(00001001) duplicate

 // 1 remaining case with gate at 4:
 10010000
(00010001) duplicate
(00010010) duplicate

You could chose to store the tile pattern as this 8-bit value [0..256) or as a case number [0..12) if you prefer.

Train Travel

To move a train (or wagon) between tiles, you would need to keep track of a 'from' tile and a 'to' tile. Let's call them tile_fr and tile_to.

And then keep a parameter 0 <= t <= 1 that records where on the track the train is.

At t==0, the tail of the wagon is at the start of tile_fr. At t==q, the nose of the wagon is at the end of tile_fr, at t==1, the tail of the wagon is at the start of tile_to.

If q <= t <= 1 then the wagon is occupying both tile_fr and tile_to partly.

When t has reached 1, you need to swap the tiles. Tile_fr is set to the old tile_to value, and tile_to will be assigned the next tile.

Axle Travel

As you stated, when consider positions of wheels (axles, really) it gets easier. You track a progression parameter for the rear-axle, and one for the front-axle.

To deal with differences in track-lengths per tile, you can modulate the speed at which you move the axle parameters along the track.

If you define the straight-track piece as having unit length, then you can determine lengths L₁ for the bend, and L₂ for the diagonal track across a cell.

When an axle position parameter is moved along the track, you divide the speed by the track length, so use (v / L₁) to move the parameter along the cell with a bend.

The rationale: On longer pieces of track, you need to take more time to progress from value 0 to value 1, so that you get the same distance per unit of time.

Alternative Grid

Let me conclude with describing the approach I used in my train simulation. First off, my tiles are hexagons, not squares. Next, my tracks are splines, not line segments. Last, my tracks are directional, meaning there is an entrance edge (0..5) and an other edge as exit, which MUST NOT be a neighbour of the entrance edge. This gives me 6*3 or 18 different cases. Each track goes either L, R or S. A nice bonus is that the splines in all three cases (L,R,S) has pretty much the same length, which is not the case in your square-crossings.

Using splines means that there will be no sharp corners, which may or may not be something you want. If you do, look into Hermite Splines, for example.