Hello, this is Cheese, currently developing .
In March, we focused on improving the tutorial and polishing the game overall in preparation for the second user test, which is currently underway. However, we felt that those topics alone would make this DevDiary a bit lacking. So in this entry, we would like to introduce some of the tools we either created ourselves for development convenience or are currently using, including how they were developed and how they are being used in practice.
Map Editor
features a total of three expedition themes, and for each theme, we needed to create a variety of map stamps across three difficulty levels. Even if we assume there are only 10 maps per difficulty, that still means designing 30 maps per theme, or 90 maps in total. And since that number does not include event areas or various special maps, the actual number of maps we need is much higher. Because of this, having a tool that would allow developers to create map stamps more easily was essential for this project as well.
In the early stages of development, we also considered using a random map generation system that would automatically create maps. However, after testing it, we concluded that it had clear limitations when it came to building carefully designed levels that made full use of various objects and enemies. In the end, we decided to create a new tool for this project similar to the map stamp editor we had built during the development of .
Although it may look similar to the editor from our previous title at first glance, this map editor has two major features that set it apart.
The first is a system that allows us to freely configure enemy compositions and movement routes.
We felt this feature was necessary because, in this project, we did not want every enemy encounter to automatically lead to combat. Instead, we wanted players to be able to avoid certain fights or engage enemies under more favorable conditions depending on their judgment and actions. To support that, we included functions in the map editor that let us define the routes enemies will repeatedly patrol.
The second is the random/probability system.
Because we build spaces through the map editor by hand, there is a physical limit to how many maps we can realistically create. As a result, players who revisit the game multiple times are likely to encounter maps they have already seen before. To make repeated runs feel a little different even on the same map, we introduced a random/probability system that allows different enemies or previously unseen objects to appear.
For enemies, when a predefined group is placed, one group is randomly selected from the configured set and spawned.
Objects each have their own individual spawn probability, so even when entering the same map, the set of objects a player encounters may be different.
The maps created in this way are saved according to their respective themes, and when an expedition begins, maps matching the selected theme are loaded and arranged according to the node structure.
Thanks to the map editor, we were able to save and manage a wide variety of maps more efficiently. However, creating a large number of maps still requires a considerable amount of time and effort, so in the future we hope to further improve this tool by combining it with the early automated map generation system.
Data Analytics System
In our previous title, , we used Unity Analytics as our data analytics system.
However, compared to the amount and variety of data we wanted to collect, the structure of Unity Analytics was somewhat too simple, and in the end, it was difficult to see it as a tool that truly fit our game. Because of this, we decided that it would be more suitable to build a new analytics system ourselves for this project.
Our newly built system now follows the process shown in the image above, with data being stored through Google Cloud. The collected data is organized and managed by the categories we need, and we have also prepared SQL queries for each item so that we can easily retrieve the data we want at any time.
Going forward, we plan to use this data in a variety of ways, such as analyzing user playtest and demo play records to understand character usage rates and overall gameplay progression.
AI Localization System
Localization may not be the most enjoyable part of development, but we believe it is a challenge that must be addressed. Many people would agree that supporting more languages improves accessibility in the Steam market. However, supporting a wide range of languages requires a significant amount of work, and ensuring the quality of each language takes even more time and effort.
While thinking about ways to reduce that burden, we came across a session at last year’s Unite Seoul where the developer of explained that they had introduced their own AI translation system, allowing them to handle multilingual support even with a small team. At the time, we thought it would be worthwhile to research similar approaches for our next project and see whether we could apply related technology to our own team as well.
After that, we reached out to the speaker directly to learn more about the method they had actually developed and to see whether it could be combined with the translation system we were already using. However, because there were major differences between our translation workflows and development environments, we needed to look for another approach. While reviewing other options, we found that the Google Sheets workflow we were already using could be extended quite easily with Apps Script and the Gemini API. So we decided to build on that approach.
As a result, we were able to add a feature to our existing Google Sheets setup almost like an extension tool, allowing us to select either Korean or English as the source text and automatically generate translations for each language column. This feature is still in the testing stage, but we expect it to be a great help for our localization work going forward.
Closing
With tools like these, we were able to significantly reduce the time required for tasks that would otherwise have taken much more effort to handle individually. We plan to continue building and refining various tools to further improve our development efficiency.
This coming May, we will be attending PlayX4, where we will be presenting our offline build to players for the first time.
Our second user test is currently live on Steam and will run until this Sunday, April 5 (UTC+9). If you are interested, we would greatly appreciate your participation and feedback, as it would be a huge help to the development of the game.
That concludes this DevDiary.
Thank you for reading.