A while back, we wrote about ZHAIand its intriguing approach to combat, where the hero’s missing memories directly influence what they’re capable of doing in a fight. We saw plenty of potential in the idea, and saying that the core mechanics caught our attention would be quite an understatement. Making that idea work across a large world has demanded some unexpected decisions from The Orange Giant, from rethinking the game’s original form to making sure its different teams aren’t building in isolation. We spoke with game director Maher Chebli about finding the right shape for the adventure, keeping powerful abilities under control, and giving the world of Il’Navir an identity of its own.
Interview made possible by PR by Aleks!
Before It Became an Open-World Adventure
Long before the finer details of combat were settled, there was a more fundamental question: what kind of game should ZHAI be? Chebli recalls a few possibilities that would have led the project somewhere quite different.
One of the earliest challenges was actually deciding what kind of game Zhai was going to be in the first place. We experimented with very different ideas, including things like a top-down RTS, before eventually settling on an open-world action game.
Once we made that decision, we wanted the world to feel as open and accessible as possible. We didn’t want players constantly running into invisible walls or arbitrary restrictions just because we weren’t ready for them to go somewhere yet. If we did need to restrict access to an area, we tried to make sure there was a natural reason for it within the world. It could be the environment, the geography, something happening in the story, or an obstacle that the player isn’t equipped to deal with yet. The important thing was that the restriction felt like part of the world rather than the game simply telling you that you can’t go there.
Game director Maher Chebli
The Orange Giant traces the setting’s beginnings to sketches inspired by a world one of its founders remembered after a motorcycle accident and coma. Those images gave the team something to work from, but a place that looks striking on paper still has to make sense when players move through it.
A version of those original sketches made it into the game one way or another. We definitely made changes as the world developed, mainly to make everything feel more cohesive, but we tried to preserve the original intention behind each area rather than just copying the concept literally.
If something from the early sketches conflicted with how the final world needed to work, we would adapt it to fit the setting rather than throw the idea away completely. For example, the snow region was originally imagined more like a giant iceberg. As the world became more defined, that didn’t fit as naturally with the rest of the planet, so we changed how it was integrated into the environment while keeping the same feeling we wanted from that region. For us, the important thing was preserving the identity and atmosphere of the original idea.
More Than a Change of Scenery
Il’Navir’s regions aren’t meant to be interchangeable fantasy biomes. We wanted to know how the team connected the different tribes’ identities to their appearance, histories and powers, and whether any early concepts proved too familiar to keep.
Culturally, we made sure each tribe had its own history, beliefs and identity, and the player gets to learn about that through the main story, side missions and collectibles scattered around the planet. We also wanted each faction to feel visually distinct in a way that actually connected back to the world rather than just looking different for the sake of it.
For example, the desert tribe has very pale white skin because their bodies evolved to reflect more of the intense sunlight rather than absorb it. That adaptation also ties into how their powers developed, so the visual design, the lore and the abilities all support each other.
Mechanically, we took the same approach. We would start with the tribe’s lore and ask what kind of abilities actually make sense for them and for the story we’re telling, rather than choosing a power first and trying to justify it afterwards.
We did abandon some ideas quite early on when they felt too familiar or didn’t really fit. The snow tribe originally having ice abilities is a good example. It was the obvious choice, but that was also the problem. It felt too expected, and more importantly it didn’t necessarily fit the lore we were building for them, so we moved away from it.
Learning to Fight by Remembering
Zhai’s missing past gives the story its central mystery. It also raises a design question: why should remembering something unlock a fighting skill, rather than simply reveal another piece of the plot? Chebli says the connection emerged as the team worked out what sort of fighter Zhai would be.
The decision actually came pretty naturally while we were making the game. It wasn’t something where we first decided that memories had to be tied to progression and then designed everything around that. We already knew Zhai had lost his memories, and we also knew we wanted him to have both melee combat skills and powers. So it just made sense that, as he fights more and gets pushed into different situations, some of those abilities would start coming back to him almost instinctively. Kind of like Jason Bourne suddenly knowing how to fight, just much more gradual. So rather than treating memories and combat progression as two completely separate systems, they naturally started to become part of the same thing.
The story itself progresses through both the missions and his skills. If a memory or revelation made sense narratively, then we would incorporate it into the missions and the story. If it was related to combat, then it made more sense for that memory to come through his skill tree and the abilities he gradually remembers.
I never really wanted to force an idea into the game just for the sake of having another mechanic or another story moment. I like things to have a reason for being there. So if something made sense naturally within the story or gameplay, we included it. If it didn’t, we didn’t try to force it.
Gravity provides a good example of a power that had to feel useful without taking over every encounter. We were curious whether the team had changed its purpose since the earliest prototype, or spent more time refining what was already there.
Gravity actually didn’t change that much from the original prototype. The basic idea was always about manipulating enemies and the space around you rather than just being another damage type. We had things like pulling enemies toward you, slamming them, and using gravity to control groups, and that core idea stayed pretty consistent.
Most of the work was really in tuning it rather than redesigning it. We had to make sure the physics felt reliable and responsive, but also that the abilities didn’t make encounters too easy. If you can just constantly throw enemies around or keep them permanently controlled, it takes a lot of the challenge away. So it was more about adjusting things like force, range, cooldowns and which enemies could be affected in certain ways.
But overall, gravity was one of those ideas that made sense quite early and we didn’t feel a need to change it just for the sake of changing it.
When One Good Combo Becomes Too Good
Once players can pull enemies around, attack them directly and follow up with area damage, there’s a risk that one sequence will work so well that trying anything else feels pointless. We asked Chebli what testing revealed about those combinations.
Lots of testing. Every ability and combination needs to be tested thoroughly to make sure the overall experience stays balanced. Games are usually more fun when you have several viable ways to approach a situation, rather than one combination that is clearly better than everything else.
One example was combining the gravity pull-and-stab attack with a ground slam. The first move gave you strong single-target damage, and then the slam gave you high AOE damage, so together it became a very effective answer to almost every type of encounter. We had to tweak things like the damage and radius so that it stayed a strong combination without becoming something you could just spam and use to get through most of the game without much effort.
The goal wasn’t to make every ability equally strong in every situation, but to make sure different abilities and combinations had their own strengths and reasons to use them.
That led to a related concern about upgrades: a bigger number on a skill tree isn’t necessarily a more interesting decision. Chebli explains how the team tried to make different powers worth choosing, and how it handled ideas that had too little practical use.
We tried to give each power its own role rather than having them all do basically the same thing with different visual effects. Gravity was more damage-focused, the desert’s electric abilities were more about speed, Ma’azul’s abilities focused on life-steal, and the snow abilities were more spatial and control-focused.
The tricky part was then designing encounters where certain powers, or combinations of powers, made more sense than others. We didn’t want there to be one mathematically strongest option that players would just keep upgrading and using for everything. We wanted different situations to make you think about which abilities would work best, which helped keep the combat versatile and made the different powers actually feel different.
I can’t think of a specific upgrade that made it far enough into development and then had to be removed because it was too complicated or situational. Usually, if an idea felt like it would only be useful in one very specific circumstance, we would catch that fairly early and either simplify it or not pursue it. I’d rather have fewer upgrades that players actually have a reason to use than add something just to make the skill tree bigger.
Enemies had to hold up their end of that design as well. We wondered whether any one particularly effective power had forced the team to scrap an enemy outright, or whether the fixes were generally smaller.
Enemy design really followed the same philosophy as the powers themselves. Because each ability had a different role, we also had to make sure enemies and encounters gave players reasons to use those different roles.
So rather than designing enemies in isolation and then trying to fit the powers around them, we looked at how things like gravity control, speed, life-steal and spatial abilities would interact with different enemy types and groups. Some encounters might reward controlling multiple enemies, others might favor mobility or single-target damage, and others might work best when combining different powers.
I wouldn’t say we had one specific enemy that had to be completely redesigned because a power broke it. It was more of an ongoing balancing process during testing. If a certain combination made an encounter too easy or made another ability feel unnecessary, we would adjust the enemy behavior, numbers or the ability itself until there were still several viable ways to approach it.
The Problem with Building Everything Separately
The biggest difficulty wasn’t necessarily an individual enemy or an unruly physics effect. Looking back, Chebli identifies a broader assumption about production that the team had to reconsider as the connections between its systems became clearer.
One assumption we probably made early on was that we could develop the story, combat and progression as fairly separate parts of the game and then bring them together. As development went on, we realised they were much more connected than that.
That was made more complicated by the way we produced the game. We used different teams for different parts of production, so you might have one team working on combat or mechanics, another working on the world and environments, and another focused on story or other elements. On paper those can look like separate functions, but in the actual game they all have to feel like they were designed together.
A change to an ability, for example, isn’t necessarily just a combat decision. If that ability represents something Zhai is remembering, then it affects when he should learn it, what is happening in the story at that point, what the player can access in the world, and potentially how encounters are designed around it. A decision made by one team could therefore have consequences for several others.
I think one of the biggest things we learned was how important communication and coordination between those different teams became. We couldn’t really treat any one part of the game in isolation. Everyone needed to understand not just what they were producing, but how it connected to everything around it.
It definitely made development more complicated, but I also think that interconnectedness became one of ZHAI’s strengths. The progression isn’t just about becoming stronger; it’s tied to Zhai gradually rediscovering who he is, and ideally the story, world and combat all reinforce that same journey.
We can’t do anything but admire the ambition behind making Zhai’s recovered abilities matter to more than his damage output. Hearing how much work goes into keeping the combat, story and regions in step makes us even more interested in seeing whether the pieces feel as connected when we’re exploring Il’Navir ourselves. ZHAI is in development for PC and can be wishlisted on Steam or viewed on the Epic Games Store. Its release date has yet to be announced.
Leave a Reply