FTCG - Forum Trading Card Game

017

Admin
Staff member
Developer
Joined
Dec 18, 2025
Messages
20
Reaction score
10
Points
3
Location
Denver, CO
This is currently in early alpha versions, being worked on by me. I'm making this a more public post for people who are interested when it comes online later to suggest features before the design is completely finalized and anything you add is a 'pack plugin' under this architecture system. -017

FTCG — Forum Trading Card Game (Design Snapshot / Public Discussion)
FTCG is a XenForo-integrated trading card game where normal forum participation earns an in-game currency (“FTCG credits”), and those credits are used to open packs and build a collection. Cards then become both:


  1. a real game system (deckbuilding + duels), and
  2. a social layer on the forum (ex: reacting to posts using owned cards).
This post describes the intended “final” feature set (what we’re building toward), with some notes on how moderation, safety, and anti-scam mechanics will work.




1) Core Loop: Earn → Open Packs → Collect → Play / Social

Earn credits from forum activity
Posting and other configured actions grant FTCG credits. This keeps the economy grounded in participation rather than paywalls. Spend credits on packs
Credits buy packs, which roll from configured rarity/weight tables (pack systems are designed to be “pack plugin” modules so admins can add/enable content cleanly). Optional real-money support (admin-controlled)
Forum admins may optionally enable real-money purchases through XenForo Resource Manager (XFRM) as a premium convenience category, such as “unlock many credits now” microtransactions. This remains optional and server-governed.


2) Card Types, Identity, and Progression

Card identity
Cards are referenced by stable card_id strings, with a registry system planned to define rules, visuals, rarity, and behavior. Intended card categories
  • Creatures (core combat units; Pokémon-like)
  • Traps (hidden / triggered effects; Yu-Gi-Oh–style)
  • Land (land like Magic the Gathering - applies environmental effects)

    Unique Flagship Pack Modules:
  • Flagships (one per player in normal decks; ship platform)
  • Ship components / upgrades (slotted into ships; consume budget)
  • Planet Cards(Unique Land Card Subtype, Allows land cards to be deployed onto it for cumulative effects - for example a desert planet with a high gravity subtype land card, or a high heat type land card. Basically they're mutators)
Evolution + grades (premium capstone tier)
Creatures evolve across 3 stages, with an additional capstone tier (“EX-like”) intended to feel especially premium. Grades increase move count, initiative bonus(grade 2 = +2 card), with one “special” move or passive effect per creature. Branching evolutions are preferred for build variety.


3) Duels and Match Formats (Planned Pillar)

Match sizes
  • 1v1
  • 2v2
  • 3v3
Initiative
Players roll initiative like D&D using their active main creature; ties reroll. Energy (Pokémon-like, with trap/ship twists)
Energy is accumulated/attached to enable stronger moves. Traps have element types and may require upkeep/maintenance energy. Ships/traps may support “owner-fed” energy vs “sapped” energy modes (sabotage style).
Conditions + staged effects
A conditions system is planned with staged elemental states (ex: cold → frozen, singed → burning), integrated into visuals and combat resolution. Ships: boarding / sabotage
Ships are a major pillar: teams operate within ship budget rules, slot modules into ships, and eventually support boarding/sabotage gameplay for that “invasion” feeling.


4) Card Presentation (The “Hero UI”)

FTCG is designed around premium card presentation:
  • 2.5D layered cards (base art + up to multiple layers for parallax/tilt)
  • Holo/foil styling for higher rarity/grade
  • Optional audio riffs (attack / reveal / pack reveal / selection)


5) Packs, Plugins, and “Installed but Not Activated” Function Packs


This is the long-term architecture goal:


Pack modules are self-contained
Each pack is intended to be its own mini-module (routes/templates/assets/data/logic), so admins can enable/disable or audit content cleanly.


Users cannot add arbitrary plugin functions
End users should never be able to upload executable logic. This is a hard boundary for safety and stability.


Pack/Plugin authors can ship new “card functions”
Creators (trusted pack authors) can provide new card behaviors/effects in a pack module. If installed, those functions become available to the card-design UI.


Installed but not activated
Admins may keep packs installed but not “activated” (so the pack’s own cards do not enter the drop pool), while still allowing the pack’s unique function set to be used by:


  • staff-approved user cards, or
  • admin-curated community cards.

This creates a safe modding ecosystem: admins control what enters packs, but can still expand the “design vocabulary” available to the community.




6) Personal Cards: Community “Calling Cards” Unlocked by Activity


