davidslv
Joined 14 years ago
Karma
22
Submissions
32
Member since
Mar 9
Recent submissions
Comment · 3 months ago
Interesting read, but I keep finding that these are well intended but rarely the solution. On your words: "Bad requirements produce bad code reliably."
This is a different problem to solve, but clearly is saying "garbage in, garbage out". To me this seems more cultural education.
Comment · 4 months ago
Author here. This started as a hobby attempt to understand Codemasters' old driving AI, which had received quite a few interesting game reviews at the time. Which meant first reading their "BIGF" archive format. The surprise was Ruby: String#unpack is basically a fast, C-backed binary parser hiding in the stdlib, and the whole reader is dependency-free. Repo (MIT): https://github.com/davidslv/bigf
Honest note: AI-assisted throughout — I steered and verified every claim against the bytes. No game data committed; tests synthesise fixtures from the documented format.
Comment · 11 months ago
I spent 5 years building a roguelike game in pure Ruby (no game engines) to explore Entity-Component-System architecture and event-driven patterns outside of typical Rails applications.
Full disclosure: The project benefited significantly from AI assistance in the later stages to keep momentum going while balancing a full-time job and family. I used AI as a coding partner - I made all architectural decisions, reviewed every change, and stayed in control of the direction. It let me focus on the interesting problems (ECS design, event systems) rather than grinding through boilerplate.
The game runs entirely in the terminal and uses the same architectural patterns we use in production web apps - ECS for entity management, pub/sub for events, observer patterns for game state.
Why Ruby? Honestly, because it's the language I know best, and I wanted to prove you could build a game without reaching for Unity, Godot, or even a Ruby game library. It's all vanilla Ruby.
The codebase is fully open source and I've also written a book about the process (5 years in the making) that walks through the architecture decisions: https://www.amazon.com/Building-Your-Own-Roguelike-Hands-ebo...
Technical highlights:
- Entity-Component-System from scratch - Event-driven game loop - No dependencies (just Ruby stdlib) - Runs in the terminal
I'd love feedback from the HN community, especially on the architecture patterns. Happy to answer any questions about the implementation.
Thank you, davidslv
Comment · 4 years ago
I've been working on writing a roguelike game in ruby, without using any external libraries.
It's not really a complete game at this stage, all you can do is travel through the randomly generated mazes once you hit the stairs.
I thought I would share as I have been struggling for time to do further features.
Any feedback is appreciated, feel free to have a look around and contribute if you so wish.
I build things from scratch to actually understand them: a roguelike in pure Ruby — no engine, just a terminal and an entity-component-system — and a modular-monolith Rails reference app where the boundaries are real.
The two architecture books I've written came out of that work, not the other way around.