【UGDGアドカレ2022】「中規模」のゲームを作りきるライフハックかもしれない

本記事は、Unityゲーム開発者ギルド Advent Calendar 2022
8日目の記事です。（コピペ）

最初に軽く宣伝をします。

https://twitter.com/matsu_friends/status/1529734130098765824

まっともぉん氏と共同開発したローグライトと
オートバトラーの合いの子のようなゲームです。
買って。

https://twitter.com/MetaFormingPro/status/1600415338856083458

いま作ってるパズルアクション系ゲームです。
ウィッシュリスト登録して。

概要

中規模ゲームを作りきるのにあたって
個人的に使っているライフハックを書いていきます。

ライフハックです。精神論や技術論ではありません。
そういう記事はたぶんネットの海にいっぱいあります。

ところでこの記事は「鉄棒で後方支持回転まではできないやつが
逆上がりができないひとに偉ぶる記事」です。
想定する対象は「u1wで何回か作品は出してるけど、
まとまった規模のゲームを完成させたことはないなあ」くらいの人です。
既に中規模のゲームを販売まで漕ぎつけて且つそれでがっつり
収益を上げてるレベルの人はとっくに通過してるレベルの話なので
回れ右しましょう。

中規模とはなんだ

u1wで一週間で作るような規模よりは大きいゲームです。
どの程度を「中規模」と称するかは個人差があるので
「こうです」と断言はしませんが、この記事では上述した
「ボクロボ」「Cubis」、一般的に知名度の高いタイトルでは
「初代スーパーマリオブラザーズ」くらいの規模を指すことにします。

さて本題に入ります。ここから述べる内容は
実際に自分が開発する時に意識しているものです。

結論

最初に結論を書きます。
この後書いていく内容は、全て

DONE IS BETTER THAN PERFECT.

に帰着する内容です。結局そういう事なのだ。

最初に分量を仮定する

作るゲームを決めた段階で、想定ボリュームを最初に決めてしまいます。
マリオで例えるなら、1ワールド4ステージ、全8ワールドで32ステージ、
といったように。敵もX種類（調べたらマリオは14種？）
アイテムやギミックといった部分も全てです。

やっちゃいけないのは「できるだけいっぱい作ろう！」です。
この心持で作ると1-4が最終ステージになります。

ボクロボも「全26ステージ」「メインのボクロボ（ユニット）は15種類」は
初期の段階で決まっています（確か）。

ところで決めた分量を絶対に貫かなくてはならないわけではありません。
ゲーム的にそこまで要らないと判断したら減らしてもいいし、
逆にもっと出来ることがあると思ったなら増やしてもいい訳です。
まずいのは見積もりをそもそもしない事です。

その分量分の"データ"を最初に全部作る

これはかなりのライフハックです。
またマリオに例えますが、とりあえず1ステージ分作ったとしましょう。

そうしたら、その時点でそのステージデータをコピペして
32ステージ分のデータを作りましょう。

「0の状態から0.1を作る」という工程、毎回やると案外面倒で……。
逆に0.1の状態のデータを予め用意しておくと、思いつきのアイデアを
適当に作ってみる、という作業が隙間時間に進められたりします。
「こういうマップあったら面白いんじゃない？」みたいな
フラッシュアイディアを適当なステージに突っ込んだり。
ここで「データそのものがない」状態だと
「そのマップを作るためにまずデータを作る」そこの1ステップが
精神的に億劫で「今はやらんでええや」になり、
そして次の日にそのフラッシュアイディアは忘却の彼方になります。

重要なのはデータの受け皿を"最初に決めた分量"分作ってしまう事です。

全シーンと全遷移を作る

前二項と地続きの話。はじめからおわりまで基盤を作ってしまう。
タイトルは勿論、エンディングやスタッフロールまで。
もちろんゲームサイクル以外にも設定画面とかが想定されるならそれも。
そしてそれら同士の繋ぎ部分も最初に作ってしまいます。

ここで付随的に行う（行える）のは、
「作っているゲームで想定されるシーン」
及びそのシーン同志のつながりのすべての洗い出しです。

「繋ぎ」の処理だけ作れば、見た目や演出は度外視して問題ありません。
見た目というのは後からいくらでも盛れるものです。

ここでもまずいと言えるのは「開発途中だから」という理由で
仮遷移状態のシーンを作ってしまう事。
どんなにインゲームを作り込んでも、それが開発者にしか
遊べない遷移になっているゲームはゲームにすらなっていないのだから。

少し話が逸れる

バーティカルスライスと呼ばれる開発手法が存在します。

ものすごく平たく言うと、
「とりあえず１ステージ分を『完璧』な状態で作る」という手法です。

これは企業基盤でがっつり仕事として取り組むプロジェクトとしては
有効な手法の一つですが、
ひとりではじめて中規模のゲームを作る時は絶対にオススメしません。
理由はあまりにも自明、よっぽど怪物みたいなスタミナの持ち主じゃない限り
確実に最後まで持たないから。

我々が信奉するべきものはバーティカルスライスの手法ではなく、
みんなも知っている
"DONE IS BETTER THAN PERFECT."の方なのです（２回目）。

