2021-12-01に更新
ゲーム開発 1日目

個人ゲーム開発の壁

個人で初めてゲーム開発をしようとしたときに障壁になりそうなものを個人的メモとしてまとめてみます。

障壁になりそうなものについて単に思いついたものを羅列して書いたもので、それぞれの対処法は未調査、または未整理であるため、ここで対処法について詳しくは記述しません。

個人ゲーム開発の障壁となりそうなものは、以下のものです。

  • ゲームアイディア発想の壁とメンタルブロック
  • 技術選定の壁
  • プログラミング学習の壁
  • プログラム設計の壁
  • デバッグの壁
  • パフォーマンスチューニングの壁
  • グラフィックデザインの壁
  • 作曲の壁
  • 物語創作の壁
  • プロジェクトマネジメントの壁
  • ゲームデザインの壁
  • マーケティングの壁

ゲームアイディア発想の壁とメンタルブロック

ゲームを作ろうとしたはいいものの、どのような内容のゲームを作るべきかが思いつかない、という問題です。

すでに作りたい内容が明確に構想できている場合は、ここの問題はスキップされます。

この問題に対して先人らはよく「作りたいもの作ればいいじゃん」とか言いますが、その作りたいものが何かわからない、というような状況がありそうです。さらに「作りたいものが無いなら、そもそもゲーム開発なんてできない/ゲーム作りは向いてない」などと追い打ちをかけられることもあります。

すでに世に出ているゲームの模倣をする、という方法も取れますが、その場合「ゲームアイディアの発想」以外の取り組みの練習にはなりそうですが、肝心の「ゲームアイディア発想」自体はスキップされ、その能力を養う機会を損失しそうです。

