DEV Community

Cover image for I Can't Code. I'm Building a Monster-Raising Game With AI Anyway — 300+ Original Monsters and Counting
Aikata
Aikata

Posted on

I Can't Code. I'm Building a Monster-Raising Game With AI Anyway — 300+ Original Monsters and Counting

"Hey — could you make a game app?"

That is honestly how this started. I had zero programming knowledge, no design document, no plan. I'm just a gamer, and one day I casually asked Muse, an AI assistant, whether something like that was even possible. This article was originally published in Japanese, and this English version was translated and adapted from that original with AI assistance, then edited by me — I want to be upfront about that, because how this game gets made, and who (or what) makes what, is kind of the whole point of the story.

The answer I got back was: "Yes, it can be made." So we started building a monster-raising game. About 46 minutes after that first question, a first prototype was running: pick an egg, name the monster that hatches from it, train it, evolve it, take it into a dungeon. The basic loop, playable.

That was about a week ago. Development is still going, and the game has grown into something far bigger than I expected. This is a report from where things stand right now — what I'm building, how it actually gets built, and, honestly, where the AI falls short. The screenshots throughout are from the real game in development. It isn't finished, and there's no release date yet. This is a work in progress, shared while it's being made.

How I make this (transparency note): I'm a gamer in Japan with no programming background. I design, direct, and playtest this game; AI tools do the implementation under my direction. This publication is written by me, translated and adapted from my Japanese originals with AI assistance, and edited by me before publishing. The game itself is built the same way: my decisions, AI execution, and a lot of human checking on a real phone.

The game I'm building: Montore

The game is called Montore — short for "Monster Treasure" — a monster-raising game set in an ancient-ruins world, built around a deep green and gold look.

The loop is simple: hatch monsters from eggs, raise them, evolve them, collect treasure, and work toward clearing dungeons. The contents, though, kept growing:

  • 32 monster species, with more than 300 original designs so far
  • Evolution isn't fixed — it branches depending on how you raise the monster (four branches at the fully evolved stage, plus a special catalyst route, and ultimate forms beyond that)
  • A raising tournament, the Deep Green Cup, run as a proper bracket tournament with 8 entrants
  • Friend battles, and even a feature that generates an egg by scanning a barcode — both already implemented
  • Music made with a composition service, and voices for characters like the shopkeeper and the mentor
  • Animation for every event in the game — that work is currently in progress

The version number of the updates passed 300 a while ago. Honestly, I didn't expect it to come this far either.


Figure 1 | The state of development, in numbers.

Here is what it actually looks like on a phone right now:


The home screen: your monster, its status, and everything one tap away — the whole raising loop fits on one screen, no scrolling.


A battle in progress, on a real device build.

The village item shop, complete with its own shopkeeper, background art, and voice lines.

The Deep Green Cup: a real tree bracket, all 8 entrants visible from the start.

How it's built: I don't just hand everything to the AI

There's a common misunderstanding about projects like this, so let me be clear: the AI did not "make this game by itself."

What actually happens is a division of labor. The planning, the decisions, and the player's perspective — "how will someone playing this actually feel about it?" — come from me, the human. The AI turns those decisions into something real. And nearly every time I've thrown out an idea on a whim — "wouldn't it be fun if you could make an egg from a barcode?" "I want friend battles" "the shopkeeper should have a voice" — the answer came back "that can be done," and then it got done. You don't really understand how strange it is to never hear "no, that's impossible" until you start building something this way.

But here's the other half: a lot of what an AI produces isn't usable as-is. So I built a check into the process — whatever one AI makes gets shown, as the real thing, to a different AI, which scores it. The bar is 95 points. Anything under that gets fixed and scored again. And to be clear, those scores are just a guide for improvement. At the end, I check everything myself, on a real device, with my own eyes.


Figure 2 | How the work is divided, and how quality gets checked.

The training screen is a good example. At first it was just rows of stat names — it conveyed nothing about the world of the game or the fun of raising a monster. So I asked for the cards to be redone as full training-scene illustrations, had a mock (a finished-image target) made, and then checked the implemented screen on a real phone, fixed it, checked it again — several rounds of that is what it took to reach the current form.


