Binglecraft

A content rich voxel survival-adventure game built using Codex and GPT-5.6 Sol. Do you have what it takes to become the next Bingle Lord?

Comment

Inspiration

Binglecraft began with a single question: how far could a single developer push Codex and GPT-5.6 Sol to build a cohesive game with exploration, progression combat and a unique visual identity?

This project started as small browser prototype inspired by the discovery and creative freedom I loved in Minecraft, Terraria and Hytale. I want to combine the open-ended sandbox experience with a more structured adventure that gives players a clear objective and a satisfying conclusion. AI-assisted development made my ambition possible, but turning an idea into a polished game still required extensive planning, experimentation, testing and of course, human judgement.

What it does

Binglecraft combines an open-ended voxel-building system with a structured seven-boss campaign. The player explores an infinite procedurally generated world, gathers resources, crafts equipment and defeats seven major bosses to claim the Throne of Bingles to become the next Bingle Lord.

Players travel through seven distinct biomes and an alternate dimension, encounter more than 50 enemies and minibosses and discover, collect and craft over 500 unique items. They can also build freely, farm renewable resources, explore dungeons and unique landmarks, experiment with magic, and prepare for the ever-looming Binglemoon, a relentless onslaught of mobs that seek the player anywhere in the world.

Binglecraft is designed for players who enjoy creative survival sandboxes but also want clear progression, memorable boss encounters, and a campaign they can master.

How I built it

I first used a browser prototype to validate Binglecraft’s basic movement, exploration, combat, and resource loops. The project was then ported to native C17 using raylib, OpenGL 3.3, and GLSL shaders. Before Build Week, the native version supported a simplistic and very broken port to C17, many of the games features were non-functioning or simply did not exist. During Build Week I used Codex and GPT-5.6 Sol to add functionality to all items, redesign world exploration and progression, introduce a broader test suite, and overhaul item art across the board.

The engine streams a deterministically generated world in 16 × 16 × 288-voxel chunks and runs gameplay on a fixed-step 60 Hz simulation. The codebase separates world generation and streaming, rendering, gameplay and enemy behavior, inventory and crafting, persistence, interface systems, and centralized content definitions. The finished game also includes distant-terrain levels of detail, dynamic lighting, shadows, water, post-processing, and multi-world persistence.

I used Codex powered by GPT-5.6 Sol as a repository-level engineering partner. Instead of asking it to “make the game,” I divided work into bounded tasks with specific behavior, constraints, and acceptance criteria. After each major change, I compiled and played the build, reproduced failures, inspected the affected systems, and returned precise bug reports or revised specifications.

Codex accelerated implementation, repository exploration, debugging, asset generation, test creation, and documentation. My role was to decide what the game should become, translate that vision into testable engineering tasks, play and evaluate every major build, and reject work that did not meet the project’s technical or creative goals. Codex generated and modified much of the implementation under that direction, while I remained responsible for integration and the final result.

Challenges I ran into

The hardest challenge I faced was maintaining quality while many interconnected systems changed quickly. AI can produce code rapidly, but a plausible implementation is not necessarily a correct or well-integrated one. Problems often appeared at the boundaries between rendering, world generation, saving, collision, and gameplay.

One example was chunk streaming. Synchronous chunk construction caused visible frame hitches while the player moved through the world. Before the redesign, synchronous chunk construction consumed 15.6 ms at the 95th percentile and 18.6 ms in the worst sample of a repeatable 160-chunk release-mode benchmark. I used those results as acceptance criteria while Codex helped move construction to a low-priority background worker, leaving only a small, bounded publication step on the main thread.

After the redesign, the main-thread publication step measured 0.50 ms at the 95th percentile and 0.66 ms in the worst sample. In a related rendering stress test, the number of frames exceeding the 16.67 ms frame budget fell from 26 out of 440 to zero.

That process became the model for the rest of Binglecraft's development.

Accomplishments that I'm proud of

My greatest accomplishment is that Binglecraft feels like a complete game rather than a disconnected collection of random features. Exploration provides resources, resources create equipment, equipment enables new encounters, and boss victories advance the player toward becoming the Bingle Lord.

I also developed a consistent visual pipeline for inventory icons and in-hand 3D models. Items remain recognizable when moving between the interface and the game world, while enemies, bosses, spells, blocks, and environments share a coherent block-inspired style.

The project is supported by 18 deterministic native test suites, repeatable stress tests, visual-capture tools, and targeted performance benchmarks. These systems allowed me to validate large Codex-generated changes instead of relying only on whether the game appeared to work during one play session.

Most importantly, exploring Binglecraft gave me a small piece of the feeling I had when I first played Minecraft as a kid. Creating that experience myself is something I am deeply proud of.

What I learned

The biggest lesson was that AI changes the development bottleneck; it does not remove it. The challenge shifted from writing every line manually to specifying systems clearly, evaluating implementations, diagnosing failures, and preserving coherence across rapid changes.

I learned to use smaller implementation tasks, explicit acceptance criteria, reproducible bug reports, frequent checkpoints, and regression testing. I also learned to reject weak technical or artistic directions early. During the first stages of development, vague feedback sometimes sent asset work in the wrong direction and cost hours of rework. Icon refinement became a recurring example: vague feedback produced inconsistent results and repeated rework, while item-specific references and constraints produced much stronger assets.

Codex was most effective when I treated it as a powerful engineering tool operating within clear boundaries. My responsibility was to provide the intent, constraints, judgment, and final decisions that turned its output into a unified product.

I learned how to take an idea and guide it through design, implementation, testing, revision, and completion. I can now say that I made the game I had always wanted to make!

What's next for Binglecraft

My next milestone is a public playtest focused on onboarding, combat balance, performance, and progression. I want to observe where new players become confused, which encounters need adjustment, and whether the seven-boss journey remains satisfying from beginning to end.

After incorporating that feedback, I plan to package a stable public release. Future updates can then expand Binglecraft with additional bosses, biomes, dimensions, items, and abilities without sacrificing the quality and stability of the existing game.

Built With

Share this project:

Updates