Posted November 30, 2023 by D'sProduction
#strategy #black_girl #intersex #Game #NSFW #big_breasts
This post is a free part of what was posted on the Japanese creator support site “Ci-en”. If you want to see the latest production progress on the paid part, visit Ci-en.
For a long time, the title of the work had not been determined and was simply referred to as “New Work.” However, we have recently decided to name it “Forest Invader Shinnemia.” “Shinnemia” is the name of the protagonist.
This month, our efforts have been primarily focused on enhancing the system and balancing. At the time of the last article posted, we had created a system where enemies place units, marking the completion of the foundational game system. However, merely having this system does not make it a playable game.
The initial units for both sides, the cost of producing new units, and the rate of resource increase—all these numerical settings significantly influence the subsequent developments. Determining these settings is crucial and must be based on the overall design of at what stage of the game and to what difficulty level it should be set.
▲Turn-by-turn battle report. This is only a result, but various numerical values must be set in advance, anticipating the desired outcome.
In a difficulty where players would quickly face defeat without employing various techniques from the beginning, only the most courageous players would continue, while an absolute ease leading to no chance of losing would result in quick boredom, causing many players to quit midway. A delicate balance of being moderately easy and moderately difficult is required. It’s highly idealistic, but worth the challenge—and a challenge that must be undertaken at any time. At present, it seems to have achieved a reasonably balanced state.
Although it is still far from completion, I will distribute the current game data at this stage through the support plan of Ci-en.
For a long time, I did not have a game controller for the computer, so I had not made any settings for my game (basic operations are possible due to the specifications of Wolf RPG Editor). But recently, when I started using it, I realized that I could play comfortably. — Or rather, when playing for a long time with a keyboard, my hands would start to hurt, but that doesn’t seem to happen with a controller.
Therefore, in future self-made games, I plan to set them up so that they can be played on controllers as comfortably as on keyboards. At the same time, I have decided to implement the “Key Config” function that I had been considering for a long time but had not yet implemented.
This is because there is a possibility that the button layout of the controller used by the author is different from that of the players, and there is a risk that keys will be assigned to very inconvenient buttons. Even if that’s not the case, the key/button configuration set by the author may not be user-friendly for the player. In D’s Production works, with a user-friendly perspective, we try to provide as many shortcut keys as possible to remove the burden on the player in terms of operation. This attempt is ambitious and good, but even if there are shortcut keys, their value is halved if the operation is difficult.
For example, in RPG Maker games, Q/W are often used for item switching. However, since many players naturally position their fingers around the Z key, it can be inconvenient as they have to stretch their fingers.
On the other hand, in D’s Production works, the W key is used for skipping events. If pressed, events can be skipped with a single touch, making it prone to accidental operation. Therefore, preventing this is crucial. To achieve that, the button should be placed farther away.Certainly, the specification of “skipping events with a single touch” itself requires careful consideration, so there seems to be a need for improvement in the future.
In any case, if players can determine their own key configurations, these problems can be avoided without troubling the author’s mind.
Additionally, there is a risk that keys may be assigned to non-existent buttons depending on the controller used. By actually detecting the player’s controller input and assigning the buttons accordingly, this worst-case scenario can be prevented, I believe.
Although the conversation is a bit out of order, I am considering making a relatively large update to the past work “Continent of Slaughter” in the near future. I am proud that “Continent of Slaughter” is an ambitious work with plenty of play value, but on the other hand, it is quite clumsy in balance adjustment, and there is a tendency for repetitive tasks, especially in the later stages.
Therefore, I tentatively introduced controller support and key configuration functionality in “Continent of Slaughter.” So far, it’s working quite well. I also plan to incorporate similar features into the new work “Forest Invader Shinnemia,” and “Queen of Massacre.”
▲Key/Button Config Screen.
▲The displayed operation guide on the screen changes according to the set keys and controller buttons.
On the other hand, since I am only experimenting with the controller I have, I am not confident about how it will behave with other controllers or whether it will function at all, and this point is deeply concerning.
Maybe in the near future, I will recruit collaborators or test players.
In the paid article of Ci-en, you can see the latest game data and images under production.