Posted October 12, 2025 by fromqcwithgamedev
Hey everyone, it’s FromQCWithGameDev! In this devlog, I want to talk about what I think is the most important part of starting any new project — whether it’s game development or anything else — and that’s planning.
I’ve learned that I perform way better when I have clear, concrete objectives to work toward. Having a to-do list I can check off each day helps me stay focused and motivated.
In game development, planning means defining your objectives and your end state — knowing exactly what you’re trying to make, how it should play, and what “done” looks like.
For this project, I wanted to be super clear about all of that before jumping into code.
Since I’m already comfortable with Unity, I decided to stick with it. One less thing to worry about.
For the concept, I drew inspiration from one of my favorite board games, Karak. It’s a tile-based dungeon-crawling board game that already feels like a video game at its core.
My goal was simple:
Recreate the feel and mechanics of Karak
Focus on local couch co-op gameplay
Maybe add online multiplayer someday down the road
Recreating a board game has one big advantage — the rules already exist! That meant I could focus on implementation instead of game design.
Before touching Unity, I jumped into Figma to storyboard and visualize the game flow. It’s a great way to answer two big questions early on:
What happens in the game?
What do I want it to look like?
Because I was targeting desktop (Mac/Windows), I knew I’d be designing for a horizontal layout, not mobile. That made things simpler.
I started gathering UI inspiration online — menus, buttons, and layouts I liked — then began creating my own versions. I built a main menu first just to warm up and get a feel for Unity’s UI tools.
In Karak, each player takes turns and gets four actions per turn. That gave me my first UI requirement:
Clearly show whose turn it is and how many actions remain.
Players move between tiles, exploring as they go. Each new tile reveals something — maybe a room, maybe an enemy, maybe treasure.
That meant I needed a:
Tile placement system (players choose how to place new tiles)
Tile content generator (decides what’s inside each new tile)
Special ability UI for characters who can pick between two tile options
When a player discovers an enemy, they have to fight it. Battles are resolved by rolling dice, with damage boosted by weapons in your inventory.
So I made a battle UI:
A button to roll dice
A results screen explaining the outcome (super helpful for debugging and clarity)
Then I added special abilities — like re-rolling dice, chaining turns, or skipping fights — which required extra buttons and logic in the combat UI.
Once that was in place, I made separate screens for winning and losing battles.
After a fight, enemies drop loot. Players have limited inventory:
2 weapons
3 spells
1 key
If they find a new weapon, they can choose which old one to replace.
Some enemies even let players curse another player when defeated — so I built a small UI for that too.
The final goal of the game is to defeat the Red Dragon, so I added an end-game screen that triggers when that happens.
With all that, I circled back to smaller gameplay details:
UI for opening treasures, picking up spells or weapons
Target selection for spell casting
Handling cases like finding treasure without a key
By this point, I had a full map of what my game’s systems and UI needed to look like — from menus to movement to combat.
Next up? Designing class diagrams and state machines to bring all those pieces to life in code.
Planning might not be the most glamorous part of game dev, but it’s absolutely essential. Having a clear idea of what I wanted to make — and how each piece fit together — made every next step more manageable.
Even though my UI was rough and simple, this process gave me direction and confidence to start building for real.