Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

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

Would this approach to movement mean that your speed is capped by the framerate? Since you're moving one pixel at a time. It's a very interesting way to do collision detection though! Solves the overshooting issue.

The total movement is still the same. Instead of moving 5 pixels per frame in one go I split those 5 pixels up into 5 separate 1 pixel movements. That simplifies some things: Instead of moving 5 pixels and seeing "oh, now I'm overlapping something, where do I go now" I can just go "can you go to the next pixel? Yes? Move." Pixel is actually the wrong word here because a screen pixel is made up multiple subpixels internally but the idea is the same. You should really take a look at the linked blog post because the idea is very interesting but only works for integer based positions I guess so it lends itself to pixel art.