また、ゲームアイディアを発想してみたものの、自らの冷静で客観的な評価として否定される(”自分の中のもう一人の自分”や"自分の中の他人”が否定的な評価をささやき、そのゲームを作ることをやめさせる)問題があります。このような「自分の行動を制限しようとする思考」は、通称「メンタルブロック」と呼ばれています。(もう一人の自分が「そんなゲーム作ってどうするんだ?」「どのゲームのどこがおもしろいんだ?」などとささやいてくる)

技術選定の壁

ゲーム開発の技術的な知識がほとんど無い状態だと、何を使ってゲーム開発すべきかがわからない場合があります。

この場合、Webで情報を検索してみたり、質問サイトで相談する、という方法がとれます。そして、(下書き執筆開始の)2020年12月執筆時点では、個人ゲーム開発で使用する技術としておそらく一番多くおすすめされるものが Unity というゲームエンジン兼各種エディター、ツールで、次点で Unreal Engine がおすすめされるでしょう。

たまに素のプログラミング言語(とその処理系)から、Unity のようなツール群を使わずにゲーム開発をしたい、という(学習者の技術投資の価値観としての)ケースがありますが、その場合は、各種プログラミング言語とその処理系、実行環境との相性などの特徴から選定を行う必要があるため、迷いが発生しやすいです。

昨今、ゲーム開発企業の現場から「Unityの表面的な部分しか使えないより、もっと奥深い部分を理解して使いこなせる人材がほしい」という声も聞かれるため、もし個人でゲームを作ろうとする理由が就職のためである場合に、Unity 以外の選択肢を選ぼうとする理由が生まれる可能性はあります。

「Unity でも深く学べば、奥深い仕組みの部分も学べるんじゃないか」という意見もありそうですが、Unity が持つ機能の一部はブラックボックス(中身が見えないもの)であり、むしろ、「奥深く中身を見なくてもゲーム開発ができるようにするためのツール」であるため、やはり、Unity についてのみ学習することは、その奥深い、コンピューターに近い部分の仕組みや、レンダリングの仕組みや手法、その特性などを学ぶ機会を失う可能性が否めません。

プログラミング学習の壁

多くの開発環境では、プログラミング言語を駆使する必要があるため、プログラミング言語についての学習を行う必要があります。しかし、この段階でつまづくケースがあります。(Unity では C# というプログラミング言語を駆使する必要があります)

多くの場合、学習の順序、段階をスキップしているがゆえに起こる問題が多いように思います。例えば、プログラミング言語の文法の学習をスキップして、作ろうとしているゲームの機能の実装方法を調べて(「〇〇の作り方」などと検索して)得られたプログラムの断片をコピーして作ろうとすると(いわゆる「コピペプログラミング」と呼ばれる方法)、コンパイルエラーや意図しない動作への自力での対処が難しく、このような状況に陥ると「ゲーム開発は難しい」「わからない」などの感想を強く持ち、ゲーム開発をあきらめる理由が強化されます。

かと言って、プログラミング言語の文法をいちからじっくり学ぶ方法をとっても、いつまで経っても動くゲームを作ることができず、学習が飽きてしまうという問題が指摘されることがあります。そのため「プログラミング言語の学習と、ゲームの実装の両方を、ほどほどにバランスよく進める」という助言がされることもありますが、どうやったらほどほどにバランスが良いのかの指標が具体的に提示されることは少ないため、なかなか迷いやすい部分にはなりそうです。

「自分は今、どの部分の知識が足りていないがゆえに、今の問題に直面しているのか」が可視化されれば問題に対処しやすいですが、現時点ではそれを可視化するための良い方法が普及しているとは言い難いため、救われない人が多くいるのではないかと想像します。

学習のガイド役となるような(いわゆるメンター的な)存在が身近にいて、学習をガイドしてくれるなら救いの道があります。このガイド役は「学習者がいま問題に直面しているのは、どの部分の知識が足りていないからなのか」について分析(広義のカウンセリング)をして、どの部分の知識が足りていないのかを知り、その不足を補うための("処方箋"のような)具体的な対処法を提示する必要があります。

この分析をせずに無理に助言をしようとする場合、その多くは「説教」のようになってしまうでしょう。

プログラム設計の壁

小規模のゲーム開発であれば、プログラム設計が雑でも”チカラ技"で完成させることができるかもしれないですが、中規模以上のゲーム開発となると、雑なプログラム設計では、ちょっとした機能追加や修正作業でもプログラムを変更する箇所が多すぎたり、データとロジックの不整合などによってプログラムのうまい変更方法を思いつけなくなったり(この場合は、たいてい作り直すのが早い)、プログラムの変更が意図しない機能に影響を与えて不具合を生んだり、などのような問題が起きます。

この分野に関しては「プログラムの一般化/抽象化/モデル化」「高凝集化」「疎結合」「関心の分離」「オブジェクト指向設計」などのキーワードで語られることがあり、高度なものになると「MVC」「MVVM」「双方向データフロー」「単方向データフロー」「クリーンアーキテクチャ」「リアクティブプログラミング」「ドメイン駆動開発」などのソフトウェアアーキテクチャの分野で説明されることがあります。

これらの分野は、自主的かつ積極的にプログラミング関連の情報を収集しているか、学習のガイド役の人がガイドをしない限り、学習しようとする機会が生まれないかもしれないです。

デバッグの壁

プログラミング初学者が、コンパイルエラー、実行時エラー、意図しない動作に遭遇したときの対処方法を積極的に学ぶ機会は少ないかもしれません。

コンパイルエラー、実行時エラーのエラー文の意味を解読するためにはプログラミング言語の文法を理解している必要があるため、そのエラーの対象となる文法の学習をスキップしている場合は、その解読ができません。(エラー文で検索して出てきた対処法を見よう見まねで組み込んでも、それは付け焼刃的なものになるでしょう)

また、実行時エラーや意図しない動作に対処する場合、何らかのデバッグテクニックや、いわゆる「デバッガー」というツールを駆使して、問題の原因を特定する必要があります。しかし、プログラミング初学者は「実行時エラーや意図しない動作の原因を特定するためにはデバッガーを使えば良い」ということ自体を知っていないケースがあり、たまたまデバッグ方法について上手に説明している教材に巡り合えたか、良いガイドがされた場合だけに成長が約束されます。

パフォーマンスチューニングの壁

ゲームを作ってはみたものの、メモリ使用量が多すぎたり、処理に時間がかかりすぎてフレームレートが低くなったりなどの問題が起こることがあります。

このようなとき、いわゆる「プロファイラー」と呼ばれるようなツールを使ってボトルネックを発見し、そのボトルネックを解消させる必要があります。

メモリ使用量や実行速度の問題が起きた時に「プロファイラーを使ってボトルネックを見つけて解消する」という方法を自体を知るには、かなりプログラミングについて調査、学習をしているか、良いガイドが必要になります。

グラフィックデザインの壁

自作でゲームを作るからには、グラフィック素材についても自作したい、と思うケースがあります。ゲームに近いグラフィックデザインに関する理論が確立されているのかどうかは筆者はわかりません。

お金に余裕があれば、上手な人に頼んだり、有償の素材を購入するという対処ができます。

フリー素材を使うという方法もあります。

作曲の壁

自作でゲームを作るからには、音楽素材(または効果音)についても自作したい、と思うケースがあります。音楽理論は長い歴史で確立されているので、学習しやすい分野ではあるかもしれないです。

お金に余裕があれば、上手な人に頼んだり、有償の素材を購入するという対処ができます。

フリー素材を使うという方法もあります。

物語創作の壁

物語要素を含めたゲームを作る場合、その物語を作る必要があります。

物語要素を含むゲーム作品では、その物語の内容はオリジナルである必要があるため、グラフィック素材や音楽のようにすでに提供されている素材を使う、というような方法はとれません。

良い物語を作るため方法論は長い歴史の中で割と確立されているようで、関連した書籍が多く出版されている印象がありますが、その書籍を購入するための資金と、その書籍を用いた学習をするための時間と心的リソースは必要になります。

プロジェクトマネジメントの壁

中規模以上のゲームを開発するような場合、プロジェクト管理を上手くやらなければ以下のような問題が起こります。

  • 次に取り組むべき作業が何かわからない
  • どこまで作業をすれば良いのかわからない
  • いつ完成するのか見えない
  • 今どのくらい作業が進んでいるのかわからない(残りの作業がどのくらいあるのかわからない)
  • 仕様の何を直せばいいのかわからない(目指す品質・優先しない品質が何かわからない)

いわゆる「創作のモチベーション維持」がうまくできていない場合は、ここがうまくできていない可能性があります。

ゲームデザインの壁

思い描いたゲームの試作してみたものの、「思っていたものと違う」「どうも面白くない」というような場合はゲームの内容を上手く修正して良い内容に変えていく必要がありますが、具体的に何をどう変えたら良くなるのかがわからない場合があります。

ゲームの内容の良さに影響する要素は複数ありますが、それぞれで良さを生むようにするための方法はそれぞれで専門性があります。例えば、ゲームの競技ルールが良くないがためにゲーム展開が盛り上がりに欠けるようになってしまったり、視覚効果が貧弱でゲームプレイで高揚感が得られにくい、などあります。競技デザインと視覚効果デザインは専門性が異なります。

マーケティングの壁

これはすでにゲームが完成したあとの話になるが、「作ったゲームが知れ渡らない」「作ったゲームが良い評価を受けない」というような場合、マーケティングの視点でゲームの内容を見直す必要が出てくる。

ツイッターでシェア
みんなに共有、忘れないようにメモ

mozukichi

Crieitは誰でも投稿できるサービスです。 是非記事の投稿をお願いします。どんな軽い内容でも投稿できます。

また、「こんな記事が読みたいけど見つからない!」という方は是非記事投稿リクエストボードへ!

有料記事を販売できるようになりました!

こじんまりと作業ログやメモ、進捗を書き残しておきたい方はボード機能をご利用ください。
ボードとは?

コメント