Doodle Defense

Inspiration

I wanted to build something that felt immediately understandable on a phone but still gave the player meaningful decisions. I kept coming back to the notebooks I filled with doodles in school: blue pen, lined paper, stars, arrows, monsters, and drawings slowly taking over the page.

That became Doodle Defense: a tower defense game that looks like a notebook coming to life.

The project did not actually start there. I initially explored a survival/resource-management concept, but after prototyping and playtesting it, the core loop wasn't as immediately fun as I wanted. I decided to pivot rather than keep adding systems to something that wasn't working.

How I built it

I used AI throughout the development process, primarily Codex for implementation and testing and ChatGPT for design iteration, requirements analysis, and implementation prompts.

I acted as the designer and playtester: choosing the direction, playing each milestone, identifying what felt good or bad, and deciding what should change. The AI handled the heavy lifting of writing the Three.js/HTML5 implementation, maintaining tests and documentation, and packaging the final build.

I built in small playable milestones rather than prompting for the entire game at once. The prototype grew from one enemy and one tower into an Ink economy, five waves, three distinct defenses, mutations, multiple enemy types, winding routes, a second-route reveal, and a final boss.

Challenges

The biggest lesson was that automated tests cannot tell you whether something is fun.

One early version allowed the FREEZER defense as a starting choice, but human playtesting immediately exposed an economy trap: it couldn't kill quickly enough to earn the Ink needed to recover. We adjusted it and added opening-build simulations.

Later, increasing enemy density made the final waves more exciting but created another problem: all those enemies generated enough Ink to spam towers, making the game too easy. Instead of simply making enemies stronger, I added a tower-capacity system. The player starts with one tower slot and must decide whether to spend Ink on another defense or invest it in additional capacity.

That changed the final battle dramatically. In the final balance playtest I was rapidly buying slots and placing defenses under pressure and defeated the boss with one life remaining.

What I learned

The most useful part of building with AI was the speed of iteration, but the most important part was still making decisions from actual play.

AI could implement an idea, validate it, and rebuild it extremely quickly. My job became deciding what was worth building, testing the result, recognizing when something wasn't working, and resisting the temptation to keep adding features.

The final prototype is much smaller and more focused than many of the ideas explored along the way—and it is much more fun because of that.

Built With

• ai
• chatgpt
• chrome
• codex
• generative-ai
• git
• html5
• javascript
• openai
• three.js
• web-audio-api