115 KBのゲーム開発-ハッキング、バグ、迷惑

11月初旬に、私は115回の独立ゲーム開発者コンテスト（IGDC）コミュニティコンテストに参加しました。このコンテストでは、週115キロバイトのアーケードシューティングゲームの開発に焦点を当てました。 カットの下では、OpenGL + Free Pascalでゲームを開発するストーリー、LZOを試す、uFMODのFPCコンパイラーのバグをバイパスする、テクスチャーの最も簡単な生成、NVidiaグラフィックカードの迷惑なバグ、すべてを台無しにしました。

ビデオ、Windows用バイナリ、およびソースコードも含まれています-記事の最後をご覧ください。

叙情的な紹介

ゲーム開発は私の主なお気に入りであり、非常に古い趣味です。 私はアマチュアのゲーム開発会社でスピンし続けており、約10年間、大きな成功、知名度の高いリリース、巨額の長期的な建設はありませんでした。 頭に浮かぶ多くの凍結プロジェクトがあります-ユニット。 ある時点で、私からは何も得られないことに絶望しました。 そして、最終結果だけでなく、ゲーム開発プロセス自体も気に入っていることに気付きました。 その瞬間から、生活は落ち着きましたが、いつか自分を圧倒し、ある種のプロジェクトを商業レベルに引き上げるという考えを手放しません。

ある時点で、特定のトピックに関するゲームを開発するための短い（数日から3週間）コンテストを主催するIGDCコミュニティに出会いました。 温かみのあるランプコンテストは、賞ではなく参加が主なものです。 マーケティングや収益化ではなく、得られた経験と仕事の喜び。

最近では、gamedevに入るためのしきい値が大幅に低下し、率直に失敗するゲームのストリームがモバイルプラットフォームに殺到しています。その著者は、ゆるい鳥のために別の快適な生活を送ることを夢見ています...

もちろん、強力なLudum Dareがありますが、これまでのところ彼のハードコアな言葉は私の家族生活に反しています。

開始する

したがって、2014年11月7日に、次のコンテストがコミュニティのWebサイトで発表されます。 条件：

• 「Pyshch-pyshchk」と敵-これらはコンテストのリーダーがアーケードシューティングゲームを説明した言葉です
• サイズ-競合は連続115位であるため、厳密に最大115キロバイト
• 期間-週

これらの条件には永続的な前提条件が追加されています。オフラインで動作し、サードパーティのパッケージや再配布可能パッケージをインストールする必要はありません。 ゲームを実行するために必要で、システムに付属していないものはすべて、リリースとともに提供され、同じ115キロバイトに収まる必要があります。

制限は、真のデモシーン（4k、32k ...）にはあまり大きくありませんが、適切に「変態」するには十分です。 開発ツールをすばやく分析すると、これらの要件に適合するもののかなり印象的なリストが得られます。

• フラッシュ
• html5 + js
• C、C ++、C＃
• Delphi、FreePascal
• ...

オーバーボードは、Unity、Cry Engine、Unreal Engine、JVMベースの言語（プリインストールされたjreが必要）、およびほとんどのゲームデザイナーです。


私の生活の中で、私は多くの言語と技術を試すことができました。そして、上記のリストのほとんどは直接私によく知られています。 しかし、謙虚な使用人は、最も簡単なオプションであるFree Pascalを選択しませんでした。 なぜ最も簡単ではないのですか？

まず、2014年には、DelphiのようなFree Pascalは流行遅れと見なされています。その結果、FPCコンパイラには、オープンソースとクロスプラットフォームにもかかわらず、ユーザーが少なく、多くのバグがあります。 第二に、Lazarus IDE + FPCバンドル用にコンパイルされたexeのサイズは、wikiの別のページの機会です。 第三に、他の多くの言語や技術を絶えず使用している場合、それは非常に少ない構文糖衣です。

もちろん、プラスもあります：

• 正しく準備されたexeは自給自足ですが、静的CRTリンクを持つC / C ++のexeと比較できます
• デフォルト設定では、C / C ++のように自分で足を撃つことはできません
• 適切な設定で、両方の脚を撃ち落とします
• かなり偶然に 、私はすでにFree Pascal + OpenGLのミニフレームワークを持っています

行こう！

まず、将来のゲームのコンセプトを決定しました-プレイヤーが「タンク」を制御し、あらゆる方法で敵の群衆を撃つトップビューを持つアーケード2Dシューティングゲームから、さらに楽しい敵のシューティングのためのボーナスがあります。 バクナリアは、死があなたが分身を手放すまで続きます。 最も近いアナログはCrimsonlandです。

