State対応について

[toruki]

完全に再現するのは難しいと思いますが、位置と色が変化したり画像が入れ替わるトグルボタンのような動作を再現したいと考えています。

以下のような感じで自分で試してみようかと思っていますが、こうした方がいい、これは無駄だなど、アドバイスがあると助かります。

1. 選択しているステートだけでなく他のステートも取得してみる
2. ランタイムはトリガーで後々対応する

[kyubuns]

AdobeXDのState機能について、State毎にSpriteの変更のみならずObjectの変更まで可能というなかなか自由度が高い機能であるため、
State機能の中でもどこまで対応するか、というのを先に考えておく必要があると思っています。

懸念点として、例えばAdobeXD上で通常State(A Stateとする)の画像のSpriteを差し替え、その後、別の未使用State(B Stateとする)のSpriteを差し替え忘れていた！という時に、
B State用の古いSpriteもUnityにインポートされてしまい無駄にSpriteAtlasがでかくなるという、とても発見しずらい問題に発展することも考えられ、State対応は慎重に行う必要があるなと考えていました。

このようなことから自分の方ではState対応は保留にしているため、
「Stateの、この機能とこの機能だけでも再現出来れば、こういうことが実現出来て便利そう」などありましたらお聞きしたいです。

[toruki]

今再現したいものとしては、背景色と位置が変わるスライドスイッチと、クリックで画像が入れ替わるトグルスイッチの２つです。

これら２つは典型的に使われそうだとは思うのですが、おっしゃる通りState機能は自由度が高く、完全なState機能を実装するのは簡単ではなさそうですし、無駄に複雑になってしまいそうです。

まだ全体を把握していないので的外れかもしれませんが、Stateの機能をランタイム（Unityスクリプト）なしで再現するのは難しいと思うので、まずは各Stateが子要素となるようにインポートするオプションだけを用意し（選択されているState以外はDisabled）、位置や色のアニメーションへ変換したり、オブジェクトの表示・非表示で切り替えるかなどは、トリガーやパーサー、もしくは別途Unity側のスクリプトで後々何とかする。というのはどうでしょうか？

[kyubuns]

なるほど。
色の変更や位置の変更、のように変更できる情報を制限すれば現実的に実現出来そうです。
オブジェクトの数が変わらない想定であれば、別のGameObjectとして作ってしまうのではなく専用のComponentを貼り付けて、そこに各ステート毎の情報をSerializeFieldで保持しておき、ランタイムで取得できる形の方がアニメーションさせながらステート変化させたい時に便利かと思いました。

提案としてはこのような形になります。
どうしても機能としては複雑になってしまいそうなため、mainブランチに取り込むかどうかはまた別途検討とさせて頂きます。

[toruki]

ステートがどのようなデータ構造をしているか調べ、子要素（別GameObject）としてインポートする実験をしてみました。
https://github.com/toruki/AkyuiUnity/tree/testing-include-states
ステートの入れ子状態など、いくつか作ったパターンでは取り込めたようです。
これに決め打ちのスクリプトを追加して、とりあえず実現したかったことはできそうです。

オブジェクトの数が変わらない想定であれば、別のGameObjectとして作ってしまうのではなく専用のComponentを貼り付けて、そこに各ステート毎の情報をSerializeFieldで保持しておき、ランタイムで取得できる形の方がアニメーションさせながらステート変化させたい時に便利かと思いました。

確かにアニメーションに落とし込めると便利ですね。
ステート用の GroupParser を作ることで実現できそうですが、汎用性をどこに線引きをするかが難しそうです。
自分でも少し考えてみます。