Home

Table of Contents

1. Cards (Basic)

2. Cards (Advanced)

3. Card Decorators

4. Artifacts

5. Status Effects

6. Characters

7. Events and Dialogue

8. Card and Artifact Packs

9. Validators

10. Acts

11. Run Modifiers

12. Exporting Your Game

13. Mod Support

Introduction and Terminology

Welcome to Slay the Robot, a Godot framework for developing games similar to the popular roguelike deckbuilder Slay the Spire. In this document you'll learn a high level layout of the framework covering the main scripts, processes, and features available as well as any kind of gotchas that one may come across.

It's important to note that this initially started as its own independent toy project before evolving into a full blown framework, and also seeks to be its own thing separate from Slay the Spire. While a lot of it is consistent, some of the terminology varies which may be confusing.

StS to StR:

1. Potions -> Consumables
2. Enchantments (StS2) -> Card Decorators
3. Relics -> Artifacts

Card

Validators

Cards Basic

Cards Advanced

Card Decorators

Artifacts

Status Effects

Events and Dialogue

Characters

A character is composed of three separate components: A PlayerData prototype, a CharacterData, and a ColorData. To make a new character there should be one instance of all three, making sure to map their PlayerData.player_character_object_id and CharacterData.character_color_id values.

Acts

Run Modifiers

Exporting Your Game

Mod Support

Hand and CardManager

Hand is the UI element for managing

request signals

Cards

Card

Card Energy

Validators Validators are simple scripts which can be attached to cards and actions that output to a true or false result. They can be attached to a card via CardData.card_play_validators to prevent a card from being played unless conditions are met, or used in actions via the ActionValidator to allow for if/else logic. Generally speaking a validator will be designed for either cards, actions, or both/neither, as either the card or action input into the validator can potentially be null depending on how you're using it.

ActionValidator

CardListeners CardListeners are simply event handlers attached to the Card object. These provide an easy interface to apply dynamic checks for events against a card in hand that are specific to that type of card, rather than a general status effect. The ListenerCardCostModifier subclass for instance can hook into CombatStatsData and modify the energy cost of a card based on

CardPlayRequest

Combatants BaseCombatant Enemy is_alive() enemies and enemies_alive_or_dead groups

Action Interception

BaseActionInterceptor and ActionInterceptionProcessor

Rewards Reward Overlay, reward groups(include auto rewards and mutual exclusivity) RewardButtons Custom Rewards ActionGrantReward ActionClearReward (use smoke bomb as example)

Events Enemy Spawns

Enemy spawns are handled via EnemyContainer. Spawning and enemy placement is done in two seperate ways: automatic and slot based. If you don't care how enemies are placed and just want to initialize them into a basic HBoxContainer, use the former. If you want say flying enemies, lots of small enemies, or enemies that summon more enemies in combat, use the latter