The challenge of blind development

Let’s be honest: creating a mod for a game that isn’t even released yet is a peculiar exercise. We’re working with assumptions, trailers, bits of information. Not exactly the ideal workflow.

And yet, we’ve found a method that works. Our approach relies on three essential pillars:

  • Game Design: the conception of game mechanics
  • Tooling: development tools
  • Domain: the universe and lore

Today, we’re focusing on the first pillar. Upcoming devlogs will cover tooling and domain.

Game Design: building on solid ground

Roles

This is the most logical starting point. We have dozens of roles to create and balance. Most of the team is focused on this.

Choosing roles wasn’t that complicated. We focused on the classic archetypes for this type of game:

  • Gatherers: those who extract raw resources
  • Craftmans: those who convert them into useful items
  • Military: those who protect… or threaten
  • Civilians: those who shape everyday village life
  • Antagonists: those who add chaos

We’re aiming for about twenty complete roles at launch. Concretely, we’re basing ourselves on what we know about the game. There will be mining, so we create a miner. There will be wood, so a lumberjack. A village implies beggars, merchants, guards.

Each role must fit into a global context. So we’re building lore in parallel that we’ll reveal soon. And most importantly: each role must have a purpose. The lumberjack cuts wood, but for whom? For the carpenter building houses? For the blacksmith who needs charcoal? Everything is interconnected, schematized, documented.

Stories

We’re building the gamemode around stories. A story is typically a scenario or event that disrupts the players’ daily routine.

The goal: inject randomness, both positive and negative, so each game is unique.

How does it work? There’s a game master controlled by the computer: the TaleWeaver. It decides when to stir things up. It can spawn a meteorite, increase players’ luck, or even trigger an epidemic. The inspiration comes directly from games like RimWorld.

Some examples of events we’re developing:

Solar eclipse: The sun doesn’t rise. Another celestial body is blocking it. Night will be permanent until further notice. Nocturnal creatures are having a field day.

Animal abundance: Nature is generous. Animals are plentiful around the village. A boon for hunters… and perhaps a problem for crops.

Some events are more significant and modify the entire game: these are global scenarios. Typically, a vampire-centered game would be a dedicated scenario with its own rules.

The TaleWeaver balances all of this through a scoring system that will be the subject of a future devlog.

Map and locations

The game is documented enough that we can already map out zones. We know where different buildings, spawn zones, and points of interest will be.

We do this in Minecraft or even in Paint. Yes, Paint. The tool doesn’t matter, it’s the thinking that counts.

The main constraint: the game must support 100 players. So 100 beds, 100 jobs, 100 living spaces. That requires real thought about density and space.

The game loop

This is the big one. Our gameplay loop is heavily inspired by Space Station 13, and it remains super difficult to calibrate.

As a reminder: we want each game to last an evening. A few hours, no more. So we need to create a coherent loop that fits within this timeframe.

Tales Of Chaos puts stories first. So we decided to build the loop on classic storytelling principles:

Initial situation: Players arrive, receive their roles, discover the village. It’s the calm before the storm. Relationships form, routines settle in. Nothing really moves, but everything is being set up.

Inciting incident: The TaleWeaver strikes. An event breaks the balance. Maybe a traitor is revealed. Maybe an external threat appears. This is when the game shifts.

Rising action: Players react, organize, clash. Alliances form and break. Each role comes into play, each skill finds its use. Tension builds progressively until the climax: the peak where everything explodes.

Resolution: The actions undertaken find their conclusion. The conflict resolves, one way or another.

Final situation: The game ends. The village survived… or didn’t. The heroes triumphed… or the traitors won. Either way, the story is complete.

In short: we structure each session like a play. A beginning, a middle, an end. No frustrating cliffhangers, no “to be continued tomorrow.” A complete experience in one evening.

What’s next

Next time, we’ll talk about the other elements that allow us to get ahead: tooling and domain.

We’re also going to try to communicate more. On launch day, we’ll need a sufficient community to test all this and iterate quickly.

Join our Discord to follow the development.

— Prakkmak