Nestor Venegas and I built Lord of the Strings at Flatiron. It was a command-line RPG in Ruby: rock paper scissors combat, levels, HP, a relic to retrieve, and enemies in the way.
It is an early project, and it reads like one. That is fine. The value is not that the game was technically impressive. The value is that it forced me to work inside code I did not fully control yet.
Under the hood
The app used a small Ruby object model with command-line input and feedback. Nothing clever, but the state still had to stay consistent while two people edited combat, player progression, and story flow.
Collaboration
Nestor had more Ruby mileage and carried more of the implementation early. I showed up in design calls, refactors, and whatever needed hands that day. The lesson that stayed was not syntax. It was learning how to read someone else's code, make changes without ego, and keep the build moving.
problem
We needed to ship a small Ruby application as a team, which meant learning object modeling and collaboration at the same time.
constraints
- The game state had to stay understandable while two people were changing it.
- We had to split work without losing the story, combat flow, and player feedback.
- The biggest technical skill was learning to read and change code I did not write first.
what it taught me
- Shared ownership is a skill, not a default setting.
- Small object models are easier to extend when state has a clear home.
- The first useful lesson in collaboration is learning how to disagree without stopping the build.