This post is a free part of what was posted on the Japanese creator support site “Ci-en”.

Progress Report

　 　Now we have developed of the new project. 　When we started production, I mentioned that we were aiming to complete it within 2 to 3 months. However, it’s been about 2 and a half months since the start of production. It seems impossible to complete it within this month, so we are now aiming for completion in approximately 4 months.

System Expansion

　Although the production progress is slow, it’s steadily moving forward, and we are currently focusing on building the game system. Here are the systems that have been newly created since the last report.

Producing Units

　New units are produced by crossbreeding existing units. In other words, they mate and give birth. 　Female individuals can become mothers, and hermaphrodite individuals can be both mothers and sperm providers. There are no males in this game. 　Once they become pregnant, they cannot go to the battlefield until they give birth. Deciding how many units to send to the battlefield or to allocate for new unit production will be an important strategic consideration in this game.

Construction

　You can consume resources to set up barricades on the battlefield. However, to set them up, you need to allocate construction personnel and it takes time. Naturally, this reduces the number of units available to attack the enemy. However, if multiple units work together, they can complete the construction more quickly. In the image, three units are building one barricade. 　Also, if you construct buildings at the front lines, they may be attacked by enemies while under construction. There’s a risk that the barricade itself may be destroyed. In general, these are set up to build defensive lines slightly behind the front lines.

Drawing the Range of Movement

　When selecting units deployed on the battlefield, their attack range was previously displayed as a filled square. Now, in addition to that, the range of movement is displayed as lines. 　In reality, the game engine we use, Wolf RPG Editor, doesn’t have the functionality to draw polygons or their outlines, which made this challenging. While displaying the range of movement is essential for the game system, it wasn’t necessary to do it with these timing. However, I was determined to make this happen due to my technical curiosity. As a result, this feature was created. 　But it’s not perfect; there are sometimes gaps in the lines. I realized that I need to continue improving technically.

Sorting the Unit List

　This is a sorting feature for the unit list based on multiple criteria, which was also present in Continent of Slaughter. However, it’s more user-friendly, with the ability to save and replicate sorting criteria. The idea of implementing this feature existed during the development of Continent of Slaughter, but we couldn’t manage to do it at that time.

Personal Thoughts

　While creating the sorting feature, I was filled with indescribable impatience. Certainly, in creating this type of game, sorting is a desired feature, and I thought it must be implemented before release. 　However, this is a matter of interface comfort and isn’t an essential part of the gameplay system. Furthermore, this feature has no direct impact on the game’s fun (though, without it, players might feel significant discomfort, making it indeed a desired feature). 　In reality, what I truly wanted to create at that time wasn’t this but the enemy unit placement and behavior algorithms. 　About player unit placement, as long as the interface is available, players thierselvs will puzzle and think how to do it. However, it’s not the case for the enemy side. Developers need to program that. Of course, we can’t predict for sure what units the opponent (the player) will have or what configuration he or her will use at any given time. So, some anticipation and preparation to respond to certain situations are needed. 　This is why the sorting feature becomes necessary. 　For instance, when the enemy is approaching with superior numbers and great force, all units should be sent to the battlefield to stop the invasion. However, in less critical situations, units with moderately depleted HP should be rested, and this feature allows you to decide who should be sent out relatively easily based on the order of their HP. 　In practice, as units and military branches have different attack ranges, attack power, and defense, it’s necessary to think about where to place each unit based on those factors. This sorting feature is essential not only for players but also for developers. That’s why we had to create it before developing the enemy behavior algorithms.

　Therefore, the sorting feature had to be created inevitably before setting up the enemy behavior algorithms. However, in that case, it was enough to create just internal programs, not a player-facing system with a user-friendly interface as mentioned above.

▲ Reiterated image. This can be operated using the keyboard during gameplay. This system could be created in a relatively short amount of time, but generally creating a user-operable interface, as described above, takes a fair amount of time.

　I created this for two main reasons: it’s something that will eventually need to be created, and it’s also to verify that the sorting program I’ve created functions correctly. 　Originally, operations related to variables and databases are internal matters, and you can never truly understand what’s going on inside without issuing commands to the computer to display it. For example, suppose you write a program to add 1 to variable X. You probably assumes that X’s value is 1, but you won’t know for sure until you deliberately instruct the computer to display X’s value on the screen. In reality, X’s value may have been changed elsewhere, and it might already be 3 at the time of the calculation. There’s also a possibility that you intended to add 1 to variable X, but you mistakenly wrote a program that subtracts from it. Therefore, programs aren’t something you create and then forget about; you need to test whether they work correctly. In this case, it’s essential to display items based on the specified criteria and check if any items disappear in the process.

▲ This is the screen the developer is working with. It’s not something that can be understood and operated by players, and even the developer doesn’t understand everything.

　However, for testing, you need data in the form of a list (database). A database with nothing in it, or one where everything is 0, can’t be sorted. But here, we have the ideal database. The unit list is already created, and the functionality for adding and removing units and displaying them is complete. 　Of course, it’s possible to prepare a test database and the functionality to display it, but these are only useful for testing, making it a genuinely wasteful effort. So, I thought it would be better to complete the construction of the player-facing system that would eventually need to be created and do it at this point. It’s like hitting two birds with one stone.

　When explained like this, it seems like a very rational sequence of production. Indeed, I think it’s a suitable progression (though the progress of “Drawing the Range of Movement,” as mentioned above, might have been somewhat unsuitable). However, at the time of creation, because it was a detour from what I really wanted to do, as explained above, I was filled with impatience. 　In game development, you often have to take these detours and frequently feel frustrated and impatient. But these are the pains of creation, and they must be overcome. 　Please look forward to future progress.