Authoring Random Events in Nantucket

Hi there folks,

Today we’ll talk about Random Events in Nantucket and how we handled a rapid-iteration authoring of them.

Random Events is a fundamental system in Nantucket, we implemented it for both telling stories and giving challenges to the player.

An usual random event in Nantucket

Design Goals

• Represent accurately usual sea threats of 19th century sailing
• Emphasize crew personalities, and how they interact each other
• Let the player live Ishmael story and face important choices
• Give challanges to the player, and reward or punish him based on his choice
• Have a huge amount of events, to cover many situations and add gameplay variety

You may recall a system like this in other games as well. We looked at: challenges in Crusader Kings 2, narrative in Banner Saga, systems interactions in Faster than Light and tried to put all of these ideas in our system while integrating brand new ones.

What’s inside an Event?

• Prerequisites: series of conditions based on crew or ship status, or triggered by the story. All the prerequisites must be accomplished to let an event be triggered.
• 1 to 4 options: each one has its prerequisites, and chance to succeed based on the current game state
• Effects: after an option is chosen, positive or negative changes on the game state happen like damage to the ship, a crew member gets ill or a quest is completed …

When an event pops up, the player carefully chooses an option and a popup appears to tell him what happened as a consequence of his choice

Event First Popup – An option is selected

Event Second Popup – Reporting the consequences

The Problem

We are aiming to add more than a thousand events in the game. Writing an event is far from trivial and takes a lot of time from concept to completion, so we needed a fast way to let the designer create an event and put it in the game. We tried a couple of approaches:

Designer writes the event on a document, in plain text. Then the programmer puts it in the game

We scrapped right away this one. It was easy for the designer to describe an event, but it was impossible for him to test it and there was a big possibility that the event wasn’t implementable because of the constraints of the system, and it took too long from conception to implementation because we had to wait the programmer to put it in the game.

Designer writes the event in a spreadsheet, and imports it in the game

The programmer wrote an importer which let the designer to create events through a spreadsheet, and then push the events into the game automatically. The main problem was that the event system was too complex and writing events without any validation of the input was too error prone, also errors from the importer weren’t enough to let the designer understand what was wrong with his event. I’ll show you an event created in the spreadsheet:

This screen represents the event showed previously, you can notice yourself how difficult it is to understand all its parts and how hard it would have been for the designer to get it right the first time.

So we scrapped also this other solution and we finally ended up creating a tool in Unity to let the designer insert his events.

The Tool

Thanks to the easy and flexible Unity API to extend the editor, we designed a tool to help the designer to create an event within the constraints of the system, help him spot eventual errors and test the event right away. Here is a screen of the tool:

The tool is composed of the following parts:

• Events List:  All the events grouped by category
• Event Header: General info about the selected event (description, subcategory …)
• Event Prerequisites: Series of conditions, all of them must be true to let the event be triggered
• Options Header: Here is set the number of options, and selected the current option to edit
• Option Details: Prerequisites (analog to the event’s ones), chance to succeed, outcomes
• Commands: Toolbar to create new events, duplicate, copy, test and save changes

The big advantages of this solution are:

• Input validation: the tool checks whether an event parameter is an integer, a string or an enumerator value and leads the user to insert a valid value
• Fast iteration: through the “Test” button, the designer can test the selected event right away, in the test scene there is a panel which describes what should happen in the game in plain text

Test Scene – Event First Popup

Test Scene – Event Second Popup

Conclusions

We discovered that implementing custom tools improves a lot the efficiency of authoring and decreases turn around times. But on the other hand, writing your own tools takes time, in our case 4 weeks, so make your own estimations and be sure that the time saved using the tool is more than the time writing it.

For more in-depth discussion on random events, please have a look at the video where our designer Marco talks with other devs about different approaches to use the random events in games.