Goal
Reward long-term community members with a personal card design that becomes part of the forum’s evolving “Forum Card Pack.”


Unlock model (admin-tunable)
Personal card slots unlock either by:


  • milestones (ex: 1k posts, 5k posts, 10k posts…), or
  • percentile rankings (top 25%, 10%, 5%, 1% by post count), or
  • a hybrid of both (recommended).

Submission + approval workflow
When unlocked, a user can submit a “personal calling card” design form:


  • art/assets (or staff-provided art selection)
  • name, flavor text
  • stats/moves constrained to allowed templates/functions
  • element/rarity rules constrained by admin policy

Staff must approve before it is minted as an actual card entry.


Forum Card Pack population + series rollover


  • The “Forum Card Pack” can contain up to 150 approved user cards.
  • When it hits 150, the server rolls to a new Forum Card Pack Series (Series 2, Series 3, …).
  • Older series can remain openable as legacy packs, rotate seasonally, or be “vaulted” (admin option), but the main point is: the community pack remains curated and doesn’t balloon forever.



7) Gifting Packs (and/or Credits) via XFRM


Admins can optionally enable gift purchases through XenForo Resource Manager:


Gift flows
  • Gift packs directly (recipient receives pack tickets / pack openings)
  • Gift credits (recipient receives FTCG credits to spend)


Key design requirements


  • Recipient selection at purchase time (username lookup + confirmation)
  • Gift message (optional)
  • Audit trail (who bought, who received, what was delivered, timestamps)
  • Fraud controls (cooldowns, minimum account age if enabled, staff review triggers on high volume)

This supports community events (prizes, giveaways) without staff having to manually grant inventory.




8) Trading Cards


Trading is a core “TCG fantasy,” but it must be built to minimize scams and “he said/she said” disputes.


Trade Offer → Review → Accept windows (two-party escrow model)


  1. Offer Window(initiator selects what they give + what they request)
    • Shows a clear itemized list (cards, quantities, any credits if allowed).
  2. Review Window(receiver sees the exact terms)
    • No ambiguity: “You give X, you receive Y.”
  3. Mutual Accept(both sides must accept the same locked offer)
    • Once accepted, the system performs an atomic swap (escrowed transfer).

Hard anti-scam rules


  • Trades are system-enforced only. No “trust trades” required.
  • Items in a trade are locked once offered (can’t be edited out from under the other party).
  • Trades can expire automatically.
  • Trades can be canceled before acceptance (with clear notifications).
  • Cards that are in a deck / otherwise reserved may be blocked from trading (to prevent weird edge cases and “vanishing cards”).
  • For real-money related grants, admins may optionally enable trade cooldowns or restrictions to reduce chargeback abuse.

The UI should make scamming difficult because the player never has to interpret “what was promised”—it’s all explicit and confirmed.




9) Sockets vs Flagship Sockets (Important Separation)


This is a big clarity point for plugin authors and for future expansion:


A) Sockets (Core System Layer)
“Sockets” are a generic assignment layer used to attach/assign one thing into another:


  • card → deck slots
  • sub-cards/modules → a host card
  • future: traps into zones, equipment into creatures, etc.

Sockets are not flagship-specific. They are a reusable core mechanic for “this container has typed slots; validate what can be placed there.”


B) Flagship Sockets (Flagship Pack Module)


Flagship sockets are the flagship pack’s implementation of sockets:


  • ship slot layouts (bridge/engineering/gunner/medbay/cargo/module slots, etc.)
  • ship budget rules
  • module categories and constraints
  • future: boarding/sabotage hooks that use the ship platform
In short: core sockets are the engine; flagship sockets are one pack’s content + rules using that engine.




10) What This Enables (Community and Admin Benefits)


For players


  • Earn packs by being active
  • Show off collections and signature cards
  • React to posts using owned cards
  • Trade safely with clear, system-enforced terms
  • Unlock personal calling cards through participation milestones/rankings

For admins


  • Strong control over economy and content
  • Optional monetization via XFRM without turning FTCG into pay-to-win
  • Modular pack ecosystem (install/enable/disable)
  • Community card pipeline that stays curated (150-card series caps)
 
Last edited:
  • Love
Reactions: Beneathe
General update on this, early release is a few days off due to needing to tune up the files a little bit - some code is still not entirely the right syntax so I'm doing a lot of line by line edits.
 
  • Like
Reactions: Beneathe
Forgot your password?
Don't have an account? Register now
or