ご確認中であり、既存のセットアップを維持したまま機能する解決策や回避策を検討しています。オブジェクトの設定が非常に役立ちました。アニメーションや複数のセーブポイントが互いに干渉し合うなど、考慮すべき要素が多数あるためです。何か機能するものが見つかり次第、こちらで返信いたします。私の目標は、すべてのセーブポイントに1つのオブジェクトを使用でき、セーブポイントがトリガーされた際にそれらがすべて自身を適切にクリーンアップできるシステムを提供することです。もちろん、現在のロジックを尊重します（若干の再構成は行われる可能性があります）。
「いいね！」 1
保存が破損する件について、baz 様にお伺いしたいのですが、現在制作チーム側で原因を調査する動きはあるのでしょうか。現在、いくつかの重大なバグに頭を悩まされているのもその一つです 
こんにちは、S.Cさん！
この件について作業を進めており、試していただけるモジュールを作成しました。これは以前お話していたシステムで、1つのオブジェクトがすべてのセーブポイントを管理し、セーブポイントがトリガーされると自身をクリーンアップする仕組みです。
まず、セーブポイントAとセーブポイントBを別々に設定していた理由が少しわからなかったため、調整を加えてセーブポイント1つで動作するようにしました。問題ないでしょうか？ セーブポイントAを取得し、そこにChangeActionを追加して、いくつかの構成を整理しました。詳細はモジュールをご覧ください。
モジュールのインストールと使用方法は以下の通りです：
- モジュールをダウンロードします。revamped_save_a.tres (9.8 KB)
- 「モジュールリスト」ウィンドウを開きます。出力デバッガーウィンドウの近くにあります。
- フォルダアイコンをクリックし、「ファイルマネージャーで自分のモジュール場所を開く」をクリックします。
- ダウンロードしたモジュールをそのフォルダに配置します。
- AGMakerに戻り、「モジュールリストをリロード」をクリック（フォルダアイコンのすぐ隣）して更新します。
- 更新された「Revamped Save A」が表示されます。これをセーブポイントAのビジュアルスクリプトにドラッグ＆ドロップします。
- 内部にある古いステートを削除します。
- 初期ステートを正しいものに設定します。時々混同されることがあるので、必ず再確認してください。
次に、ゲームシーン2に移動し、ろうそくの間隔を少し広げてください。近すぎると同時にセーブされてしまい、ロジックの問題が発生します。これはオブジェクトの距離が25に設定されていることによる制限です。おそらく実際にそこまで近づけて配置することはないと思いますが、念のため少し間隔を開けてください。
AとBの両方を動作させるのはより技術的な作業になります。ChangeActionを使用し、すべてをAに設定すれば非常に良く動作します。しかし、BとAの両方がある場合、AがBをそのステートに切り替える前にアクティブになってしまいます。そのため、セーブポイント1つで済むのであれば、そちらの方が良いと思います。これはこれらのアクションと条件の動作原理によるものです。
これをテストして、結果をお知らせください。どうしてもセーブポイントAとセーブポイントBの両方が必要な場合は、なぜ2つ必要なのかを教えていただければ、アプローチを再考します。
bazさん、返信ありがとうございます。AとBの2つのセーブポイントを使用する主な理由は、ろうそくに戻るアニメーションの途切れを防ぐためです。
ご覧の通り、私のレベルでは同じ画面内に2つのセーブポイントが表示される可能性があります。ここで1つ目のセーブを行う際、もう一方も同時にアニメーションの変化に従って動くのは非常に奇妙に見えます。そのため、最終的にAとBを採用し、同じカメラ内にあってもそれぞれのアニメーションを独立して演出できるようにしました。
このようなものであれば、より受け入れられるでしょうか？
動画が無効になっているようで表示できませんが、英語モードに切り替えると見られます。
ゲーム内のすべてのアニメーションフレームは私が描いたもので、ゲーム全体のアニメーション演出をより滑らかにしたいと考えています。もしカクつきやフレームの欠落が発生すれば、クリエイターとして受け入れがたいです 
視覚的な仕様の改良を続け、改めてご連絡いたします。
本当に本当にありがとうございます！
AとBが同時に存在することで保存に失敗する問題については、開発チームによってエンジン内で修正できないことが確認済みでしょうか？
この難関を乗り越えるためには、別の方法を考えなければならないのでしょうか？
その不具合ではなく、ビジュアルスクリプトやデザイン設定の問題です。参考までに、セーブ/ロードを滑らかで洗練されたものに感じさせることは、最も難しいタスクの一つであり、PGM でも同様でした。セーブ/ロードシステムはあえてシンプルで信頼性が高く設計されています。実際の作業は、それに見合ったビジュアルを施すこと（例えば、一度に一点しか点灯しないようにする、リトラクトアニメーションが繰り返されないようにする、といったことです）です。
一つのデザイン上の解決策は、同じビューポート内で複数のセーブポイントが見えないようにレベルを配置することです。それが最も簡単で迅速な方法です。
これはかなり良さそうですね。bazさんの最適化に感謝します。まだそのロジックは完全に理解できていませんが、一度エンジニアに渡して調査してもらおうと思います！
昨日、これはバグではないと指摘されてから、セーブ失敗の問題を解決するより簡単な方法を思いつきました。AとBの保存処理を変数スイッチに置き換えるというものです。シーンに空のオブジェクトをもう一つ追加し、スイッチがオンになったときに保存をトリガーするようにします。こうすれば、ゲーム全体でセーブオブジェクトを1つにまとめることも可能です
あー、もう解決してたんだね。このバージョンでよければ教えてね。そうじゃなかったら、次の作業に進むよ。
このバージョンのファイルを必ず送ってください。個別のオブジェクトがアニメーションで非同期に動作する実装方法がわからず、非常に素晴らしいので勉強したいです！
セットアップ（セーブポイントAの順序で）
-
スクリプトを追加する。 セーブポイントAで、子ノードを追加し、
save_point_driver.gdをアタッチします。
save_point_driver.gd (16.5 KB) -
スイッチを追加する。 スイッチ設定で、以下の3つを追加します。名前はスクリプトと一致させる必要があります。異なる名前にしたい場合は、両方で名前を変更してください。
-
モジュールを配置する。 ビジュアルスクリプトを開き、セーブポイントモジュールをドラッグして配置します。AGMaker がこれをグループ化し、ノードIDを再番号付けしますが、これは正常です。すべての状態と接続が自動的に構築されます。custom_save_method.tres (5.9 KB)
-
モジュールが破損しているか欠落している場合、以下の「ロジック」セクションを使用して手動でステートマシンを構築してください。
-
セーブポイントAのオブジェクトを配置する。 プレイヤーがセーブできる場所に配置します。
-
すべてのセーブポイントBを削除し、セーブポイントAに置き換える。 完了です。
スイッチ
| 名前 | セーブ可能 | 理由 |
|---|---|---|
request_save |
OFF | 一度限りの「今すぐセーブ」シグナル。セーブ可能だと、ファイルに true が保存され、ロードのたびに再発火するため、ループが発生します。 |
request_load |
OFF | ロードについても同様です。 |
current_save_point |
ON | ロード後にどのポイントがアクティブだったかをゲームが記憶する必要があります。 |
ビジュアルスクリプトのロジック
両側の通信方法:
- スクリプトがプレイヤーがセーブしたときに
request_saveを ON にすると、ビジュアルスクリプトが「セーブ」を実行し、再び OFF にします。 - スクリプトがロード後（アクティブなポイントでのみ）に
request_loadを ON にすると、ビジュアルスクリプトが「ロード」を実行し、再び OFF にします。 current_save_pointはスクリプトのみの担当です。ビジュアルスクリプトは無視します。
4つの状態と「Any State」があります。開始状態: wait。 wait 自体は何も実行しませんが、2つのスイッチを監視します。
セーブ: wait → on save setup → save → wait
- wait → on save setup —
request_saveが ON になったとき（スイッチ変数変更、request_saveを監視）。 - on save setup を実行: 音声再生（セーブ音） ·
request_save = falseに設定 · プレイヤーのHPを回復（ターゲット = P1）。 - on save setup → save — 自動、条件なし。
- save を実行: ゲームデータのセーブ。
- save → wait — 自動。
ロード: wait → on load → wait
- wait → on load —
request_loadが ON になったとき（スイッチ変数変更、request_loadを監視）。 - on load を実行: アクション変更（プレイヤーをリセット、P1） ·
request_load = falseに設定 · プレイヤーのHPを回復（P1）。 - on load → wait — 自動。
両方のブランチでHPを回復するため、すべてのセーブとロードでプレイヤーが回復します。
ビジュアルスクリプトの簡易フロー:
- 開始状態は
wait wait → on save setupはrequest_saveで発火- on save setup: 音を鳴らし、
request_save = falseに設定、HPを回復 - save: ゲームデータのセーブを実行
- save → wait は自動
wait → on loadはrequest_loadで発火- on load: アクションをリセット、
request_load = falseに設定、HPを回復 - on load → wait は自動
request_saveとrequest_loadはセーブ可能ではありませんcurrent_save_pointはセーブ可能です
「いいね！」 1
これはとても素晴らしいですね。vs ノードの下にサブノードとして GD を追加できるなんて、勉強になりました。baz さんの親切なご指導に心から感謝いたします！
「いいね！」 1
大変おまたせしました。
カメラが近づいたら、オブジェクトのロード時のリーク問題について1.3.0にて修正させていただきましたのでご確認をいただければと思います。
ありがとうございます。ただし、投稿の返信先が間違っているようです。正しい投稿はこちらです。
また、子ノードのGameObjectの復活位置が親ノードの位置に依存する問題について相談したいです。
最新バージョンでも依然として多くの不可解な問題があります。例えば、カメラを選択して復活させる場合、移動後にたまに復活する一方で、たまに復活しないことがあります。
さらに、子ノードが復活した後、親ノードの下で実行されず、独立したノードとして分離されてしまいます。
現在、この問題は修正中でしょうか？
これに対応するチケットが開かれていることを確認しました。現時点では、完了の見込みは立っていません。