Strange Tales
of the Ink Pool.
Inspired by Chinese tales of the supernatural, a scholar’s encounter with a koi unfolds through shadow-puppet and pop-up-book imagery. I implemented the core card gameplay, bringing the jam theme “Everything is alive” into playable encounters.
Watch gameplay ↓
00 / MY CONTRIBUTION
A story played
one card at a time.
Observe, move, light a candle, or summon a koi. Cards act as the player’s verbs, revealing the next encounter as the story unfolds.
What I built
- Core card rules, hand layout, selection feedback, card rewards, and card consumption.
- Target matching by scene-object tags, connecting card effects to interactions and story progression.
- Card and scene configuration integration, using an existing CSV tool.
I worked with the designer and the other programmer to define the configuration fields. The other programmer primarily handled Spine animation work.
01 / THE PLAYABLE LOOP
Actions become the next chapter.
Using a card changes the scene and can add new cards to the hand. A small set of effect types carries the player through seven configured scenes.
- 01
Observe the pond
Discover a koi in the pond and gain new ways to continue the journey.
- 02
Enter the dream
Summon the koi in a dream and use cards to extinguish the flames.
- 03
Transform
The koi takes human form to save the scholar, and the story turns toward waking.
FROM INPUT TO FEEDBACK
Select. Confirm. Rearrange.
Selecting a card raises it above the hand; clicking it again uses it. As cards are awarded or consumed, the remaining cards move into their new positions.
02 / WORKING WITH THE DESIGNER
From shared data design
to playable interactions.
The designer proposed cards and their intended behaviors. Together with the other programmer, we defined what the data needed to express: effect types, targets, animations, interaction values, and rewards. The designer then authored the content in spreadsheets, using the fields we had agreed on.
From configuration to playable cards
The CSV configuration is loaded into card definitions indexed by ID. Initial hands and rewards use those IDs to create runtime instances and their UI. Each instance references its definition for artwork and effects; consuming it removes the instance and UI while leaving the definition available for future cards.
A CARD DEFINED IN DATA
“Observe the pond”
Observing the pond and extinguishing fires use the same interaction logic. Different configurations select the target, animation, and rewards, allowing each encounter to advance the story without a separate execution path.
| Effect type | Interact |
|---|---|
| Target tag | chitang |
| Animation | jump |
| Interaction value | 1 |
| Reward cards | 202 · Koi / 203 · Move |
The target’s phase tracks its remaining interaction stages. The interaction value reduces it; rewards are granted when it reaches zero or below.
03 / A DEBUGGING CASE
A stall traced
to BGM loading.
After the scene loaded, the game briefly stalled. I initially suspected redundant card data. Further debugging traced the hitch to loading a large BGM resource. I resolved it by adjusting Unity’s audio import and loading settings.
WORKING WITH THE TEAM
What I learned
This 48-hour jam connected each step of gameplay implementation: defining data with the designer, organizing configuration into card definitions, creating runtime instances, and executing different interactions through shared logic. Deciding what the data needs to express is itself design work shared by programmers and designers.