Inside Emberblast: How an X-Team Engineer Turned a Terminal Window Into a Python RPG

Most role-playing games sell themselves on cinematic visuals. Felipe Ramos da Silva decided to build one that lives entirely inside a terminal window.

The project, called Emberblast, is a Python RPG with no graphics, no animations and no fancy UI — just a grid of dots, a config file and a handful of design choices that doubled as a self-imposed engineering challenge. Ramos, a Senior Fullstack Developer who joined X-Team as a Python engineer a few months before he started the game, wanted something that felt native to the developer's everyday environment. The terminal fit the bill.

In this story, Ramos walks through how a grid of graph nodes became a working RPG, which Python libraries pulled the weight, and why he thinks personal projects without clients or product specs are some of the most valuable work an engineer can do.

A Graph Problem Disguised as a Game

The idea started not with a game design document but with a classic developer obsession: data structures.

"I really love RPG games. I'm also interested in data structures and algorithms," Ramos says. "Most of the algorithms and data structures I've come across professionally aren't very complex. It's graphs, trees, as well as traversing, shortest path and search algorithms. All doable."

The seed came from watching colleagues play X-Team's internal Slack games — particularly The Tower — and realizing he wanted to build something that fit the same mental space as the work he did every day. "Most games have a fancy UI," he says. "I wanted something a little more aligned to a developer's reality. The first thing that came to mind was a game in the terminal."

Once he framed Emberblast as a graph problem — every tile on the map a node, every legal move an edge — the rest of the design fell into place. The map became an adjacency matrix. Each dot a node. Pathfinding became a traversal problem he already knew how to solve.

Why Python — And the Libraries That Made It Work

Ramos had several languages to choose from, but Python was an easy pick for three reasons: it was the first language he learned, it handles the math and analytics the game requires without ceremony and its metaclass system lets him generate classes at runtime — which turned out to be critical.

He wanted Emberblast to be deeply customizable. Players should be able to edit a YAML file to add their own races (Human, Elven, Dwarf) and jobs (Knight, Archer, Rogue, Wizard) without touching the game's source code. To make that work, Emberblast reads the config file, validates it and constructs custom classes on the fly based on whatever's inside.

"Thankfully, because of metaclasses in Python, as well as some singleton and configuration management techniques, I managed to do it," he says.

A short tour of the stack he settled on:

• InquirerPy — the game asks the player constant questions and validates input. InquirerPy (a Python port of the popular Inquirer npm package) handles raw inputs, list selection and radio validation.
• Cerberus — validates and parses the YAML config files against a schema and flags errors back to the player.
• NumPy — handles the matrix math and calculations.
• Built-in Python features — metaclasses, dictionaries, generators and decorators do most of the structural lifting.

When he gets to multiplayer, he's eyeing Django for the web framework layer and websockets for the real-time connection.

The hardest part of the build so far, he says, wasn't the customization layer — it was the map. Graph traversal is straightforward on its own, but the moment you add constraints (where can a player legally insert, what moves are reachable from this square, how does the graph change when the player count changes), the complexity multiplies fast.

What Personal Projects Give You That Client Work Doesn't

About 60% of the base game is written. There's no deadline. No client. No product manager telling Ramos which features to prioritize. That, he says, is the point.

"Personal projects give you a world without constraints," he says. "You don't have clients and vendors with strict requirements on the tools you need to use. Instead, you're free to use any technology you want and do whatever you like."

The work still demands real engineering judgment — Ramos still has to make logical, comprehensive decisions about architecture and scope. But the freedom to experiment with technologies he wouldn't get to touch on a client project is what keeps him moving. The roadmap that excites him most: replacing Emberblast's hardcoded bot logic with actual machine learning models, likely trained and deployed via AWS SageMaker. Then a multiplayer mode modeled after League of Legends' matchmaking queue, complete with websockets, multithreading and a dedicated game client. Then clan-war modes beyond the current free-for-all Deathmatch arena.

"I'd be really proud to present it to my friends," he says. "I'm eager to see the full result, and that motivates me."

For an engineer who joined X-Team to ship production code for partners, Emberblast is the inverse: a project whose only stakeholder is the engineer himself and whose only KPI is whether he's still excited to open the file tomorrow morning.

You can play Emberblast — or read its source — on its GitHub page.

Ready to build work you're proud of? Apply for an open role at X-Team.