Node-based behaviour design

Designing the crowd through nodes

NPC behaviour was not primarily determined by individual needs or a global party stage. Instead, it was mostly set through nodes placed around the level. Common nodes such as Dance and Smoke defined where an activity could happen.

This did more than assign an NPC action. It regulated the estimated number of NPCs and their distribution between activities without artificial crowd control. Rather than deciding what one person would do, the system let us design how the party would look and shape the crowd.

From jam solution to series foundation

The system began as a fast solution during a game jam. After trying other approaches, we concluded that it worked best for this game and our goals, so its core remained in the following games.

The jam’s theme and goal were “fun to play and fun to watch”. From the beginning, we worked to make things happen in different corners of the map, so each level felt alive and a little unhinged.

Different kinds of behaviour

There were many types of behaviour. Some were reactions, such as panic after an explosion or a response to being attacked. Others were special roles — cops, medics and event characters with particular scenarios and tasks.

But many behaviours existed simply to create a party. That is the part this case study focuses on.

Rare events and replayability

Rarer nodes were more dramatic: vomiting, sex, fist fights, calling an alien ship and more. They appeared in smaller numbers and might not exist in a particular replay.

On top of the node system, levels were partially procedural and could select different options for parts of a level. This made some events almost certain to happen while ensuring they did not all happen at once.

Keeping the party together

There were also case-by-case regulating systems. For example, once only a few people remained at a party, they would try to move closer together instead of staying alone in random corners of the level.

Making 80 characters interruptible

The hardest part was running around 80 characters that could interrupt one another, kill, die or be arrested — all without player involvement. In many cases, the solution came down to checking whether the expected object or situation was still there, and placing those checks as widely as possible.

The rest came from a huge amount of internal testing and playtesting, which exposed edge cases between behaviours.

Developing in public

For both the first game and its sequel, development was wild: with very few exceptions, we released a public demo every month during production. Each one brought millions of views.

What the system achieved

First and most obviously, the game became fun to play, fun to stream and fun to laugh at.

More subtly, a YouTube or Twitch viewer could notice something the streamer had missed and wonder, “What if?” That gave the game strong conversion to sales: people wanted to try it themselves, rather than feeling they had already seen everything in a video.