9 days left

The last development work went into the train movement. I implemented user controlled choosing of rails at switches regardless of going forwards or backwards. The way I implemented it was pretty straightforward: I look ahead the pulling waggon (remember, always pull the train) as long as I don't encounter a node which I has more than 1 valid rail for the current train movement direction. That node will be the next upcoming switch unless the train changes its direction.

Trains can now collide correctly with other trains, and depending on docking mode waggons can be docked with each other on collisions. Also slightly modified my train movement algorithm: I work with discrete integer positions of waggons on rails so I don't have some weird decimal stuff going on, but now I move every pixel position one pixel at a time instead doing the movement in one go. The basic idea can be found in the blog post from Maddy Thorson (Celeste and Towerfall Physics). I determine how many "pixels" a train needs to move. After that, move every single pixel of the total movement one by one until an obstacle (other waggon) is collided with. If we can dock it: Continue movement together with the newly added waggon, otherwise: Reset the pulling waggon back to the previous position and stop moving. I can probably throw in some physics inertia stuff but I need to focus my time on other areas.

The locomotive received particle effects for smoke. Interestingly I don't draw opaque smoke but I also don't alpha blend it. I go through a palette of colors to replace the current screen color at the smoke pixel with so all colors covered by smoke are replaced by corresponding darker ones. The smoke particles also have a z position and cast a small shadow on the ground which works the same way.

Next up:

• Gameplay: Decided for train siege combat / action gameplay. Will get interesting.
• Computer controlled trains (dumb random movement)
  
• Train docking/undocking via GUI?
• Camera looking ahead