最近、最初のゲームBYTEPATHをリリースしましたが、作成プロセスで学んだことについて考えを書き留めておくと便利だと思いました。 これらのレッスンを「ソフト」と「ハード」に分けます。ソフトとは、ソフトウェア開発に関連するアイデアを意味し、ハードなものはプログラミングの技術的な側面です。 さらに、なぜ自分のエンジンを作成したいのかについても説明します。

ソフトレッスン

コンテキストのために、5〜6年前に自分のゲームを作り始め、最初のゲームのリリース前に3つの「深刻な」プロジェクトに取り組んだことをお知らせします。 これらのプロジェクトのうち2つは死んでおり、完全に失敗しました。BYTEPATHで作業するために最後のプロジェクトを一時的に中断しました。





最初の2つのプロジェクトはさまざまな理由で失敗しましたが、プログラミングの観点からは（少なくとも私が見ているように）失敗しました。 ほとんどのソフトレッスンはこの失敗に関連しているため、そう言うことが重要でした。

時期尚早の一般化

これまでのところ、このゲームから学んだ最も重要な教訓は、いくつかのタイプのエンティティで繰り返される動作がある場合、抽象化/一般化を早めるよりも、デフォルトでコピーして貼り付ける方が良いということです。



実際には、これを達成するのは非常に困難です。 私たちプログラマーは、繰り返しに気づき、できるだけ早くそれらを取り除く努力をすることに慣れていますが、通常、この衝動が解決するよりも頻繁に問題を引き起こすことに気づきました。 彼が作成する主な問題は、一般化がしばしば不正確であり、一般化が誤っている場合、コード構造をそれ自体に結び付け、一般化がない場合よりも修正および変更がはるかに難しいことです。



ABC



アクションを実行するエンティティの例を考えてみましょう。 最初に、エンティティに直接ABC



をコーディングします。他に理由がないためです。 しかし、 ABD



を実行する別のエンティティに関しては、すべてを分析し、「これら2つのエンティティからAB



を取得し、それぞれがC



とD



のみを処理します」と考えます。 AB



および他の場所で再利用できます。 新しいエンティティが定義されているのと同じ方法でAB



を使用する場合、これは問題ではありません。 ABE



やABF



などがあるとしましょう...









しかし、遅かれ早かれ（そして、これは通常、より早く起こります）、 AB*



を必要とするエンティティが現れますが、 AB*



とほとんど同じですが、小さな互換性のない違いがあります。 その後、 AB*



を考慮してAB*



変更するか、 AB*



動作を含む完全に新しいパーツを作成します。 この演習を数回繰り返すと、最初のケースではさまざまな動作のすべての種類のスイッチとフラグを備えた非常に複雑なAB



になり、2番目のケースではフィールドの最初のセルに戻ります。コードを複製します。









この問題の核心は、新しいものを追加したり、古いものの動作を変更したりするたびに、既存の構造を考慮してこれを行わなければならないという事実です。 何かを変えるために、私たちは常に「それはAB



かAB*



か」と考えるべきです。そして、この一見単純な質問がすべての問題の原因です。 これは、新しい構造を追加して機能させるだけでなく、既存の構造に何かを挿入しようとしているためです。 必要なことを行うだけで、既存のコードを考慮する必要があるため、違いを過大評価することはできません。



したがって、最初はコピーと貼り付けのコードをデフォルトで選択する方がはるかに簡単であることに気付きました。 上記の例では、 ABC



がありますABD



を追加するには、 ABC



をコピーして貼り付け、パーツC



を削除してD



に置き換えますD



ABF



を使用するABE



同じことが当てはまりますABE



AB*



を追加する必要がある場合は、 AB



再度コピーして貼り付け、 AB*



置き換えます。 このスキームに新しいものを追加する場合、既存のコードにどのように埋め込まれるかを心配せずに、同様のアクションが既に実行されている場所からコードをコピーして変更するだけで十分です。 この方法は、実装がはるかに優れており、問題が少ないことがわかりましたが、直感に反しています。

