Erebos started from a simple question: can a game still feel immersive if most of the experience is carried by text, stats, and player imagination rather than graphics?
That question made the project interesting immediately. A text RPG removes many visual layers, which means the game has to survive on rules, pacing, balance, and atmosphere.
This post is a development review of building Erebos as a lightweight Python-based game and what that process taught me about game design, portability, and testing.
Why build a text RPG at all
A text-first game sounds small, but it creates a very different design challenge.
Without flashy visuals, the game has to rely on:
- progression
- combat feedback
- tension
- item systems
- world framing through text
That makes the underlying systems much more visible. If the numbers are boring, the game feels boring immediately.
The appeal of stripping the game down
Part of the motivation was curiosity. Modern tools make it easy to assume more rendering, more effects, and more asset work will automatically produce a stronger experience.
But text games ask a different question: what is the minimum structure needed for players to feel progression and risk?
That made Erebos feel like a good product exercise as much as a coding exercise.
The most important technical choice: separate core logic from presentation
The architectural decision that mattered most was keeping the game engine independent from the interface.
Instead of tying rules directly to one UI, the game logic stayed in a core layer responsible for:
- combat formulas
- leveling
- item handling
- progression rules
That made it much easier to imagine the same game working in:
- a CLI version
- a web version
- future interface experiments
The engine should decide what happened. The interface should decide how to show it.
Why that separation was useful
That separation reduced a lot of friction later.
It meant:
- game logic stayed easier to test
- UI changes did not force engine rewrites
- balancing work stayed focused on rules, not rendering
- the product became easier to move between terminal and web contexts
For a system-heavy game, this kind of separation is much more valuable than it first appears.
Balance was harder than building the structure
The most difficult part was not getting the project to run. It was getting the numbers to feel fair and interesting.
A text RPG exposes balance problems very quickly:
- if monsters are too weak, the game becomes flat
- if monsters are too strong, progress feels arbitrary
- if item upgrades are too safe, tension disappears
- if punishment is too severe, frustration replaces excitement
That is why balancing consumed more attention than many people might expect from a text-first project.
Risk systems create tension, but they must feel intentional
One memorable example was item enhancement.
Risky upgrade systems can be powerful because they create real stakes, but they also become the kind of feature players blame instantly if the probabilities feel unfair or unclear.
That means systems like enhancement are not only math problems. They are trust problems too.
You need the game to feel dangerous, but not random in a way that breaks player confidence.
Testing mattered more because randomness was involved
A game with probability, damage formulas, and progression rules can become fragile very quickly if the underlying logic is not verified.
That is why test coverage mattered so much here.
Tests helped verify things like:
- damage calculations
- level-up behavior
- item effects
- progression outcomes
- edge cases around risky upgrades
When randomness is part of the product, testing is not a luxury. It is one of the things that makes iteration possible.
What I learned from building the project
Erebos reinforced a few ideas that apply well beyond games.
1. Smaller presentation can reveal deeper product problems
When the visuals are stripped down, weak mechanics become obvious immediately.
2. Portable core logic is a big advantage
Separating rules from presentation creates room for experimentation later.
3. Balance work is real product work
Numbers are part of the user experience, not just technical detail.
Why projects like this are still worth building
Even if a text RPG sounds niche, it is a very good side project for practicing:
- system design
- clean architecture
- balance thinking
- testing under uncertainty
- product identity
That makes it more valuable than a quick demo that only proves a framework can render something.
FAQ
Q. Why make a text RPG instead of a visual game?
Because text-first systems expose the quality of the mechanics more clearly and reduce the need for heavy asset production.
Q. What was the hardest part?
Balancing progression and risk so the game felt tense without becoming unfair.
Q. Why was test coverage important here?
Because probability-based rules and progression systems become hard to trust if the underlying logic is not verified repeatedly.
Read Next
- If you are interested in lightweight browser-delivered games, continue with the Phaser Beginner Guide.
- If your next interest is product and interface polish rather than game systems, the UI Design Guide for Developers is a useful follow-up.
Related Posts
While AdSense review is pending, related guides are shown instead of ads.
Start Here
Continue with the core guides that pull steady search traffic.
- Middleware Troubleshooting Guide: Redis vs RabbitMQ vs Kafka A practical middleware troubleshooting guide for developers covering when to reach for Redis, RabbitMQ, or Kafka symptoms first, and which problem patterns usually belong to each tool.
- Kubernetes CrashLoopBackOff: What to Check First A practical Kubernetes CrashLoopBackOff troubleshooting guide covering startup failures, probe issues, config mistakes, and what to inspect first.
- Kafka Consumer Lag Increasing: Troubleshooting Guide A practical Kafka consumer lag troubleshooting guide covering what lag usually means, which consumer metrics to check first, and how poll timing, processing speed, and fetch patterns affect lag.
- Kafka Rebalancing Too Often: Common Causes and Fixes A practical Kafka troubleshooting guide covering why consumer groups rebalance too often, what poll timing and group protocol settings matter, and how to stop rebalances from interrupting useful work.
- Docker Container Keeps Restarting: What to Check First A practical Docker restart-loop troubleshooting guide covering exit codes, command failures, environment mistakes, health checks, and what to inspect first.
While AdSense review is pending, related guides are shown instead of ads.