Unityでの設計の話 -鉄血篇-
この間のTUT-LTでコンポーネントとは何かを、めっちゃ抽象度高く喋りました。 この記事はその補足というか、喋っただけで資料になってない話を書いていきます。静的LTです。
(幣チームの)ゲーム開発ではこんな感じに仕様が降って沸くので、それに対応してみる、継承ベースな設計と集約ベースな設計とをそれぞれ追ってみて、ここがこう難しいよね、みたいな事を喋らせてもらいました。
話のキモは、オブジェクト指向で「オブジェクト」という枠に押し込めたいのは「流動要素」で、決して現実世界の「物」なんかじゃあないよって事でした。 今回の場合、流動要素とはゲーム世界での物体(車/バイク/アイテム)の「振る舞い」そのものでした。なので、そこを切り分けて「オブジェクト」にしました。
じゃあ、どうやって流動要素を見極めるんだ! という質問をいただいたので、それについて書いてみます。
その前に、幣サークルでのゲーム開発手順を軽く説明すると、
- 各個人がA4一枚に企画書いて持ち寄り
- やりたい企画に参加(この時点で1企画2-4人位になる)
- チームで企画をブラッシュアップ
- 適当に分担して設計&実装、時間があれば3に戻る
- 完成
という感じです。今回のLTで再現したのは3-4の繰り返し部分です。核になるゲームアイデアはあれど、具体的になるのは4の直前ということになります。 仕様が変わるのは2巡目以降の工程3なので、如何にこれを先読みするか?が鍵です。
一つは、初回の3をきっちりやることです。つまりは、このゲームの面白さは何か? 何が自分たちにとって譲れないか? ということを固めることです。これは他のチームメンバーと共通認識を作るためにも大切です。譲れないものが固まると、そのために調整すべき事柄が見えます。
幸い(?)、うちのサークルでは、プランナーとプログラマーがちゃんと分業しているわけではないので、変更の痛みを無視した要求が飛ぶことは稀(のはず)です。これは逆に、プランナー的な仕事の質を求められない可能性を意味してもいます。面白さが担保されず、なんだかよくわからないものが出来上がることがあります。
もう一つは、先読みを諦めることです。3-4を回すためのプロトを作って、ある程度仕様が固まるまで待つ方式です。ゲームの企画において幣サークル民はほぼ素人である一方、プログラミング/ソフトウェア開発については企画ほど素人ではないため、実際に作ってしまう方が掴みやすいです。
しかし、恐ろしいことに(??)、プロトができると、「わーいwできたw」「実質完成」などとのたまい、気が抜けがちです。また、学業優先で進めていると、思ったほど3-4のサイクルが回せるほどのテンポで開発ができない事も多々あります。
どちらを取るにせよ、流動要素を抜き出すには、要件を固めるほか無い、というのが私の回答です。 なぜなら、設計とは要件の影であり、要件を実装可能にするものだからです。では要件とは何か、これはどうすれば引き出せるのか。これは企画の進め方そのものを考えないといけません。
というのも、例えばこれが受注開発で、クライアントとのコミュニケーションで作るなら、それを如何に円滑にするか?ということにもなりうるし、幣サークルの事案であれば、如何に自分達が納得できるものを余暇の時間内で組み上げるか? になるわけです。
幣サークルの場合、最もネックなのは、サークル民は忙しいという事実です。これは幣学の入学年次的にも仕方ない話です。なので、如何に手軽に実装するか、の早道である「使い回し」がし易いモデルを求めて、いろいろな設計パターンを取り入れてみています。その一つがLTで紹介したコンポーネントモデルです。流動要素を見極めるのも、変更にかかる労力を最小にしたいがためです。
そんなこんなな、設計すると、やがて楽になるよって話をしました。したかったです。
蓋を開けると、なんだか設計というより幣サークルの紹介みたいな内容になりました。 熱血編ではUI設計の話をします。たぶん。