あれ、まずい精神論っぽい内容になってきた。これはよくない流れだ。
ライフハックの文章に戻ろう。

常に定期的に「テスト公開」する

またまた前項と地続きの話です。
「常に自分以外のユーザも遊べる状態を維持する」のが大事です。
新しいシステムや新しいレベルを作る時に、
「ちょっと（開発者だけが）テストできる状態で作る」
というのをやりがちですが、これが悪い膿です。
「ちょっとだけならええやろ」と作った仮部分は放置していくと
ミントの如くどんどん増殖していきます。
割れ窓理論の如く増えていきます。
気づいたら仮部分だらけの開発者しか遊べないゲームがそこに誕生します。

これを防ぐライフハックが「常に定期的に「公開」する」と
己に義務付けることです。場所はunityroomでいいでしょう。
そして不特定多数に全体公開する必要はなく、
自分のtimesにでも貼ればよいでしょう。

すまん今Cubisの方に集中してて新規に作ったやつ実践できてないや

そして遊んでくれるフォロワーがいればよい

これも前項から地続きです。結局全部続いているじゃねえか。
せっかく定期的に公開する形をとるのならば、
実際に他の人に遊んでもらうに越したことはないでしょう。
一人で作っていると徐々に視点が歪むので、
第三者の眼鏡を通してもらうことは効率的なゲーム開発の手法です。

量産するリソースの"メモ"は最初からガンガン実体にする

賢明なクリエイターの諸君はこう考えるかもしれません。

「最初にシステムを完璧に作り上げよう！
　リソース系を制作するEditor拡張や環境も最初にしっかり構築して、
　そうしたら一気にリソースを作ろう！　効率的に！」

これはバーティカルスライスであり、個人長期開発の死亡ルートです。

リソースの量産というのはつまりだいたいは単純作業であり、
単純作業が苦手なプログラマーはこの長距離マラソンのモチベ管理を
甘く見積もり、そして途中で力尽きます。

遷移のつなぎ合わせと最低限のインゲームが出来上がったら、
もう思いつき次第どんどんリソースを作った方が良いです。
これも前項で記述した、受け皿の部分に。
どうせ最初は完璧だとおもったリソース制作ツールも
リソースを制作しているうちにどんどん改善点が見つかるんだよ！！！！

システムの構築の息抜きにリソースを作り、
リソース制作の息抜きにシステムのブラッシュアップをしましょう。
それがモチベーションの管理術です（個人差はあります）

ちゃんとタスクは可視化して管理しましょう

これはまあ普通の話。
頭の中の記憶はアテにならないので、
一回テストプレイして気になった部分などを全てどこかにメモして、
そしてテストプレイを終わった後にまとめて消化しましょう。
見つけるパートと消化するパートはしっかり分けた方が良いです。

メモする場所はなんでもいいです。
がっつりしたチケット管理システムを使ってもいいし、
（個人ないしは少人数でやるなら）スプシでもExcelでもなんでもいいです。

蛇足：襲い掛かる傍観者効果の問題

……ところで前の項でテスト公開の話を書いたが。
此処を読んでいる人の大半はUGDG経由だと仮定した上での話ですが、
UGDGは単純なユーザ数だけなら1300人を超えているようで、
これは半パブリックみたいな規模なので、
「自分のtimesで公開した、遊んで！」で ※UGDG内の個人スペース
不特定多数に遊んでもらえるかは少し怪しい気もします。
一応 #_テストプレイ広場 という場所がギルド内にありますが、
あまり有効に機能している感じはしません。

これは某消防車のミーム化した漫画で説明される
傍観者効果に近いものがあると思います。

「そう!!! フィードバックは来ないのだ!!! なぜなら!!!」
「誰も!!! あなたのゲームを遊んでいないからである!!!」

傍観者効果の心理学でいわれているように、
なまじコミュニティの規模が大きいゆえに起こる可能性があるわけで……
これを回避するには元ネタ同様、より小規模で凝固なコミュニティに
所属する必要があるわけですが……

某松で友な配信のコメント欄の常連陣なんかは10数人の
密なコミュニティが形成されているわけで、
お互いが「ゲーム作って公開してみたよ」と言えばお互いが遊ぶ関係です。
そのような「お互いのゲームを遊んでフィードバックする」
小規模のクラスタが作れればベストなわけですが、
これを新規に作るのは自分にも具体的な上手い方法は思いつきません。
丁度u1wが近いしそのタイミングで同志を見つけましょう（無責任）

まとめ

ライフハックを書くつもりがなんかUGDGのコミュニティの実情にも
メス刺し始めたけどまあええや（

あとボクロボを買いましょう！
あとCubisのウィッシュリストも登録すると泣いて喜びます。

余談

この記事自体もこの手法で書きました。
まず雑でもいいから全項目書いて、後で清書する。
後からブラッシュアップしたり調整するのは思ったより容易く、
ゆえに最初の"土台"を作るのが大事である。

"DONE IS BETTER THAN PERFECT."
全てはこの一文に帰着する……。