Devlog 1: What If YOU Were the Shopkeeper... For the Bad Guys?

Hey everyone! 

Welcome to the first devlog for DungeonMart (working title—might change, probably will change).

The Concept

You're running a shop inside the dungeon. Your customers? The goblins, skeletons, slimes, and big bad bosses who are supposed to be fighting the heroes. They need supplies too—weapons, armor, potions, traps. Someone's gotta keep the dungeon economy running.

You're on the villain's side of the operation, and business is... complicated.

Think Recettear but you're arming the monsters instead of the heroes.

At least, that's the vision today. Ask me again in three weeks and it might be completely different. That's the prototype phase for you.

The (Not Really a) Restart: 2D → 3D

This week I made the switch from 2D to 3D.

But here's the thing: I'm not actually starting over.

About 90% of my code so far is pure systems—economy logic, inventory management, item data structures, customer behavior patterns. None of that cares whether it's rendered in 2D or 3D. The switch was mostly swapping out sprites for models and adjusting the camera.

Why make the switch?

I just work better in 3D. My brain thinks in three dimensions, and I've already got a collection of low-poly dungeon/fantasy assets that all match stylistically. Why fight my natural workflow when I can lean into it?

Plus, with Claude Code helping me scaffold the 3D-specific stuff (camera controller, 3D UI positioning, basic lighting), the actual migration took like... two days? Not bad.

What's Already Built

Since most of my work has been on systems, here's what's actually implemented so far:

Core Gameplay Systems:

• Core inventory system
• Ordering system with UI
• Day/Night cycle with three phases
• Customer wave system (fixed spawns per day)
• Delivery system (boxes spawn, player opens them)
• Phase restrictions (order menu only at end of day)
• Starting delivery boxes on Day 1 & proper day progression

UI & Menus:

• Main Menu Scene with Play, Settings (TBD), and Quit buttons
• Pause System with ESC key, pause menu overlay, and all buttons
• End of Day Summary Panel with statistics and continue button

3D Gameplay & Movement:

• 2D to 3D Conversion: Complete transformation from 2D orthographic to 3D perspective top-down gameplay with NavMesh pathfinding, WebGL-optimized rendering
  
• 3D Physics with NavMesh pathfinding (player movement on XZ plane, customer AI navigation, configurable spawn points)

Customer Systems:

• Basic Customer Types & Corporate Humor (3 types, dialogue system, visual bubbles)
• Visual Polish: Customer visuals now use random SPUM character prefabs (48 variants) not relevant anymore in 3D

Item & Shelf Management:

• Diverse Shelving System with item sizes and multi-item support
• Single Item Size Per Shelf Type restriction
• Restock UI System with item selection and size filtering
• CSV Item Importer Tool: Automated ItemDataSO generation from Excel/CSV spreadsheet
• Item System Refactor: Converted from 2D sprites to 3D models - ItemDataSO now carries prefab reference (data-driven design), Item.cs simplified to pure data container, visual setup handled by prefab structure
• Shelf System Refactor: Replace grid-calculated slot positioning with inspector-assigned transform array for maximum flexibility in shelf design

Economy & Progression:

• Monthly Expenses System: Rent tracking, loan system with interest, fail states (KNOWN BUG: Game Over UI input blocked)
• Progression System: Lifetime revenue tracking, tier-based milestones (5 tiers: Street Vendor → Tycoon), persistent progress UI
• Upgrade Shop System: Card-based UI, purchase flow, tier-locked upgrades, dynamic rent contribution (8 upgrades for tiers 1-3)

Audio & Polish:

• Sound System: Multi-AudioSource sound effects with gameplay and UI sounds
• Music System: Phase-based dynamic background music with smooth crossfades

Code Quality & Architecture:

• Managers Refactor: Merged 3 Managers (expense, loan, failstate) → 1 Unified Manager (financial)
• Debug Input System: Centralized DebugInputManager with compilation directives for automatic release build exclusion

These systems are mostly backend right now—they work, but they're not pretty. That's intentional. I'm building the skeleton before worrying about the skin.

The Big Design Question I'm Wrestling With

Here's where it gets interesting. I'm deep in research mode on a core design problem:

Is it better to sell MANY items at lower prices, or FEW items at higher prices?

This sounds simple, but it completely changes what kind of game this is:

• Volume-based gameplay: Fast-paced, lots of customers, quick transactions, inventory turnover management, maybe even time pressure. 

• Margin-based gameplay: Slower, negotiation-heavy, reading customers, waiting for the "right buyer" for rare items, more strategic patience.

I've been prototyping both approaches, running little economy simulations in spreadsheets (yes, there are many spreadsheets), and honestly? I don't know which is more fun yet.

Maybe it's both. Maybe you start with volume and unlock margin gameplay later. Maybe customers have different behaviors and you adapt. Maybe I'm overthinking it.

This is the stuff I'm figuring out right now—not through design documents, but by building it and seeing what feels good.

Claude Code: My Prototyping Weapon

I mentioned this briefly, but it deserves its own section. I'm using Claude Code (Anthropic's CLI tool) to accelerate prototyping, and it's been a game-changer for solo dev.

Here's how I'm using it:

When I want to test a gameplay idea—say, "What if there's a seasonal system where goblin tribes need more fire resistance potions in winter?"—I can scaffold that system in 20 minutes instead of spending half a day building it from scratch.

I'm not having AI "write my game." I'm using it to compress the experimentation phase. Build fast → Test fast → Keep or kill fast.

This matters because I have limited time to prove this concept works. Every hour I save on boilerplate code is an hour I can spend testing whether the game is actually fun.

What I'm Building right now:

Right now, the game looks like a bunch of Synty assets  and cubes and capsules in a Unity scene. Beautiful? No. Functional? Getting there.

Current focus:

Trend/Seasonal System - I'm exploring whether customers should have changing needs based on events. Maybe adventurers are getting stronger, so your dungeon customers need better gear. Maybe there's a "dragon migration season" and fire-related items are hot sellers. Maybe a new dungeon level opened and slimes suddenly need mobility upgrades.

The question is: does this add strategic depth, or does it just add noise? Testing will tell.

Economy Tuning (Volume vs. Quality) - Still deep in the weeds on this one. Continuing to prototype different customer flows, price points, and transaction speeds. The spreadsheet grows ever more terrifying.

Basic Systems Implementation - Improvement of customer AI pathfinding, buy/sell interactions, inventory management. The unsexy but necessary foundation work.

The goal isn't to make it pretty. The goal is to make it interesting enough to know if I should keep going.

Behind the Curtain

Tech stack:

• Unity 6.2
• Claude Code for rapid prototyping, working with Jetbrains Rider IDE
• Low-poly asset collection (finally being put to use)
• One big Excel file called "DungeonMart_Economy_Balance.xlsx"

Bugs encountered: All of them.

Current state: Placeholder and basic assets pretending to be evil customers. They don't look threatening. They just look... geometric.

Thanks for reading! I'll be posting regularly progress shots on [https://x.com/bouldouklu] and updating here weekly.

Got thoughts on shopkeeper games, economy design, or what monsters would actually buy? Drop them in the comments—I'm actively figuring this out and would love to hear what you think!

~Bouldouklu