Mr. Question Mark?

What if randomness itself became a deck-building resource?

MY ROLE

Game Systems Design
Gameplay Programming · Testing

STACK

C# · .NET 9 · Godot 4.5.1
BaseLib · Harmony

PROJECT

Custom Slay the Spire 2 character
Custom transformation-based card pool

Actual gameplay · Card selection, combat resolution, and a changing hand. Muted recording, approximately 17 seconds.

01 / The design question

Uncertainty with agency.

Randomness is fundamental to deck-building games. But completely uncontrolled randomness can reduce meaningful player decision-making.

What happens when the player controls the boundaries of randomness, without controlling the exact result?

Mr. Question Mark has an independent starting deck, card pool, and relic systems. The character transforms uncertainty into a strategic decision.

02 / Controlled randomness

Choose the pool. Adapt to the result.

CharacterCard typeRarityEnergy costFunction

1. Select constraints2. Generate eligible pool3. Random selection4. Transform card5. Adapt strategy

The player does not choose an exact result. Instead, they choose how uncertain that result should be. Existing cards become potential outcomes within those constraints.

In-game custom card collection with cards constrained by attack type, rarity and character — The in-game card collection makes the constraints concrete: Random Attack, Random Common Attack, and character-specific transformations. Card art shown reflects the current development build.

03 / A deck that evolves

Transformation across the fight.

Actual gameplay · A card upgrade interaction, followed by combat and the reward flow. Muted recording, approximately 19 seconds.

Persistent transformation

Some cards continue changing after entering the discard pile. Relevant state—including upgrades—is preserved while their identities evolve.

PlayDiscardTransform again

Fission

A card becomes a zero-cost version that generates a copy when played. Originals and copies can continue participating in transformation mechanics.

Zero-cost cardPlay + copyContinue evolving

04 / Temporary relics

A changing strategic environment.

The character can temporarily borrow randomized relics between combats. Each encounter offers a different strategic environment without permanently adding every borrowed relic to the run.

Track sourceShow temporary stateCombat lifecycleRestore on load

The implementation connects relic source tracking, tooltips, visual states, combat lifecycle, and save restoration.

Pipe of Thought starter relic tooltip and a borrowed Cracked Core effect for the current combat — **Pipe of Thought**
Borrow a random starter relic effect each combat. The tooltip exposes the currently borrowed effect.

Fine Tweezers rare relic tooltip describing energy gain for enchanted cards — **Fine Tweezers**
Enchanted cards among the first three cards played each turn grant energy, connecting card state to resource management.

05 / Engineering challenges

A mechanic is also a software system.

State inheritance

Dynamic cards need to preserve appropriate upgrade and enchantment information while changing identity. Copies introduce further questions about which state should carry forward.

Save restoration

Temporary systems introduce additional state that must survive serialization and reconstruct correctly after loading a saved run.

Asynchronous resolution

I used runtime logs and exception traces to debug timing and resolution problems involving asynchronous card behavior and event handling.

Packaging

The mod combines compiled DLL code with Godot PCK resources for deployment into the game's mod environment.

06 / Reflection & process

Rules, state, and player experience.

A simple idea—“transform this card again”—raises questions about upgrades, copies, save data, combat timing, and interactions with other systems. Building this character taught me to treat gameplay mechanics as connected software systems.

Development Process

AI-assisted development tools were used during implementation. I defined gameplay requirements and systems, reviewed and adapted implementations, tested behavior in-game, debugged failures, and iterated on the resulting mechanics.

Explore more

SteamDeals

A product that turns pricing data into clearer purchase decisions.

Explore the case study