ゲーム化!tomo_manaのブログ

ゲーム化!tomo-manaのブログ

Unityでゲームを作る方法について紹介しています

ちいさなどうぐや 途中振り返り#1


実装が予想どおりに行かないことが増えてきたため、一度設計方針を見直したいと思い、現時点までの取り組みを振り返ることにしました。

これまでの流れ

ゲーム開発の動機

ちいさなどうぐや は、財務諸表の勉強をする中で、箱型ボックスシートを直感的に学べるアプリを作りたい動機からスタートしました(開発スタート:2021年9月)

箱型ボックスシート/ゲームへの展開

転機

Unity1week(2022年5月)

開発に時間がかかっていたので、2022年5月に参加した Unity1week で、さっくり ゲーム感 だけを確認したいと思いました。

そこでは、財務諸表 は出さず、純粋な売買 のみを扱ったゲームを作りました。

薬草そろえて売ってみる? | フリーゲーム投稿サイト unityroom

Unity1week「そろえる」作品


この作品自体は、絶妙なレベル設定がおもしろいと好評いただけたことは嬉しかったのですが、その他に作ってみて分かったことは、

●ゲームに必要なリズム感は、開発初期から作らないと、後から足すのは難しい
(大幅な作り直し=手戻りが生じる)

●ゲームは 体験を中心に組み立てる 必要がある

ということでした。

tomo-mana.hatenablog.com

タイマーアプリのリリース(2022年3月)/アップデート(7月)

また、この前後にタイマーアプリをリリース/アップデートしているのですが、そこで気が付いたのは

●個人開発では いかに早く作るか を念頭に置く(得意に全振りする※)

ということでした。

tomo-mana.hatenablog.com


投資時間が長くなると、負けが込んだギャンブラーのように、賭けを継続したくなる心理が働きます。そうなった場合は、

●無理して計画に間に合わせようとするのでなく、できるだけ早急に計画・戦略を立て直す(リスケジュール、方向転換)

がタイマーから学んだ教訓でした。


※得意に全振り…新規技術に手を出さないという意味ではなく、新規技術は開発する前に使い方を把握しておく(トライアルを開発期間に含めない)という意味

ゲームの案を捨ててみる

Unity1weekの後、「ちいさなどうぐや」の初期構想案では、ゲームが面白くないだろうと感じ、一度はゲーム案を捨てようと思いました。


ただ、今後のために、もし確実に面白いと感じられるものだけで構成したら一体どんなものになっていたのだろうと、考えてみることにしました。

「おもしろさ」でゲームを構成する

その結果、少し構成を変えたら面白くなるかもしれないと感じ、もう一度、一から作ることにしました(2nd Model:2022年7月)

構想の見直し

第2案での挫折

7月6日に開発を再開し、50日ほどかけて、大まかなゲームの世界観を作り込みました。

開発線表(ふりかえり)


途中、ショップ画面へのアニメ結合と、お客さん毎のセリフを設定する処理に、10日ほどかかりました(7月25日~8月3日)。どうも これまでの経験が生かせない という、不思議な感覚でした。

時間がかかる作業を疑う

先ほど、タイマー の教訓で触れましたが、一機能に想定より時間がかかる場合は、自分が慣れない方法で実装しようとしている、頭で整理できてないことを無理してやろうとしている時があります。

デジャブ感を疑う

アニメーションのパーツを揃えた後、再びゲーム性検証用の実装の中で、以前10日かけて実装した内容を繰り返している感覚に陥りました(8月21日~25日)。

数日経ったところで、おそらく設計方針に限界がある(手慣れてない方法で実装している)ことに気付きました。


これまでの開発を振り返り、新しい設計方針で作り直す必要があると考えました。

これまでの知見

初回に比べ、2回目の構想で高速化に役立った方針は以下でした。


単体テストできるように作る
 20分・90分タイマーのリファクタリングで得られた知見で、いくつかの手法を組み合わせて、短時間でUIを量産できるようにしました。

●アニメーション対象となるオブジェクトGameObjectと、アニメーション処理をする実装MonoBehaviourとを分ける
●一つの実装(ファイル)には、一つの機能(モジュール)しか持たせない:
 スイッチboolか、範囲intか、選択enumか?


できるだけ共通化しない(探す手間を減らす)
 こちらも、開発の高速化と向き合う中で気づいたことですが、毎日コマ時間で作業する副業開発では、ファイルを探す時間がリスクとなり、挫折ポイントになります。

●できるだけ共通化しない(継承しないで所有する)
●無理な分割をしない(1ファイルが大きくても探しやすければファイルを分けない)
●想定するけど作らない(YAGNI
●整理しながら進める

新たに出てきた課題と対策

これまでの知見で解決できなかった実装は以下の通り。


複数アクションを経て決定されるプロセス(行動決定プロセス)
 「売る」時の操作を中心に組んでいましたが、「買取の決定」に、思ったより複雑な決定プロセスがあることが分かりました(行動を整理できてない)
⇒どんな体験をしてもらいたいか、から発想する


ゲーム期間の終了と再開
 同期制御の一つですが、ゲーム内の時間が経過した時、再開までに初期化が必要なケースがありました。
⇒割り込み禁止を管理する


「おもしろそう」を考慮
 Twitter で進捗報告していた時に気づいたことですが、ゲームにとって「おもしろい」と「おもしろそう」は別で、「おもしろそう」からコンセプトを決め直す必要があると感じました。
⇒「おもしろい」と「おもしろそう」の両方から最初に考える


書き出してみると、どれも要求レベルの漏れなので、当然仕様・設計に大きな手戻りを生じると思いました。立ち止まって振り返ってみて良かった・・・

(以上)