Project structure

🗂️

Guide

Separate the GCS package, included Demo, and project-owned data so package updates, content authoring, and production assets each keep a clear boundary

After initializing a scene, the Project window contains both GCS package content and project-owned content. Assets/TinyGiants/ provides the runtime, Editor tools, and included Demo. Creating a custom database generates Assets/TinyGiantsData/, which stores the cards, units, statuses, decks, and encounters for the current game.

tip

The two content groups can reference each other, but they have different update paths and maintenance responsibilities.

Separate package content from project content first

GCS uses the following directory boundary by default:

📦 Assets/
├── 🏢 TinyGiants/
│   ├── 📁 GameCardSystem/                       # GCS package root
│   │   ├── ⚙️ Runtime/                          # Runtime engine, data model, and public API
│   │   ├── 🛠️ Editor/                           # Game Card Editor, FlowGraph, and Monitor
│   │   ├── 🎮 Demo/                             # Complete reference project you can run and inspect
│   │   │   ├── 🎨 Content/                      # Demo art, Prefabs, audio, and presentation assets
│   │   │   ├── 🗄️ Databases/                    # Six preset databases
│   │   │   ├── ⚔️ 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/                             # Documentation entry point in the package
│   │   ├── 📋 Samples~/CustomNodes/              # Custom-node extension source
│   │   │   ├── Templates/                        # Seven copyable node-family templates
│   │   │   └── Examples/                         # Seven finished node examples
│   │   ├── 📝 Changelog.md                      # Feature record for the current version
│   │   ├── 📖 Readme.txt                        # Package entry points, menus, and support links
│   │   └── ⚖️ LICENSE.txt                       # License terms
│   └── 🔧 Shared/                               # Infrastructure shared by TinyGiants
└── 💾 TinyGiantsData/GameCardSystem/            # Project-owned GCS data root
    ├── 🃏 CardDatabases/
    ├── 🗂️ DeckDatabases/
    ├── ✨ StatusDatabases/
    ├── 🗺️ EncounterDatabases/
    ├── 🦸 PlayerUnits/
    └── 👹 EnemyUnits/

Assets/TinyGiants/GameCardSystem/ is installed with the package and changes with package updates. Assets/TinyGiantsData/GameCardSystem/ belongs to the current project and is created one level at a time when you create the first custom database of a corresponding type. This boundary determines which files belong to the product package and which belong to the game itself.

What the GCS package directories provide

Directory	Contents	When to enter it
Runtime/	ScriptableObject data model, battle state machine, FlowGraph executor, status system, events, and GCSApi	When integrating a battle through the public API or developing runtime extensions
Editor/	Game Card System dashboard, six-mode Game Card Editor, FlowGraph Editor, Monitor, and custom Inspectors	When using the Editor tools or checking Editor behavior
Demo/	Preset content, battle scenes, board UI, presentation scripts, audio, and reference behavior graphs	When studying complete scene wiring 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/	Seven copyable node-family templates and seven complete examples	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 Game Card Editor. The package directories provide system capabilities, reference content, and extension entry points.

The Demo is a complete reference project

Demo/ organizes content data, scene wiring, and presentation assets into a card roguelike battle that you can run and inspect directly. It uses the production Game Card Editor, FlowGraph, runtime, and presentation interfaces, so it can verify an installation and act as a reference for project wiring.

Demo/Scenes/ groups scenes by the Hunter, Mage, Priest, and Warrior classes. Each class has a Normal, Elite, and Boss battle. All 12 scenes follow the <number>-<name>.unity naming pattern. The three Hunter 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/ provide the board, hand, units, HUD, intents, statuses, rewards, audio, and visual effects.

tip

References connect scenes, data, and presentation. Directory names do not connect them automatically.

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

The six databases above provide the Demo's content sources together. An asset on disk does not automatically enter an active content set. Only a database that is registered with GameCardManager and Active participates in active enumeration for its content type. See Database management 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
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 objects

These directories are organized around the objects that own the assets. Art and Prefabs for the same card type, enemy family, or class stay together whenever possible, so you can follow an object directory directly to its related resources when replacing presentation. Only content shared by multiple objects belongs under Art/.

Custom node samples

Samples~/CustomNodes/Templates/ provides one copyable file for each public node family, while Samples~/CustomNodes/Examples/ provides one complete implementation for every family.

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.

When extending the node library, copy the template into your project's own runtime assembly and edit the copy. Do not modify the package sample directly. Custom nodes defines the complete contracts for attributes, inheritance, ports, and execution context.

Keep production content under the project data root

Game Card Editor and the GameCardManager Inspector create custom databases under the following path by default:

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 data root that GCS currently recognizes. If the project already follows its own asset conventions, you can move TinyGiantsData/GameCardSystem/ as a unit anywhere under Assets/, but you must preserve the TinyGiantsData and GameCardSystem directory names. After the move, GCS relocates the actual path through the Card Database inside it.

Keep package content and production content separate

• Use the included Demo for running, inspection, and comparison, not as the production project's content workspace.

• Create production content in custom databases, then reference Demo art, Prefabs, or behavior graphs when needed.

• Keeping package content separate from project data prevents version updates from overwriting project assets and preserves the Demo as an unchanged reference baseline.

With these directory boundaries established, First battle shows how databases, scene objects, and presentation assets work together. Demo overview maps the four classes, 12 scenes, and included content in more detail.