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 class battles and one party battle
│   │   │   ├── 💻 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
│   │   ├── 📝 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
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

Author cards, decks, units, statuses, and encounters in Game Card Editor, custom-node and Inspector extension examples are separate downloads outside the installed package

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.

Hunter, Mage, Priest, and Warrior each have Normal, Elite, and Boss battles under Demo/Scenes/Single-Character/, these 12 scenes use <number>-<name>.unity, Multi-Character/ contains the three-player Party Showcase.unity, open these scene paths

Demo/Scenes/Single-Character/Hunter/1-Fenmoss Hollow.unity
Demo/Scenes/Single-Character/Hunter/2-The Spore Bog.unity
Demo/Scenes/Single-Character/Hunter/3-Mire of the Reaper.unity
Demo/Scenes/Multi-Character/Party Showcase.unity

Single-character scenes use six preset databases under Demo/Databases/Single-Character/, Party Showcase uses six party databases under Demo/Databases/Multi-Character/, both use Demo/Scripts/ and Demo/Content/ for the board, hand, units, HUD, intents, statuses, rewards, audio, and effects

tip

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

Single-character and party databases

Each directory contains the six GCS database types, scene initialization enables the set used by that scene, so Workbench lists its content

Directory	Database set and content
Single-Character/	Six Preset*Database assets: 80 Cards, 16 Decks, 12 Players, 16 Enemies, 30 Statuses, and 12 Encounters
Multi-Character/	Six Party*Database assets: 6 Cards, 1 Deck, 3 Players, 3 Enemy definitions, 5 Statuses, and 1 Encounter

The six preset databases above store cards, decks, players, enemies, statuses, and encounters, register them with GameCardManager and enable Active so Workbench and runtime can read them, see Database management for registration, ordering, and activation

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

Download the source samples

Download GCS-Samples.zip and extract it outside Unity, the archive contains source and Assembly Definitions without .meta files, copy required files from Samples~ into project-owned runtime assemblies under Assets/

Samples~/CustomNodes/Templates/ provides one template per public node family, and Samples~/CustomNodes/Examples/ provides one completed example per family, edit copies in the project, see Custom nodes for attributes, inheritance, ports, and execution context

Project-owned Workbench Inspector extensions

Keep derived content types, serialized fields, inline settings, and option providers in a project runtime assembly. Keep custom UI Toolkit controls, Inspector validation, and direct TGDropdown use in an Editor-only sibling assembly.

Samples~/InspectorExtensions/ provides the following layout, Runtime holds content types, option providers, and typed access code, Workbench reads Inspector settings from these types, Editor holds registry setup, validation, UI Toolkit controls, and TGDropdown examples

Assets/YourGame/GCS/
├── Runtime/                         # Player-available content types and data
│   ├── ContentTypes/                # Six Workbench content types
│   │   ├── SampleCard.cs
│   │   └── ...
│   ├── Options/
│   │   └── SampleInspectorOptionProviders.cs
│   └── Access/
│       └── SampleCardRuntimeAccess.cs
└── Editor/                          # Workbench controls and validation
    └── SampleInspectorRegistration.cs

These files are project content and do not belong under the GCS package's Runtime/ or Editor/ directories. Inspector extensions defines the six derived content types, serialized-field layout, and runtime access. Inspector controls defines Editor registration, validation, and the shared dropdown contract.

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.

Use First battle to inspect how single-character databases, scene objects, and presentation work together, and Demo battle scenes to locate all four class lines and Party Showcase