Rebalance

Inspiration

Rebalance was inspired by simple daily puzzle games that are easy to understand but difficult to master. I'm obsessed with games like Wordle and ColorPuzzleGame, the type of games that are simple but trigger my competitive side and desire to improve my score

This is my first Devvit app, and I found out about the hackathon only a few days ago, so I wanted to keep it simple. I wanted to create something that was fairly intuitive; that didn't need a tutorial phase to be able to do it. Basically, reducing resistance between seeing the game and trying it.

I spent about a day thinking of different games that were simple but could evoke that obsessive feeling. I eventually remembered something I used to do in between classes as a child: I would take a ruler, place it over a sharpener, and place items on either side, trying to balance it. This was the starting point for Rebalance.

At first, I had the idea to make it an asynchronous multiplayer game functionally similar to Jenga, where each player had a limited number of moves, and they would take turns moving the objects until the last player left without a move to rebalance it lost. Unfortunately, over time I realised I needed to reduce the technical complexity to be able to stay on track. I decided to return to that original childhood experience of one person trying out different strategies.

As I kept on developing and testing the game, I decided to add some features intended to bring out stronger emotional reactions and encourage players to return. This included the release of a new, unique puzzle every day, special days where the puzzle is way harder to solve, called "Chaos" days, first-attempt scoring, optional leaderboards, displaying community score distributions, objects with (similar) real world physics, a large and varied inventory of objects so new puzzles use a different set and arrangement of them, different instability levels, and objects that correspond with real world items.

The final concept slowly transformed into a daily balance puzzle where players place, stack, move, or remove familiar objects onto a plank resting upon a moving ball until the plank settles. Because the objects have different visual weights and shapes, any move could be the tipping point.

What it does

Rebalance is a daily puzzle where players are given a collection of recognizable objects arranged on and around a plank. They must drag, stack, reposition, or remove objects until the plank becomes stable. The moving fulcrum responds to how the weight of the objects is distributed on the plank. When it is unbalanced, the plank shakes and tilts, which can cause objects to fall off. Players can return fallen objects to the plank or choose to leave some objects out.

How we built it

Rebalance is built as a Devvit application using Phaser for the interactive game layer and Redis for the persistent data. Phaser is responsible for the draggable objects, plank movement, stacking, etc. Basically, the physics of the game.

I used OpenAI's ChatGPT and Codex in VSCode to help me build it. I am a 4th-year Computer Science major and can code, but I have developed a documentation-based workflow for AI-assisted development that is very efficient for me. I discussed the features I wanted in the project in ChatGPT, and discussed the pros and cons and what was technically feasible. I also generated some wireframes in this chat, provided the assistant with the hackathon rules, Devvit documentation, the Devvit Phaser template, and Phaser documentation. I then had it help me produce several structured project documents (markdown files):

A Project Description document explaining what the product is and what it should do A Project Instructions document defining how changes should be approached and in what order A Scaffold document describing the architecture and implementation plan A Changelog document recording what changed and why A Manual Setup document recording human actions required outside the codebase

The Project Description and Project Instruction documents were generated first, from a template I made for my own projects. Codex is instructed to read these documents before making changes and after making changes, to update them afterward. This gives the project a persistent source of truth and reduces the chance that later changes contradict earlier decisions.

Using this workflow, I reached a basic interactive prototype in approximately five substantial implementation prompts and under an hour of active implementation time (limited by my subscription tier). From there, most of the work involved testing the app inside Reddit, identifying where the experience did not feel right, and directing increasingly specific revisions.

I reviewed the changes, ran the project locally, tested it in the Devvit playtest subreddit, and repeatedly adjusted the design based on how the physics and interface felt in practice.

Challenges we ran into

Because this was my first Devvit app, some of the earliest challenges involved setup rather than game logic. I initially had the wrong Node.js version, ran npm commands from the parent directory instead of the project directory, and had to correctly register and upload the Reddit app before starting the playtest.

These issues helped me understand the relationship between the local project, the registered Devvit application, and the Reddit playtest environment. The hardest design problem was tuning the physics. The original motion was too subtle. It technically showed that the plank was unbalanced, but it did not feel urgent or visually interesting. I increased the fulcrum speed, plank angle, oscillation, directional force, and object movement until an unstable arrangement felt close to collapsing.

However, making the game chaotic introduced another problem: it still needed to feel understandable. Players should believe that an object fell because of its position and shape, not because the game behaved randomly. Originally, a falling object could invalidate or reset an attempt. During testing, this felt too harsh, so I changed the system so that removed objects and fallen objects enter the same tray. The plank keeps its current state, and the player can either return the object or continue without it when the puzzle allows pruning. This made falling part of the puzzle rather than simply a failure state.

Objects never display weight values, so this meant the object roster had to communicate weight through real-world familiarity, size, material, and behaviour. Choosing an understandable set of items became part of the game design rather than only an art decision.

Despite my best efforts, as the game developed, the model began to be less effective, occasionally making simple mistakes. This was also impacted by my increasing use of multi-task prompts - I started out only giving one or two tasks at a time but got tired of waiting so opted to create more complex prompts. However, I did notice that numbering the tasks helped it to stay on track better.

Accomplishments that we're proud of

I am proud that I built a functioning Reddit-native physics game as my first Devvit project after discovering the hackathon only a few days earlier. I am also proud of the development workflow itself. This was one of the smoothest workflows yet, with simple issues to fix. The project documents allowed me to use AI agents without losing track of the architecture, decisions, or reasoning behind individual changes.

What we learned

The non-technical aspects of this are so important, and most of the time was spent thinking up these UX features that make the game appealing.

What's next for Rebalance

Waiting for more feedback to fix any major issues and get suggestions. Perhaps more levels (e.g., easy, hard), badges for accomplishments, and the inclusion of multiplayer features.