[システム]先行入力について[Systems]About Prior Entry
Steamにて配信中の2D忍者アクションシューティングゲーム「Shinobi non grata」の仕様書（と言っていいか微妙ですが）となります。
この資料は飽くまでも初稿であり、最終的に実装された内容と異なる部分も多々あります。製品版を遊んで頂いて、どこがそのままの形で実現し、どこが変更されたかをご確認頂いても良いかもしれません（と、シレっと宣伝）。
https://store.steampowered.com/app/1796870/SHINOBI_NON_GRATA/
また、このタイトルはフルリモート環境で、１年２ヶ月で完成した実績（準備段階含めるともう少し掛かっていますが）があるため、遠隔でゲーム開発するための参考になるかもしれません。
This is the specifications (if you can call it that) for "Shinobi non grata", a 2D ninja action shooting game available on Steam.
This document is a first draft, and there are many differences from the final version. You may play the full version of the game to see what has been realized in its original form and what has been changed (casual advertising).
https://store.steampowered.com/app/1796870/SHINOBI_NON_GRATA/
Also, this title was completed in a full remote environment in one year and two months (although it took a little longer if you include the preparation phase), so it may serve as a reference for developing games remotely.
今回は、操作性に関わる部分で、結構やりとりを重ねた部分についての解説です。問題点の提起から、実際の対処に至るまで、リモート会議なども通じて作り込んでいきました。そのため資料に対して、具体的なゴール地点、PG的な手法の提案などの添削が入りました（感謝です！）。
今回の資料では、ゲームデザイナーとエンジニアとの、チューニングに関わる諸々についてのやりとりの一例として、添削後の資料を紹介いたします（追記はフライハイワークス社長によるものです）。
＊文字資料以外にリモート会議の中でエンジニアと協議しつつ進めた部分が多いので、資料のみでは不十分であることをお詫びいたします。
In this issue, I would like to explain the part of the process that involved a great deal of back and forth regarding operability. From the initial problem to the actual solution, we worked on it through remote meetings and so on. As a result, we received corrections to the documents, including specific goal points and suggestions for PG-like methods (thank you!).
In this document, we present an example of the communication between a game designer and an engineer regarding various aspects of tuning, after the correction (The postscript is by the President of Fly High Works on the specific subject method).
*We apologize that the documents alone are insufficient, as there are many parts of the project that were discussed with the engineers during the remote meetings in addition to the text documents.
Although the preceding input and cancellation are also measures to enhance the operability of the machine, their applications and mechanisms are different. The following is an explanation of why they are necessary, the current problems, and countermeasures.
First, sword attacks are currently cancelable, allowing continuous sword attacks. This improves the ability to fire in rapid succession, but it also invalidates operations up to the effective cancellation frame, so intuitively pressing the buttons quickly often results in many invalid button presses.
The next problem is that even if you want to avoid an enemy's attack right after you draw your sword, you cannot take evasive action until the "cancelable frame" when you put your sword away. This means that you often get hit by a counterattacking enemy and then have to make a "change" to the next action until you put your sword away. This makes the game feel very difficult to control. This is one of the main reasons for the poor operability of the game.
If you try playing Ninja Gaiden, you will see that in that game, you can cancel an action by jumping or other means immediately after swinging your sword (when you have your sword out in the picture). Similarly, in this game, I would like to make it possible to cancel an action by a specific action.
Advance Input
Preceding input is a technique that exists in all Smash Bros. series where a command can be entered during or before another action, taking advantage of the wide range of time available for command input. There are many actions that cannot be inputted ahead of time. If the preceding input is prepared, the action will be executed at the same time as the action is completed. This is very useful when you want to perform an action quickly, because there is no loss of time for the command input.
*In the case of Shinogura, it is better to say "at the end of the action" or "when the cancel frame is reached.
Cancel
In action games, a specific command action interrupts an unnecessary motion of the controlled character (that would be disadvantageous due to an opening) and switches to another useful motion to continue a combo, or, conversely, intentionally ends a combo and cuts off the next motion (that is not necessary). In the case of sinogura, it means to switch to a different motion to continue a combo.
*In the case of sinogura, it is used to perform an immediate evasive action (forward roll or jump) rather than to attack.
The most obvious example of "cancel" is Ninja Gaiden (available on Nintendo Switch Online).
In that game, if you press and hold the right button, the player will stand still and attack (i.e., you cannot cancel the attack with a walk motion), but if you press the jump button, which you do immediately after the attack, the player will go into a jump.
In any case,
The worst thing that can happen to a game's control system is
The worst thing that can happen to a game control system is that a button is pressed (or is supposed to be pressed) but no action is taken.
The current specifications are such that this happens frequently.
For attacks, we would like to store the button input before the cancellation frame as a preceding input, and then execute the result of the preceding input when the cancellation frame is reached.The best way to implement the program I can think of is,
To explain the mechanism of the "preceding input method" in the figure above, button inputs executed between frames 10 and 14 are temporarily stored, and when frame 15 (the cancel frame) is reached, the result of the preceding button input is executed again. In this case, we would like to record only one input at a time during one action.
If a button is pressed 5 times between 10 and 14 frames, it will be pressed 5 times later as a result of the preceding input.
Instead of jumping as soon as the button is pressed once,
Set the variable ATTACK_REQUEST_STOCK to +1.
Then, when the program runs to the point where it detects the action, if this variable is greater than 1, it will consume 1 (i.e., minus 1).
In addition, this variable is only added up to a maximum of 1.
This should solve the problem of prior input.
(And it will not cause the weird thing that if you press three times during one motion, it will attack three times.)
Although the diagram on the left depicts setting a "period for accepting prior input," there should be no need to set such a period in practice.
The next step is to implement a mechanism to immediately transition to an evasive action (forward roll or jump) when a player wants to avoid enemy bullets immediately after using a sword or subweapon.
As shown in the figure above, this mechanism is independent of the cancellation frame that has already been set (this cancellation frame is necessary; without it, the attack will hit at the fastest possible time). Without it, the attack will be executed at the fastest possible timing), the attack action is canceled and the transition to the next action is performed immediately by rolling forward, jumping, etc.
First of all, what is the cause of this problem?
In the main character's state transition diagram, ESCAPE and JUMP can only transition from "STAND_NORMAL (normal standing state)".
ESCAPE and JUMP can only be transitioned from "STAND_NORMAL (normal standing state)",
If we can enable these transitions, the cancellation should be enabled first.
Then, I think it would be better to set a "cancel enable frame".
For example, if the effective cancellation frame is set to "5," it means that cancellation is possible after 5 frames from the start of ATTACK.
(I think the diagram on the left is a little confusing. In the left diagram, the yellow "cancel valid frame" should point to the 7 position, otherwise it is not correct.)
By the way, I personally think that "1" should be the effective cancellation frame. (If you try it and it is wrong, you can adjust it.
For a single action, we need
We believe that we can solve the problem of operability by providing the following three types of cancellation frames for each action:
・Cancellation frame for normal actions
・Preceding input acceptance period (since there are many actions that do not require preceding input, we can set whether or not preceding input is required)
・Cancellation frame that allows only certain actions such as evasive action.
Finally, here is a summary of the actual action transitions and how they are connected.
Leading input method:
Sword attack → Subweapon
Subweapon → Sword attack
*Since the cannon is an attack with a large gap, the preceding input and cancellation frames may need to be adjusted in detail.
Cancel Method
Sword → Jump Sword → Forward
Subweapon→Jump Subweapon→Forward roll
*Crouching has already been modified and will not be included in the list.
Canceling a standing attack with a crouching attack and then immediately after the crouching attack, canceling with a standing attack.... It would be too strong....
It would be easy to imagine canceling a "away from body" type weapon such as a shuriken by jumping (e.g. Mega Man), but there are some weapons such as a chain scythe that have a large pictorial change when canceled (the chain scythe disappears in an instant), This is acceptable.