Zero Zero: Perfect Stop (Train Sim)

I'm familiar with the series and actually was assuming that was what you were doing! I did not anticipate the part about the E break- if not for that, my suggestion would work. What Alberto's method prevents is the awkwardness of swinging around fully and going straight from E to 5 or vice versa, that's what I meant about "immersion." Another idea could be to dock for E. Anyway I'll stop telling you how to control this train and just look forward to a release (or beta?) :stuck_out_tongue:

Ah yeah, that was a problem I immediately ran into :stuck_out_tongue: My current solution for that is actually just preventing any direct shifts between throttle and brake settings, and instead always requiring a shift through neutral. That way you can push the crank all the way around the back and it will not suddenly flip over to Throttle 5, etc.

1 Like

That definitely seems like it would work nicely. I took your MSPaint too literally!

yay! I have the plug-n-play version of Densha De Go, and it seems like the playdate is the ideal platform for a mobile / handheld implementation! Looking forward to see this one come together :smiley:

1 Like

Couple weeks since my last update!

I have implemented a few new things since then. One is the track lookahead view on the left, it now shows upcoming speed limits and checkpoints. There is also now an indicator for the distance of the upcoming station.

I have also done a first pass implementing SFX for driving the train. In the interest of keeping RAM and Disk usage down, I have done all the SFX in mono 8-bit @ 16KHz (About on par with SFX for a GameCube or Wii game). Despite the somewhat crunched samples, I think it still sounds nice. I was also able to use the built-in TwoPoleFilter to do a bandpass and implement a dynamic wind sound effect.

Check it out in the video!

Next on the docket will be implementing some game rules and getting the actual gameplay loop going.

10 Likes

Wow this looks awesome.... :slight_smile:

I've started working on the game flow stuff! First up is a game start sequence which shows the status of the course diagram...

DiaIntro

8 Likes

Oh my sweet Jeebus, if you seriously get Densha De Go on the Playdate 1) my life is over 2) I love you 3) How dare you.

GOTY contender right here.

Also, I would put money down now for a beta that was just like a random length of track with one stop and a high score board. Maybe a way to get beta feedback without "giving away" the game?

1 Like

This is the approach we're taking with Sparrow Solitaire, essentially.

Yeah, I might try a small demo with a short diagram once I get the full game loop implemented! Thanks for the suggestion

1 Like

First update in a while! I can only squirrel away time work on this project on weekends, and my past couple of Playdate sessions were spent digging into some bugs @matt reported on my PDFontConvert project

Anyway, I've been aiming to get the game loop functional before digging more into the game visuals. Yesterday I reached a good checkpoint! You can now complete a full cycle of departing, traversing a segment, then stopping at the station. Check it out in the video:

9 Likes

Getting into the fun stuff now- visuals! For starters, added some curves and hills to the pseudo 3D track...

8 Likes

Testing out some power lines and sprite scaling! Now the "super scaler" 3D effect is starting to come alive. I managed to get decent performance on device by pre-scaling the sprites, but need to figure out a way to bake that into an asset instead of doing it on game load

5 Likes

After you've generated them in game, save them to disk? Then you can combine into a sprite sheet.

This is looking really good!

Hey, good to see you adding more details. But I wonder if it would be possible to draw the cross beam with lines, because it seems to shift thickness due to the scaling. Takes away from the zen feel for me at least

I was talking about this with a friend, and came up with an interesting solution. If I originate the sprites as SVGs, I can set the strokes to maintain a fixed with when the image is scaled. Implementation is a little bit more complicated than that, but I tried it out in game and it looks much nicer :slight_smile:

4 Likes

It does look nicer indeed! Can't wait to try this one out. I can already feel the vibes of the game.

Much improved! A disadvantage is that the thick lines make the bar look solid at a distance.

Are you using lines thicker than 1px? Then I suggest the following:

  • determine the distance at which the individual lines become visible. This is the near threshold.
  • before the near threshold is reached, use a line width of 1. After the near threshold, use the current line width.

This produces a single switch in line width, hopefully not as noticeable because it happens when the bar is still small on screen.

1 Like

It's been a minute since I made an update! I'm still working on it.

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 and 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! (You can read more about this technique in this 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) which operates on track data JSON
  • Use Windows Named Pipes to communicate between the Electron app and the game DLL

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, which I will be able to use to author and live preview the levels.

Here's some shots of the editor app:



And a proof of concept of the live communication:
PlannerE_Live

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

12 Likes