Project Structure

🗂️

Guide

GCS keeps runtime and Editor code, the playable Demo, reference recipes, and project-owned data in separate locations. Once each directory has a clear role, package updates, content authoring, and production assets can remain independent

After initializing a scene, the Project window contains both the GCS package and your own project content. The package under Assets/TinyGiants/ provides the engine, tools, and included Demo. The project directory created as needed for custom databases stores the cards, units, statuses, decks, and encounters that belong to your game. These two content groups can reference each other, but they serve different purposes. Establish this boundary before production authoring so package updates and project organization do not become mixed together.

Separate package content from project content

GCS uses the following directory boundary by default:

📦 Assets/
├── 🏢 TinyGiants/
│   ├── 📁 GameCardSystem/                       # GCS package root
│   │   ├── 🛡️ Runtime/                          # Runtime engine, data model, and public API
│   │   ├── 🛠️ Editor/                           # Workbench, FlowGraph, Monitor, and Inspectors
│   │   ├── 🎮 Demo/                             # Complete reference project you can run and inspect
│   │   │   ├── 🎨 Content/                      # Demo art, Prefabs, audio, and presentation assets
│   │   │   ├── 🗄️ Databases/                    # Six preset databases
│   │   │   ├── 🧩 DocumentationRecipes/          # Behavior graph assets used by the online recipe docs
│   │   │   ├── ⚔️ Scenes/                        # 12 battle scenes across four classes
│   │   │   ├── 💻 Scripts/                       # Demo board, UI, presentation, and audio scripts
│   │   │   └── 🛠️ Editor/                        # Editor tools used only by the Demo
│   │   ├── 🔌 Integrations/GES/                  # Optional GameEventSystem integration
│   │   ├── 📘 Docs/                             # Offline documentation entry point in the package
│   │   ├── 📋 Samples~/CustomNodes/              # Custom node examples and template
│   │   ├── 📝 Changelog.md                      # Feature record for the current version
│   │   ├── 📖 Readme.txt                        # Package entry points, menus, and support links
│   │   └── ⚖️ LICENSE.txt                       # License terms
│   └── 🔧 Shared/                               # Runtime and Editor infrastructure shared by TinyGiants
└── 💾 TinyGiantsData/GameCardSystem/            # Default root for project-owned GCS data
    ├── 🃏 CardDatabases/
    ├── 🗂️ DeckDatabases/
    ├── ✨ StatusDatabases/
    ├── 🗺️ EncounterDatabases/
    ├── 🦸 PlayerUnits/
    └── 👹 EnemyUnits/

Assets/TinyGiants/GameCardSystem/ is installed with the package. Assets/TinyGiantsData/GameCardSystem/ belongs to the project and is created one level at a time when you create a custom database of the corresponding type.

What the GCS package directories provide

Directory	Contents	When to use it
Runtime/	ScriptableObject data model, battle state machine, FlowGraph executor, status system, events, and GCSApi	When inspecting runtime types or integrating the public API
Editor/	Game Card System dashboard, six-mode Workbench, FlowGraph Editor, Monitor, and custom Inspectors	When understanding Editor behavior or diagnosing tool problems
Demo/	Preset content, battle scenes, board UI, presentation scripts, audio, and reference behavior graphs	When studying a complete integration or verifying a feature
Integrations/GES/	GES event bridge enabled by TG_GES_INSTALLED	When the project also uses GameEventSystem
Docs/	Package entry point to the online documentation	When opening the documentation from the Unity Project window
Samples~/CustomNodes/	Two complete examples and one copyable node template	When extending FlowGraph with custom nodes
Changelog.md	Core capabilities delivered in the current version	When checking version changes before an upgrade
Readme.txt and LICENSE.txt	Common entry points, support channels, and license scope	After first import or when confirming usage boundaries

Routine content authoring does not require direct changes to Runtime/ or Editor/. Create and maintain cards, decks, units, statuses, and encounters through Workbench. Use the code directories as implementation references only when integrating APIs, extending the system, or diagnosing a problem.

The Demo is a complete reference project

Demo/ organizes content data, scene connections, and runtime presentation into a card roguelike battle project that you can run directly and inspect layer by layer. Demo/Scenes/ groups scenes by the Hunter, Mage, Priest, and Warrior classes. Each class has a normal, elite, and Boss battle, for a total of 12 scenes. Every scene follows the <number>-<name>.unity naming pattern. The Hunter Demo scenes are:

