Skip navigation

Welcome to WordPress. This is your first post. Edit or delete it, then start writing!

The train setup menu now displays a preview of the engine you are purchasing.  It also allows you to edit already purchased trains.


Train with smoke stack moving South.


Train with smoke stack moving North.


Just a quick update.  A train’s boxcars now fade in as they pull out of the station.





Today’s task was to create boxcars that follow the engine and each other in turn. Once again I had to catch myself from making the problem too difficult.  I set up a test scene that I could quickly iterate on (instead of having to place track and stations and buy a train every time I wanted to test).  That was smart.  This was dumb:  I started out by trying to make the boxcars behave like real physical objects that have a forward and backward attachment point and tried to “figure out” where they were on the track based on the boxcar (or engine) they are attached to.

After floundering with that for a while I had a thought: I have the engine working correctly, why not just have each boxcar behave like the engine but delay it the correct amount of time before sending it down the track after the engine.  A little bit of programming later I had a much simpler solution and it looks great.


Please excuse the height miss-match.  I will fix that later as I polish the train code.  I think I might have each boxcar fade in as it pulls out of the station…

When I first sat down to implement train path finding on placed tracks I had an overly complicated model in my head of how tracks connected and how one might sniff out a path on the track.  It involved allowing “turning around” at a station that was not the train’s destination – how do you indicate that it’s “OK” to be traveling the same path but now the other direction… Then, in the spirit of MVP and my original “simplify it if you can and the game is still fun” mentality I realized that trains don’t need to be able to turn around at stations.  The rules I put in place for track layout guarantee that a train can get from any hex to any other hex without backtracking on hexes it has already visited.  With that understanding there are no circumstances where turning around at a station nets a shorter path or opens up solutions that wouldn’t have otherwise existed.  It was just me wanting to solve the hardest, juiciest problem.

After throwing out the idea of non-destination station turnarounds the entire problem got way easier.  A simple “bucket fill” path solving algorithm nets all possible solutions and then I just ask for the one that costs the least.  Cost is a combination of distance and type of terrain the solution has to pass though.

Here we see a train following a solved-for path from Charlotte to Donald’s Tree Farm.  Sorry about the gif artifacts, those are not there in the real rendering.



Next steps:

  • Box cars
  • Supply/Demand netting from train deliveries
  • Player Goals

Working down the list of MVP requirements I have done a lot of work.

Resources are now labeled on the map. I had to do this so I could show the label in the train’s stop list, so why not add it to the map while I had the information on hand.

Stations can now be placed.  When in station placement mode, hexes that are available for station placement are highlighted in blue.


A station has been placed in “Tulsa” and confirmation is about to take place:



A few more stations are placed and the player can now buy a train.  The player selects the type of engine and the different stations a train will visit:


After selecting “Add Stop” (need a better name for “stop”. “Way point”?) the map is available and all hexes with stations on them are highlighted in blue, indicating they are available for selection.  Hexes with a stop already placed on them for this train are highlighted in yellow as a reminder to the player that the train is setup up to stop there already, but these stations can be selected again if the player wants a train to visit any particular station more than once in it’s loop:


The stations are listed in order that the train will visit them.  Ordering and deleting of rows is available:


I have spent the last two and a half weeks working diligently on my MVP for project Cat Phone.  The plan I described in my first MVP post has been paying off.  I have worked on the project casually and have focused on my MVP one item at a time.

I purchased a hex framework a long time ago when I first got interested in re-booting this project and have been sitting on it ever since.   This gave me a very easy way to implement item number 1 on the MPV list: a hex map.  From there, I have added random resource nodes around the map, and most importantly, added path finding and track layout.   I have put into place rules like: Only one branch or resource node per hex tile.  The hex map and these rules allow me to simplify track path finding and layout quite a lot.

If you look closely at the bottom left of these screen captures, you can see the track layout working with branching.  In these pictures, new track to be placed is rendered in a purple color and track that has been placed is rendered in a yellow-brown.  Resources are spheres rendered in a color depicting their type (green for timber, off-white for color, etc.)

Next on the list to tackle is station placement, then train path finding.

screenshot2 screenshot3 screenshot4 screenshot5 screenshot6

A few years ago I was working feverishly on project Cat Phone. I ran into a problem I couldn’t figure out and left the the project alone for some time. Since then I have gotten married, purchased a house with my wife, and learned to fly (like real airplanes, I’m a pilot now).

Recently I have been reinvigorated to start messing around with another game programming project. I have a few projects I want to tackle but have to choose one.  I chose to reboot project cat phone for a few reasons:

  1. The game excites me
  2. It is not multiplayer (this significantly cuts down on the difficulty level of creating the game)
  3. I think it has the best chance of success in the market place

When I put the project down years ago I was stopped by a path finding issue where connecting tracks to new tracks was a problem. When discussing the issue with a friend he suggested I simplify the rules of how track could be placed. At the time I brushed the idea off and was determined to solve the more complicated and generic problem. That turned out to be a mistake, it burnt me out and I put the project down.

Now that I am rebooting the project I have chosen to heed my friend’s advice and simplify the track placement rules. To accomplish that, I have chosen to use a hex map instead of natural and free-roaming terrain. This will allow me to simplify the path solving by putting in place a few rules. The biggest simplification gain is rule number 1: roads may only branch once per hex.  This means that complicated intersections can not exist.

I have also chosen to follow a minimum viable product (MVP) strategy for developing the game in its first stage. I have written down a long list of things I would like the game to do that I think will be fun. I then took that list and cut out anything that wasn’t absolutely core to the game. For example, I would like the player to be able to buy upgrades for stations but that’s not a core feature so it was cut from the MVP list.

Now my task is to implement things from the MVP list and nothing else. No feature creep, no art assets (cars will be cubes, resource nodes will be spheres, etc). Once the MVP list has been implemented I will show it to some friends and ask for feedback. Till then, it’s a no-frills affair.

I have been working more on project Cat Phone recently.  I have added a lot of new mechanisms to the project.  The most recent being the supply and demand engine.  None of the numbers are correct (the rates that things produce goods, and the rate they demand them, etc.), but the engine is now fully in place.

Cities may have industries added to them (The extra-large white models in the cities you may see).  When an industry is added it creates a supply and demand sub-node on the city.  A city can have any number of supply and demand nodes.  They are all added up and the total of each type of good is displayed for the player to recognize in the HUD along with a numerical indicator for how much that type of good is being supplied or demanded.  I am using random license-free textures I found on the internet to do those indications  so they don’t look so good.  But when the projects moves towards production and becomes an official game, I will have an artist replace everything with good looking textures and models.

Supply Demand

Supply and Demand HUD

I added Cities to my game tonight.  They know their population and base how “big” they are based on it.  Each city has a number of buildings based on the population as well.  The number and size of the buildings grows with the population.  At the moment these buildings are represented by white boxes, but that can change if I ever get some real assets.


The really cool trick is that that when a road is placed near a city, all the buildings in that city check themselves and make sure they are not over the road.  If the building does exist over the road, it re-position’s itself.