ほとんどのヒントは、単一の開発者には適していません。

インターネットプログラマー向けのヒントの大部分と、私が実際に単一の開発者としてしなければならないことの間には、不一致があります。 その理由は次のとおりです。第一に、ほとんどのプログラマーは他の人とチームで仕事をしているので、通常はこの前提でアドバイスが与えられます。 第二に、人々によって作成されたソフトウェアのほとんどは非常に長い間存在している必要がありますが、これはインディーズゲームには適用されません。 つまり、プログラマーへのアドバイスのほとんどは、インディーズゲームの単独開発にはほとんど役に立たないことを意味し、このため、他の人には不可能な多くのことを行うことができます。



たとえば、グローバル値を使用できるのは、非常に頻繁に役立つためであり、それらを頭の中に保持できる限り、問題を引き起こすことはありません（詳細については、BYTEPATHチュートリアルのパート10を参照してください ）。 また、コードベースがあまり大きくないため、コードの大部分を頭に置いているため、コードにあまりコメントすることはできません。 誰もゲームを構築する必要がないため、自分のマシン上でのみ動作するスクリプトを作成できます。つまり、この手順の複雑さを大幅に軽減でき、作業を完了するための特別なツールは必要ありません。 私は巨大な関数とクラスを持つことができ、それらをゼロから作成し、それらがどのように機能するかを正確に知っているので、それらの膨大な量は問題ではありません。 結局のところ、それらに関連する問題のほとんどは、長寿命のソフトウェアに取り組んでいるチームでのみ明らかになるため、私はこれをすべて行うことができます。



このプロジェクトに取り組んで、私はこれらすべての「悪い」ことをしたとき、特に悪いことは何も起きなかったことを学びました。 多くの開発者が非常に悪いコード記述方法を使用して素晴らしいゲームを作成したという事実を考えると、意識の端のどこかで、インディーゲームを作成するのに超高品質のコードは必要ないことを常に思い出しました。









casenpai：私が怖いのは、コードに864のケース構文があるように見えることです。



Toby Foxx（Undertale author）：プログラミングできません、笑



そして、このプロジェクトは私にこの意見を確認することになっていた。 注目に値する-これは、リラックスしてジャンクコードを書くことができるという意味ではありません。 インディーゲームの開発の文脈では、これはほとんどのプログラマーのこの衝動と戦う価値がある可能性が最も高いことを意味します。それはあなたの仕事を遅くする敵であるため、すべてを正しくきれいにするほとんど自閉症の必要性を伴います。

ECS

Entity Component Systemパターンは、前の2つのセクションで述べたすべての矛盾の良い実例です。 ほとんどの記事を読んだ後、インディー開発者は継承を悪い習慣と見なし、コンポーネントを使用してレゴコンストラクターからエンティティを作成できること、そしてそれらのおかげで再利用可能な動作をはるかに簡単に使用できることが明らかになり、文字通りゲーム作成のすべてがより簡単に。



定義により、ECSに対するプログラマの欲求は時期尚早の一般化について語っています。なぜなら、物事をレゴブロックと見なし、それらから新しいものを収集する方法を考えると、有用なものと組み合わせることができる再利用可能なフラグメントの観点から考えるからです方法。 そして、プリコンパイルに関するセクションにリストした理由から、これは完全に間違っていると思います！ この正確な科学的グラフは私の立場をよく説明しています。









ご覧のとおり、私が保護する「ヨーロコーディング」の原則は、最初ははるかに単純で、徐々に難しくなります。プロジェクトの複雑さが増し、ヨーロテクニシャンが問題を実証し始めます。 一方、ECSは最初ははるかに複雑です。コンポーネントを作成する必要があり、定義上、単純な作業要素を作成するよりも困難です。 しかし、時間が経つにつれて、ECSの有用性はますます明らかになり、ある時点で彼はヨーロコーディングを打ち負かしています。 私のポイントは、MOSTインディーズゲームのコンテキストでは、ECSが最高の投資になる瞬間は決して来ないということです。



