🔮 The Very Serious Juniper Dev Game Jam: Six of Nyx + Big Tony's Epic Wheel

June 27, 2026

The Very Serious Juniper Dev Game Jam ran from June 19 to June 27, 2026, just over eight days. The theme: Spin to Win.

I had already planned to join with Cxbane, my regular jam partner from Necrocure and Shrimp Away. A few days before the start, a second team reached out: their programmer had dropped out and they needed someone on short notice. I said yes. So I spent eight days split across two separate projects, two codebases, and two sets of team dynamics.

Six of Nyx

Six of Nyx is a 3D puzzle game. The setup: you control a large glass sphere with a marble trapped inside it. Each level is a floating platform puzzle in 3D space with three stars and a finish goal. The marble rolls freely inside the sphere, so rotating the sphere is how you navigate. A second mode, marble-view, lets you switch to controlling the marble directly, which is needed when the sphere position is set and the marble needs more precise guidance to reach something.

Controls

Getting the two control modes to feel right took longer than expected. Rotating a large sphere and directly steering a marble inside it are very different input models, and blending between them without a jarring transition was something we kept tuning throughout the jam. We eventually landed on something that felt good, but the level design did not always make full use of the dual-view mechanic. Some levels could be completed entirely from one view, which flattens the concept. That is the clearest thing we would revisit with more time.

The Mist Shader

The most technically interesting piece is the volumetric mist inside the glass sphere. It is a raymarching shader built in Shader Graph backed by a custom HLSL file for the raymarching loop. Rays are cast through the sphere volume and sample 3D noise as they travel, accumulating density to produce soft cloud shapes that sit naturally inside the curved glass surface.

I also wired it to a script for level transitions: when the scene changes, the script drives the shader's color and density toward a dense red, then fades it back to normal once the new level is loaded. It is a small touch, but it makes the transition feel deliberate rather than like a hard cut.

Big Tony's Epic Wheel

Big Tony is the humble owner of a mechanical museum who set aside a life of crime to pursue his dream of silly gizmos, doohickeys and whatchamacallits. His past catches up with him: four old rivals show up, one wave at a time. Your weapon is a yoyo. After each of the 10 waves, you spin a wheel and get a buff or a second yoyo.

I joined this team on short notice as their sole programmer. The artists were first-time jammers, which meant some things took longer to land than planned, and the final stretch of the jam was a crunch. There are features that did not make it in, and one more day would have made a real difference to the final state of the game.

Technical Work

Three things are worth mentioning:

The dithered death fade is a dissolve shader for enemies. Instead of a hard destroy, dying enemies fade out using a screen-space dither pattern on the alpha. Simple to implement and it adds a lot of game feel.

The HP-linked vignette reads the player's current health and scales a post-process vignette from zero at full health to heavy near death. No number displayed, just growing screen pressure. It works well as a danger signal without interrupting the action.

The sprite flipbooks on 3D quads were the main structural challenge. All the character art was 2D sprite sheets, and the game runs in 3D. I built a system where each character renders as a camera-facing quad mesh, with a shader advancing through frames of the sprite sheet based on an animation index and playback speed. The artists could keep their 2D workflow entirely while the game rendered in 3D space.

Retrospective

Eight days across two teams is genuinely exhausting. Each project got less attention than it would have with a full dedicated week, and keeping two design contexts, two codebases and two sets of team communication in parallel is a real cognitive load.

The output felt rewarding. Finishing a jam is always satisfying, and finishing two in the same window is a strange kind of double payoff.

That said, I would not do it again, at least not as primary programmer on both. I tend to end up as the main programmer and producer on whatever team I join, and splitting that role across two projects just means both take a hit. One team, full commitment, is the better call.