Devlog 1

HOARD is a 2D action-adventure sandbox about being a dwarf, digging deep, hauling gold home, and defending your loot. Every seven in-game days, the goblins raid. If they reach the chest, they'll steal some of your gold.

I've always wanted to try building a game like Terraria, so over the last week, I've been tinkering away in Godot giving it a go and laying the groundwork.

I'm building it in public because I want to be transparent along the way.

Here's where it stands, and why I'm treating the engine and tech as seriously as the game itself.

What is Hoard?

Dig -> Craft -> Defend.

Caves hold mysteries and best of all, loot. Furnaces turn ore into gear. You build walls, doors, and traps. Night brings pressure on the surface. And on day six of each week, you get a warning. On day seven at dawn, the raid starts.

The loop is already playable: explore underground, deposit gold, craft defenses, survive the horde, swear, go dig again. Art is rough around the edges, lots of scrappy developer art and placeholder tiles.

World & exploration

• Chunked 2D world with procedural terrain, caves, ore placement, and underground encounter rooms
• Mining and block placement through a command system (no cheating the world state from UI scripts)
• Lighting and liquid simulation, including native C++ solvers for hot paths
• Chunk streaming, dirty-region updates, and save/load for world + player + gameplay state

Crafting & items

• Full inventory (hotbar, equipment slots, drag-and-drop UI)
• Shaped crafting grid, recipes, and furnace smelting
• Tools, weapons, placeable defenses, and building pieces (walls, platforms)

HOARD gameplay

• Hoard currency ledger tied to your base chest
• 7-day world clock with raid warnings and escalating goblin waves
• Goblin enemies with combat, pathfinding, camp spawns, and raid AI that actually targets the chest

Engineering discipline

• C# core for gameplay, registries, and world truth
• Godot for presentation: player, UI, camera, audio, particles
• Native backends behind interfaces (lighting, liquids, collision) so nothing is locked to a prototype
• Benchmarks, core tests, and debug overlays (F1 diagnostics, perf tooling) from early on

Honest status: lots of systems work, lots of polish left to do. Balance is rough. I'm at the "embarrassing but real" stage, which is exactly when a dev log is worth writing.

Built for modding. Built as engine first.

1. Mods shouldn't require a fork.

Content ships as data packs: JSON with string IDs like hoard:gold_coin, loaded from manifests and merged at boot. Items, tiles, recipes, raid waves, loot tables, spawn rules: balance lives in data, not scattered magic numbers in scripts.

Mod packs can live in a mods folder. The engine validates references before play. Authoring uses human-readable IDs; runtime maps them internally. Goal: add a block, item, or recipe without recompiling the engine.

2. Performance-sensitive systems stay swappable.

Anything that touches millions of cells like lighting, liquids, chunk IO, collision generation sits behind an interface. C# prototypes first; native solvers when Godot abstractions aren't enough.

Contributors can work on UI, gameplay, C# systems, native sim, or data-only content packs without stepping on each other.

We're not Terraria. Different vibe, different art, different lore, different bosses, different names. Same broad genre: big mutable worlds, mining, crafting, night pressure, progression.

What's next

• More art pass (tiles, items, enemies)
• Death, respawn, and mining feedback polish
• Defense crafting depth (traps, fortifications)

If a dig-build-survive game blended with horde defense sounds like your kind of stupid, follow along. Screenshots and gifs as it gets less embarrassing.

Thanks for reading! If you want to help us achieve success, any sharing/word of mouth about the project goes an incredibly wrong way. Highly advise anyone interested in sharing ideas to either tweet at us or join our Discord community.

Catch your next time, thanks again.🤘