Some of the first ideas for Vorgar were bigger than the game could honestly carry at that stage. I thought about three unit types, unit levels and a system where the army would feel more like a classic strategy roster. On paper, that sounded richer. More choices usually feels like more game.
Then I started putting those ideas against the actual board. Vorgar uses a simple hex map, clear territories, cities, mines and direct pressure between players. Every extra unit type immediately asked for balance work: how fast should it move, how much should it cost, when should it beat another unit, and how does that stay fair on a small readable map?
I did not have the time for weeks of balance testing. I also did not want the first public version to become a pile of rules that looked strategic but only worked because I had not tested the hard cases yet. So I made the first compromise: start with one main unit, keep some of the logic open for more unit types and levels later, and prove that the core game could work first.
The difficult part was accepting that one unit was not a smaller dream. It was a clearer test of the real game.
The computer opponent changed the decision
The real turning point came when I started designing how the computer opponent should behave. Even with one unit type and one level, the decisions became complicated quickly.
A computer player has to decide where to expand, which city needs defense, when a mine is worth taking, when a border is dangerous, whether an attack is worth the losses, and how to avoid spreading armies so thin that the whole position collapses. Those are already meaningful decisions. Adding more units on top would not just add content. It would multiply every AI question.
That was the first painful cut in the project: remove the extra units and levels from the active design. Not forever as an idea, but from the version I was actually trying to build, test and release.
Simple does not mean empty
Vorgar still has strategy space because the unit roster is not the only place where decisions live. The map matters. Cities matter because losing all cities removes a player from the match. Mines matter because they change the economy. Barracks matter because they shape future production. Borders matter because a safe position can become fragile after one bad move.
That direction also connects to the games and tabletop strategy memories that sit somewhere in the background for me: map-conquest classics like Risk, larger strategy feelings from games such as Heroes or Warcraft III, and board games where the visible board state creates tension without needing every rule to be heavy.
Vorgar is not trying to copy those games. It is trying to keep one useful lesson from them: a readable map can create a lot of drama when every field, city and army count is easy to understand.
The cut made the game stronger
After removing the extra unit plan, the design became easier to judge. A turn could focus on reinforcement, economy and army movement. A player could look at the screen and understand where pressure was coming from. The AI could be improved around the same visible goals as the player instead of trying to fake depth through unfinished systems.
That does not mean Vorgar will never grow. More units, levels or special rules could still return later if the game earns them and if there is enough time to balance them properly. But they need to serve the board, not bury it.
For now, the better foundation is a simple system with real pressure: raise armies, take land, control gold, protect cities, and make each turn clear enough that the next decision matters.
What stayed
The first version kept the parts that made Vorgar feel like itself: hexes, territories, cities, gold mines, barracks, armies and direct conflict. Cutting the rest was uncomfortable, but it helped the game become something I could finish, test, release and keep improving.
That is one of the recurring lessons in this project. A feature can be exciting and still be wrong for the current version. Sometimes the best design decision is not adding the next layer. Sometimes it is protecting the part that already works.