I thought that I’d write a little about a scheme I use to avoid constant path finding work in the train game. First, a status report.

Coupling and decoupling are working. I had a problem with decoupling where the orientation of the “train” when a new string of cars is decoupled could be incorrect. I had simply failed to remember that the orientation of the train is the direction that the pivot point on the key car of the train is pointing on the track segment. A car that is reversed in the train needs to have a reversed orientation. Unfortunately for me, the data structures cause me little problems like this because of how I store positions and orientations of things on the track.

Path Finding and Caching Previous Choices

This is a very simple scheme to describe although given enough effort, I could probably manage to stretch this out enough to make it an article in Game programming Gems. Some of those articles in that book are one paragraph but get made into multiple pages just to fill space.

The choice caching allows the code to save the direction of travel that the train is taking whenever a choice needs to be made. While the train is moving along the track, it must search ahead for a short distance to determine if there is an obstruction or a waypoint where the train needs to stop or slow down. the distance happens to always be the maximum stopping distance of the train given its mass and speed.

The train normally finds the shortest distance to the next waypoint any time there is a choice. This allows the track configuration to change while the train is running. I opted for this because this is supposed to be a game. In the real world, a train might continue to take the same route each day until some boss tells the engineer that the new track is ready. I want to avoid micromanagement in the game and this is one place where the player should not need to make the decision. They would not have added the new track if it weren’t to be used as soon as it was ready. It’s also possible that the player might remove some track and a new route is needed at that time too. Again, the real world would be different and a section of missing track would not be known to the engineer until he was stopped somewhere where he could be told of the situation.

Since the track configuration can change while the train is running, only those choices that are within stopping distance of the train, or underneath it, are saved. As soon as the train move ahead and a choice is not found and used, it is removed from the cache.

There may be multiple choices in the cache if the train has multiple different choices to make within the stopping distance.

One interesting benefit of the choice cache is that the train can be placed on the track relative to the one maintained track location for each iteration of the game loop. Each car is not moved when the train moves, its location on the track is calculated each iteration of the loop. This avoids having to compare the old position of a car to all of the potential new positions to decide where the car should be. That process would be good for another article but for now, let’s just say that the cars are positioned on the track using linear distances instead of distances along the curves to get a more accurate representation of the train.