コンテキストの矛盾について言えば、この記事が人気を博すと、AAA開発者がコメントに間違いなく登場し、「私はこの業界で20年間働いていますが、このナンセンスは完全に悪いです!!! ECSは非常に便利です。すでに数百万ドルを稼いだAAAゲームをいくつかリリースし、世界中の何十億人もの人々がプレイしています!!! このナンセンスを運ぶのをやめろ!!!」



このAAA開発者はECSが彼にとって有用であるという点で正しいでしょうが、これは他のインディー開発者には必ずしも当てはまりません。コンテキストの不一致により、これら2つのグループは非常に異なる問題を解決します。



そうかもしれないが、私はできる限り、自分の視点を伝えたと思う。 これは、ECSの使用が愚かであるか、愚かなことを意味しますか？ いや すでにECSの使用に慣れていて、それがうまく機能していれば、ためらうことなく使用できると思います。 しかし、一般的にインディー開発者はそのようなソリューションとその欠点に対してより批判的であるべきだと思います。 ジョナサンブローの考えはここで非常に適切だと思います（ECSに関して彼が私に同意するとは決して信じていません）。

動作を複数のオブジェクトに分割しない

回避できないと思われるパターンの1つは、1つの動作を複数のオブジェクトに分割することでした。 BYTEPATHでは、これは主に「コンソール」ルームの作成方法に現れましたが、Frogfaller（以前に行ったゲーム）ではこれはより明白です。





このオブジェクトは、クラゲの別々の脚からのクラゲの本体と、すべてを一緒に結合し、身体と脚の動作を調整する論理オブジェクトで構成されています。 動作が3つの異なるタイプのオブジェクトに分割され、それらの調整が非常に困難になるため、これはそのようなエンティティをコーディングする非常に不器用な方法ですが、この方法でエンティティをコーディングする必要がある場合（およびゲームに多くのマルチコンポーネントエンティティがある場合）、自然にこの解決方法を選択します。



デフォルトでこの分離を選択する理由の1つは、各物理オブジェクトを1つのオブジェクトのコードに含める必要があることです。つまり、新しい物理オブジェクトを作成する場合は、オブジェクトの新しいインスタンスも作成する必要があります。 実際、これは厳密なルールや必須の制限ではなく、物理APIのアーキテクチャを設計した方法のために非常に便利です。



実際、私はこの問題を解決する方法について長い間考えていましたが、それでも良い解決策を見つけることができませんでした。 異なる物理オブジェクト間で調整する必要があるため、1つのオブジェクトだけの単純なコーディングはひどいように見えますが、物理オブジェクトを正しいオブジェクトに分割し、その後の調整も受け入れられないように思われます。 他の人がこの問題をどのように解決するかわかりませんので、あなたのアドバイスを待っています！

ハードレッスン

彼らの文脈は、LuaとLÖVEで私のゲームを書いたということです 。 CとC ++で0行のコードを書きました。すべてがLuaで書かれています。 したがって、これらのレッスンの多くはLua自体に関連していますが、それらのほとんどは他の言語にも適用されます。

なし

プレイヤーから受け取ったバグの90％は、 nil



変数へのアクセスに関連しています。 私はどのタイプのアクセスがより頻繁である/少ない頻度の統計を追跡しませんでしたが、ほとんどの場合、別のオブジェクトがこの死んだオブジェクトへのリンクを保存し、それを使ってしようとすると、オブジェクトの死に関連付けられます。 これは「平均寿命」問題のカテゴリーに属すると思います。



