Jam Postmortem

WHAT WENT WRONG:

I had a late start and some other obligations in life which prevented me from working on the project for the full jam week. Total time spent was around 3.5 days, and I think it shows in that the final product is more prototype than complete game. Knowing I was already starting late and at risk of not finishing anything, I gave myself strict hard stops for each feature. Yes, movement is important and the project will fail if it's not fun to fly, but I could easily spend weeks fine tuning the movement and controls and still not have a game at the end of it, so to be sure there was still time to address everything else I had to just get as far as I could with each feature in a short time then move on to the next. With luck, there might be a little time at the end for tuning and polishing elements that I wasn't totally happy with, but at the very least all the pieces should be there... in some kind of state. As a result of this hard policy, all the major elements are there, but some very annoying physics bugs wound up in the jam build which can cause the player to get briefly "stuck" for no apparent reason when they hit a surface at the wrong angle. Since they were discovered after I had already moved on to other features it was "too late" to go back and fix. It may have been worth making an exception for this, particularly in hindsight since it turned out to be a one-line fix.

Due to the tight deadline, it made most sense to generate levels procedurally, and I decided to try out the new LevelInstance workflow in UE5. It is so much nicer than using levels for procedural components in UE4, but I ran into an unexpected issue that nearly killed the project: packaged builds crashed immediately when trying to spawn level instances with a fairly unhelpful error, but everything worked perfectly in-editor. Unsure if this was a UE5 bug or an issue with the way I was using level instances, I wasn't sure I was going to have time both to debug the issue and to finish the game. Fortunately, I did eventually find a workaround (rather than using LevelInstanceActors, you should use LoadLevelInstance ) but this was still an unexpected issue which cost a fair chunk of time to resolve.

One major feature to fit the theme was to have the track slowly shrink over time, leaving you either progressively trapped in a narrowing tunnel or skating along a thinner and thinner wire. This was actually implemented and working well, but it drove the difficulty of the game through the roof. In the interest of keeping it fun to play, unfortunately this got cut. With more time to balance everything out, though, I think it would have been a good challenge to have creep up on players. While I don't think this means the theme is not present in the game, it's definitely not as strong in the submitted build as I'd have liked.

WHAT WENT RIGHT:

Lumen is gorgeous, but has some limitations and in certain circumstances can produce some pretty glaring artifacts as the surface cache can take some time to catch up to the state of the world. A few things that cause "undesired behavior" are small/thin emissive surfaces, fast-moving lights, and lights which change state very quickly (e.g. super bright -> super dark in one frame vs. gradually dimming). While the arch viz  community is constantly complaining about these things and people making realistic shooters hate how lumen reacts to their tracer bullets, I've been looking for an excuse to exploit these artifacts for good. A rapidly-changing procedural environment with flashing emmissive lights that pop in and out of existence in just a few frames combined with the high speed players fly through the world is kind of the "worst case scenario" when it comes to using Lumen for regular projects. It causes lights to reflect off of surfaces after the original light has vanished, it leads to some occluded surfaces continuing to emit light even after the emissiveness in their material has animated away, and all kinds of other more subtle lighting inaccuracies. For example, in the image below where can the red highlight on the ceiling possibly be coming from?

Still screenshots are full of pretty obvious lighting artifacts that you can point out, but in motion everything kind of smears together in a pretty nice way. The way obstacle spawns cause waves of light to wash towards the player, and how dodged projectiles and level geometry can create their own waves following the player is completely dependent on Lumen's slightly delayed update. In any of my other projects it would look completely out of place, but here in this abstract geometry world I think it works pretty well and gives the game a very pleasant and unique lighting style. I'll be curious to see if future UE5 builds make this impossible as Lumen continues to improve.

I've been learning to play the synthesizer, recently, and was excited/nervous to finally have a project to test out my hardware synths with. This is the first time I've created effects totally from scratch rather than starting with the random button in a tool like BFXR, and it's the first project I've composed music for, but I'm really happy with the results overall. I had wanted to have several songs with different rhythms which would play depending on the player's speed but only had time to finish one before the deadline. So it goes.


SO WHAT NOW?

After the jam I was so annoyed at a few of the physics bugs that I tracked them down immediately. They were almost all due to a single typo. That's life, I guess XD  At any rate, you can expect a post-jam build to appear in the near future with smoother physics, a number of other bug fixes, and some additional polish and detail in the audio and visual departments, plus support for high scores. But beyond just filling all the holes in the jam build what should happen to the project going forward?

Obviously "more content" (different environments, player ships, etc), but in terms of the actual project direction I see two main possibilities (apart from just dropping it and moving on to other projects, of course :p). Either we introduce combat, perhaps thinking of the project like a modern treatment of S.T.U.N Runner, which had a cool laser blaster you could use to destroy obstacles. Or, perhaps we embrace speed even further and try to develop it into a proper racing game. In both cases, hand-crafted tracks rather than pure procedural tracks would probably be a nice thing to have, and I'd love to have more complex tracks in general. E.g. jumping from one track to another (which is technically possible in the current build, but getting to tracks to spawn next to each other so you can make the jump is pretty much impossible), or to have multiple tracks intersecting and weaving through each other.