Project Grimoire

Inspiration

Many study tools place practice in front of the reward, which can make studying feel like an interruption. Project Grimoire reverses that relationship: the tower-defense run is fully playable on its own, while studying becomes an optional tactical ability that the player chooses to activate.

What it does

Project Grimoire is an offline roguelite tower-defense game for Windows x86_64. Players choose one of five factions, build from 35 faction-specific towers, draft one of 12 traits after each wave, discover build-chain reactions, and evolve representative max-level towers.

Once per wave, the player may open the Grimoire and answer a question from an editable local JSON or CSV quiz pack. A correct answer activates either Haste (+25% tower attack speed) or Aegis (-50% base damage received) for the current wave. Wrong and “I don’t know” answers have no default penalty. After the run, local answer history becomes a review notebook, an LLM-ready Markdown study prompt, or a schema-v1 retry pack.

Five sample packs cover biology, English vocabulary, mathematics, world history, and computer science. Custom packs are detected locally without uploading learning data.

How I built it

I built the game with Godot 4.7 stable Mono and GDScript. Gameplay, quiz scheduling, review/export, and desktop file access are separated into explicit modules so the complete campaign and boss remain playable when quizzes are disabled. Factions, towers, enemies, traits, waves, and quiz packs are data-driven so they can be validated and tested independently.

The Windows release includes the executable, five editable sample packs, setup instructions, and the MIT license. The public repository documents the quiz-pack schema, validation behavior, build steps, privacy model, asset provenance, and release evidence.

How Codex and GPT-5.6 were used

Codex and GPT-5.6 were development collaborators rather than runtime dependencies. I used them to turn the product plan into a data-driven architecture, implement and review GDScript systems, author regression and release checks, diagnose UI and packaging issues, refine the optional-quiz design, and keep the README and submission evidence synchronized with the executable.

The collaboration also helped me make and verify several product decisions: the core game must remain quiz-independent, wrong answers should be penalty-free, learning data should remain local, platform I/O should stay outside gameplay logic, and the submission should freeze around one verified Windows x86_64 build. Image generation was used for selected original static visual assets; only the resulting PNG files ship with the game.

Challenges I faced

The first challenge was giving quizzes meaningful value without making them mandatory. If the reward were too weak, there would be little reason to open the Grimoire; if it were too strong, the tower-defense game would become a wrapper around compulsory studying. I addressed this by limiting the Grimoire to once per wave, making the selected bonus temporary, keeping the full run playable without it, and applying no default penalty to wrong or unknown answers. The goal was to make studying feel like a useful tactical choice rather than an obligation.

The other major challenge was maintaining visual consistency across AI-generated assets. This is one of the hardest parts of AI-assisted vibe coding: individual images can look appealing while still failing to feel as if they belong to the same game. Project Grimoire needed five factions, towers, enemies, battlefields, UI elements, projectiles, and combat effects to share a recognizable visual language.

I defined a common high-fantasy strategy-game direction and repeatedly used the same palette, material, lighting, shape, viewpoint, and scale constraints. I generated multiple candidates and included the outputs that matched the shared concept most closely, rejecting or regenerating results that broke the faction identity or visual hierarchy.

I originally wanted to add animated assets as well, but creating animations with acceptable quality and consistency required more time than the hackathon schedule allowed. I ultimately cut animation from the submission and shipped the most visually consistent static assets I could complete. This remains one of the compromises I feel most strongly about in the final result.

Because this was my first hackathon, I also failed to allocate the schedule realistically. I spent too much time expanding the content and did not reserve enough time for animation and final polish. That scheduling mistake contributed directly to cutting animation and is one of the clearest lessons I am taking from this submission.

The same scheduling problem affected game balance. Automated checks confirmed that runs could complete and that the systems remained stable, but they could not replace repeated human playtesting across five factions, 35 towers, traits, evolutions, and difficulty levels. I did not have enough time to tune those combinations properly. The submitted game has a functional balance baseline, but it is not the carefully playtested and polished balance I wanted to achieve.

What I learned

I learned that an educational mechanic can be more inviting when it is a voluntary source of agency instead of a gate. Keeping the full game playable without quizzes made both the game design and the learning loop clearer.

I also learned that local-first constraints can improve architecture rather than merely restrict it. Removing runtime networking and remote inference made privacy boundaries explicit, kept quiz data on the player’s device, and made behavior deterministic and inexpensive to test.

This was my first hackathon, and I was genuinely surprised by how far vibe coding has progressed. AI allowed me to attempt and complete a project at a scale that would previously have felt out of reach. At the same time, the process showed me that advanced AI still needs human skill, judgment, direction, and persistence to fill the gaps it cannot solve on its own. I was left wishing that my own abilities were stronger in the areas needed to close those gaps.

There are many parts of the result that still feel incomplete to me, and it is not the polished game I originally imagined. Even so, I find meaning in having grown through the process and, most importantly, in having finished my first hackathon submission. I am grateful that this event gave me both a memorable experience and a clear view of what I need to improve. As the AI era continues to develop, I want to keep sharpening my programming, game-design, and creative-direction skills so that I can work with these tools more thoughtfully and build something stronger next time.

Verified result

• 5 factions and 35 towers
• 12 trait cards, 3 difficulty levels, campaign and endless modes
• 6 normal waves plus a boss wave
• 5 bundled JSON/CSV quiz packs with partial validation
• Post-run review, Markdown export, and retry-pack JSON round trip
• 942 automated checks passing
• 183 validated gameplay PNG assets
• 150 simultaneously rendered enemies at an observed 60 FPS on the recorded Windows test machine
• Reproducible MIT-licensed Windows x86_64 release
• 2:43 English demo with narration and captions

Built With

• codex
• csv
• gdscript
• godot-engine
• gpt-5.6
• json