テンプレートを通常の動きでコンパイルして、最初の問題を自分で作成しました-コンパイラーのすべてのトリッキーなオプションを考慮して、フレームワークでコンパイルされたexeは120キロバイトかかりました。 もちろん、フレームワークができるという事実を考えると（これはまだFPCであることを念頭に置いて）-これは成果ですらあります。 しかし、これは私たちにはまったく合わないので、 UPXを使用して無慈悲にexeをカットしました-48キロバイト。 すでにこれで作業できます。

もちろん、ここでフレームワークの機能を最も必要なものにカットすれば、数キロバイトも勝つことができます。 時間がないため、これを拒否しました。後で判明しましたが、無駄ではありません。 その結果、115キロバイトという制限で十分超過しました。

LZOを紹介します

まれなゲームは、テキストまたは数値情報を表示せずに実行できます。 最初は私の考えでは、そのようなゲームを作成することでしたが、興味深い実装を考え出すことはうまくいきませんでした。

したがって、タスクはOpenGLを使用して画面にテキストを表示することです。 ベクターテキストを表示する古風な方法に頼らずに、ビットマップフォントを使用する必要があります。 私のフレームワークは、事前に生成され、慎重に「焼き付けられた」ビットマップフォントを使用したテキスト出力を既にサポートしていました。 問題は解決しましたか？


いいえ、タスクは複雑になっています。 このようにしてロシア語とラテン文字（および特殊文字と数字）で取得したファイルは、135キロバイトを占めていました。 ロシア語の文字を削除し、フォント自体の物理サイズを縮小します。画像はいずれかのサイズで半分になり、それに応じてサイズが半分になります-67キロバイト。 しかし、「空の」プロジェクトでは合計で115キロバイトになるため、これはまだ良くありません。

「コピー＆ペースト」コードは単純なので、最も正確でシンプルな手順は、起動時にシステムフォントからフォントを取得して生成することです。 さらに、以前のフレームワークでは、これがフォントの生成方法でした-システムフォントまたはotf / ttfファイルからの「ランタイム」で。

しかし、魂はロマンス、そして5番目のポイント-苦痛を望んでいました。 そして、私は2010年に同志XProgerがMiniLZOライブラリに対して暴力行為を行い、そのダンプをヤンクし、簡単なasm命令でラッピングしたことを思い出しました。 抽出の場合、次のようになります。

function lzo_decompress(const CData; CSize: LongInt; var Data; var Size: LongInt): LongInt; cdecl; asm DB $51 DD $458B5653,$C558B08,$F08BD003,$33FC5589,$144D8BD2,$68A1189,$3C10558B,$331C7611,$83C88AC9 DD $8346EFC1,$820F04F9,$1C9,$8846068A,$75494202,$3366EBF7,$460E8AC9,$F10F983,$8D83,$75C98500,$8107EB18 DD $FFC1,$3E804600,$33F47400,$83068AC0,$C8030FC0,$83068B46,$28904C6,$4904C283,$F9832F74,$8B217204,$83028906 DD $C68304C2,$4E98304,$7304F983,$76C985EE,$46068A14,$49420288,$9EBF775,$8846068A,$75494202,$8AC933F7 DD $F983460E,$C12B7310,$828D02E9,$FFFFF7FF,$C933C12B,$C1460E8A,$C12B02E1,$8840088A,$88A420A,$420A8840 DD $288008A,$113E942,$F9830000,$8B207240,$FF428DD9,$8302EBC1,$C32B07E3,$1E8ADB33,$3E3C146,$2B05E9C1 DD $D9E949C3,$83000000,$2F7220F9,$851FE183,$EB1875C9,$FFC18107,$46000000,$74003E80,$8AC033F4,$1FC08306 DD $F46C803,$FBC11EB7,$FF428D02,$C683C32B,$8369EB02,$457210F9,$D98BC28B,$C108E383,$C32B0BE3,$8507E183 DD $EB1875C9,$FFC18107,$46000000,$74003E80,$8ADB33F4,$7C3831E,$F46CB03,$FBC11EB7,$83C32B02,$D03B02C6 DD $9A840F,$2D0000,$EB000040,$2E9C11F,$2BFF428D,$8AC933C1,$E1C1460E,$8AC12B02,$A884008,$88008A42 DD $51EB4202,$7206F983,$2BDA8B37,$4FB83D8,$188B2E7C,$8904C083,$4C2831A,$8B02E983,$831A8918,$C08304C2 DD $4E98304,$7304F983,$76C985EE,$40188A20,$49421A88,$15EBF775,$8840188A,$188A421A,$421A8840,$8840188A DD $7549421A,$8AC933F7,$E183FE4E,$FC98503,$FFFE4284,$46068AFF,$49420288,$C933F775,$E9460E8A,$FFFFFECA DD $8B10552B,$10891445,$75FC753B,$EBC03304,$FFF8B80D,$753BFFFF,$830372FC,$5B5E04C0,$90C35D59 end; 