Demo/Scenes/Hunter/1-Fenmoss Hollow.unity
Demo/Scenes/Hunter/2-The Spore Bog.unity
Demo/Scenes/Hunter/3-Mire of the Reaper.unity

These scenes reference the six preset databases under Demo/Databases/. Demo/Scripts/ and Demo/Content/ then provide the board, hand, units, HUD, intents, statuses, rewards, audio, and visual effects.

Six preset databases

The databases under Demo/Databases/ cover the six core GCS content types:

Database asset	Content provided
PresetCardDatabase	Included cards and card behavior graphs
PresetDeckDatabase	Starting decks and reward decks for all four classes
PresetPlayerUnitDatabase	Four playable class units
PresetEnemyUnitDatabase	Enemy units and behavior graphs used by the 12 battles
PresetStatusDatabase	Buffs, debuffs, and rule statuses used in battle
PresetEncounterDatabase	12 encounters, enemy lineups, Battle Rules, and rewards

tip

An asset does not appear in its content collection unless it belongs to an active database, even when the asset already exists on disk.

See Database Setup for registration, ordering, and Active rules.

Presentation assets are organized by owner

Directory	Contents
Cards/<Type>/	Base frames, Artwork, and card Prefabs for Basic, Burst, Curse, Skill, and Support cards
Decks/	Images for the four class starting decks and reward decks
Units/Player/<Class>/	Player unit art and Prefabs for Hunter, Mage, Priest, and Warrior
Units/Enemy/<Family>/	Art and Prefabs organized by class enemy family
Units/Prefabs/	Presentation components shared by multiple units
Statuses/ and Intents/	Status and intent icons, plus their respective UI Prefabs
Encounters/<Class>/	Battle backgrounds, layered source assets, and encounter UI assets for each class
Art/	Audio, Fonts, Materials, Prefabs, Resources, Shaders, Sprites, and VFX shared across multiple objects

This structure keeps the assets for an object together whenever possible. When replacing the presentation for a card type, enemy family, or class, follow the owning object to its related assets instead of searching back and forth across global Prefab, Audio, and Texture directories.

Recipe assets and custom node samples

Demo/DocumentationRecipes/ stores the behavior graph assets used by the card, enemy, and status reference pages. Its content corresponds item by item to Common Card Patterns, Common Enemy Patterns, and Common Status Patterns. Samples~/CustomNodes/ provides HealIfBelowHalfNode.cs, AddValuesNode.cs, and FlowNodeTemplate.cs.

tip

The trailing ~ makes Unity ignore this directory, so the samples are not compiled into the project and do not appear in the normal Project view.

To extend the node library, copy the template into your own runtime assembly and modify the copy. Custom Nodes defines the complete contracts for attributes, inheritance, ports, and execution context.

Keep production content under the project data root

Workbench and the GameCardManager Inspector use the following path by default when creating custom databases:

Assets/TinyGiantsData/GameCardSystem/

Each of the six database types has a fixed subdirectory. Content created inside a database is stored as a sub-asset of that database.

Subdirectory	Stored content
CardDatabases/	Custom card databases and their cards
DeckDatabases/	Custom deck databases and their starting, reward, and other decks
PlayerUnits/	Custom player unit databases and their player units
EnemyUnits/	Custom enemy databases and their enemy units
StatusDatabases/	Custom status databases and their statuses
EncounterDatabases/	Custom encounter databases and their encounters

Click Quick Access > Custom Data on the Game Card System dashboard to open the project data root currently recognized by GCS.

If the project already follows its own asset conventions, you can move TinyGiantsData/GameCardSystem/ as a unit anywhere under Assets/. Keep the two directory names TinyGiantsData and GameCardSystem after the move. GCS relocates the actual path through the Card Database inside it.

Keep package content and production content separate

• The included Demo is a runnable reference baseline, not a workspace for production content.

• Create your own content in custom databases, then reference any Demo art, Prefabs, or behavior graphs you want to reuse.

• With this separation, package updates do not overwrite project data, and the preset content remains available as an unchanged reference.

With the directory boundary established, Your First Battle follows one complete Demo battle to show how these databases, scene objects, and presentation assets operate together. Demo Overview maps the four classes, 12 scenes, and included content in more detail.