(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)
Hello, we are the LIFUEL development team. As we embarked on our first development project, we faced many trials and errors. Gradually, as we refined the game, we've reached a point where we can finally talk to you about it. Today, we want to share the development process of and the mistakes a beginner developer makes while creating their first game.
Background: Is Roguelike About Collecting and Unlocking?
There's an unavoidable stress inherent in the roguelike genre.
-Restart from the beginning upon death-
However, this issue is a thing of the past. Relatively recent games have largely solved these problems.

Games like Hades, Dead Cells, Dungreed, Skul, and others are truly enjoyable. They have significantly reduced the fatigue of death, making roguelike games more comfortably enjoyable
But quite some time has passed since these games were released.
Subsequent action roguelike games are becoming lighter and more 'roguelite'. Collecting predetermined synergies and acquiring resources to permanently strengthen the player is an innovative system that undoubtedly reduced game fatigue and made our hobbies more enjoyable. However, as we continued to play roguelites, we began to see persistent issues in the genre.
-We have to keep collecting because we can't clear the game until we do.-

We questioned the method of collecting synergies and character growth set by developers. The need to collect specific items implies that the game can be difficult if you don't collect them. Not fully unlocking a character's abilities can make the game challenging. We found ourselves growing tired of increasingly grinding gameplay.
We wanted to alleviate many of these problems in roguelites.

While pondering over a solution, we were greatly inspired by the organic card combinations in the deck-building roguelike "Slay the Spire". This game gave us a feeling of empowerment through our choices, even to the extent of defeating bosses in one hit. This led us to question the growth in action roguelikes.
What if action roguelikes could evolve like deck-building roguelikes... Should I try making one?
Looking back, we were quite naive. We didn't realize how risky it was to think, "What if we reinterpret deck-building and apply it to a game? Could we create a truly roguelike action game?"
Nevertheless, we started game development with bright hope, knowing nothing.
A skill-building action game where growth depends on my combinations, not predetermined synergies. That was the beginning of STAND-ALONE.
And this choice haunted us for three years.
------------
We Were Unaware of the Myriad Problems That Would Emerge
Specific Planning
Our initial planning stage was far from smooth. We didn't have a concrete idea of what to make or how to make it. We only had a feeling we wanted to convey. So, we started by creating a game that allowed for some synergy combinations based on action.
The main concept was as follows:
Skillfully combine skills to unleash incredibly explosive damage!
"In the early stages of making the game, we had these happy thoughts: 'Wouldn't it be nice if basic attacks could be customized? Wouldn't it be fun to create aerial combo skills?'
However, problems approached us very quickly.
As we developed, it became obvious that skill building was not happening at all.
Yet, not fully realizing the severity of this, we naively and simply kept adding skills one by one. In the early stages of development, we had a lot of quick slot UIs because skills had to be used frequently and in a specific order to become stronger.

But the most serious problem was that even with 10 skills, it was hard to call it deck building.
The possible combinations were insufficient with just a few skill uses. Many deck-building games can be played with as few as 5 cards, but typically they involve 20-30 cards, sometimes even more than 40. However, in an action game, it wasn't feasible to have 40 skill slots.
A more experienced developer might have thought differently, but at that time, we had this foolish thought:
'Even so, since we can customize basic attacks, couldn't it be considered deck building?'
We started developing naively. Since we had nothing, the more we created, the better it seemed, and looking at the game, we deluded ourselves into thinking, 'We are doing well.'

Our game, seemingly well-made on the surface.
Embarrassingly, this video represents our status at that time.
We had no final game size, no growth mechanism in place.
However, just the two of us managed to create this and gained tremendous confidence and hope. (The joy of creating a game for the first time is truly incredible.)
At that time, we were developing over Discord, about 200 km apart. We seriously decided to stop all other work and meet to develop together. We rented a small 5-pyeong room, and two healthy men began to develop for over 120 hours a week. (Along with cockroaches, of course.)
Certainly, the game developed faster when we worked together.
But, of course, it wasn't easy.
--------
(To be continued in the next episode)
