Empires & Allies was a real-time strategy game built around competitive play, alliance coordination, and long term progression. By the time I joined, the game was well into its live phase, a mature product with a dedicated player base who knew its systems inside out.
That’s a different design challenge than building something new. The players aren’t learning. They’re evaluating. Every new feature, every seasonal event, every UI change gets scrutinised by people who’ve spent years with the game. The question wasnt “will they understand this?” it was more like “does this experience respect what our users already know?”
Design Approach
The principle I kept returning to on E&A was depth over novelty.
In live games, there’s pressure to ship new things constantly, new events, new modes, new currencies. But veteran players dont necessarily want more. They want the existing game to feel deeper, more considered, more worth their time. Novelty fades after a session. Depth is what brings someone back tomorrow.
This shaped how we approached everything from seasonal systems to event cadence to how much complexity we were willing to surface at once.
Veteran Engagement Systems
The players who’ve been with a strategy game for months have already solved most of its core loops. They know the optimal build orders, the resource math, the timing windows. If the game doesnt evolve with them, it stagnates.
We designed engagement systems specifically for this lifecycle stage. The idea wasnt to add difficulty, it was to add layers. New progression system that adds to the existing ones rather than replacing them.
The battle pass structure worked well for this. It gave veteran players an objective to work toward across a season that felt distinct from the base progression. We also introduced an additional layer to the existing league tier systems to celebrate the top percentile users. The design challenge was making these systems feel like a natural extension of the game rather than a bolted-on system.
UX Pipeline
Alongside the player-facing work, I also spent time improving how we built UI in Unity. The existing workflow involved a lot of one-off implementations — each feature built its UI from scratch, which meant inconsistency and slow iteration.
We introduced modular UI structures and clearer implementation patterns. This wasnt glamorous work, but it meant we could ship live features faster and iterate on them without rebuilding from zero each time. For a live game where speed matters, the pipeline is part of the product.
