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.
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.
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.