Devlog 02 - JellyCube - Update and moving forward

Devlog #02 - What am I working on today? Well, I am working on Jelly Cube the new game in development by Bliz Studio LLC. So today my task is to work on a moving platform. It will impact the player and the platforms around it so there is a lot to consider besides just having the platform move. I

This is devlog number two for Jelly Cube, returning to the series after a gap spent on other projects, client work, and family commitments. It covers the game's core mechanic, the role of a dedicated test level, and the specific technical problem being tackled that day: moving platforms.

The core mechanic Jelly Cube is an action puzzle game built around a cube character you swipe to move. The central rule is simple: the cube changes the color of every platform it touches, turning them blue as it travels. Once all platforms in a level have been changed, the level completes and the player gets a success message. It's a clean win condition — the objective is visible at all times because the uncolored platforms are literally the remaining work.

The test level Several levels are already finished, but the current focus is a single dedicated test level. This is where every experiment happens: new platform types, new enemy ideas, anything being prototyped. The play flow goes through one normal level and then into the test level. Keeping experiments confined to one scene rather than scattering them across production levels means a broken prototype never contaminates real content, and everything under evaluation sits side by side for comparison.

What's being designed The current design work covers enemy concepts, the shape of the puzzles themselves, and different platform types — the three things that will give the game variety beyond its single core mechanic.

The moving platform problem The task for the day is a platform that moves left and right or forward and back by a set number of units. Straightforward in isolation, but it collides with existing systems in two ways.

First, the level edges. Predefined blocks sit at the sides of platforms to detect when the player has gone over the edge, which kills the player. With a platform that moves, it's unclear what should happen to those edge detectors — do they travel with the platform, stay fixed, or need to be handled differently altogether?

Second, the player's relationship to the platform. Once the cube lands on a moving block, it has to stick to it and travel along with it rather than sliding off or being left behind as the platform moves out from under it. This is the classic moving platform parenting problem, and it's the sort of thing that's easy to describe and fiddly to get right.

Everything else on the list Development is only part of the workload. Social media presence, promotion, and building a website for the game are all on the same list. For a solo developer these compete directly with build time, and acknowledging that is more useful than pretending the game is the only job.

The toolset The project runs on Unity with Playmaker as its visual scripting tool. The recommendation is direct: for a designer who doesn't program at all, that combination opens up a surprising amount of what you'd assume required code. The devlog closes with an open invitation for questions from anyone working through similar problems.