A monster-taming roguelike can start with a single short expedition: meet creatures, choose whether to defeat or recruit them, and carry your team's remaining health into the next fight after a small recovery. Give the run a clear ending and reset it on victory or defeat. Once that loop works, add variety.
In this guide, you will plan a short monster-taming adventure with five encounters, turn-based battles, a small creature team, and a final guardian. Start with these rules, then change the creatures and encounters to make the game your own.

Choose the smallest complete run
A creature collector rewards finding and building a team; a roguelike run asks players to adapt to a sequence of encounters and live with earlier decisions. Combine them by letting a new companion change what the player can do in later fights. A fixed encounter sequence is enough for the first prototype; random encounters are useful only after the core rules are reliable.
| Part | Example game design | Why it matters |
|---|---|---|
| Run | Four creature encounters, then a guardian | Gives the player a finish line |
| Team | Start with Pebble; hold up to three creatures | Each capture changes later choices |
| Battle | Attack, guard, capture or switch | Every action has a cost |
| Reset | Restart with one healthy Pebble | A new run starts from a known state |
Before you ask an AI assistant to build anything, write down what ends a turn, how damage works, and what survives between encounters. Ambiguous rules create a prototype that may look complete but cannot be reliably tested.
Design an original creature and battle loop
Pebble begins with 16 health and deals 4 damage. Moth has 10 health and deals 6; Bramble has 13 health and deals 5. These are deliberately different: Moth hits harder but has less health, while Pebble can absorb more damage. This example uses fixed damage so the effect of each choice is easy to see.

For each turn, the active creature can attack, guard, try to capture, or switch. Attacking reduces the opponent's health by the active creature's attack value. If the opponent survives, it responds. After each non-final encounter, every surviving teammate recovers 6 HP, up to its maximum; a defeated teammate stays at zero. Guarding halves the next incoming hit, rounded up, but does not deal damage. Switching to a healthy teammate costs a turn, so the new active creature takes the response.
Capture succeeds when a non-boss opponent has at most half its starting health and the team has room. A successful capture ends the encounter and adds that companion at full health. A premature attempt fails and consumes a turn. A full team cannot attempt capture. In this small example, defeated opponents cannot be captured and there is no random capture chance; those constraints keep the test predictable.
Give your AI a specific build request
Start a fresh project in a game-making workspace and describe the outcome and rules. SEELE's capability catalog includes game creation for RPG and roguelike ideas and a 2D asset workshop; use the monster collector game maker as a starting point. Check the generated result yourself: the catalog describes capability categories, not a guarantee that a particular prompt produces a finished game.
Build a small original browser game called Lantern Trail.
Start the player with Pebble (16 HP, 4 attack). Create four encounters,
then a guardian with 24 HP and 5 attack. Use turn-based buttons for
Attack, Guard, Capture and Switch. A surviving opponent retaliates once.
Guard halves that hit, rounded up. Switching costs a turn.
Capture a non-boss only at half its starting HP or less; add it at full
health and finish that encounter. Limit the team to three creatures.
Keep team HP between encounters; after each non-final encounter heal each
surviving teammate by 6 HP, capped at maximum. Do not revive defeated allies.
If all teammates fall, end the run.
On restart, restore the initial team, encounter and health. Show current
HP, the encounter number and a readable action log. Use original art and
names; do not copy a franchise's characters, UI, music or assets.
Ask for one feature at a time if the first result breaks: first battle and restart, then capture, then switching and the boss. Keep the same acceptance checks after each change. If your tool creates code, retain a copy before requesting the next revision so you can compare behavior.
Make team choices matter

Suppose Pebble faces a 10-HP Moth. One attack leaves Moth at 6 HP, above the capture threshold of 5. A second leaves it at 2, after which capture can succeed if Pebble survives the replies. Surviving teammates then recover up to 6 HP. Choosing capture instead of the final attack trades immediate damage for a stronger but fragile teammate. Switch to Moth later only when its damage is worth the free enemy response.
That example is a design walkthrough, not a balance claim. If your version makes capture impossible before the starter falls, lower early enemy damage or give the player a healing choice. Change one number at a time and replay the same sequence before adding randomness.
Finish with a guardian and a clean reset
The guardian cannot be captured. In this example it attacks for 5 after each surviving turn and has 24 HP. With Pebble's 4 damage, six attacks defeat it if Pebble has enough health; with Moth's 6, four attacks suffice if Moth survives. Guard reduces a hit to 3 but uses an action, so it is not automatically the best choice. If no combination can win after a plausible early run, reduce the guardian's health or add a clearly defined recovery opportunity.
For a later iteration, telegraph a stronger attack one turn ahead and allow guard to counter it. State the warning, damage and timing explicitly in the prompt, then test the warning and the response. Add the telegraph only after the basic battle rules work.
Playtest the rules before adding content
- Start and restart: confirm encounter one, one healthy Pebble and no previous companions after restart, including after a loss.
- Capture threshold: try above half health and observe a failed attempt plus retaliation; then try at or below half with room in the team.
- Turn cost: guard against a 5-damage hit and expect 3; switch and verify that the new active creature takes the reply.
- Team and defeat: fill three slots, verify that capture is refused, and reduce every teammate to zero to check the loss state. After an encounter, confirm survivors heal by 6 without exceeding their maximum and defeated allies remain at zero.
- Ending: reach the guardian, verify it cannot be captured, win, and start again. Make sure victory does not accidentally start a sixth encounter.
When a check fails, describe the exact setup, action, expected result and observed result to the assistant. For example: “Moth started at 10 HP and has 6 HP left. Capture should fail and the opponent should retaliate once; instead it joins the team. Fix the threshold without changing attack damage.” Repeat the failing check and the restart check after the fix.
Keep the game your own
A reference game can help you identify a feeling or a mechanical question. For example, the PokéRogue project describes itself as a browser-based Pokémon fan game inspired by roguelites. Write your own creatures, names, art, sound, interface and code instead of copying a game's expressive assets. The U.S. Copyright Office's game guidance distinguishes game ideas and methods from copyrightable expression; other rights and jurisdictions may also matter. For more on shaping a creature concept, see this creature-design guide.
Frequently asked questions
Do I need random encounters in the first version?
No. A fixed sequence makes bugs and balance changes easier to reproduce. Once capture, combat and reset work, introduce a small encounter pool and record the random seed so you can replay failures.
How many creatures should I create first?
Three are enough to test different roles: a durable starter, a fragile attacker and a balanced option. Add more only when each creates a meaningful decision and the existing team limit and capture rules behave correctly.
Can I build this without writing every line of code?
An AI game-making workspace can help turn a written specification into a starting point. You still need to inspect and test the result, clarify broken rules and revise the prompt or implementation. The exact workflow depends on the tool and its current capabilities.
What should carry over between runs?
For the first prototype, carry nothing: restart with the same starter and full health. If you later add permanent unlocks, separate that saved progression from run-only health and companions, and test both a normal restart and a fresh save.
Build one run, then expand it
Start with a small roster, a predictable capture rule and a boss you can actually reach. Use the checks above to make sure every turn and reset behaves as intended. Then bring your own creature designs and rule changes to SEELE's monster collector game maker and iterate on the parts that make your run distinctive.


