Dev Log #7: Two Months Post-Launch — What I Got Wrong, and What Comes Next
It’s been two months since Mark of Cain launched.
I shipped it. I survived it. And now I’m sitting here with the clearest head I’ve had in a while — looking back at the decisions I made and being completely honest about what didn’t work.
I Overscoped. Badly.
This one is hard to admit, but it’s the most important lesson from this entire project.
I spent months building features. Split-screen multiplayer. A level editor. Steam Workshop integration. A whole progression of meme bosses. Feature after feature after feature — and somewhere in the middle of all that, I lost the thread of what the game was actually supposed to feel like.
The core gameplay loop didn’t need half of what I stuffed into it. Players don’t care about the number of systems. They care about whether the game is fun to play. And I spent more time on feature breadth than on making each second of gameplay feel tight and responsive.
Next time: nail the feel first. Ship the extras later — or not at all.
Going Back to First Principles
After the release dust settled, I started reading again. And as always, I ended up back on John Carmack.
There’s something about the way Carmack thinks about problems — the radical focus on performance, the refusal to accept layers you don’t understand, the belief that if you understand the machine, you control the machine — that I keep coming back to every time I feel creatively stuck.
So I made a decision: I’m going to build my own raycaster engine.
Not because it’s practical. Because I want to understand every line of what renders pixels on screen. Because I’m tired of abstraction layers making decisions for me.
The Problem with Modern Game Engines (for Someone Like Me)
Here’s my real issue with Unity and Unreal: you don’t have full control. You adopt their vision of how games should be built, and you accept the tradeoffs they decided on — whether or not those tradeoffs make sense for your project.
A concrete example: I can’t use OpenGL 2.0 in most modern setups because engine developers decided to drop it. Fine, maybe that makes sense for their target hardware. But what about my audience? What if someone can’t run the newer API? That’s now my problem — one I inherited from a decision I had no part in.
For a solo dev like me — someone with a programming background who enjoys being close to the metal — that’s a bad deal.
Unity and Unreal make a ton of sense if you’re a 3D artist who wants to focus on assets and level design. The visual tooling, the node graphs, the drag-and-drop workflows — that’s genuinely powerful for a certain kind of creator. I’m not that person.
I’m better at pixel art and direct code. I’m better at writing 4 lines to sync a state across a network than dragging nodes around a UI editor and hoping they connect the right way. I find it faster, clearer, and more satisfying. And when something breaks, I know exactly where to look.
The Raycaster Plan
The plan is simple: build a raycaster from scratch, understand it deeply, and make games with it.
Not Quake. Not Doom’s full BSP engine. A clean, minimal raycaster in the spirit of Wolfenstein 3D — but built the way I want it, with zero dependencies I don’t understand, targeting hardware I actually care about.
If it ends up being overkill, I’ll know why. If it ends up being exactly enough, even better.
I’ll be posting updates here as things take shape. This is early days — right now it’s mostly me re-reading graphics programming papers and sketching out the core rendering loop — but it’s the most excited I’ve been about a project since the first week of Mark of Cain.
What’s Next
For Mark of Cain: I’m keeping the lights on. Bug fixes if they come up, nothing more. The game is what it is, and I’m proud of it for what it taught me.
For the raycaster: that’s where my head is now.
See you in the next one,
— Stamatios