It's been a minute since I made an update! I'm still working on Zero Zero: Perfect Stop!

In terms of new gameplay features, the biggest things I have updated are adding a parallax background layer, and migrating the game to use framerate independent logic.

I was previously using 30FPS fixed frame logic, but I've been wrestling with keeping a steady 30FPS while adding graphics features. This was making the game feel sluggish whenever the framerate would fluctuate, and also meant the in-game clock was drifting quite a bit.

Ultimately, I decided to unlock the frame rate, implement deltaTime, and use that across the game logic. The result was a smoother and more consistent game feel, and since the train motion was so gradual already, FPS dips became less noticeable when playing on the device. This also had the side effect of letting the game run at full 50FPS in simulator! (This technique is discussed in this Playdate developer forum thread)

Here's some footage of the game running on the device with these changes:

After getting over that hump, I was stuck for a while about how to handle authoring the track data. I had a bit of a head start, because back in May I worked out how to estimate timetables given distances between stations, speed limits, etc. At the time, I used d3.js to help me because it was an easy way to draw custom graphs.

Here's a look at my Timetable tool back in May:

The trouble with the pseudo 3D presentation style is that it is tough to visualize a course layout in other modalities. Really, you need an authoring tool that can let you preview your work in the pseudo 3D style moving forward through the course.

I also wanted to leverage work I had already done. So, if possible I wanted to build on top of the timetable tool, without having to reimplement the pseudo 3D drawing stuff and worry about maintaining parity between that and the game.

The way forward I decided upon was:

• Turn the timetable tool into an Electron app
• Make it a "document" centric app (New/Open/Save/Save As/etc.) which operates on track data JSON, and can export track data in game-ready binary format
• Use Windows Named Pipes to communicate between the Electron app and the game DLL

I had experience working with Named Pipes already in C via Win32, but this StackOverflow thread helped me close the loop on the Electron/NodeJS side.

When the game connects, the Electron app dumps the track data to the game in a binary format I wrote for the game-ready asset. The game loads the level and maintains a live connection. I'll be able to leverage this workflow to author and live preview the levels.

Here's some shots of the editor app:

And a proof of concept of the live communication:

So yeah, this is coming along, and hopefully should enable me to build up a full course soon for a demo!