Skip to main content

Design overview

Weird Task Framework was born out of a procedural quest pack, and this procedurality is imprinted in its DNA. WTF is built around reusable components, dynamically provided values, composability and customization. The core question WTF tries to answer is:

How do you retain expressiveness while building quests from small, composable pieces?

The answer, it turns out, is complicated. There are stupidly many inter-interacting parts in a quest: setup, logic, success and failure conditions, rewards, description, dialogues, etc. All of these parts may interact with each other; for example, description needs to show rewards, which depend on logic of the quest and initial conditions in setup. In short, it is a pain to get them all moving.

Structure of a quest​

To work around the infinite complexity of human imagination, WTF splits quests into frames, and frames into entities. Each frame can be thought of as a single task stage, while entities represent single conditions for finishing the stage.

To define these conditions, WTF uses controllers - small pieces of logic, which can access the data in their entity and run code. Controllers are more than just a status function though - they have access to entity lifecycle and can define additional methods for special quest needs.

Multiple entities can work in parallel to define complex logic inside a single quest stage. This way you can build your quest from simple and composable parts, while keeping everything comprehensive and independently verifiable.

Quest Lifecycle​

Just checking conditions is not enough - you need to prepare the quest, create game objects and clear everything up afterwards. For that, quests, frames and single entities have their own lifecycle.

While the lifecycles are independent, the phases are the same for everything: Setup, Initialization, Run and Finish:

  • Setup is used to prepare data
  • Initialization is meant to create game objects
  • Run is where the player goes through the quest
  • Finish is for cleaning up after you're done

State and Macros​

The whole state of a quest lives in a single table. This makes the quest inspectable, trivializes save logic and makes the logging simple. You define quest state in a json configuration and use macros for dynamic data loading.

Macros are pieces of inline lua you write in your configuration. This way, the data structure of your quest becomes obvious from the config, and you're free to use the whole power of lua for your needs.

Developer tooling​

WTF provides a set of functionality to make quest development more enjoyable.

  • CTD protection lets you iterate faster, because you don't need to restart the game after every mistake
  • Debug-mode logging provides logs for every action the framework does
  • When using MO2, both scripts and task configurations reload after loading a savefile
  • MCM integration adds more debug options, like disabling preconditions for blazingly fast testing