Unity でのゲーム開発に対するカオス ゴブリンのアプローチ

ゲーム開発プロジェクトを開始するときに最も麻痺する感情の 1 つは、ゲーム ジャムのためにナプキンに書き留めたいくつかのアイデアであれ、伝統的な 10 ページのデザインであれ、最初のゲーム デザインを終えた直後に感じる感情です。書類。

というのは、ゲームを ROGUELITE-RTS-MMORPG にすることを決めたら、実際にそれを構築する必要があるからです。

そして、最初に構築するのは RTS 部分であると決めたとします。そこで、ユーザー ストーリー、タスク、または自分自身を整理するために使用する作業単位を書き留めます。

次に、そのリストの最初の項目が「スクロール可能なマップの実装」であるとします。

そしておっと！スクロール可能なマップを実装したことがありません。でも、心配する必要はありません。Googleが助けてくれます。そうでしょう?

しかし、オンラインで見つけたソリューションが必要なことを正確に実行しない場合はどうなるでしょうか?それとも、あなたが見つけた解決策は 15 年前のものですか?それとも、その下に、その解決策がいかにひどいかを述べているコメントがたくさんあるのに、より良い解決策を指定するコメントは 1 つもありません[^0]?

したがって、構築しようとしているものについてのコードリファレンスが見つかりません。ゲーム開発者は何をすべきですか?

答えはカオスゴブリンモードに入る事です。

カオスゴブリンモードに突入

ゴブリンに馴染みのない人のために説明すると、ゴブリンはいくつかのファンタジー作品でよく登場する種族であり、通常、より本格的なオークやホブゴブリンの小さないとことして描かれています。他のいくつかのプロパティでは、彼らは非常に特殊な方法で機械に熟練しているように描かれています。そしてその方法は信頼できません。つまり、ゴブリンが作ったものは、うまく設計されたり作られたりしたからではなく、純粋な創意工夫と頑固さによって機能することがあります。

それがゲーム開発に対する Chaos ゴブリンのアプローチの本質です。さて、ここで少し話が逸れ始めていると思いますので、戻ってカオス ゴブリンの本質を要約させてください。

この点をさらに詳しく説明するために、Fallout 3 の大統領メトロヘッドについて話しましょう (全文はここで読むことができます)。その要点は、プレーヤーが地下鉄の車内に立っていると思っているゲームのシーン中、プレーヤーのヘッドギアは実際には地下鉄車両のモデルに置き換えられており、地下鉄車両の上を移動しているのはプレーヤー自身のモデルであるということです。あらかじめ決められたトラック。

これを読んで、開発者が怠けていると思うプレイヤーもいるかもしれません。しかし実のところ、開発者は常にこのようなことを行っているのです。

そして、まさにそのような実践こそが、次のようなカオス ゴブリン モードの教義を形成しています。

プレイヤーが知らないことで傷つくことはありません

ゲームの一部で、プレイヤーが城の塔の内側に立って、外を飛んでいるドラゴンに矢を放っているとします。時々、ドラゴンが近づいてきて、窓から頭を突き出してプレイヤーに噛み付こうとします。

さて、プレイヤーに関する限り、ドラゴンは実際にそこを飛んでいます。しかし、私たちゲーム開発者は、この幻想を解消し、状況を最適化するために、いくつかのトリックを採用したかもしれません。

実行できることは次のとおりです。

• ドラゴンがプレイヤーからどれだけ離れているかに応じて、異なるモデルを使用してください。プレイヤーがドラゴンの詳細を見ることができるのは、ドラゴンが近づいたときだけです。そのため、ドラゴンの 3D モデルを、詳細度が低く、メモリ内で占有するスペースも少ないものに置き換えてはどうでしょうか?

  
  

• プレイヤーが見ていないときはドラゴンの電源を切ります。プレーヤーが見ている場所を追跡することで、3D モデルのオンとオフを選択的に切り替えて、レンダリングを節約できます。

  
  

• プレイヤーに未完成の作業が表示されないようにします。何らかの理由で、塔の外の環境に関するアートが未完成だとしましょう。したがって、プレイヤーが窓の出っ張りに出ても、何も見えません。これを解決するために、ゲーム デザイナーは窓の出っ張りが即死スポットになることを決定しました。そのため、プレイヤーが棚の上に立つと、ドラゴンの咆哮音が 3 秒間再生され、プレイヤーの画面が暗くなり始めます。 3 秒間のサウンドが終了すると、ドラゴンがプレイヤーを食べる簡単なアニメーションが再生されます (おそらく、既にあったアニメーションを再利用します)。プレイヤーに関する限り、棚はドラゴンが彼らを狙い撃ちできる場所にすぎません。未完成の作品を見られないようにするためにそれが行われたことを知る必要はありません。

  
  

