「まずは小規模なゲームから」に聞き飽きた人のための中規模ゲーム制作手法
■前説
この記事は、Unityゲーム開発者ギルド Advent Calendar 2022に投稿した記事をリファインしたものとなります。UGDGアドカレは他にも知見になる記事が多くあるので興味ある方は見てみましょう。
■前節
みなさん、ゲームを作ったことはありますね。
みんなゲーム作ってる人ではない? そうですね。
でもたぶんここ読んでる人の多くは一本位はゲームを完成させている人だと思います。 というかそれが前提です。
ところで、ネット上の多く存在するゲーム制作講座、何かしら読んだことがあると思います。
そしてそのほとんどの場所で、「初心者」向けにこういっているでしょう。
「いきなり大作を作ろうとしないで、まずは小さい作品から😊😊」
うるせえ!! 俺はもうそこは通り過ぎたんだ!!
そこはもう通り過ぎたから、まとまった規模の作品を作りたいんだ!!
となる。 そう。「入門講座」は小規模ゲームを完成させた人に、その先の作り方は教えてくれない。
この記事はそんな段階の人のための、「中規模」のゲームをうまく作り上げるテクニックを記載している記事となります。
尚、例によって多分に筆者の主観を交えた内容であると最初に断っておきます。断らないとマサカリが飛んでくるんだ。今のネットワールドは。
◆そもそも「中規模」とはなんだ
例えばunity1weekで投稿するような、一週間で作るような……いわゆる「ミニゲーム」よりは大きい規模のゲームなど。どの程度を「中規模」と称するかは個人差があるので「こうです」と断言はしません。が、一般的に知名度の高いタイトルとして、「初代スーパーマリオブラザーズ」くらいの規模を指すことにします。
■本文(テクニック集)
それでは本題に入ります。ここから述べる内容は
実際に自分が開発する時にも意識しているものです。
◆唐突な結論
最初に結論を書きます。
この後書いていく内容は、全て
DONE IS BETTER THAN PERFECT.
に帰着する内容です。
(画像張ろうか迷ったけど著作権どうなんだって感じなのでやめた)
……何のことかわからない? 界隈ではそこそこ知られている、
かの元FaceBookにポスターとして貼られていたとかいう噂のある格言です。詳しくは適当に検索して調べてください。
■制作工程編1
◆最初に分量を全て見積もる
中規模のゲームであろうが、大規模のゲームであろうが、最初にやるべき重要なことがあります。それは、想定するボリュームの見積もりを最初に全て立てることです。 マリオで例えるなら、1ワールド4ステージ、全8ワールドで32ステージ、といったように。敵もX種類(調べたらマリオは14種?)、アイテムやギミックといった部分も全てです。
この見積もりをこなすことで、ゴールを見据えて制作する事が出来るようになるという利点ももちろんありますが、それ以外にも、ゲームそのものの企画・構想に見落としがないかの確認にもなります。 ここの見積もりであやふやな部分が存在した場合、それは即ち構想・企画時点で穴があるという事になりますので。
なお、ここで決めた分量を、絶対に貫かなくてはならないわけではありません。製作途中で、そこまで要らないと判断したら減らしてもいいし、逆にもっと出来ることがあると思ったなら増やしてもいい訳です。
一番まずいのは見積もりをそもそもしない事です。「できるだけいっぱい、ボリュームのあるゲームを作ろう!」みたいな心持で始めたが最後、1-4が最終ステージのゲームが出来上がります。
◆その分量分の"データ"を最初に全部作る
より実戦的なライフハックです。
またマリオに例えますが、とりあえず1ステージ分のマップデータを作ったとしましょう。
そうしたら、そのステージデータファイルをすぐに複製して、32ステージ分のデータを作ってしまいます。
「0の状態から0.1を作る」という工程、毎回やると存外面倒で……。逆に0.1の状態のデータであっても予め用意しておくと、思いつきのアイデアを適当に作ってみる、という工程が隙間時間に進められたりします。「こういうマップあったら面白いんじゃない?」みたいなフラッシュアイディアを適当なステージに突っ込んだり。
ここで「データそのものがない」状態だと「そのマップを作るためにまずデータを作る」そこの1ステップが精神的に億劫で「今はやらんでええや」になり、そして次の日にそのフラッシュアイディアは忘却の彼方になります。
とにかくデータの受け皿を"最初に決めた分量"分作ってしまいましょう。
◆全シーンと全遷移を作る
前項から地続きの話。
まずはじめからおわりまでシーンを作ってしまいましょう。
タイトルシーンは勿論、エンディングやスタッフロールまで。もちろんゲームサイクル以外にも設定画面とかが想定されるならそれも。そしてそれら同士の繋ぎ部分も最初に作ってしまいます。
ここで付随的に行う(行える)のは、
「作っているゲームで想定されるシーン」
及びそのシーン同志のつながりのすべての洗い出しです。
最初の項で書いた必要リソースの洗い出しと本質的には同じ話です。
「繋ぎ」の処理だけ作れれば、見た目や演出は度外視して問題ありません。
見た目というのは後からいくらでも盛れるものです。
ここでもまずいと言えるのは「開発途中だから」という理由で仮遷移状態のシーンを作ってしまう事。どんなにインゲームを作り込んでも、それが開発者にしか遊べない遷移になっているゲームは、極端な話、ゲームにすらなっていないのだから。
■脱線
◆休題:バーティカルスライスという手法
バーティカルスライスと呼ばれる開発手法が存在します。
ものすごく平たく言うと、
「とりあえず1ステージ分を『完璧』な状態で作る」
という手法です。
これは企業基盤でがっつり仕事として取り組むプロジェクトとしては有効な手法の一つですが、ひとりではじめて中規模のゲームを作る時は絶対にオススメしません。理由はあまりにも自明、怪物みたいなスタミナの持ち主じゃない限り確実に最後まで持たないから。
我々が信奉するべきものはバーティカルスライスの手法ではなく、
みんなも知っている
"DONE IS BETTER THAN PERFECT."
の方なのです(2回目)。
◆本質論:どこで中規模ゲームは頓挫する?
ゲーム制作を頓挫する話はよく聞きますが、なぜ頓挫するのだろうか?
色々な理由を聞くことはありますが、結局それらそのものが頓挫の理由になったわけではなく、そういった障害などで完成までのモチベ<諦めとなった結果、頓挫する、それこそが本質ではないでしょうか。
そして更に掘り下げると、その「諦め」はどの段階で生じているのか?
それはやはり、中規模以上ならではの、ゴールが見えない・遠い段階
なのではないでしょうか。
私もこれまでいくつものプロジェクトを立ち上げて、
もちろんその中には頓挫したプロジェクトもいくつもありますが、
どのタイミングで頓挫したかというと、リソースを少しだけ作った段階で頓挫してしまっているケースが大半な気がします。逆に言えば、これまでの項目で挙げた内容を実践し、想定したボリュームぶんのリソースを粗方作れたプロジェクトは、だいたい完成まで漕ぎつけています。
なので粗削りでもリソースを最初に作ってしまえば勝ちなのです。
粗削りでもそこにリソースがあれば、磨くのは難しくない。
あれ、まずい精神論っぽい内容になってきた。これはよくない流れだ。
ライフハックの文章に戻ろう。
■制作工程編2
◆量産するリソースの"メモ"は最初からガンガン実体にする
賢明なクリエイターの諸君はこう考えるかもしれません。
「最初にシステムを完璧に作り上げよう!
リソース系を制作するEditor拡張や環境も最初にしっかり構築して、
そうしたら一気にリソースを作ろう! 効率的に!」
これは先ほど触れたバーティカルスライスであり、
個人長期開発の死亡ルートです。
リソースの量産というのはつまりだいたいは単純作業であり、
単純作業が苦手なプログラマーはこの長距離マラソンのモチベ管理を
甘く見積もり、そして途中で力尽きます。
厄介なことに、なまじ小規模のゲームを完成させた経験がある作者ほど、論理的に考えた結果、この罠に嵌ることが多い印象です。
前述した遷移のつなぎ合わせと最低限のインゲームが出来上がった段階で、
もう思いつき次第どんどんリソースを作った方が良いです。
これも前項で記述した、受け皿の部分に。
どうせ最初は完璧だとおもったリソース制作ツールも
リソースを制作しているうちにどんどん改善点が見つかるんだよ!!!!
システムの構築の息抜きにリソースを作り、
リソース制作の息抜きにシステムのブラッシュアップをしましょう。
それがモチベーションの管理術です(個人差はあります)
◆ところでそのリソースは順番に作るべきか?
NO。 理由は2つ。
・最初から順番に作ると最終的なスケール感を把握しづらい
・そもそもモチベーションが保ちにくい
これはプロの現場でもある種の常識ですが、レベルデザインを構想するときは、基本的には「最初」と「最後」の段階を最初に見積もります。特にソシャゲなんかだと、プレイヤーがどの運営段階でどの部分まで到達するかまで割と緻密に見積もりを立てます。見誤るケースも多いけど2つの地点が決まってしまえば、その中間を作ることは難しくないです。
なお、これも最初に構想した「最後」を絶対に固定する必要はありません。作ってる段階で「もっと上」が有りうると思ったら「最後」を延長しても問題ありません。
そして2つめである。作りたいところからつくったほうがいいよ。
というか、これもマリオに例えて話しますが、ステージ「4-3」を作るぞ! みたいな意気込みで作らない方がいいかもしれません。これまでに再三述べているように、とにかく思いついたものをひたすらリソースのメモとして貯め、その後に「このステージは『4-3』に割り当てよう!」みたいにジグソーパズルしたほうがやりやすいと思います。
もっと根本的な話すると、もし楽しいと思わず作るような場所が生じた場合、そもそもその部分は不要の可能性があります。作者が作ってて楽しくないところは、プレイヤーも楽しく遊ぶわけがないので。
◆ちゃんとタスクは可視化して管理しましょう
これはまあ普通の話。頭の中の記憶はアテにならないので、
「まだ作ってないところ」は常にリストにしておきましょう。
テストプレイ・バグ取り・ブラッシュアップでも同様。
テストプレイして気になった部分などは全てどこかにメモして、
そしてテストプレイを終えた後にまとめて消化しましょう。
項目を見つけるパートと項目を消化するパートは分けた方が良いです。
メモする場所はどこでもいいです。がっつりしたチケット管理システムを使ってもいいし、(個人ないしは少人数でやるなら)スプレッドシートでもExcelでも問題ないと思います。
■テスト公開編
◆常に、定期的に、「テスト公開」するべし
「全シーンと全遷移を通る」に通ずる内容です。
「常に自分以外のユーザも遊べる状態を維持する」のが大事です。
新しいシステムや新しいレベルを作る時に、
「ちょっと(開発者だけが)テストできる状態で作る」
というのをやりがちですが、これが悪い膿です。
「ちょっとだけならええやろ」と作った仮部分は放置していくと、それはミントの如くどんどん増殖していきます。割れ窓理論の如く増えていきます。
気づいたら仮部分だらけの開発者しか遊べないゲームがそこに生誕します。
これを防ぐライフハックが「常に定期的に「公開」する」と己に義務付けることです。どんな形態でも構いません。unityで作っている人ならば、unityroomで公開するのが一番手っ取り早いでしょう。(webGLプラットフォーム扱いになりますが)
また、必ずしも不特定多数の目にとどまる場所に公開する必要もありません。これについては次項で。
◆そして遊んでくれるフォロワーがいればよい
これも前項から地続きです。結局殆ど続いているじゃねえか。
せっかく定期的に公開する形をとるのならば、実際に他の人に遊んでもらうに越したことはないでしょう。一人で作っていると徐々に視点が歪むので、
第三者の眼鏡を通してもらうという観点においても、効率的なゲーム開発の手法です。
◆…………ところで誰が遊ぶ?
え? 遊んでくれるような知り合いがいない?
それは… 気の毒に…
そんなあなたに、Unityゲーム開発者が集まるコミュニティがあります!!
……と言いたいところなんですけど……
UGDG、なまじ規模が大きいために、却って傍観者効果が炸裂して、
そこまで強いメンバーの結集度が高いわけではないんですよね……
それでもUnityでのゲーム開発者なら入った方が良いと思いますけど。
自分はこういう時に言えば遊んでくれる(そして自分も言われたときに遊ぶ)関係性の小クラスタに所属しているのでなんとかなりますが、この部分に関しては「こうすればOK!」という快刀乱麻の解決法はちょっと見つかりません。なんか上手い方法がないか模索しているのですが。
■まとめ
毎度まとめに困る
まあ……すべてをまとめると、中規模ゲームの完遂に必要なのはモチベーションの維持のひとつに集約されることは間違いなく、そしてそれは他のゲーム制作講座でも言われている事でしょう。この記事に書いたのは、それ(モチベーション)を手法として維持するライフハック、それだけのことです。
そしてそれは
"DONE IS BETTER THAN PERFECT."
のマインドという事です……(3回目)
とりあえず! これを読んだら! 「中規模」ゲームを完成させましょう!
ひとつでも完成させれば、作家としての己を示す記号としては強力な手札となるでしょう。適当言うたかも知らんけど。
■宣伝
そういった手法で作り上げたプロダクトを宣伝します。
まっともぉん氏との共同制作である、ローグライト&オートバトラーゲームです。現在リリース済み。
間もなくリリース予定のパズルアクションゲームです。ちなみにこの記事を書いている途中でUnityプロジェクトがなぜかオート初期化されてあやうく全データ吹っ飛ぶところだった バックアップはだいじだよ
■定番の文句
この記事がいいとおもったら
いいねとかシェアとかフォローとかお願いします!!
月並みな文句だけど、ちゃんと口に出して言うのが大事だってきいた。
■最後の余談
この記事自体もこの手法で書きました。
まず雑でもいいから全項目書いて、後で清書する。
"DONE IS BETTER THAN PERFECT."
全てはこの一文に帰着する……。(4回目)
この記事が気に入ったらサポートをしてみませんか?