...および圧縮自体のための同様の魔術。 これは正常に機能しますが（すぐに入手することはできませんでしたが）、実動コードにはお勧めしません。 デバッグするときは少し不便です...

フォントを圧縮すると、67ではなく17キロバイトになります。 また、生成をその場で実装した場合は、2〜3キロバイトでした。 。

uFMODを使用して音声を出力する

音や、少なくとも音楽なしでゲームをプレイしたい人はいません。 このコンテストの前に、私は低音ライブラリを使った経験がありましたが、それを船外に残さなければなりませんでした。必要なdllは97キロバイトも消費していました。 コンテストのレポートトピックで、アセンブラーで記述されたxm音楽を出力するためのミニチュアライブラリであるuFMODについて言及しました。 今後、プロジェクトでのその実装は、exeファイルのサイズに実質的に影響を与えないと言います。

しかし、1つの小さなニュアンスがありました。 FPCコンパイラの最新バージョン（2.2.x以上）では、このライブラリは機能しませんでした。 そして問題は、リンカのあいまいな動作にあります。 この問題の技術的な側面を可能な限り正確に説明できるかどうか、つまり、ヘッダーファイルで宣言された外部関数が、そこに接続されているオブジェクトファイルに表示されない理由を説明できません。 この動作は、コンパイラ開発者に残っています。 関数の1つに対するこの動作の「回避策」の例を示します。

次のようなものでした。

 function waveOutClose(hwo:Pointer):LongWord; stdcall; external 'winmm.dll'; 

そして、このようにラップしなければなりませんでした：

 function my_waveOutClose(hwo:Pointer):LongWord; stdcall; external 'winmm.dll' name 'waveOutClose'; function _waveOutClose(hwo:Pointer):LongWord; stdcall; public name 'waveOutClose'; begin Result := my_waveOutClose(hwo); end; 

そして、ライブラリが必要とする数十の関数に対して。 uFMODの実装は、最も軽量で使いやすいものとしてwinmmを使用したことを明確にします。 シンプルさのマイナスから-一度に1つのストリームしか再生できませんでした。 したがって、音楽は私のゲームに登場しましたが、音を放棄しなければなりませんでした。

実際には、xm-track自体がここに取り込まれ 、その後uFMODのユーティリティがそれをまさにそのような pasファイルに変えてくれました。

テクスチャ生成

クラシックを言い換えると、テクスチャ生成なしでどのデモシーンプロジェクトが実行されますか？ 最初は、このトピックを省略したかったのです。これは非常に単純で、「額に入れて」単一の（！）テクスチャを生成しました。 しかし、おそらく新参者の中にはこのアプローチが役立つと思う人もいるでしょう。

ゲーム内のほぼすべてのスプライトは同じテクスチャを使用します。



審美性を高めるために、「ボーダー」を付けた縞模様のテクスチャです。 色合い（つまり、そのようなテクスチャで目的の色を「乗算」する）が与えられると、任意の色のストライプテクスチャが得られます。

私は絶対に生成コードが好きではありません。明らかにより最適に記述できます。 さらに、境界線が誤って描画されているという永続的な感覚があります。

 function TGame.GenerateTexture(aWidth, aHeight, aBorderSize: Integer): TglrTexture; var m, m_origin: PByte; i, j: Integer; value: Byte; begin m := GetMemory(aWidth * aHeight * 3); m_origin := m; for j := 0 to aHeight - 1 do for i := 0 to aWidth - 1 do begin if (i < aBorderSize) or (j < aBorderSize) or (i > aWidth - aBorderSize - 1) or (j > aHeight - aBorderSize - 1) then value := 196 else if ((i + j) mod 16) >= 8 then value := 255 else value := 196; m^ := value; m+=1; m^ := value; m+=1; m^ := value; m+=1; end; Result := TglrTexture.Create(m_origin, aWidth, aHeight, tfRGB8); end; 

変更の場合、敵の赤の色合いはランダム（）でわずかに異なります。

NVidiaの迷惑なバグ

コンテストに作品を提出した後、ホストは提出された作品からアーカイブを収集し、公開展示します。 参加者のタスクは、自分以外の互いの場所を整理することです。 評価のために3日間が与えられるので、緊急作業の後はリラックスできます。 しかし、そこにありました！

しかし、次々と出場者は私のゲームが彼らのために正しく動作しないことを退会します-プレイヤーの「タンク」は原則的に見えず、多くの敵戦車は見えません。時々点滅します。 敵は排気管からの煙によってのみ識別できます。 このような問題は、Nvidiaビデオカードのすべての出場者に現れます。 さらに、参加者の1人は私の構成と同じですが、私のバグはまったく現れません。 誰かがWindows 95（！）との互換モードでの起動を助けましたが、ほんの少ししかありませんでした。

