Hypothetical Game Jam

The Question

A channel member named "Super Duper" asked Tim to imagine he's in a 48-hour game jam with the theme "your hobbies" — what game would he make? What's the story, setting, and mechanics? How would he keep the workload light while making a robust game?

Choosing the Hobby: Dice

Tim's first instinct was to make a space combat game (something he's always wanted to do), but the hobby theme redirected him. He considered baking and chocolate but dismissed chocolate because "Fallout was my brown game." He landed on dice — he loves buying, looking at, and playing with dice, and he already has a dice roller toy project he's built.

Play to Your Strengths, Avoid Your Weaknesses

Tim's core game jam advice: always work towards your strengths and avoid your weaknesses. A game jam is not the time to learn new skills.

His Strengths

• Can code quickly, especially game mechanics
• Has a whole library of toy projects (dice roller, dungeon generator, space game) built in Unity with C#
• Can get by on 4-5 hours of sleep naturally ("a secret power of being old")
• Can easily crunch for 48 hours with adequate caffeinated watermelon beverages

His Weaknesses

• Cannot do art — "I can't even make a mouse cursor," as confirmed by an art director
• Cannot write good dialogue (can write lore and narrative monologue, but not back-and-forth NPC conversations)
• Can't crunch for weeks like he used to ("I'm old... young and passionate and a little stupid")

Setting: Fantasy, No Question

Tim chose fantasy immediately. His reasoning: fantasy carries built-in connotation that everyone understands. Say "vampire" and everyone gets it — there may be variants, but the stereotype is shared. Science fiction doesn't have this advantage. Say "Reaver" and people don't know if you mean Firefly, Marvel, or Warhammer — those are all totally different things. Fantasy is easy to explain and easy to make content for.

Keep the Story Simple

Tim emphasizes: do not spend your time in a game jam doing deep lore dives. Keep it simple and move on. If you spend half your game jam thinking of a cool story, you only have 24 hours left to make the actual game. His story: "You're going into a dungeon to get treasure." Done.

The Game Design: Dice + Deck Builder

Tim designed a fantasy dungeon-crawling deck-builder with dice combat:

Core Mechanics

• Character abilities are represented as cards in a deck (attacks, healing, stealth, etc.)
• Monsters are also represented as cards with dice patterns on them
• Combat works like Yahtzee — you roll dice and try to match patterns on the monster's card (a straight, a full house, a pair, etc.)
• If you match all patterns, the monster dies; if not, you take damage and roll again
• Think "Balatro, but instead of poker hands, it's damage dice"

Dice Variety

• Different sided dice (d4 for debuffed, d6 standard, d8 for buffed)
• Possibly colored or patterned dice
• Items or abilities that let you adjust dice results by ±1

Progression System

Killing monsters gives three rewards:

• Experience points — fill a bar, level up, gain a new ability card from the deck
• Money — adds to a running total
• Items — one-time-use abilities, or keep them for their money value

Win Conditions

1. Kill everything in the dungeon (default win)
2. Collect minimum total worth (money + item values) and leave the dungeon — enabling a stealthy thief playstyle where you steal items instead of fighting

Workload Management

Design for Easy Coding

All the mechanics were deliberately designed to be easy to code. Tim already knows in his head how to implement every rule he described — because he's coded similar systems many times on many games.

Leverage Existing Code

Tim already has toy projects for dice rolling and random dungeon generation. Having reusable libraries ready to go is a major advantage.

Time-Box Every Task

Write down every task needed and estimate time for each. If a mechanic takes too long, stop — either cut the feature entirely or fall back to a simpler version. Example: if "backstab from stealth" is too complex, fall back to just "steal an item."

Watch Out for UI

Tim's biggest warning: user interface is the biggest time suck he's ever encountered on any game. It always takes longer than you think. His mitigation: keep the UI dead simple — cards are just rectangles with text and art, bars fill up for XP and money, dice roll in 3D behind the card display.

Art Solutions

Since Tim can't do art, he'd either:

• Partner with an artist (his top choice if the jam allows teams)
• Buy or download free art from the Unity Asset Store
• Make simple 3D models for basic things (walls, dice) but buy 2D art for monsters

Avoid Feature Bloat

Resist the urge to add more features. When people hear the concept and suggest additions — "oh you should add this and that" — remember: you only have so much time.

Summary

Tim believes he could build this game in 48 hours. The entire design philosophy centers on self-awareness: know what you're good at, know what you're bad at, have code ready to reuse, keep the story tropey, design mechanics you've coded before, time-box everything, have fallbacks ready, and above all — keep the UI simple.

References

• Tim Cain. YouTube video. https://www.youtube.com/watch?v=jeP9wVou9hA