いずれの場合も、この問題の解決策は通常非常に簡単に実装されます。オブジェクトが存在するかどうかを確認し、その後でアクションを実行するだけで十分です。

 if self.other_object then doThing(self.other_object) end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、この方法でのコーディングの問題は、再保険をかけすぎた別のオブジェクトを参照することです。また、Luaはインタープリター言語であるため、コード分岐に関するこのようなまれなバグが発生します。 しかし、この問題を解決する他の方法は考えられません。バグの深刻な原因であるため、それらを正しく処理するための戦略を立てることは正しいようです。



将来、あるオブジェクトから別のオブジェクトを直接参照するのではなく、それらのIDを使用してそれらを参照することを検討します。 そのような状況で、別のオブジェクトで何かをしたいときは、まずそのIDでそれを取得し、それから何かをしなければなりません：

 local other_object = getObjectByID(self.other_id) if other_object then doThing(other_object) end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このアプローチの利点は、何かをするたびにオブジェクトを受け取るように強制されることです。 また、私はこのようなことは決してしません：

 self.other_object = getObjectByID(self.other_id)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、現在のオブジェクトに別のオブジェクトへの永続的なリンクを保持しないことを意味します。つまり、別のオブジェクトの死によりエラーが発生することはありません。 これは、私が何かをしたいたびに多くの冗長性を追加するため、私には非常に望ましい解決策ではないようです。 MoonScriptのような言語は、これに似たようなことができるので、これで少し役立ちます。

 if object = getObjectByID(self.other_id) doThing(object)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、MoonScriptを使用しないため、これに同意する必要があります。

メモリ割り当てのより優れた制御

特に次のゲームでLuaを使用するので、ガベージコレクションが悪いことを主張するつもりはありませんが、その側面のいくつかはまだ好きではありません。 Cライクな言語では、リークの発生はうっとうしいですが、通常はどこで発生するかを大まかに理解できます。 ただし、Luaのような言語では、ガベージコレクターはブラックボックスのように見えます。 これを調べて、何が起こっているかについてのヒントを得ることができますが、これは理想的な作業方法ではありません。 Luaでリークが発生すると、Cよりもはるかに大きな問題になります。これは、私が所有していないC ++コードベース、つまりLÖVEコードベースを使用することで補完されます。 開発者がどのように各自のメモリ割り当てを設定するのかわかりません。そのため、Luaが予測可能なメモリ動作を実現するのははるかに困難です。



速度の点で、Luaガベージコレクターに問題がないことは注目に値します。 特定の制限で動作するように（たとえば、nミリ秒間起動しないように）制御できるため、問題はありません。 唯一の問題は、n msを超えて実行しないように彼に伝えることができ、フレームごとに生成されたすべてのガーベッジを収集できないことです。 したがって、割り当てられたメモリの量を最大限に制御することが望ましいです。 このトピックに関する非常に優れた記事があります： http : //bitsquid.blogspot.com.br/2011/08/fixing-memory-issues-in-lua.html 、およびこの記事でエンジンに到達したときにそれについて詳しく説明します。

タイマー、入力、カメラ

これらは、私が受け取った決定に非常に満足している3つの領域です。 これらの一般的なタスクのために、3つのライブラリを作成しました。

• https://github.com/SSYGEN/chrono （タイマー）
• https://github.com/SSYGEN/boipushy （入力）
• https://github.com/SSYGEN/STALKER-X （カメラ）

それらはすべて、私にとって非常に直感的なAPIを備えており、私の生活をずっと楽にします。 これまでのところ、タイマーは私にとって最も有用であることが判明しました。これは、あらゆる種類のソリューションを簡単な方法で実装できるためです。

 timer:after(2, function() self.dead = true end)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードは、2秒後に現在のオブジェクト（自己）を強制終了します。 このライブラリを使用すると、トゥイーントランジションを非常に便利に実装できます。

 timer:tween(2, self, {alpha = 0}, 'in-out-cubic', function() self.dead = true end)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この行により、tween in-out-cubic



モードを使用して2秒間オブジェクトのalpha



