Winning!

Now the game will tell you when you have met the win conditions of the level and open up the next level to play. There can be a few types of goal, like "deliver 10 trains to the terminus", or "gather 10000 points from delivering cargo". The type and amount of the win condition are set in the map maker.
I'm taking this home with me for winter break to show my Oregon buddies!

196 hours...

Hills and Bridges!

I made some more types of tracks, including extra-long curves, inclines, and overpasses. This required new animation paths for the cars to follow, rebuilding the map-maker menu, and losing the saved maps whose information could no longer be interpreted the same way. I built a much less fragile system this time.

Also, for my birthday, I made a cake-carrier car! Eventually, I'll want all kinds of stuff to be carried by the trains. Maybe the type of cargo will fit some kind of story as the levels progress...

177 hours in.

Money!

When you stop a train at a station, it will now unload its cargo and give you money. Now that there is a score, it begins to feel like a REAL game...

163 hours in.

Physics!

I decided trains that cleverly avoid collisions aren't as much fun as trains that crash. The "ghost car" thing is a bust. The traincars are animated until the moment they collide with another traincar. At that moment, they turn into physical objects with the same velocity as the kinematic cars had, and let the inadequately-secured logs fall where they may!

Here is what happens when crashed trains build up and newly-spawned trains can't get out of the station. Train fountain is a feature, not a bug. : )

120 hours in.

Smart trains!

One can now start and stop a train by clicking on it. Trains now spawn from the green boxes, and disappear into the red (yellow stations are there, though they don't mean anything yet). 

Also, implemented a collision-avoidance system. First, tried casting a ray (which is very like shooting a laser detector) ahead of the engine to detect if it was about to hit another train, and if so, stop by itself. But it was too unreliable. Next, I sent an empty gameObject ahead of the engine to collide with other trains. It behaved exactly like any other train car, but without the geometry. An invisible car zero, a "ghost car". The ghost car can safely hit another train and stop the real train behind it in time. This works a lot better. In cases of two ghost cars hitting each other, the train that has existed the longest gets the right of way. Seniority!

83 hours in.

Map Maker!

Got tired of moving the tracks around manually to test different scenarios. Knew I would have to make a tile-based level-editor eventually...  maybe someday, this will be a fun part of the game too: making one's own maps to play on. I use external XML files to store the saved maps and load them in when it's time to play. That was totally new to me, and took some learnin'.

Here, as a key example, is a line of code that collects the contents of any tags named "T" in the whole XML document and puts them into an ordered list called "types". My program then refers to the list when deciding what track to put at what square. Handy!

string[] types = xmlDoc.Descendants("T").Select(element => element.Value).ToArray();

About 400 lines of code for the map maker, 200 for the train motion so far. As we learned on Starbounder, working out a good user interface is much harder than the actual game.

53 hours in.

Cars!

Box now replaced with basic engine, hopper, and caboose models. Rather than check ahead for itself, cars behind the engine do whatever the car in front of it did, but delayed. Only the engine decides where to go, so the train doesn't split if you switch tracks in the middle of it. The white "station" box at the top can spawn a train with a random number of cars and send it down the track.

22 hours in.

Motion!

Instead of plotting the box's path with complicated trigonometry equations I don't know, using a finicky physics simulation to stay on track, or using costly raycasts to read the rails every frame; this rectangle is simply animating along a local motion path. When the end of a path is reached, the "train" looks ahead to see where the next track section is, centers itself on the new section, and starts a local animation clip (either straight right or left depending on the type of track). If all goes right, the moment it jumps to the new track section should be unnoticeable. It then animates along that path until the end is reached and the process repeats. Let me see if I can illustrate this idea. I know words probably won't do it...

Cars will loop their animation locally if there is no next track section...

...if there is, however, the car moves and re-orients itself to the next track section before re-playing the animation. The jump is too fast for the player to see (here, I have made it visible with the green indicator), and the motion of the car looks seamless.

16 hours in.

Start!

I decided to start making a game about trains using an idea for motion I had left over from Starbounder 2. More about that next post. First, the inspiration. There is a clever little 2D Flash game called "Train of Thought" that I enjoyed when I was paying for Lumosity earlier this year. Here is what that looks like:

I wanted to make my own version in 3D, and expand upon the gameplay too. To see if this maddening split-attention brain exercise could be made into a real game.

I will be using Unity's free engine (v.5), the included features of which have been greatly and graciously expanded since we used it (v.3) on Starbounder. We get shadows now! It's the full engine and one only pays to be able to output to a device (iPad, android, Xbox, etc.) other than your computer. It's a smart move, thank you, Unity!
Also, I will be programming in C#, learning it as I go along. C# is a bit stricter than Javascript, which was the preferred language 4 years ago on Starbounder. For the stricter rules, I've been told you get more efficiency. C# is a lower-level language, closer to the "assembly language" a computer actually "thinks" in, and therefore quicker to translate and execute. Theoretically. 
Anyway... the question boards and tutorials accommodate both languages, and the community is really, really good. I have never run into a problem in Unity that was un-google-able.