表編：Arbor3のすすめ裏編：ギルド内での軽率質問のすすめ

はじめに

本記事は
Unityゲーム開発者ギルド Advent Calendar 2020 - Adventar
12/10 の記事です。

軽率に登録したものの「記事かく場所ないじゃん！」と、
過去のあれやこれやをさばくった結果、
大昔に登録だけしてろくに使っていなかったブログを見つけたので、ここに投稿します。

読んでタメになりそうな人

プログラム専門外の方
ググった記事を参考にして、単一の挙動は作れる人
でも、たくさんの挙動をどうまとめて書いたらいいか困っている人

概要

自語りではありますが、私の技量はこのくらいです。

○Update()の中に、移動コマンドを作ることはできる

    void Update()
    {
        //何かいい感じに移動するコマンド
        CharacterMove(hogehogehogehoge);
    }

○移動させたくない時があるので、分岐で通らなくすることはできる

    void Update()
    {
        //止まらなくていい時
        if(!isStop)
        {
            //何かいい感じに移動するコマンド
            CharacterMove(hogehogehogehoge);
        }
    }

ここまではググって見つけたコードを参考に作れる。
ただし、この先はどうだろう？

攻撃中は移動できない（分岐を増やせばいけそう）
ポーズメニュー中は移動できない（まだいける？）
タイトル画面中は移動できるようにする（分岐増えてきてつらそう）

もっともっと分岐が増えてきて、
Updateで分岐ゴリ押しができなくなる未来が見えています。
ですが、中々事例を検索しても、いい感じに処理できず困っていました。

こんな状況を解決できそうな（実践中のため、できそう）ツールとして、
Arbor3arbor.caitsithware.comを紹介するのが、本記事の本題です。

Arbor3で、毎フレーム回したい処理をかんたんに分離できる

これです。この記事では、この1点だけをピックアップします。

使い方は公式ドキュメントを見たほうがいいので省略しますが、

Arbor3の機能を経由して作られるスクリプトStateBehaviourScriptには、
作成時点で、それぞれのステートにいる時だけのUpdate()が用意されています。
そこに愚直に挙動のコードを書くだけで、
前述の挙動のONOFFをするためだけの分岐を書かなくて良くなるのがとても凄いです。

	// OnStateUpdate is called once per frame
	public override void OnStateUpdate() {
		//自機の移動処理に関しては、全てここに書くだけ

		//何かいい感じに移動するコマンド
		CharacterMove(hogehogehogehoge);

		//キー入力次第で、次の攻撃ステートに移行できるようにする
		if (Input.GetButtonDown("Attack"))
		{
			Transition(nextAttackState);
		}
	}

これくらいなら書ける！

移動用のステートで使うスクリプトにはこれだけ書けばよく、
攻撃用のステートには攻撃用のスクリプトだけ書けば良い、

もう最高ですね。これがやりたかった。
Update()にif分岐ゴリゴリで処理を書きまくっているご同輩がもしいたら、
ぜひとも導入を検討してみてください。

UnityStationでも紹介されていました

www.youtube.com
最近のUnityStationでもArbor3回がありました。
もっとわかりやすく紹介しているので、
見てみると使いたくなってくるかもしれません。

本記事の内容は、以上になります

本記事で紹介したかった内容は以上です。ありがとうございました！
明日以降もアドベントカレンダーをお楽しみください。

裏編：ギルド内での軽率質問のすすめ

裏編です。
せっかくのギルドのアドベントカレンダーなので、ギルド話を添えます。
「軽率質問のすすめ」です。10割自語りです。

事例１：何かめちゃくちゃ詳しく返答がきた

ログ残していましたので貼っておきます

シェーダーの選択肢で何を選んだら良いのかわからず、
かるーい気持ちで質問を投げてみたところ、
めちゃくちゃピンポイントで返答を頂きました。
さらに調べ方まで。

確か参加して数日以内でしたので、
面識も何も無い人相手に、ここまで手厚くやり取りをしていただきました。
なんだここ……。

事例２：何かめちゃくちゃ多く返答が来た

設計について話す部屋があり、
当時設計という言葉を知ったばかりの時に、
「どこから学べばいいでしょう？」的な質問をしました。

何かめちゃくちゃ回答が返ってきました。

オススメの概念や書籍やなんやかんや。
ログを残し忘れてしまったのが心残りですが、
そこで紹介頂いた本を何冊か読んで、設計の概論を知ってとてもタメになりました。

こちらも数日以内だったと思います。
加えてこちらは十数人の方がアレコレ話していてビビりました。
なんだここ……。

裏編の結論：軽率に質問ができる場所！

上記２例から、UGDGは私が思っていた以上に活発で、
裾野が広い場所だとわかりました。

色々返してくれる方々への敬意は忘れず、
とはいえ、返せるものが無いから質問は……なんて、
ガチガチに固まりすぎて手をこまねかず、
という塩梅で付き合っていけたらなと考えるようになりました。

しばらく忙しくてあまり加われていませんが、
また積極的に活用させていただけたらと思います。

私からも何か提供できると良いのですが、
技術的な何がしは無く、
唯一、超裏口から紛れ込むゲーム業界企画職レポ　ならできそう、という位です。
時と場合と需要が噛み合うときがあれば、貢献できたらと思いました。

おまけ：表編も実はギルド内で助けて頂いた事例

表編で紹介したArbor3ですが、実はギルド内のSlackにて、
奥村さんにおすすめして貰ったのがきっかけで触るようになりました。

当時、事例２の設計話の後で設計に目覚めて、
「Stateパターンを理解したら表編の問題は解決する！」
と頑張っていましたが、

「Stateパターンわかんないよ～！」
~~~~~~ Execute ~~~~~~~~~~
~~~~~~ Prosessor ~~~~~~~~~~
~~~~~~ deligate ~~~~~~~~~~

意味がわからない。
処刑してそうだし、野菜とか砕いてそうだし、かっこいい門の話してるし。

と苦しみをボヤいたところ、奥村さんにお声がけ頂いた、という次第です。

www.youtube.com
Arbor3の説明動画も添えていただきました、
こちらも実際のテストもしていて分かりやすく、こちらを見て導入を決めました。

ということで、表編も実はギルド内で助けて頂いた事例でした。

企画にゲームが作れるか？

ゲームのモックを作るために知ったあれこれをまとめるところ。企画屋のため技術レベルは低めです。