属性を0にスムーズに変更（トゥイーン）し、オブジェクトを破棄できます。 これにより、段階的な溶解と消失の効果を作成できます。 また、インパクト時にオブジェクトを点滅させるためにも使用できます。

 timer:every(0.05, function() self.visible = not self.visible, 10)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードは、0.05秒ごとに10回、 self.visible



の値をtrueとfalseの間で切り替えます。 これは、0.5秒間フリッカー効果を作成することを意味します。 ご覧のとおり、ライブラリはほぼ無限に使用できます。 これは、Luaが匿名関数と連携する方法のおかげで可能になりました。



他のライブラリも同様に些細なAPIを備えており、強力で便利です。 カメラライブラリは低すぎることが判明した唯一のものですが、これは将来改善される可能性があります。 その意味は、このビデオに示されているものに似たものを実装できるようにすることです。





しかし、最終的には、カメラモジュールの非常に基本的な部分とビデオに表示される部分との中間層のようなものを作成しました。 LÖVEを使用している人々がライブラリを使用することを望んでいたため、どのタイプの属性が使用可能かについての仮定を少なくする必要がありました。 つまり、ビデオに示されている機能の一部は実装できません。 将来、独自のエンジンを作成するときに、ゲームオブジェクトについて必要なものを想定できるようになります。つまり、このビデオに示されているすべてを実行できるライブラリの正しいバージョンを実装できるようになります。

部屋とエリア

私にとって、部屋（部屋）とエリア（エリア）の概念は、オブジェクトを扱うのに非常に適した方法であることがわかりました。 部屋は「レベル」または「シーン」に類似しています。 すべてのアクションはそれらで行われ、それらの多くが存在する可能性があり、それらを切り替えることができます。 エリアは、部屋の中に配置できるオブジェクトマネージャの一種です。 一部の人々は、そのようなAreaオブジェクトを「スペース」と呼びます。 AreaとRoomはほぼこのように連携します（これらのクラスの実際のバージョンでは、AreaにaddGameObject



、 queryGameObjectsInCircle



などがあるなど、さらに多くの機能があります）。

 Area = Class() function Area:new() self.game_objects = {} end function Area:update(dt) -- update all game objects end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 Room = Class() function Room:new() self.area = Area() end function Room:update(dt) self.area:update(dt) end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらの概念を分離することの利点は、部屋にエリアが必要ないことです。つまり、部屋内のオブジェクトを制御する方法は固定されていません。 ある部屋で、オブジェクトを別の方法で管理することを決定できます。それから、エリアコードを新しい機能に適応させる代わりに、コードを書くだけです。



ただし、このアプローチの利点の1つは、部屋に両方がある場合、ローカルオブジェクト制御ロジックとエリアオブジェクト制御ロジックを簡単に混在させることができることです。 これは非常に混乱を招く可能性があり、BYTEPATHを開発する際に重大なエラーの原因になりました。 したがって、今後は、Roomがエリアを厳密に使用するか、オブジェクトを管理するための独自の手順を使用するようにしますが、両方を同時に使用することはありません。

snake_caseとcamelCase

現在、変数名にsnake_caseを使用し、関数名にcamelCaseを使用しています。将来的には、クラス/モジュールの名前を除き、あらゆる場所でsnake_caseを使用する予定です。クラス/モジュールの名前はCamelCaseのままです。その理由は非常に単純です。キャメルケースでは、長い関数名を読むのは非常に困難です。snake_caseで変数名と関数名を混在させる機能は、名前を使用するコンテキストのため、通常は問題になりません。そのため、すべてがうまくいきます。

エンジン

このゲームが終わった後、自分のエンジンを書きたい主な理由はコントロールです。 LÖVEは素晴らしいフレームワークですが、ゲームのリリースに関しては失礼すぎます。 Steamworksサポート、HTTPSサポート、Chipmunkのような他の物理エンジンのテスト、C / C ++ライブラリの使用、Linuxでの配布のためのゲームのパッキング、すぐに言及する他の多くのことは複雑すぎます。



