Make a roguelike game with Chatforce

Build a run from meaningful choices

A roguelike run is a compact journey through systems that the player gradually understands. They face an encounter, spend health or resources, choose a reward, and decide what risk to take next. A run works when those decisions connect. A powerful item might cost health, a safer path might offer fewer supplies, and a defensive ability could support a slower strategy. Random changes can keep runs fresh, but the player still needs enough information to make an informed choice. Use variation to change the situation, not to hide the rules. Games like Slay the Spire apply this structure to cards. If you are coming from an engine, the Godot alternative page compares the two approaches.

Make resets teach the player

Failure can be useful when the player can point to a decision that caused it. Give clear signals about danger, damage, and available options. A loss should help the player form a new plan, not leave them guessing whether an unseen rule changed the outcome. Decide which elements reset and which persist. Many roguelikes reset temporary health, items, and route progress while letting player knowledge carry forward. If you include persistent unlocks, make sure they add choices rather than make early runs automatic. A poker-scoring twist on the same loop appears in Balatro-style games.

Roguelike games made with Chatforce

Chatforce has published roguelike projects in 2D. Eternal Horde and Tomb of Hexes are examples of games in this genre and dimension. Card-based runs are covered on the card game maker page.

Describe the rules behind each run

1. 1. Select the view and run format

   Choose 2D or 3D at creation, since the dimension cannot be changed later. A 2D view can keep rooms, items, and status information easy to scan; a 3D view may suit a real-time world where position and camera angle shape decisions. Specify whether play is turn-based or real-time, how a run begins, and what ends it. Chatforce's 2D scaffolds do not include a roguelike system, so describe room flow, combat, rewards, and resets directly. Keep your first attempt short enough for a player to reach its ending.

2. 2. Define actions and danger

   Choose a small set of actions, such as moving, attacking, guarding, or using an item. Explain how each action changes the situation and what response an enemy or hazard can make. Give warning before a costly danger resolves, so the player can learn its pattern and react. State how health, energy, or other resources work. Avoid adding several overlapping meters in the first version. Every resource should force a decision, such as spending energy now for safety or saving it for a harder room later.

3. 3. Make rewards change strategy

   Offer a few distinct rewards that support different approaches. One reward might strengthen a direct attack, another might recover health after a careful play, and a third could make exploration safer. Describe how often rewards appear and whether they stack, replace each other, or require a resource. Give the player enough information to compare them. Add a small amount of controlled variation to room order or reward choice, then check that each combination remains understandable. The goal is a fresh decision, not a pile of effects the player cannot track.

4. 4. Review a run and tune it

   A first playable usually arrives in 10 to 15 minutes. Play several attempts and note where the player loses control, where a reward feels obvious, and whether a defeat suggests a new tactic. Tell Chatforce what feels off and ask for one concrete change, then replay to compare. You can iterate by chatting and replaying rather than attempting every system at once. When the basic loop works, publish a browser-playable game at a shareable URL. Friends can play without an account and can tell you which choices made them want another run.

Example prompt: Make an original 2D turn-based roguelike about exploring a buried observatory. Each run has five connected rooms, with a choice of two doors after each encounter. Give the player a basic strike, a guard, and a limited-use flare. Enemies show a clear warning before attacking. Rewards can improve the strike, restore health, or reveal the next room's danger. End each run at a guardian room, then restart with the same basic kit and new room choices. Use original names, characters, art, music, and story. Keep the rules visible and the first run brief.

Use randomness with a purpose

Randomness is useful when it asks the player to adapt. A changed room sequence can force a different route, while a limited reward choice can make the player reconsider their build. Random outcomes feel unfair if they decide success without giving the player a response. Keep essential threats readable and let skill or preparation affect the result. When you add a random element, ask what decision it creates. If it only makes the screen unpredictable, it may not be helping the run. Randomized rooms work in 3D as well, as long as each one has a readable layout.

Borrow systems, create your own world

Use consistent cues so players can learn patterns and connect outcomes to decisions. This makes a later attempt feel informed. Consistent sound effects for each enemy attack help players learn patterns. Horde survivor games are a real-time variant of the roguelike run.

Frequently asked questions

What makes a game a roguelike?

Run-based games commonly use changing encounters, consequential choices, and restarts. Define the specific traits and rules your game needs.

Does Chatforce include a roguelike scaffold?

No dedicated roguelike scaffold is listed. Describe the run sequence, encounters, rewards, and reset behavior in your prompt.

Should progress carry over between runs?

Persistent upgrades can create long-term goals, but they may reduce run tension. Keep unlocks focused on adding choices.

Related pages: How to make a game with AI · How to make a game like Hades · How to make a game like Slay The Spire · Make a survivors game with AI · 2D game maker