テスト用ゲームの作成目的の整理
テストゲームを作成する目的を整理します。
➀現在の実装方針の実現性確認
②アーキテクチャ・モジュールの評価
➂展開実装のベースに設計と評価
以下の項目を追加した場合に、不自然な実装にならないか
→イベントの増加
→シーンの追加
→弾の種類
→軌道の追加
→会話パートの追加
→無敵、被弾、消滅、などのアニメーションの追加
→ステージの作り方と追加
④モジュール/イベント送受信関係の依存関係を定義
⑤パフォーマンスの評価
→弾幕
→シーン切り替えや、敵の登場
テストゲームといいつつベースとなる設計の実現は目指すので、
テストを行えるのはいつの日になることやら…?
次はテストゲームの実装計画を立てる。
転職活動なりなんなりしているので、とっても先の話になりそうな予感。。。
事前調査を完了とします
いろいろ調べてきた結果、シューティングゲームへの要素を更新しました。
黄色が更新箇所です。
※マインドマップが肥大化したので一部のみ
参考にした内容は以下です。後者はとても有用で、無料ってレベルじゃねーぞ!
https://scratch.mit.edu/studios/26220298
・Unityパフォーマンスの無料電子版
【無料公開】社内研修書籍『Unity パフォーマンスチューニングバイブル』のPDF公開&オープンソース化しました! | CyberAgent Developers Blog
さて閑話休題。
いろいろ調べ終わったと思います。次は実際にUnityでテストコードを作成していきます。
そういえば今更計画について考えていたのですが、私の頭の中ではざっくりと↓のようになっています。
テストゲームの作成→テストゲームの品質評価(コード、ゲーム性など)→システム作り→各シーン、ステージの作りこみ→テスト→再調整→スマホ用への調整→テスト→リリース
こんな計画を話していたとしても、テストゲーム次第では中身が変わるので後半の方で上げたやりたいことの解像度は低いです。必要に応じて柔軟に変更します。
ゲームアーキテクチャの草案
プログラミングを行う上でアーキテクチャというものを決定しないと大変なことになります。
どこになんの処理を書いたのか忘れたり、機能拡張ができない!なんてトラブルが多発することに。
今自分が行いたいものを整理していきましょう。
シューティングゲームでやりたいことはいくつかありますが、
プログラミング的にはそう多くはないでしょう。
ということでマインドマップで要素を書き出しました。
まだ深堀が必要です。例えば↓のようなサイトを見てゲーム処理内容の過不足を見つけていきましょう。
https://dixq.net/rp/
さてアーキテクチャの話。
現時点でゲームに必要な要素は多くないのではという判断をしています。そのため、以下のようなシンプルな仕組みで設計が耐えうると思います。
UnityのGameObject自体が、マイクロアーキテクチャ思想とマッチしそうなのでその構造を活かすイメージを持つと↑のような絵なのかと思います。
自機やステージ管理オブジェクトは、イベントを発行することで各モジュール間は通信を行う想定です。
アーキテクチャとしては、レベル2かレベル3の実装になると思います。
https://logmi.jp/tech/articles/324456
詳細は以下。
・Unityのマイクロサービスアーキテクチャのような構造とマッチさせたい。
そのために、GameObjectに紐づくComportからInterFaceを呼び出しすモジュール化を行う。
Componentはイベント通知を発行して疎結合で処理を行っていく仕組みにする。
・そこまで大規模にならないし、すべてコードに書き出していくようなことはしない。個人開発では無理。
しかしこだわりたい要素もあります。
・チープな演出はしたくない
→何をチープとするのか難しいが決めないといけない。
・重い動作はいや。
→弾と敵は多くなってしまうので対策が必要。
・自機や敵、ステージ、アニメーションの追加は変更の余地を残したい
→アーキテクチャ的には問題なさそうだが…?
・楽しいと思えるポイントを作りたい
→売りになるものは何か考える
シューティングゲームの要素という横軸と、行いたい処理をどう実現するのかという縦軸、こだわりたい要素の補助線の3つを深堀していくとゲームの全体像が見えそうです。
まだ問題定義は終わらない…。
アインシュタイン曰く、「私は地球を救うために1時間の時間を与えられたとしたら、59 分を 問題の定義に使い、1分を解決策の策定に使うだろう」
Unityのマニュアルを斜め読み
Unityとはなんなのか?
Unityで開発しようと思います。
1年前、Unityのゲーム学習を行ったときはなんだかよくわからず終わりました。
でももう違います。経験積んだのでよく理解できるでしょう。
まずはユニティのアーキテクチャを一通り読んでみます。
https://docs.unity3d.com/ja/2021.3/Manual/unity-architecture.html
驚きました。日本語ではありません。
動揺しないように深呼吸して、Chromeの翻訳機能を有効にして読み進めました。
そんなに難しくなさそうです。C++かC#を選べるようですが、コードはほぼ書かない想定で進めるのでC#を使いましょう。
もしコード量の増加が見込めるならC++で。
やりたいことに大きく差が出る言語ではないので、特に気にせずに進めます。
次はゲーム動作の根本。
以下の記事によるとGameLoopという仕組みがUnityのようです。
https://yotiky.hatenablog.com/entry/background-knowledge-of-architecture-in-unity
よく分かりませんが、ユーザーの入力とCPU速度を切り離すことを目的として導入されているようです。
結果的に、各オブジェクトはupdateタイミングによる更新処理を行うことに繋がっているのでしょう。
ということはupdateを行うオブジェクトが増加すればするほどスループットが遅そうです。ふーん。
そのうえでアーキテクチャをどうするのかという話を調べたのですが、難しくて読むと眠くなる記事しか出てこないので明日にまわそうかな…
なんか言葉だけそれっぽい記事が多く、結局どうつくるのかイメージがわかない記事が多い印象です。
アーキテクチャマニアになりたいのではなく、ゲームが作りたいので不要な情報は読まないようにします。
今回の要点は以下です。
・Unity側がゲームシステムのアーキテクチャを呼び出すような形式がいい
・分散システム的にデータが存在する状態は避けたい?
ユーザーに聞いても需要が分からない
姪と甥にプレイしてもらうことを想定して作ります。
お金稼ぎではなく、「楽しかった」といってもらうことが目標です。
なのでどんなゲームが好きなのかヒアリングしてみました。
甥っ子に聞いてみたところは以下です。
・一本道みたいなやつは嫌。自由度がほしい
・カスタマイズとか考えてやるのが面白い
・難しそうなのは嫌
なかなかに難しい。
ちなみに出てきたゲームはオープンワールドばかりで戦々恐々としております。2Dシューティングは受け入れられるのだろうか。。。
一方で姪っ子は
・四天王とか倒すの楽しい
・なんか楽しそうなのならいい
・怖いのは嫌
とのこと。
本質としては楽しそう、優しそう、自由であることが大切そうです。
ユーザーに聞いても需要が分からない
姪と甥にプレイしてもらうことを想定して作ります。
お金稼ぎではなく、「楽しかった」といってもらうことが目標です。
なのでどんなゲームが好きなのかヒアリングしてみました。
甥っ子に聞いてみたところは以下です。
・一本道みたいなやつは嫌。自由度がほしい
・カスタマイズとか考えてやるのが面白い
・難しそうなのは嫌
なかなかに難しい。
ちなみに出てきたゲームはオープンワールドばかりで戦々恐々としております。2Dシューティングは受け入れられるのだろうか。。。
一方で姪っ子は
・四天王とか倒すの楽しい
・なんか楽しそうなのならいい
・怖いのは嫌
とのこと。
本質としては楽しそう、優しそう、自由であることが大切そうです。