これは、タスクが解決できないことを意味するものではありませんが、それを解決するには、C / C ++レベルに移動してそこで作業する必要があります。私はCでプログラムしているので、これで問題はありませんが、最初はフレームワークを使用することにしました。なぜなら、私はLuaを使いたいと思っていたからです。したがって、いずれにせよ低レベルで作業しなければならない場合は、自分でコードベースを作成してコードベースのこの部分を所有します。



ただし、ここではエンジンに関するより一般的な視点を示したいと思います。そのために、LÖVEの代わりにUnityをscる必要があります。私が好きで、かなり長い間プレイしたゲームがあります-Thies of Lies：





これは「マフィア」のクローンであり、非常に健全で優れたコミュニティがありました（おそらく今もあります）。私が見ているストリーマーからそれを知ったので、ゲームには同じような考え方の人がたくさんいます。一般的に、私はゲームが本当に好きだった。 / r / gamedev で、開発者の1人からこのゲームの事後調査を見つけました。この男はプログラマーの一人であり、彼は私の注意を引くコメントを1つ書いた。

, . , , , . , . , , , . -, ; , . Unity , . : . , , , . . , . . Unity , - , .



, Async, Vulkan, FB standalone , , ( FB ..), UI , , , , Scroll Rect' , ( , Unity).



, … , . , UI . Play, Stop, , , .



… (collab) , — , , , . . collab gitlab CE . . — 2-3 ( , ), Unity . -… Play, 2 . 2-3 . 10 .



… Unity , , — . , , Unity, .



… UNET? . , . , , - , , , . , , . , Photon , , . , . . , … … . : , , .



そしてたくさんありました。私が言えることは次のとおりです。3Dを実行している場合は、Unrealに切り替えてください。失望を説明することすらできません。マスクの背後にある恐ろしい真実を見るまで、私は誇り高いUnity開発者でした。ウェブサイトからUnityロゴを削除することさえ恥ずかしかったです。あまりにも多くが投資されており、Unityを他の開発者にすすめることすらできません。

つまり、私が非常に気に入ったゲームを作成したこの人は、Unityについてひどいことを言っていました。彼は非常に不安定であり、開発者は常に新しい機能を求めており、それらを正しく実装しないなどです。誰かがUnityをあまり好きにしていないので、そのようなことを書いていることに非常に驚きました。それで、私は彼を少しプッシュして、彼がUnityについて他に何を言うことができるかを見つけることにしました：









そして彼はこれを言った：









そしてそのような：









私はUnityを使用したことがないので、彼が真実を語っているかどうかはわかりませんが、彼は完成したゲームを書いたので、嘘をつく理由はわかりません。これらすべての投稿での彼の視点はほぼ同じです。Unityは既存の機能を改善するのではなく、新しい機能を追加することに焦点を当てており、Unityはバージョン間で多くの既存の機能の安定性を維持するのに問題があります。



私の意見では、彼の投稿で最も説得力のある議論の1つは、Unityだけでなく、他のエンジンにも適用されるということです。エンジンの開発者自身はゲームを作成しません。少なくともLÖVEについては、重要なことに気付きました。フレームワークの多くの問題は、開発者がインディーゲームを積極的に作成すれば解決できる可能性があります。この場合、これらの問題はすべて明らかになり、最も高い優先度を受け取り、すぐに修正されるためです。 xblade724は同じことがUnityにも当てはまることを発見しました。そして、私が知っている他の多くの人々は、他のエンジンでも同様のことを発見しました。



開発者自身が積極的にゲームを作成するフレームワーク/エンジンはほとんどありません。最初に思い浮かぶのは、Unreal。Epicは独自のエンジンで一連の超成功ゲームを作成したためです。最後のゲームはFortniteです。 Monogame。主な開発者はゲームをさまざまなプラットフォームに移植します。 YoYo Gamesはそのエンジンでモバイルゲームを作成するため、GameMaker。



