Hello, this is LIFUEL. We are truly sorry to greet you again with a delay announcement. As the current development progress has been delayed significantly beyond our original schedule, we would like to share our current situation with you.
In the process of development, as we tried to flesh out our initial concepts and add more content, the overall scale of the game gradually expanded. The main reason is that we found some of our early designs lacked the fun we aimed for, so we decided to invest more time into adjustments and additional development.
Although this has extended the development cycle, we hope to polish the game into a much better state. In this announcement, we would like to share how the central system of our next update—the map system—expanded in scale, and what we are currently working on.
The feature originally planned to be added to the map system was the "Backtrack" function.
The original map system was a one-way progression structure. Our design goal was clear: players needed to make judgments within limited choices, acquire rewards to continuously build their character builds, and gradually form the most suitable playstyle for themselves through repeated challenges. Therefore, our design focus at the time was not on the map itself, but rather on letting players experience the fun of different playstyles through rich build combinations.
However, as development progressed, we gradually discovered some shortcomings in this design, and from player feedback, we extracted two main issues:
Rewards are too few.
The differences between different routes are not distinct enough.
This feedback indeed pointed out deficiencies in the current system. However, simply increasing rewards or adjusting numerical values could not truly solve the problems.
For example, if we increased the number of normal battles to make the reward system richer, although it would increase resource acquisition, it would also lengthen the overall process and cause players to feel more of a burden during progression.
Right around that time, someone pitched an idea: instead of making the map one-way only, allow players to move more freely to explore and farm resources on the map. If the map could take on more of an exploration and resource planning role, players could choose routes based on their own needs, get more opportunities for growth, and create clearer differences between routes. This direction aligned very well with the experience we wanted to achieve.
However, the problem was that this proposal would completely overturn the existing level structure and overall design, making it impossible to implement directly at that development stage.
Nevertheless, we realized that the directional experience brought by this idea was extremely valuable. So, we recorded this idea and continuously pondered how to integrate it into the existing system during subsequent development. And now, we are attempting to combine this idea with the current map system to create a richer map experience that better meets players' expectations.
We were fully aware that completely scrapping the existing map system and rebuilding it was high-risk. Therefore, we conducted very cautious testing and evaluations regarding this direction.
Free Movement Map
First, we tested a scheme that allowed players to move freely on the map. However, during actual testing, we encountered several major issues:
Players re-enter previously cleared battle areas:
Respawn all enemies and repeat the same battle -> This is the simplest implementation, but easily causes fatigue.
Keep enemies in a dead state and move the player directly to the exit -> Requires additional development for related functions + re-entering the same room still consumes a movement turn + creates inefficient movement paths.
Increased map production pressure to keep up with the fast consumption of battle areas.
These were major dilemmas for us. If we referenced game designs like Risk of Rain, where difficulty gradually escalates as time or turns pass, some of these issues might be alleviated. However, the direction we wanted to achieve was not to simply add pressure, but to lower challenge difficulty through resource farming, allowing players to make choices and plan their growth.
Even if we solved the above issues, we still had to face a reality: for our current two-person development team, producing a large amount of extra explorable map content would bring immense pressure. This was no longer just a matter of "adding some workload," but something that could exceed our team's current capacity. Therefore, after evaluation, we temporarily scrapped this plan.
So we thought of creating a special mechanism: setting up "Backtrack Transports" (internally referred to as "Backdoor Transports") at specific outposts that allow players to travel backward. This way, players can choose different routes to acquire rewards they previously missed. At the same time, it lowers the game's difficulty without causing route confusion or dragging down the pacing. Players can choose to go further ahead or head back to closer areas based on their current location.
However, we quickly discovered a new problem: if "going backward" always guaranteed higher gains, there would be no reason to keep moving forward. It would no longer be a choice, but a mandatory routine for all players. To prevent this situation, we designed a new type of enemy called "Pursuers."
Pursuers are special robots created by the Wolf faction, tasked with hunting down the sheep that defeated the wolves and "messed up" their outposts. As players continue to advance through new battles, the number of Pursuers will gradually increase.
If players choose not to use Backtrack Transport and only advance straight ahead, they will likely rarely encounter them. However, if they choose to backtrack to explore previously cleared areas in order to get more rewards, battles with the Pursuers will become inevitable.
However, the intrinsic role of these Pursuers was to prevent players from acquiring rewards too easily, acting as a mechanic to "torment" players. We felt that while this role made sense conceptually... It was simply not fun at all. (Since it only serves to inconvenience the player.) We fell into a dilemma: if combat itself is fun, players have no reason not to fight; but if the combat process lacks fun, then it stops feeling like actual game content.
As this issue grew larger, we even began to doubt whether our entire design direction was flawed, and we engaged in deep discussions and reflection during the testing phase.
How can we lower the difficulty without simply tormenting the player, while allowing players to actively choose a structure of "higher risk, but maximum return if successful"?
We are currently creating an action-combat style hidden boss. It will appear when the accumulated number of Pursuers reaches a certain threshold.
Because the Pursuers themselves were designed to create pressure and torment players, this boss also features extremely threatening attack patterns.
By default, we designed it so that players cannot directly kill the Elite Pursuer, giving it absurdly high stats. Therefore, instead of making the goal "defeat it," we designed it as a survival challenge where you must "survive for a certain amount of time," which is currently in production.
During this development process, I couldn't help but recall the time when we overhauled Project Omega. If I remember correctly, that also took about 3 months. Compared to adding brand-new features, fixing and reworking existing features is definitely much more dangerous and time-consuming. Because compatibility testing needs to be conducted constantly, the time spent on testing feels just as long as the actual development time.
Therefore, when undertaking such a large-scale overhaul, we should have been more conservative with our announcement timelines. But at the time, out of impatience and eagerness to bring new content to everyone as soon as possible, we set our schedule too tightly. We are deeply sorry for this.
Since the update schedule has been pushed back multiple times, we will do our absolute best to complete it as quickly as possible. We are currently expecting to complete the update in about 2 to 3 weeks following this announcement. (We will work hard to ensure progress does not fall further behind.)
If further delays occur, we will continue to share our development progress with you, or provide updates through beta versions and other means so that you can stay informed about the current situation.
Thank you very much for your patience and support!