ドウモ、バーチャル埼玉県民であり、リアル埼玉県民でもある者デス。
はじめに（宣伝）
はじめてファンメイドゲーム「春日部つくしの暴走 -ハナガサイタマ春日部変-」をリリースできたのでぜひプレイしてみてね。
あと、春日部つくしを推せ。
ついでに、春日部つむぎも推せ。
・・・宣伝が終わったので、ここからはちゃんと記事を書こうと思う。
この記事の要約
ファンメイドゲーム開発は、推し活と勉強が両方そなわり最強に見える、がそんなことはない。
（釣りタイトルで申し訳ない。）
リソースがない
- 仕事ではないし、直接的には仕事に繋がらないので時間等のリソースを集められない。
- 外乱（本業の活動の影響等）をもろに受け、プロジェクトが破綻しやすい。
ファンメイドゲーム特有の難しさがある
- Unityのアセットストアでは賄えない推し対象特有の要素があり、それについては必ずアセットを自分で用意する必要がある。
- 推し対象に失礼がないようにちゃんとしたクオリティを求めてしまい、完成できない。
「リリースできない」の処方箋
- 推しへの愛という精神論だけで挑まず、建設的に開発負荷も考える
- 低クオリティだと思っても「ゲームとして一通り遊べる」を一つのリリース基準にしてみる
- Web サイトとしての公開だとすぐに触ってもらえるので、友人とかからもフィードバックを受けやすく、モチベーションにつながる
本当の「はじめに」
先日ファンメイドゲームをリリースした。実はこれまで何度か挑戦したことがあるものの、どれもうまくいかなかったが、今回ようやく一本リリースできた。制作期間はおよそ一ヶ月である。
本記事ではこれまでの失敗や反省点等も踏まえて、ファンメイドゲーム開発について思ったことを自戒も含めてつらつらと書こうと思う。文字だけなので読むのがしんどいかもしれないが、そんな時は春日部つくしのカリンバ配信を聞いて癒されると良いだろう。
ファンメイドゲーム開発者が歩む開発体験（開発者の旅）に沿って記述するよう心がけた。あくまでこれは筆者の体験に基づいているものであって、一般論とは言えない部分も多々あると思うが、参考になれば幸いだ。
あと、「お前、一つしかリリースしておらんやんけ！」は禁句。それ言ったやつ出禁です。
読む前の注意
この記事はファンというよりもあくまで一開発者としてファンメイドゲーム開発を記述しようという試みであり、ファンとは思えないドライな表現が多々出てくると思うが、ご了承願いたい。特にこの記事では「ファンメイドゲーム開発」のネガティブな面をかなり記述することになる。
この記事の最後のおまけとしても書いているが、根底にある筆者の思想は「推したいというモチベーションをゲーム開発のコストが基本的に上回る」というものである。したがって、ファンメイドゲーム開発が途中で破綻しリリースできなくなるのはむしろ当然であり、推しへの想いが足りなかったからではない。
ファンメイドゲームを作り切るには、それ相応の 「開発」という活動を手懐ける技術がいる ということをこの記事から感じ取ってほしい。
筆者スペック
- エンジニア畑 🧑💻
- Web サイト、チョット作れる 🤏
- Unity でゲーム、チョット作れる 🤏
- インディーゲームを一度だけリリースしたことがある 🤏
- お金がない 😭
- ゲーム制作はしたい 💪
- ファンの中ではライト層だと自負 👍
- ライト層なので他のファンに対して引け目がある 😔
- というのは建前で、他のファンと仲良くしたいと思ってない（厄介） 🙄
- 埼玉県民 🏠
- 学生ではない 🧑💼
ファンメイドゲーム開発はなぜ難しいのか
具体的な開発者の旅を追う前に、なぜ難しいのかを最初に押さえておくと良いかもしれない。開発者には以下の三重苦が立ちはだかっている。
-
個人開発の難しさ
ファンメイドでは特にリソース不足からくる難しさ。 -
ゲーム開発の難しさ
プログラミングだけでなく絵や音楽等の複合的性質からくる難しさ。 -
ファンメイドの難しさ
「推し」という心理からくる難しさ。
「個人開発」や「ゲーム開発」に関する様々な言説は調べればたくさん出てくると思うのでそれは各自調べてほしいが、このあと語る開発者が体験する具体的な問題の中には、ファンメイドならではというよりかは、この「個人開発」ゆえ「ゲーム開発」ゆえの困難さが出てくる。
今回強調したいのはそれらに加えたファンメイドゆえの困難で、具体的には以下のような難しさが増える。
- 推し対象の要素を入れる必要がある
- 推し対象に失礼がないようクオリティ要求は高い
- 推しへの想いがあれば完成できるという幻想を抱きやすい
- 推しや他のファンが不快にならないよう配慮することが求められる
- 対価を求めない・量的で具体的な対価を想定できない
こういった根本的困難性を抱えながら、それが具体的にどのように現れるかを書いていこうと思う。
0. そもそもファンメイドゲームを作って良いのか
開発者はとりあえず制作したいゲームのイメージを思いついたとしよう。しかし、そもそもゲームとして制作可能なのだろうか。
二次創作に関するガイドライン・規約についてまずは調べる必要がある。推し（公式）がちゃんと許可しているのかを確認しなければならない。もし規約がなければ、基本的にはやるべきではない。（ちなみに「春日部つくし」については 公式サイト で二次創作ガイドラインの記述がある。）
また、推し対象が「人」に関わる場合は特に注意が必要で、（たとえ入れたいギャグパートがあるにせよ）その人格を傷つけない内容になっているか考える必要がある。
1. アセットの準備でつまづく
さて、これで一応作れそうだと確認したところで、開発者は制作したいゲームのイメージはあるものの、今目の前にあるのは Unity の初期立ち上げ画面だけである。今持っている完成イメージにできる限り近づけたいので、とりあえずアセットを準備したくなる。
しかし、開発者にアセットをどこまで準備できる能力があるのか。
特に開発者がエンジニア畑の場合は出鼻を挫かれるポイントである。プログラムを書いてグリグリ動かしたいけど動かすアセットがなくて初手からつまづく。しかも、このアセット準備は開発の旅最初の難関にして継続的問題なので開発中は常に悩まされることになる。
技術的制約
大きなゲーム会社のように、ゲームを作るのに十分な人や技術が集められるわけではない。今ある開発者の技術までの範囲で成し遂げなければならない。
なので開発者の手ではアセットを用意するのにとても手間がかかる or 用意できないという問題にぶつかる。
実は、ただのオリジナルゲーム制作の場合、これらをうまく立ち回ったり妥協すればこの制約を認めつつ作ることができる。Unity アセットストアを利用したり、円や四角など幾何学図形だけを利用してゲームを作ることはできるからである。
しかし、ファンメイドという特性上、開発者の推し対象の要素を入れることは必須であり、何らかの自作アセットの制作はしなければならない。
アセット制作の技能に乏しい開発者の場合、このアセット制作でどんどんやる気が削がれていく。アセット作り自体も正直地道な作業であり、ダイナミックでない。
エンジニアとしてはプログラムを書きたいのに着手できない上、動いているものができないので Unity の画面は殺風景のままである。
フリー素材ハントの大変さ
世の中はとても素晴らしい人々に支えられていて、画像、音楽、効果音、フォント等を無料で提供してくれている人たちがいる。本当に頭が下がる。
ただ、ちゃんとした供給があるゆえに探すのが大変になる。「よりこのゲームに合った素材が存在するのではないか」という不安と期待が大きくなり、選定に時間がかかってしまいがちである。
また利用規約的に使えるのかをちゃんと確認しながら進める必要がある。
特に問題となるのはフォントで、以下のような注意が必要だ。
- 個人利用可能であってもゲームソフトなどに同梱するのはNGな場合がある。
- ゲームソフトへの同梱はフォントデータ自体が入るので再配布にあたる。再配布禁止のものは使えないものとみなす。（再配布禁止でも明示的にゲームソフトへの同梱が許可されている場合もある。）
- 再配布等の禁止・許可が明示的に書かれてない場合は禁止されているとみなす。
こういう条件を通してみるとフリーフォントもゲームに同梱する場合は結構絞られ、使いたいと思ったフォントも使えない場合がある。ただしフォントデータ自体を同梱しなければいいので、タイトルロゴのみとかのピンポイント利用であれば画像として作って用意するなどの対策はできる。
（ちなみに、TextMeshPro で使うとき Font Asset Creator からTMP_Font Assetに変換するけど、あのファイルってどういう扱いなのか気になっている。）
それでもアセットは開発上必要
「モックでいいじゃん。適当な四角（俗に豆腐と呼ばれる）をおいて実装していけばいいじゃん。」という言い分がある。これは正しいが、結局アセットがないとテンションは上がらない。動かしたい！という気持ちが湧かない。結果プログラムもまともに進まない。仕事ではないので、テンションやモチベーションはとても大事な指標である。
ただ、動いているものがあるというだけで開発モチベーションは本当に変わる。さらに推し対象（アセット）を自分の操作で動かせるようになると楽しい気持ちになる。だから動くものを迅速に作ることは大事。
とはいえ、本当に全てアセットを用意しようとするととても時間がかかり、プロジェクト破綻確率が極めて上がる。重要なのは本当に必要なものは用意しつつそれ以外を作らずに上手く誤魔化す方法を見つけることだ。
例えば、筆者が今回作ったゲームでは"世界が真っ暗になってしまった"という設定を付与することで、背景を描く必要をなくした。これによってだいぶ実現性が上がった。
それでも最終的には開発全体の時間のうち 1/2 から 2/3 程度の時間がアセットの準備に費やされていた印象である。（最初だけでなく開発を進めながら準備する時間も含む。）
2. 能力不足に気づく
もうすでにだいぶ挫けそうだが、それを一旦なんとか乗り越え、アセットとの付き合い方がわかってきた開発者。
だんだんとアセットが揃ってゲームロジックも組めるようになり、動くものができてくる。
しかし、そこでじわじわと絶望が始まる。
完成イメージのゲーム規模が大きすぎる
だんだん具体的なものが見え始めると、最初に想定（妄想）していたゲーム規模の大きさが具体的に見積もれるようになってくる。そしていかに馬鹿げた規模のイメージを持っていたかがわかるようになる。
せっかく順調に進み出したのに、進んだがゆえに絶望することになる。しかも悲しいことに最初に抱いていた完成イメージも、作り始める前時点では「やっぱ作れる範囲のミニマルなものじゃないと厳しいよな！」と思っていたにもかかわらずこれが起こる。（N敗）
結局のところある程度進めないと全貌は把握できない。そしてファンメイドという確実に趣味でやる以上、仕事の時のように「作業前に見積もりを出すぞ」という考えになりにくいのである。
初心者向けに「本当に小さなクソゲーでもいいから作ってみよう！」という言説はよくみるが、実践するのはなかなか難しい。そもそもどの程度のゲームや規模感が「できる範囲」なのかを想像できないからである。
想像よりも大きなビジョンだったことによって、挫折することも多い。
簡単にリリースできている（ように見える）人たちは基本的に技術力ムキムキの猛者たちだと思ってよい。少なくとも経験値の差がある可能性が高い。一般人と一緒にしてはいけない。
リソースが足りない
開発者でやりがちなもう一つの問題は技術以外のリソースを考慮し忘れることである。そしてそれは少し時間が経ってから発覚する。（N敗）
仕事では技術的に可能だがやりたくないことを避けようとしているにも関わらず、いざ趣味で作るとなると技術的可能性だけで判断しがちである。
ただでさえ仕事以外の時間は仕事の時間よりも確保しづらい。リソースの見積もりの甘さはプロジェクトの継続性に響いてくる。
技術だけでなく、体力や時間等の総合的な「能力」に見合ったものでないと趣味で作るにはなかなか難しい。
「完成イメージのゲーム規模」の過小評価もそうだが、「開発者の持つリソース」も過大評価してしまいがちである。
結局のところ、失敗を繰り返しながらラインを見極めるという順当で泥臭い方法が最善である。
3. モチベーションの継続が難しい
能力不足を認め、それでも能力に見合ったものを作ろうと捉え直した開発者。日々の中にゲーム開発が組み込まれるようになってきた。
しかし、その継続はあまりにも困難である。
理想と現実の乖離
これまでで一度は自身の能力の限界と折り合いをつけたはずだが、それでも理想と現実とのギャップに継続的に苦しめられることになる。
- 自分の理想とはかけ離れた、妥協の結果としてのアセットと実装の数々
- 進捗もまた予定通りには進まず、どんどんリリース日は遠のいていく
- 開発する時間が十分に確保できない
- 時間は確保できても体力や精神がついていかない
- 実装すると新たな実装が必要になる
この焦燥感と不満の蓄積に耐えられずギブアップするケースはかなり多いのではないだろうか。
自身の能力と折り合いをつけるのは、そのギャップを感じた最初だけで終わりではない。それを継続的にし続ける必要がある。
ただ、ギブアップしたいという気持ちを責めないでほしい。誰でもこうなる。リリースが遅れたりすることを誰も攻めやしない。だって趣味の開発だもの。
でも、逃避したくなるということは何らかの大きな耐えがたい負荷が潜んではいないだろうか。それが何かを振り返ってみて改善してみたり、どうしようもない場合は違う手段や表現はないかを模索してみたりするのがいいかもしれない。
プロジェクト外の影響
仕事ではないゆえに、プロジェクト外（本業等）の活動の影響をもろに受ける。仕事とは異なりそのプロジェクトの進行を守ってくれる強制力が低い。なので本業が忙しくなると優先順位の低い趣味のプロジェクトの進行が真っ先に止められる。
摩擦と同じで一度止まると再び作業するのに抵抗が大きくなる。そのため、これはプロジェクトが破綻する十分な要因になる。
これは対策のしようがなく、難しい課題である。
労力に対する動機づけが弱い
本業のお仕事にせよ個人開発にせよ、その労力は最終的に金銭として対価を受けられることが期待されている。オープンソース開発であっても、巡り巡って自身の営利につながることであり、具体的な利益を想定できる。（金銭に注目したのはちょっとミスリードだが、ここでは量的にわかりやすい対価を想定できるということを強調したい。）
しかし、ファンメイドの開発は一体なんのためにやっているのだろうか。抽象的な説明はできるかもしれないが、具体的な対価を想定することが難しい。この具体性の低さは、いざモチベーションが低下した時に自分自身を説得できなくなる一つの要因である。
また、対価の具体性が低いゆえに労力を減らすインセンティブも低くなる。
営利目的の活動である場合、ある機能等を追加するのにかかる労力と、その機能によって期待される対価とを天秤にかけて判断することができる。したがって、何をやって何をやらないのかが議論可能になる。これによって導かれるのは、最小の労力で最大の対価が期待できる機能実装を優先するようになることだ。
一方ファンメイドでは労力に対しての天秤にかけるものが想定しにくい。なんなら頑張れば頑張るだけ推しへの想いを表現できる・良いものができるという思考に陥りがちである。その結果投下する労力が増え続け、最終的にそのコストの蓄積が自身のモチベーションを上回る時がくる。
基本的には気長にやっていくことを覚悟するか、怠惰な選択をとり続けるかを考えた方が良い。ただ、人の持つ忍耐力の限界を考えると後者の方が最終的なリリース到達確率は高いとは思う。
（ちなみに誕生日などの記念日に合わせてリリースしようというのは残り時間を天秤にかけられるので良さそうだが、作業時間の見積もりの難しさと、リリースが間に合わなかった時のモチベーション低下が凄まじいので諸刃の剣である。）
4. 改善サイクルの罠
さて、そんなことを乗り越えてついに開発者は「遊べるもの」を用意できるようになった。ここでいう遊べるものとは完成したものではなく、1-1面だとか、プレイ可能なゲームの最小単位というべきものである。
ここまで来るとレベルデザインを考えたり、実際の実装レベルではなく一つメタな作業になっていく。その時に必要なのは PDCA などといった改善サイクルを回していくことである。
レベルデザインの難しさ
レベルデザインは本当に難しい。そもそもレベルデザインだけで本にできるくらい難しい。筆者も難しいと思いつつ勉強まではしたことがないので、理論的なことは言及できない。
ただ開発者が完全に個人であれば起こる問題は経験上ある。「制作者、制作中ゲームに上手くなってしまう」現象である。アクションゲームだとこの傾向は顕著である。
制作者はデバッグや動きの確認等で何度もプレイすることになる。そのため制作者自身がそのゲームに対して上手くなってしまい、特に最初の方の面で「なんかコショウ足りないな」感覚で安易に難しくしがちである。
またレベルデザインとは少し違うが、制作者は自分で作ったシステム・操作に慣れるので、操作自体の難しさや説明不足を発見しづらい。
特に推しが配信者の場合、その配信者がやるかも、という場面では誰かを捕まえてプレイさせてみることは重要。もはや自分の感覚を信じてはいけない。
しかし、ゲームが上手い友達とかにやらせても、それはそれで良いプレイヤーサンプルにならないので注意が必要である。
「改善のしづらさ」の改善
改善する際、「改善のしづらさ」によってサイクルがうまく回らないことがある。例えば、ゲーム内の盤面や挙動が簡単に変えられない（しなければならない手続きが多い）ことや、ソースコードに直に埋め込まれた値がある（ことによって毎回コンパイルが走る）等である。ソースコードの構成や書き方等で変更コストが（心理的ハードルも）高くなり、結果として改善の効率が落ちる。
良いコードを書くモチベーションはこういうところにクリティカルに効いてくるが、しかし、この改善可能なフェーズになるまで気付きにくいところでもある。厄介なのは「改善しづらい」ソースコードの修正はコード自体も改善しづらいので骨が折れることである。しかし、これは時間と共に負債が大きくなるので気づいた時に対処するのが吉である。
改善がしやすい環境の必要性に気づく
改善サイクルにおいて、開発者以外の人にプレイしてもらうことは有効である。
しかし、その「プレイしてもらう」こと自体がかなりハードルが高い。いつもリアルで会える人ならまだしもインターネット越しだったりでなければ難しい場合は大変である。
筆者の場合はデプロイ先をそもそも Web サイトとしていたので、Web サイトを通して共有した。Web サイトで共有するためには当然 Web サイトを用意する手間が発生するが、その手間に対して有り余るメリットを感じた。
-
Web 上だと友人などにすぐに触ってもらえるし、触ってもらえる確率が高い
- ダウンロード・インストールなどの手間な作業があるとやってくれないことが多い
- Web サイトの場合はURLを共有するだけだし、そのリンクを飛べばすぐにプレイもできる
-
友人でなくとも、複数の開発メンバーがいるのであれば、他のメンバーが手間なしにすぐに実装を確認できる
- 開発メンバーであっても Unity の操作に慣れないメンバーがいる中だと、Unityに触らせること自体が心理的負荷になることがある
- 心理的負荷が高いとメンバーのプロジェクト離脱確率が上がる
- いずれにせよフィードバックが早い
ただし、注意点としては、Unity の WebGL の出力が結構時間がかかることである。linking build.js (wasm) ですごい待たされる。
これは、development buildモードにすると速くなるのでその活用はした方が良い。もちろん開発中の素早いサイクルのためであって、間違っても本番用のビルドではしないこと。
Web サイト上に Unity のビルドを公開・共有するには以下の拙著・共著を読んでもらうと良いかもしれない。
また筆者は使ったことはないが Unity 公式が提供している Unity Play というサービスがあるらしいのでそれを活用しても良い。
Unity Japan で Web 出力に関する案内動画があるので一見してみると良いだろう。
5. いつまでもリリースできない
この改善サイクルを通して開発者はプロジェクト終盤に差し掛かってくる。
しかし、もうリリース可能な塊は見えているにも関わらず、進まない。リリースが見えているが故に開発を続けなければと考えるが、しんどいし逃げ出したいという矛盾に苦しめられる。ここまできた場合、「やめれば苦しみから解放される」ではなく、「リリースすれば解放される」なので逃げ道がないのもキツい。
ここで 90対90の法則という格言を紹介する。（日本語訳）
コードの90%が、開発時間の最初の90%を占めている。残りの10%のコードが、他の90%の開発時間を占めている。
使用文脈としてはちょっとズレた引用かもしれないが、最後がなかなか終わらないというのは開発体験としてはよくあり、リリースは開発者の最後の難所である。
合格点の基準が高すぎる
大体の場合はリリース合格ラインの基準が高いことによってリリースができなくなる。特にファンメイドでは推しに失礼がないように「ちゃんとしたクオリティ」を求めがちである。
ただこの「ちゃんとしたクオリティ」の基準が以下の点で非常に厄介である。
- 「ちゃんとしたクオリティ」基準は見慣れたゲームと同等レベルにしがち。見慣れたゲームというのは結局「任〇堂」とかの大手企業製品のクオリティ。リソース的に個人では到達不可能なので目標が高すぎる。
- 同人ゲームをプレイしている人たちでも有名ゲーム程度を基準にしがちで、少なくともそれらはクオリティが高かったから有名ゲームになっている前提を忘れている。
- 「フ〇イナルソード」とかも一時期有名になったが、あれは「ゲームとして最後まで遊べる」ことが担保できている時点でちゃんとしたクオリティなのだ。「あの程度」と思っている人がいるかもしれないが、「あの程度」でさえ作るのは大変なのであり、むしろ話題になるくらいには「何をやりたかったかがわかる」ので、結構頑張っている。（あれは有料ゲームなので同列に語っていいというわけではないが。）
できる限りリリース合格ラインを下げることを考えた方が良い。正直なところお金を稼ぐための実利あるプロダクト開発ではないのでリスクなど初めからないのだ。あとから更新してもいける。
しかしどうしてもクオリティを気にしてしまうあなたに、こんなことを言っておこう。
あなたの推しは低クオリティであったら貶すような存在なのか。お前の信じる推しを信じろ。
もしダメであれば、改善サイクルをまた回せばいい。最初から高いクオリティを出そうとするな。リリースはお前のプライドよりも重い。
正直今回筆者がリリースしたゲームは個人的には100点満点中10点のクオリティだ。
本当は会話シーンのカメラ、キャラクターの動きや演出等を入れたかったし、（なんなら春日部つむぎを使ってんならVOICEVOX使ってボイス入れろって話だし、）それを制御できる仕組みも用意したかった。もっと盤面も作りたいし、セーブ・ロード機能も用意したかった。ストーリーももっと起伏をつけて面白くできたら良かった。
ただ、能力の限界と、リリースに重心を置く価値観を持つようにしたので、極めて遺憾だがそれでもリリースを優先した。
求めている・ほしい機能一つ一つはそこまでハードではないかもしれない。しかしその総量は大きく、それをやっていたらいつまで経ってもリリースできない。
なので「ゲームとして一通り遊べる」を最小の価値とみなしてリリースした。そこから需要があれば拡張していこうと割り切った。
リリースの優先性およびその価値観は以下の拙著に書いてあるので一目していただければと。
それ以外の観点
二作目以降に起こる問題
一度リリースできたからといって、次もリリースできるという保証はない。
特に一作目の改善点が多い場合は、その反動でオーバーエンジニアリングになって（必要以上に問題を先回りして対策に時間をかけてしまい）完成しない。あるいはゲーム自体に対する進捗がでない。
オーバーエンジニアリングを乗り越えた先に本当の技術力が待っていると筆者は考えている。
開発チーム立ち上げにおける問題
言い出しっぺの責任は大きいし、周りは意外と協力してくれない。
「責任が発生する前に自分でやれるだけやっておけ」 という精神の方が良いと考えている。むしろそれすらもできない場合は自分ですら難しいのだから、相手と一緒にやるのはもっと難しい。
友達でもなんでも自分以外の人に頼んで（巻き込んで）プロジェクトを進めるということは、それが上手くいかなかった場合の責任が大きくなる。特に時間や労力が注がれれば注がれるほど大きくなる。
少なくとも誘った自身の責任を最小化するために、やれるところはやっておき、完成までやり切れる確率をあらかじめ最大化しておくこと。
金銭的に縛っている（本当に発注してやっている）のであれば別だが、なんの拘束力もないプロジェクト運営はかなり難しい。またプライベート上の信頼関係とプロジェクト運営上の信頼関係は全く別であることを理解しておく必要がある。人ではなく能力に対して信頼する必要がある。
最後に
ここまで長々と書いてきた。半分も読んでないよという人も多いことだろう。なんなら目次読めば言いたいこと全部わかるのでそれでいいと思う。
最後まで読んでくれた方はありがとう。画面に集中して筋肉が凝ってしまっているだろうから、ほぐすために春日部つくしと筋トレでもしてみたらどうだろうか。
最後に少しだけ書きたいことを書く。
「Flappy Bird」は偉大
「Flappy Bird」は初心者向けの学習でよく出てくる題材である。タップすると少し上に飛び、タイミングよく飛び続けながら穴を潜り抜けていく強制横スクロールアクションゲームである。
簡便ながらゲーム性が十分にある上、結構味付けしやすいゲームであり、必要素材も実はかなり少ない。優れたフォーマットのゲームだと思っている。
ストーリー要素が増えるとアセット量も膨大になるので、ファンメイドゲーム作ってみたいマンはまずは「Flappy Bird」を推し向けにアレンジしてみるといいかもしれない。
とりあえず、全ての人の全ての推しに対して、それぞれにアレンジされた「Flappy Bird」がリリースされればいいと思う。
「記事駆動開発」という方法論
実は今回あえて立項しなかったが、うまくいった要因のもう一つは「記事を書くこと」だったようにも思う。
今年に入って Zenn に記事を投稿しはじめたのだが、その中で沸々とファンメイドゲーム開発の困難性を記事にしたいと思っていた。しかし、筆者が一本もファンメイドゲームを出してないのにも関わらずその記事は書けないと思い、今回頑張ったところがある。つまりこの記事を投稿すること自体がモチベーションを支える原動力の一つだった。
これはファンメイドゲームでなくても、あらゆる開発で可能なフォーマットではないだろうか。だからみんなも「記事駆動開発」やってみよう！
おまけ
筆者はスーパーマン？
この記事で開発の大変さを長々と語ってきたが、それを一人でリリースしたこの記事の筆者は一体何者なのだろうか。極めて計画的で時間をちゃんと確保し確実に開発を進めていってリリースした超人だったのだろうか。
否、全く異なる。
- 普通にリソースが全く足りないので仕事をサボりながら制作してた。（案件終わった後でちょっと暇な期間だったから許してー。）
- これ以上リソースを費やせなくなったので開発を切り上げねばならなくなった。
- 10点のクオリティは本当に遺憾だが、ボロボロになりながら無理やりリリースした。
- 「リリース優先だから」はさすがに言い訳かもしれない。
なんでこの記事はideaではなくtech？
そりゃあ記事投稿コンテストにエントリーしたかったからでしょうよ。
実際のところ、ファンメイドゲーム開発というのはそのイメージとは裏腹に（？）推しへの想い・愛という精神論だけではどうしようもないハードルがあるということは言いたかった。（もちろん精神論で成し遂げちゃう人もいる。）
特にファンメイドゲームを一度でも作りてぇなぁと思う人たちの中には、ゲーム開発や個人開発の実態を知らないままに考えているところがあるだろう。何ならゲーム開発や個人開発の経験がある方が稀である。
開発には技術が必要である。これは単に絵が描けるとか、プログラミングができるとか、そういう話ではなく、開発という活動そのものに技術がいるということであり、そうした背景でアジャイルあたりの様々な開発手法が提案されている。
そういった開発手法もあわせて勉強をしながら開発するのが望ましいのではないだろうか。
Discussion