前半はこれを作った経緯なので、技術情報だけ欲しい方は後半へ飛んでください。
それ「ゲーム」？謎のガラクタSceneを積む哀しさ
ゲームは人に遊んでもらってナンボのものです。とはいえ、
「なんか変なものが出来てしまった、次はがんばるぞ（きっと）」
って繰り返していませんか？
やらかしてしまうアンチパターン
Unityでゲームを作るとき、よくあるのが、まずはゲーム本体から作ってゲームのメカニクスを考え確認するところから入ること。例えば、「爽快感のあるFPS」ならこんな感じです。
- 自分が動ける
- カメラが付いてくる
- 的になる敵が在る
- 自分が動けて弾が打てる
とやってるうちに、次は「敵を増やしたい」、「武器の種類を増やしたい」、「乗り物に乗りたい」など盛っていく方向に行くか、「キャラをもっと可愛くしたい」、「爆発のエフェクトを派手にしたい」と見た目を変えていくなど、やりたくなってきます。楽しく作るのは大切なのでガンガン作っていくのは好いです。そして、いつしか楽にやれることをやりつくすと、自分のゲームに飽きてきます。
ゲーム自体に「ゲームオーバー」「ゲームクリア」などの概念が無いと、何かがうごめく謎のSceneが出来がって飽きてきたり、力尽きたりすることが多いです。
元に在った「爽快感のあるFPS」というコンセプトを具現化するゲームを作るはずが、手段であるゲーム作りを目的にしてしまい、それが半端に達成されて目標を見失う、「ディレクターは俺」でアリがちです。
やらかさないように、完成させるために
問題は、「本質を観ることを続けること」で解決します。
誰がお客さん？問題
このパターンは、以下だとまあまあ防げます。
- ディレクターがしっかりしている
- 開発費とスケジュールがきちんと出来ていて進捗管理されている
- レベルデザイン、リソース作成などをディレクションと分離した人でやっている
つまり、「仕事のように管理する人が別」になっていると上手くいく可能性が上がります、そして、その目的は顧客が居る想定がなされているからです。
じゃあ、素人が作る、「予定も適当で金もかかってないに等しいゲームだったら無理なのか？」となりますが、お客さんのプレイヤーがいてのゲームです。インディーズ未満のゲームでは、「お客はだれ？」というと、ありがちなのを順番に挙げるとこうなります。
- 自分が作りたいものを作ってる、つまり「お客＝自分」
- グループ制作のメンバー
- 想定した近くにいる人
誰かが作りたいといったものを一人ないし数人で作る場合、スタッフ内にお客が居る、何か作りたい人もいるという状態で、ディレクションをうまく分けにくくなります。
お客さんに遊んでもらえる形にならない問題
創っているものの規模が想定できるような人は習作を作るような人ではなくプロなので、素人は計画的にできません。それで四苦八苦してゲームメカニクスの元になるところを右往左往していくことが多く、遊んでもらえるシステムになかなかならないことがあります。実験は重要なのですが、何を作るべきと研究開発しているのか、判らなくなることもあります。
先ず、プレイアブルなゲーム創る！
誰が楽しめるゲームであるか、そして簡単にテストプレーできる形に初めから持っていければ、後からは楽になります。プレイヤーが自分自身でも、全体の流れを確認し、「すべきこと」をゲームを試しながらタスクに落としていければ、完成へ徐々に近づき、求めていたコンセプトを達成できるゲームへ、脱線せずに到達できることでしょう。
ゲームはフィードバックが大事、初期段階からプレイヤーに評価してもらいやすいのが好い
試しやすいゲームのもとになるスケルトンを考える
いい形で望んだプレイヤーに、そして出来れば多くの人に遊んでもらいましょう！
[コンセプト]きちんと遊べて感想もらえる
遊んでもらうことは重要です、そして創る上で脱線しにくいことも重要です。
- 他の人に遊んでもらいやすい
- 創っていても少し楽しくなる（楽しい部分に集中できる）
- 評価し感想が貰いやすい
[考察]範囲と比較対象が明確だと評価しやすい
「感想をください」というと、おおむね、こんな感じだと思います。
- つまらない（どこか判らない）
- あまり好きじゃないかな（個人的に？）
- ここが好きじゃない
- まあまあ面白い
そうした感想を貰うと（あるいは自分でプレイして考えると）、じゃあどこをどうすれば好くなるのかが、判りにくいです。そうして次の目標が定まらなくなり、悶々とするうちに飽きてしまったりします。評価はまず、範囲がどうなってるか、そしてなにを指標にするかがあると楽になります。
- ゲームスタートからゲームクリア、ゲームオーバーが分る
- 較べる対象があると「ｘｘよりここが良い」など、理解できる感想を持ちやすい
[基本設計]ゲームスタートからゲームオーバーを較べてプレイ
ゲーム起動からの流れは以下とします。
画面遷移
[スプラッシュスクリーン]：作者のロゴなど、無くても良いがあると気分が良い
↓時間経過
[タイトル画面]：タイトルロゴなど
↓クリック
[ステージセレクト画面]：ステージを選べる
↓ステージのボタン
[ステージ（複数)]：ゲーム本体
基本は上記です。ゲーム本体は複数用意して、較べる対象が最低でも二つ、あると良いで安いす。
リソースの分割
Unityは自由度が高いので、処理速度やメンテナンスしやすいかなど、何をどれくらい優先したいかで実装方法が多様です。今回は、以下で行います。
- 画面はそれぞれSceneにする
- 単体のテストがやりやすい
- 担当をそれぞれに振りやすい
- 共通部分はPrefabと、アタッチしたScriptにする
- テクニカル担当がレベルデザイン担当に提供すると無駄が無い
- ブラックボックスのままで触らないと事故が起きにくい
[実装]Scene構成
画面の遷移をSceneにしているので、以下を用意しています。
| Scene | 内容 | 次への遷移 |
|---|---|---|
| Splash | 最初に出るスプラッシュスクリーン。 | 一定時間でタイトル画面へ |
| Title | タイトル画面 | クリックでStart画面へ |
| StageSelect | ステージの選択画面。 | ボタンでそのSceneを読み込む |
| Stage01~Stage03 | ステージ、いわゆるレベル | ゲーム本体。クリアかゲームオーバーのとき、ボタンでリトライかStageSelectへ |
Splashなんて本当は要らないのですが、在った方が本格的な雰囲気で良いですよね！
と、そんな感じで作った作ったのがこちらになります。
結構、ゲームで差が無いので、中身をどんどん変えると楽に複数ステージが組めて、レベルデザインの比較とか難易度調整の実験もしやすくなり、他人にも遊んでもらいやすくなります。
[JunShimura/GameBaseSkelton on Github
https://github.com/JunShimura/GameBaseSkelton/releases]
(https://github.com/JunShimura/GameBaseSkelton/releases)
ちょっと解説が追いついていませんので、あとから順次、コードを解説していきます！