• おそらく、ドラゴンが窓から頭を出したとき、私たちはドラゴンの完全なモデルを、より小さいがより詳細な頭部のモデルに置き換えます。これにより、使用していないモデルからメモリを解放しながら、プレーヤーのエクスペリエンスを向上させることができます。

  
  

ゲーム業界に長く携わったことがある人なら、上記のことが標準的な慣行であることを認識しているでしょう。しかし、これらのテクニックが巧妙なトリックであり、非常に革新的であると考えられていた時代がありました。

プレイヤーに、見ているものにはもっと深いものがあると思わせる新しい方法を考え出すのはあなた次第です。

最良の解決策は現在機能しているものです

多くのゲーム開発者は、将来起こり得るすべてのシナリオをカバーするソリューションを考え出そうとするため、行き詰まってしまいます。この態度は適切な状況下では価値がありますが、カオス ゴブリン モードの場合、目的は何かをできるだけ早く機能させることです。

これへの補足:

欠陥のあるプロトタイプは、未完成の傑作よりも価値がある

上記の点と同様に、多くの開発者は、機能を実装しようとするときに、最適化するのが早すぎるためにフリーズしてしまいます。

最適化は、開発者の制御外のマシン上でプロジェクトを実行する必要が生じるまで残しておく必要があります[^1]。

X を実行する前に、どれくらい知っておく必要がありますか?答えは、今持っている知識があれば十分です。

これは、多くの初心者ゲーム開発者が遭遇するもう 1 つの障害です。彼らは機能の実装を延期して、あと 1 つのコース、オンライン チュートリアルをもう 1 つ受講し、ビデオをもう 1 つ視聴すれば、ゲームを実装する準備が整います。

私はこれに関して特に罪を犯しており、それがどれほど陰湿であるかを知っています。

より具体的な例として、Pong ゲームをゼロからプログラミングするという任務を与えられたとします。

何を知っているか、何を知らないかに応じて、これにはさまざまなアプローチが必要になる可能性があります。

• Unity の物理システムに精通していれば、これは比較的簡単な作業です。いくつかのリジッド ボディとコライダーを使用し、力と速度を適用し、ボールの弾むために物理マテリアルを使用するだけです。ベアボーン Pong クローン。

  
  

• しかし、あなたは Unity の衝突システムに詳しくなく、Unity の変換コンポーネントの使用方法しか知らないため、取得できるのはオブジェクトの位置とサイズだけであるとします。

  • しかし！ Pong を実装するにはこれで十分です。ボールの位置とサイズを追跡し、それをパドルの位置とサイズと比較して衝突があるかどうかを確認するスクリプトを作成できます。

    
    

• あるいは、Unity さえ知らず、知っているのは C++ とコンソールに出力する方法だけかもしれません。

  • しかし、それだけでも十分です！端末のトリックを使用して、ボール、パドル、およびプレーエリアを表すシンボルの行と列を印刷できます。ゲーム ループの概念と合わせて、入力に応答する新鮮な UI をプログラムするには十分です。

    
    

• それとも、コンピューター サイエンスのバックグラウンドすら持っておらず、C++ のクラスも受講しておらず、Javascript しか知りませんか?

  • 問題ない！メイン言語として JS を使用し、レンダリングと物理コンポーネントの両方が付属するPhaserを使用できます。

    
    

• プログラムすらできないの？全く問題ありません。

  • Gamemakerは商用ゲーム エンジンであり、無料版があり、コードなしのオプションもあります。
  • GDevelop は、ノーコード オプションも備えた無料のオープンソース ゲーム エンジンです。

これで私が何をしようとしているかわかりましたね？

失敗したプロジェクトはなく、再利用されるのを待っているスクラップの山があるだけです

ほとんどのゲーム開発者は通常、1 つまたは 2 つ (または 10,000) の放棄されたプロジェクトをどこかに眠らせています。無駄にしては意味がありません。一時停止システムなどのコードがそこにある場合は、それを再利用します。同じことを書き直すのは無意味です。書き方を正確に覚えていても、それをコピーしてください。適応するのが難しい場合は、それを繰り返して、次回は簡単になるようにします。

おそらく、再利用できるいくつかのコードを含むワークショップ プロジェクト[^2]があるかもしれません。

光るものが見えますか？光るものを取る

対話システムが必要ですか?オープンソースのものを見つけて再利用します。すべての要件を満たしていますか?いいえ？ 50％以上満たしてるのかな？はい？その場合、新しいものを最初から作成する代わりに、それを使用する価値があります。

在庫システム？ itch.io でオープンソース ゲームを見つけて、そのシステムを採用してください。