さまざまなビルド（既に競合のルールに少し反している）をレイアウトし、コード内のすべての疑わしい場所をクリーンアップし、さまざまな設定をアドバイスしましたが、すべてが無駄でした。 最後に、参加者の1人、最も細心の注意を払っており、彼に感謝（hello、pelmenka！）、理由を発見しました-Nvidiaコントロールパネルでスレッド最適化をオフにすると、ゲームは正常に動作します。 迷惑なのは、いくつかのゲームでBSODの原因となった太古の昔から、私の設定がオフになっていることです。

この貴重な情報のおかげで、私は自宅でバグを再現して修正することができましたが、ほとんどの競技者がすでに投票していることはすでにわかっていましたが、一般的に、私はNvidiaコントロールパネルの標準設定でゲームをチェックしなかった自分にとって邪悪なピノキオでした。

長い間、問題の解決策を見つけるプロセスを説明しません。 私は、検索プロセスで次のことに気づいただけです：

• ストリーミングの最適化は、メリットよりも多くの問題をもたらします。 「nvidia threading Optimization」を簡単に検索すると、ゲームフォーラムへのリンクが表示されます。ゲームの「点滅」を避けるために、この設定を無効にすることを強くお勧めします。
• この最適化がドライバーレベルで行うことを説明する仕様はありません（またはありますか？）
• ストリーミング最適化がオンになっているバグについて不満を言っているインディー開発者からの多くのトピック。 「ただオフにする、仲間」以外の答えはありません

最後に、「名前を付けられない」ピースがオンになっているときにglBufferSubData関数の誤った操作について不平を言うトピックに注目しました。 これは私に手がかりを与え、しばらくしてから（デバッグ、チェック）、問題の本質を特定しました。

glBufferSubData関数は、頂点バッファーのデータを更新します。 この関数の主な目的は、バッファの「ピース」を更新することですが、メモリを割り当てずにバッファ全体を更新する必要がある場合にも使用する必要があります（私の場合）。

ストリーミングの最適化がオンになっている場合、NVidiaドライバーは（常に？）ガイド付き属性の1つに基づいて、この関数への呼び出しを別のストリームに入れ、すぐに制御を返し、嘆かわしい結果をもたらします。 バッファに描画される前にバッファに「フラッディング」する時間があるデータは不明です。 また、NvidiaのOpenGLドライバーは、これを問題と見なしていません。 あなたの質問に先立ち、私は答えます：いいえ、転送されるデータのサイズはごくわずかで、数キロバイト（特にバス帯域幅と比較して）なので、問題は太いデータとはほど遠いです。

OpenGL仕様では、この関数を別のスレッドで実行できるとは言われていません。 Nvidiaのメンバーからの個人的なイニシアチブですか？

フレームごとにglBufferSubDataを1回使用する場合、ドライバーはこのバッファーに対するすべての操作の完了を待機した後（おそらく）このバッファーの描画を「キャッシュ」して呼び出します。

そして、私の場合、1つのバッファーがフレームごとに数回使用されます。 それは：

 glBindBuffer(GL_ARRAY_BUFFER, BufferId); glBufferSubData(GL_ARRAY_BUFFER, 0, Size, Data); glDrawElements(...); glBindBuffer(GL_ARRAY_BUFFER, 0); ... glBindBuffer(GL_ARRAY_BUFFER, BufferId); glBufferSubData(GL_ARRAY_BUFFER, 0, OtherSize, OtherData); glDrawElements(...); glBindBuffer(GL_ARRAY_BUFFER, 0); 

そして、ここであなたはすべての栄光の中でストリームの最適化を感じるでしょう。 最終的に画面に表示されるものによって、ブラインドケースが決まります。

これはまあまあの解決策ですが、glFinish（）呼び出しが役立ちます。 個人的には、このような微妙な状況を避けるために、バッファー内のデータを更新するためのロジックを少し変更しました。

Q：データを組み合わせて一度に描画しないのはなぜですか？
A：これらの呼び出しの間に他の要素のレンダリングがあり、描画順序を変更することはできません。

Q：異なるバッファーを使用しないのはなぜですか？
A：バッファ内のデータはフレームごとに更新されるため、いくつかのバッファを保持するのはリソースの無駄です

まとめ

その結果、2位または3位を争うことはできたかもしれませんが、私は4位になりました。 イライラは、私がリーダーの「トロイカ」を過ぎて飛んだという事実によってではなく、良いゲームと7日間のわずらわしい仕事を「台無しにした」という認識によって生じました。

短いビデオゲームプレイ：



合計リリースサイズは約80キロバイトでした。 彼らが含まれます：

• 62.0 kb-exe
• 17.3 KB-フォント
• 0.52 kb-シェーダー

- リリースをダウンロードします（必要なすべてのソースが添付されています）。
-githubのソース