最小限のスキルを開く
プライベートサーバーのビルダーツールに入り、現在の Moveset、Awakening、Special、Character のブロックフローから Skill Builder を探します。システムの進化に合わせてラベルは移動するため、ライブのメニュー階層を確認してください。唯一の動作中 moveset を編集せず、新しいテストスキルから始めます。
近距離 starter、movement tool、extender、defense、finisher のように、名前と目的を明確にします。すべての目的に使えるよう設計したスキルは、バランス調整も相手からの読み取りも難しくなります。
最初のタイムラインを作る
コミュニティの記録では、animation、wait、hitbox、sound、velocity、property、condition などがタイムラインの構成要素として示されています。animation、意図した短い wait、1つの hitbox、視覚または音による feedback、recovery から始めます。追加するたびに preview してください。
順番はプレイヤーに見える流れと一致させます。telegraph が始まり、hitbox が有効になり、contact feedback が起き、その後 recovery で操作が戻ります。見える動作が対象に届く前に damage が発生するなら timing を直します。active window が終わっても effect が長く続くと、相手はその技を学習できません。
最初の version は簡素に保ちます。余分な effect があると、元の hit と移動が動いているか分からなくなることがあります。
公平な hitbox の形を作る
animation が伝える力の位置に hitbox を置きます。近距離、端、上下、背後の位置をテストします。スキルがプレイヤーと一緒に向きを変えるのか、方向を固定するのか、移動を追うのかを決め、その挙動を制御するライブの property を確認してください。
大きすぎる見えない volume はテストを楽にしても、不誠実なプレイを生みます。ゲーム内ツールが debug view を提供している場合だけ一時的に使い、最終攻撃は animation と effect で読み取れるようにします。
block、miss、interruption、ragdoll、壁、複数の target をテストします。予想外の hit がどの state で発生したかを正確に記録してください。
Conditions と properties
基本の timeline が安定してから conditions を追加します。condition は hit の成功、player state、awakening、charge、direction、または別の作成者定義の分岐を参照できます。まず1つの branch を作り、true と false の両方をテストしてから次を加えます。
movement、stun、knockback、cooldown、resource の挙動などの properties は、スキルの役割を支えるようにします。値は1つずつ変更してください。reach を広げるときに speed も上げて recovery も短くすると、どの変更が counterplay を壊したのか分からなくなります。
変わったルールは Workshop の説明に書き、プレイヤーが意図した挙動を理解できるようにします。
Feedback と performance
sound と visual effect で startup、active contact、finish を伝えます。effect を増やせば自動的に分かりやすくなるわけではありません。画面全体の flash、残り続ける particle、他プレイヤーの判断を隠す重なった sound は避けてください。
控えめなデバイスとグループでテストします。複数のプレイヤーがスキルを使うと、繰り返しイベントが負荷を増幅することがあります。隠れた、または重複した effect を取り除きます。interruption の後に付属オブジェクト、sound、hitbox が片付くかも確認してください。
Roblox の asset と audio のルールを守ります。使用許可のないコンテンツを import しないでください。
テストマトリクス
hit、miss、block、interruption、death / reset、wall、slope、airborne target、multiple target、high latency、repeated use の条件でスキルを動かします。保存した item を新しいサーバーに読み込んだ後もテストしてください。authoring preview でしか動かない timeline は未完成です。
相手が脅威を理解できるか、強い effect の前に対応できるか、雑な miss を punish できるかを尋ねます。使用者がスキルに失敗した理由を理解できるかも確認します。damage を増やす前に分かりやすさを直してください。
意味のある変更ごとに version を作り、最後の安定版を保管します。
キットに組み込む
スキル単体のテストに合格したら、custom moveset の他の技すべてと組み合わせます。意図しない loop、cooldown の重複したカバー、避けられない stun、マップの bounds を無視する移動がないかを探します。完成したキットの中では、スキルに別の recovery が必要になることがあります。
役割を補い合うように割り当てる方法は Custom Movesets ガイドで、安全な共有方法は Workshop ガイドで確認できます。Jujutsu Shenanigans のビルダーが大きく更新されたら、duplicate を再読み込みし、安定版を上書きして公開する前にテストマトリクスを繰り返します。
失敗を1つずつデバッグする
preview が失敗したらスキルを duplicate し、予想外の地点より後ろにあるイベントを取り除きます。animation が始まったか、wait が完了したか、hitbox が現れたか、condition が予想した branch を選んだか、cleanup が実行されたかを確認します。その後のイベントを1つずつ戻してください。複数の property を変えて、いつの間にか不具合が消えたようにするより速く、原因も分かります。
問題を再現する最小の sequence、期待する結果、live での結果、サーバーの日付、reload で変化するかを記録します。wall、interruption、multiple target のときだけ起きるなら、その condition をレポートに残してください。デバッグ中も動作している元の version は変更しません。最小再現手順があれば、自分自身にも作成ツールの保守担当にも実際の不具合が伝わります。