私が知っている他のすべてのエンジンについては、この条件は満たされていません。つまり、これらのエンジンはすべて、既製のゲームを作成する上で非常に明らかな問題と障害があります。インセンティブがないためですよね？ゲーム開発サイクルの最後に発生するため、一部の問題が5％のユーザーにしか影響しない場合、自分のゲームエンジンで実行せず、これらの問題に自分で対処する必要がないのに、なぜそれを修正するのですか？



そしてこれは、ゲームの終わり近くで予期せぬ問題に遭遇することなく、信頼できる実証済みの方法でゲームを作成することに興味がある場合、私の人生を複雑にするエンジンを使用しないため、他のエンジンを使用しないことを意味します上記の3つ。私の特定の場合、私は主に2Dゲームに興味があり、Unrealは彼らにとってあまりにも多く、Monogameは動作しません。C＃が嫌いで、GameMakerは視覚的なコーディングやインターフェイスベースのコーディング。つまり、残りのオプションは1つだけです-自分のエンジンを作成するためです。



したがって、これらすべての考慮事項に対処したので、特定のタスクに移りましょう。

C / Luaの相互作用と記憶

C / Luaバインディングは、2つの基本的な方法で（少なくとも私の限られた経験に基づいて）実行できます。完全なユーザーデータと制限されたユーザーデータです。完全なユーザーデータを使用する場合、LuaコードがCで何か（物理オブジェクトなど）の配置を要求すると、Luaでこのオブジェクトへのリンクを作成して使用します。この方法で、オブジェクトCを確実に記述するメタテーブルとさまざまなパラメーターを備えた完全なオブジェクトを作成できます。このアプローチの問題の1つは、Luaから大量のゴミを作成することです。前のセクションで述べたように、メモリ割り当て、または少なくとも発生時にそれを完全に制御したい。



したがって、ユーザーデータが限られているアプローチを使用する方が論理的です。制限されたユーザーデータは、通常のCポインターであり、これは、指しているオブジェクトに関する多くの情報を取得できないことを意味しますが、このオプションは、Luaからほとんどの制御を提供します。このスキームでは、オブジェクトの作成と破棄を手動で行う必要があり、すべてが魔法のように行われるわけではなく、まさにそれが必要です。 Stingrayエンジンの開発者による非常に興味深いレポートは、このトピックに当てられています。





ドキュメントを読んだ後、彼の説明がエンジンでどのように発生するかを確認できます。



独自のエンジンを作成するポイントは、C / Luaバインディングがどのように発生するか、発生する妥協の選択を完全に制御できることです。Luaで他の誰かのエンジンを使用する場合、選択は私のために行われ、たとえばLÖVEで起こったように、この選択に完全に満足することはできません。したがって、これは、メモリをより詳細に制御し、高速で信頼性の高いゲームを作成できる主な方法です。

外部統合

Steamworks、Twitch、Discordなどのサイトには、便利な機能を使用するために統合する必要のある独自のAPIがあり、C / C ++でコードベースを所有していない場合、このタスクははるかに困難になります。もちろん、たとえば、それらをLÖVEに統合する作業を行うことができますが、独自のエンジンに統合する場合よりも多くの作業が必要になります。



UnityやUnrealのような非常に人気のあるエンジンを使用している場合、これらのサービスのほとんどと他の人の統合が既に行われている場合、これは問題ではありませんが、より小さなユーザーベースで別のエンジンを使用する場合は、これらのものを自分で統合する必要があります、または誰かの半分実装された、ほとんど機能しないコードを使用することは、悪い決断です。



また、C / C ++コードベースの一部を所有すると、必要なものだけを実装することができ、確実に機能するため、このような統合がはるかに簡単になります。

その他のプラットフォーム

