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

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. Custom-node and Workbench Inspector extension source is distributed as a separate website download, so it does not appear under the installed package root.

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.

Under Demo/Scenes/Single-Character/, Hunter, Mage, Priest, and Warrior each contain a Normal, Elite, and Boss battle. Those 12 scenes use the <number>-<name>.unity pattern, while Multi-Character/ contains the three-character Party Showcase.unity. You can open:

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

The single-character scenes reference six preset databases under Demo/Databases/Single-Character/. Party Showcase references six focused databases under Demo/Databases/Multi-Character/. Demo/Scripts/ and Demo/Content/ provide the shared 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.

Two isolated database sets

Each directory contains one database for every core GCS content type. Scene initialization activates only the set used by that scene, so Workbench lists stay focused and party-only content does not change the original preset counts.

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 screenshot above shows the original preset set. 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

Download the source samples

Download GCS-Samples.zip and extract it outside the Unity project. The archive contains source files and Assembly Definitions without Unity .meta files. Keep the extracted Samples~ directory outside the project, then copy only the required source into a project-owned runtime assembly under Assets/.

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

When extending the node library, copy the template into your project's own runtime assembly and edit the copy. Keep the downloaded archive unchanged so it remains a reusable reference. Custom nodes defines the complete contracts 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.

The downloaded archive's Samples~/InspectorExtensions/ directory provides this split as a complete copyable reference. Here, Runtime means that the code can enter a player build; it does not mean those files only support runtime UI. Derived content definitions, option providers, and typed access are required by runtime code, while Workbench reads their Inspector metadata. The Editor side contains only registry setup, validation, the full-width UI Toolkit field, and direct 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.

With these directory boundaries established, First battle shows how a single-character database, scene objects, and presentation assets work together. Demo battle scenes maps all four class lines and Party Showcase to the included content.