一人称視点のカメラが必要ですか?事前に構築されたアセットを利用して処理します[^3]。

世の中には、間違いなくあなたや私よりも熟練した優秀なゲーム開発者がたくさんいます。

特別な理由がない限り、すべてが事前構築済みシステムの使用の候補として考慮される必要があります。ただし、次のような賢明な例外も存在します。単にコピーして貼り付けたコードをゲームのバックボーンとして使用しないでください (少なくともコードを理解し、クリーンアップし、コメントしていることを確認してください)。このモジュールは 10 年前のもので、おそらく作者はパパラッチのいない楽園でエルヴィス、トゥパック、マリリン モンローとマイタイを飲みながら熱帯のどこかでくつろいでいたと思われます。

迷ったらコピーしてみよう

機能の実装に自信がない場合は、希望するものと似た機能を実装しているゲームを見つけて、それを真似してください。

「コピー」とは、アート スタイル、ストーリー、キャラクターではなく、コントロールの処理、カメラ ビュー、メカニクスなどのデザインの側面を意味します。

たとえば、今では忘れ去られた架空の ROGUELIKE-RTS-MMORPG では、スクロールはどのくらいの速さでなければなりませんか?

推測する代わりに、別の RTS がそれをどのように管理したかを見ることができます。 Age Of Empires II (歴史的に重要な RTS) を観察し、ユーザーがカーソルの移動速度を制御できることを発見したとします。ゲームを AoEII と並べて配置し、同等に感じるまでカーソルを調整することもできます。目標を達成するために、このようなシンプルでローテクなソリューションに依存している開発者がいかに多いかに驚かれるでしょう。

別れの思い

それで、カオスゴブリンのふざけた行為を終えた後、何をすべきでしょうか？さて、一息入れて一杯やり、後でコードに戻りましょう。

コードを休ませた後 (天候が乾燥しすぎる場合は湿ったタオルの下で)、コードを少し整えて共有する必要があります。はい！理想的には上級開発者、同僚、学生、最悪の場合はオンライン コミュニティと共有してください[^4]。

なぜそれを共有するのですか？なぜなら、カオス ゴブリンであるということは、耐久性のあるものや最適なものを作り出すことではないからです。それは機能するものを構築することです。完璧に機能する必要も、見た目が美しい必要もありません。機能するだけで十分です。このタイプの開発では結果が生成されますが、その結果がすぐに製品化できることはほとんどありません。したがって、誰かに相談してフィードバックを提供することが非常に重要です。

プロジェクトの段階によっては、この人のコメントをすぐに実装する時間がない場合があります。その場合は、少なくともコード内にコメントを文書化する必要があります[^5]。

以上です！あなたは、世界中のプロのゲーム開発者が問題を解決するために使用しているナンバーワンのテクニックを習得しました。

2杯目の一杯を飲む時間だと思いませんか？

ノート

[^0] - これは驚くほど一般的な現象であり、「デンバーの寓話」と呼ばれています。詳細については、次の学術論文を参照してください。

[^1] - これは少し一般化したものですが、ほとんどの一般化と同様に、プロジェクトの要件を徹底的に分析するほど役に立たない可能性があります。ただし、本当に必要になるまで最適化を延期するのが経験則です。最近では、ビデオ ゲームの最適化は以前よりもはるかに困難ではなくなりました。 Unity などのゲーム エンジン会社によっては、無料のコンサルティングを提供してくれる場合もあります。結局のところ、ゲームを正常に起動することが彼らにとっての最大の利益です。

[^2] - ワークショップは、Unity についての理解を高めるために私が使用する型または実践の 1 つです。この機能とその他のテクニックの詳細については、こちらをご覧ください。

[^3] - この記事では、他の便利なツールと並んで非常に優れた FPS コントローラー パッケージを見つけることができます。

[^4] - これには、オンラインで受け取るコメントの約 95% が、内容が何であれ、無意味、不完全、時代遅れ、または著者の非常に個人的な信念を反映している可能性があるという警告が含まれています。したがって、このようなフィードバックには常にある程度の懐疑心を持って対処してください。有益なコメントを探し、残りは無視または削除し、コードを共有できる人を見つけるために真剣に努力してください。

[^5] - チームごとに、コード ドキュメントを管理する場所に関して異なる規範を支持しているため、それに従う必要があります。ただし、一般的には、コードのドキュメントをコード自体の隣に配置することを推奨します。それが不可能な場合は、選択したコード バージョン管理システムでgit サブモジュールまたは同等のものを使用することを検討してください。ドキュメントをメイン リポジトリに配置できない場合は、少なくとも git サブモジュールに配置する必要があります。