Figure 3 | How the training sheet's mock evolved.

The honest part: three places where the AI was weak

There's no point writing only the good parts, so here are the weaknesses, honestly. There were three big ones.

First, image boundaries. Cutting out illustrations — making the background transparent — sounds trivial, and it isn't. On characters with white bodies, the feathers got erased together with the white background, in bulk. "This is the body, this is the background" is obvious at a glance to a human. For an AI, it's surprisingly hard.

Second, sound. From an AI's explanations alone, I couldn't confirm that audio would actually play correctly on a real device. Where we landed: music from a dedicated composition service, voices from speech synthesis, and every single sound checked by human ears at the end.

Third, originality of ideas. Ask an AI to "come up with a fun feature, roughly," and what comes back is either a rehash of another game or something safe and generic. So the core of any new feature has mostly come from my own feel as a player. "The raising screens fit on one screen, no scrolling." "Tabs you tap to switch stay in a fixed position — they never move." Those kinds of specifications never emerged from leaving things to the AI. I had to play the game myself and say them out loud.

What it cost, in money and time

Since people always ask, here are the main services used so far and what I actually paid:

  • Muse: ¥0 (I've been using it without a paid plan)
  • ChatGPT: ¥3,000/month (a paid plan, at my own cost — used for image generation, consultation, and scoring)
  • Suno Pro: US$10 (one month only, for composing the BGM)
  • Grok / VOICEVOX: free

As a hobby, the money was completely acceptable. The hard part was time. If you don't care about mistakes and just want something in shape, a minimally playable prototype took me less than half a day. But between "it runs" and "the game I actually imagined" there is a much bigger distance than I expected. The process of crushing the details, one by one, eats as much time as you can give it.

Why I'm writing this in English

The Japanese version of this article was published on note, and readers there have been following the development. I'm bringing the story to English readers for a simple reason: building in public is part of the project. The game is being made by someone who can't code, directing a team of AIs, arguing about quality, and checking everything on a real phone — and I think that process is worth showing as it happens, not after the fact.

If you follow along, what you'll get is the development as it unfolds: what got built, what got cut and why, and what broke along the way. The full making-of is planned for when the game is completed.

The honest reason: so I can keep building this (a Muse invite)


Mai, the shopkeeper from the game, bowing in thanks.

This section is the real reason I wrote this article.

Muse, which I'm using as the command tower for this development, is something I've been using without a paid plan. In exchange, the free usage (tokens) has a limit — and now that development has picked up pace, that limit is in sight. If I use up the free allowance, it will be hard to keep developing at the current pace.

So let me put a Muse invite here. This is Muse's join page, and my invite code. I'll be upfront about it: if you enter my code and meet the conditions, I receive a bonus too, and it genuinely helps me keep this development going. Using it is completely optional.

How to use the code: according to the invite screen I checked, if you enter the code within 48 hours of joining Muse, both the person who invited and the person who joined receive a token bonus. Because there is a deadline, if you're thinking of trying it, I recommend entering the code right after you sign up. Where to enter it: in the smartphone app, Settings → "Redeem token"; on the web (muse.ai), Settings > General > Usage > Redeem invite code.

The latest details and conditions shown on the invite screen itself are the official ones. Screens and steps can change, so please check the actual screen.

And one promise, same as in the Japanese edition: if you use my code, tell me in the comments on this post — when the game is finished, I'll put your name in its credits.

If you've ever thought "I'd like to make something with AI," this is a good place to start. Even with zero knowledge like me, starting really was that simple.

To close

I have zero programming knowledge. I'm just a gamer.

And still — you give an instruction, and the thing comes back made. A game that existed only in my head starts moving on a screen in front of me. No matter how many times I see that moment, it makes me happy.

Filling a game with everything you care about is, honestly, hard work. Struggling to put things into words, getting angry about quality, checking on a real device, over and over — it's not all fun. But taken at a relaxed, hobby pace, it's genuinely enjoyable. Starting is really as simple as asking, lightly, "hey, could you make this?"

When the game is finished, the full development story will be published as well. If you'd like to see how it turns out, follow along — I'd be glad to have you.

— Aikata ("AI as your partner": a practical notebook)

Top comments (0)