Fixed Timestep and Custom UGameEngine in UE4

Note: This article originally appeared on my Tumblr and was reposted here in 2019.

Okay. Fine. Everyone who told me to fix the timestep was right.

This is an update now that I’m finally back to tinkering with this project after dealing with a bunch of more important stuff (like getting a new job).

I got the math right for the projectile integration, then dealt with the weird time delta debt problem. Unfortunately, problems like the time delta debt permeated every single layer of the system. I solved the problem, but could not find a clean way to implement the solution that doesn’t make everything an unmaintainable, buggy mess.

This also means I’m abandoning the sync-action-to-the-music stuff, because the gameplay progression is now dependent on the framerate, and can quickly get out of sync with the music.

For the record, making UE4 do a fixed timestep for everything (to keep all the matinee stuff and whatever in sync) was about as difficult as the calculus to integrate the bullet movement, so it’s not like I was saving myself any effort either way.

I’ve also realized that I spent too much time worrying about making everything accessible to UE4’s Blueprints system. When going back and looking at the blueprints I actually made for the simple demo bullet pattern I had in there, they were a mess. Took me a while to figure out what the heck they were intending to do! I have no one to blame but myself for that one, I guess. The interface I came up with just doesn’t translate cleanly to blueprints.

As of UE4 4.5, the “hot reload” feature works pretty well. So I guess from now on I’ll just worry about having a C++ API for bullet scripting and I’ll rely on the hot reload for my fast iteration on designs.

So now onto the technical part of making UE4 use a fixed timestep.

Epilogue (added 2019-01-14)

I’m no longer working on this game in Unreal Engine. I started a project, called libdanmaku, to act as a scriptable gameplay system for making these Touhou-like bullet hell sh’mups. It’s written as an independent library, with the original intent to use it both with Unreal Engine and possibly others. It used Lua as a scripting engine, instead of UE4 blueprints, and had an API that allowed an application using it to track in-game objects and represent them with whatever fancy graphics they wanted to, with all the logic, collision detection, bullet behavior, and so on being handled by the library.

The UE4 sh’mup project continued a bit using this gameplay engine, but eventually it was abandoned. The gameplay engine lives on, however. It’s currently (as of this writing) being migrated from Lua to my own scripting system (Ninkasi) that I built specifically for this project. It’s being used in a game with a custom graphics engine that’s also due for a re-write!

One hell of a long project, but I love it, and I’m probably never going to stop!