(This content was written by me using translation tools as I study English. Therefore, there may be mistranslations, and I would appreciate it if you could read the original in Korean if you wish)
Introduction
Hello, we are the development team LIFUEL. Another year has passed, and it's now 2023. We are always focused on development. The reason we have been able to develop tirelessly over such a long period is, we believe, due to your genuine feedback. We are always grateful for it.
We always take your feedback seriously. However, it might be difficult for you to know how attentively we listen and whether we are applying it correctly. This makes us think that we should be more diligent in writing our development diaries, but it's quite challenging to do so while also managing updates. Although our development diary has been delayed, we have been actively gathering past materials to write even a little. Even if it's late, we will continue to work steadily.
Happy New Year, and we wish you all the best.
--------
Read Previous Post
Emerging Challenges
In an effort not to create an action roguelike that revolves around collecting and nurturing predetermined synergies...
Two developers, fueled solely by passion and working 120 hours a week, rapidly progress in their game development.
They immediately address minor issues and focus all their efforts on game development.
However, developing without a proper plan led to encountering major problems that sometimes slowed down the development.
The first issue was skill-building with a limited number of keys.
1. Skill Building Like Deck Building
We decided to limit the skill keys to four, considering controller support. We planned to use A, S, D, F as LB, LT, RB, RT later.
However, we started doubting whether it was possible to create a deck-building experience with just these four keys and basic attacks. Deck building usually involves dozens of cards, but we had only a few.
Thus, we decided to create a chain system for scalability.
Chain System: Using a skill with a key and then pressing the same key to use a new skill attached to it.
We specifically thought of it as follows:
1. Passive
Passives are enhancement parts dependent
on skills. Usually, when you enhance a skill, you get a predetermined option or a random feature from a certain table. However, we set our enhancement parts to be common across all skills.
1. Active
This is the chain system I mentioned earlier. The difference is that these active skills are also common across all skills. An interesting feature is that actives are affected by all passives.
For example, if you have four passives equipped on Skill 1 and use Active A, Active A will be executed with the effects of all four passives. (This system is still in place.)
(The graphics were crude at that time, as shown above.)
Now, we have enabled continuous attacks by equipping subsequent skills in the form of "parts" to each skill.
Having only four skill keys no longer meant being limited to four skills. Finding and combining suitable parts allowed for skill customization. This was the birth of the prototype of STAND-ALONE.
Of course, developing without a proper plan brought many big and small problems. There were no set rules for how skills and parts relate, how many parts can be equipped to a skill, how they are acquired, and how the UI is provided.
We just kept developing and fixing things at an overwhelming pace, constantly iterating without rest.
The second major planning issue we faced was customizing the basic attack.
2. Customizing Basic Attacks
We decided to enable customization of basic attacks for the following reason:
To expand the system for skill deck building with a limited number of input keys.
Lower left UI: Skills / Lower right UI: Basic Attacks
We designed the structure to allow even basic skills to be customizable. We thought it would be interesting if players could remove unnecessary motions from basic attacks and configure them for optimal efficiency.
This led to the development of the following system:
All skills can be inserted into basic attacks.
At that time, we thought the idea of was revolutionary.
And it was indeed very exciting. We began to enjoy combos by modifying basic attacks as we desired.
However, problems arose immediately when tested by the public.
At that time, a user named Lee**an reported the video above.
The issue arose for the following reasons:
There is no cooldown on basic attacks.
Therefore, if a skill with a long cooldown and high power is inserted into the basic attack, it can be executed infinitely.
We were somewhat aware that this problem might occur, so we planned to make overly powerful skills unavailable for customization.
We then began to look for the fundamental cause to solve this issue.
However, the problem started to become more complex. If certain skills are not available for customization, we need to clearly provide information on why they are unavailable and which skills are affected. Moreover, many issues began to surface, such as whether the deck-building aspect would still be enjoyable with such restrictive development.
The problems kept emerging, and we realized that there was an issue with the overall structure of the game.
"We were just developing to solve problems!"
It took us a year to realize this, and another year to find a solution to these problems.
Finding the Solution to the Problem
At this point, we began to plan something that could integrate all the issues we had encountered so far, including offering a unique experience to the user. This might have been our first real, well-thought-out plan, not just an idea.
UIUX
First, we needed to create a UIUX that could solve all the ideas that had piled up so far.
The existing UI UX was implemented as a simple but terrible table array with editing features. At that time, we were so engrossed in coming up with ideas for the game and concurrently running a membership program called SGM that we overlooked the importance of UIUX.
This issue had so many problems that it was evident without needing much explanation. To summarize a few key points:
There were too many tables, making cursor movement inconvenient.
It was unclear what the parts were.
The concept of modifying skills was difficult to grasp.
Even if the concept of modification was understood, it was unclear what the difference was.
And so on.
The state of the game had so many significant issues that it was hard
to determine whether the game was unique or not. It was disheartening to realize that even after a year of development, the prototype did not adequately convey the game's intent.
Nevertheless, we humbly accepted and acknowledged these issues. We strived to fix the problems immediately and sought extensive feedback. Our goal was not to create a perfect and beautiful UIUX but to provide a comfortable and functional one.
(We had not anticipated that it would take over two years, though.)
------
(To be continued in the next episode)