これは、独自のエンジンを書くことに比べて、UnityやUnrealのようなエンジンで見られる利点の1つです。これらはすべての最も一般的なプラットフォームをサポートします。それがうまく実装されているかどうかはわかりませんが、私が印象的なのは、彼らがそれを実行できることであり、単独でそれを行うのは難しいでしょう。私はアセンブラーで生き生きと息を吹き込んでいるわけではありませんが、将来のエンジンをコンソールや他のプラットフォームに移植するのに多くの問題があるとは思いません。 。





最初から本当にサポートしたいプラットフォームの1つがWebです。ブラウザーでBloons TD5ゲームをプレイした後、しばらくして、Steamに切り替えて10ドルで購入することをゲームが提案しました。だから私はやった。したがって、より少ない機能を備えたブラウザバージョンのゲームのサポートとSteamへの切り替えの提案は、実装したい優れた戦略であると考えています。以前は、Cエンジンを作成するために何が必要かという質問を研究しましたが、Emscriptenはブラウザーの画面に描画できるSDLを操作するのに便利だと思われます。

リプレイ、予告編

このゲームの予告編を作成することは、非常に悪い経験であることが判明しました。私は彼がまったく好きではなかった。映画/予告編/ストーリーを頭の中でよく考えることができます（何らかの理由で音楽を聴くときはいつもこれを行います）ので、ゲーム用に作成したい予告編について非常に良いアイデアがありました。しかし、必要なツール（ビデオエディターなど）の使用方法がわからず、録画をあまり制御できないため、結果は完全に間違っていました。





エンジンにリプレイシステムとトレーラーシステムを実装したいと考えています。リプレイシステムを使用すると、ゲームプレイを記録するのにサードパーティのプログラムは必要ないため、ゲームプレイクリップを簡単に記録できます。さらに、開発中にゲームプレイが常に記録されていることを確認できるため、すべてのリプレイをプログラムで表示し、トレーラーで使用できる特定のイベントまたはイベントのシーケンスを選択できます。成功すれば、必要なレコードを取得するプロセスがずっと簡単になります。



さらに、このリプレイシステムを実装した後、エンジンに組み込まれたトレーラーシステムを追加して、異なるリプレイのフラグメントを一緒に接続できるようにします。実際、これには技術的な障害は見られないため、問題は実装のみです。



また、リプレイシステムを作成するために独自のエンジンが必要な理由は、リプレイが制御された方法で機能し、スペースを節約できるように、バイトレベルで作業する必要があるためです。この記事では、Luaにリプレイシステムを既に構築しましたが、わずか10秒でリプレイにより10 MBのファイルが作成されます。さらに最適化を追加できますが、最終的にはLuaには制限があり、Cで最適化する方がはるかに便利です。

設計の完全性

そして、私が自分のエンジンを作成したい最後の理由は、設計の整合性です。 LÖVEについて私が好き/嫌いな原則の1つであるLua（Linuxの哲学でも同じです）は、その分散化です。 LuaとLÖVEには標準の実装方法はありません。人々は自分が正しいと思うことをします。他の人が使用するライブラリを書きたい場合は、あまり多くの仮定をすべきではありません。私がLÖVEのために作成したすべてのライブラリーは、このアイデアに従っています（リポジトリーで見つけることができます）。



このような分散化の利点は、誰かのライブラリを簡単に取得し、ゲームで使用し、ニーズに合わせて調整できることです。一般に、すべてが機能します。この分散化の欠点は、各ライブラリが私を節約できる時間が、標準のセットに関してより集中化されたコードと比較して短いことです。これについては、独自のカメラライブラリを使用した例で既に説明しました。これは、すべてを高速に行うことに反しています。



したがって、私がエンジンで本当にやりたいことの1つは、すべてを正確に希望どおりに集中化する機能と、多くの仮定を立てる機能です。これにより、作業のペースが向上します（また、生産性が向上します）。