たくさんのコーンを埋めてゲームをリリースする方法

すべては2013年に始まりました。 それから、Androidにはたくさんのおもちゃがありましたが、あらゆる点で今よりも少なくなっています。 そして、当時のAndroidマーケットでゲームをリリースすると、いくらかのお金を得ることができました。 そして、私はゲームを作るのが好きなので、疑いはありませんでした-私たちはゲームをリリースします。 私たちは、プログラマ、アーティスト、テスター/アイデアのジェネレーターの小さなチームです。 将来を見据えて、コーンとレーキをたくさん集めました。 基本的に、技術的なポイントのレビューがあるので、この記事はゲームの開発に何らかの形で関係しているすべての人に役立ちます。 間違いを繰り返さないでください。

ゲームのアイデア

その時点で存在していたゲームの中で、私たちはボールが迷路を転がり抜け、穴を避け、最後のポケットに到達しようとするゲームが好きでした。 当時、そのようなゲームはすでにいくつかありましたが、グラフィックスの点ではそれほどではありませんでした。 したがって、私たちはカラフルさを重視して、独自に行うことにしました。 私はアーティストに注目したい、彼は非常に、非常にクールに描いた。 彼のおかげで、ゲームはそのままになりました-美しい。



エンジンとしてlibGDXを使用することが決定されました。 私はその時彼をよく知っていて、彼が好きで、すでに彼のプロジェクトを完了しました。 私たちは勝利を収めることができると確信していました。 判明したように、私たちはそれを手に入れました。

ゲームプレイ機能

原則として、ゲームプレイはこのタイプのゲームの標準であることが判明しました-加速度計の助けを借りてボールを転がします。 追加機能-テレポーターがあり、壁は単なる退屈な長方形ではありません。 しかし、それについては後で。



私が管理に注目したい機能の。 快適なゲームのために加速度計の設定を選択するのに長い時間がかかりましたが、テスターは常に何かが間違っていることに気付きました。 例として、彼はAndroidマーケットの同様のゲームを引用しました。 最後に、私はこのゲームをダウンロードし、逆コンパイルし（難読化されていないことにまだ驚きました）、制御の瞬間を見ました。 コードは私のものと同一であり、係数のみが異なることがわかりました。 逆コンパイルされたゲームもlibGDXで書かれていることに注意してください。つまり、当時は大量のゲームがすでに書かれていました。





管理をセットアップできます

技術部

前述したように、ゲームはlibGDXで記述されています。 ゲームは多くのリソースを使用します-グラフィック、サウンド、マップ、フォント。 すべての瞬間を見ていきましょう。



グラフィックス ゲームには数百のスプライトがあります。 パフォーマンスのために、すべてのスプライトはテクスチャアトラスにパッケージ化されました。 メニュー画面用のアトラス、レベル選択用のアトラスなど。 ビデオメモリを節約し、パフォーマンスを拡張する標準的な手法。 アトラスは、Texture Packerによってパッケージ化されました（libGDX Webサイトからダウンロードできます）。 今これを行う場合、組み込みのTexturePackerクラスを使用します。 Atlasパッケージは、TexturePacker.pack（「folder-with-sprite」、「output-folder」、「atlas-name」）のようなものです。 このアプローチの利点は、アトラスを再パックするためにIDEから別のプログラムに切り替える必要がないことです。









これは、異なるボールを持つ縮小されたアトラスがどのように見えるかです。 これは小さな部分です。このようなアトラスがいくつかあります。



アトラス形式は32ビット、pngです。 透明度のない一部の写真は、jpegアトラスにパッケージ化されています。 私が今やった場合-透明性のないアトラスはETC1で梱包します。 LibGDXはこの形式をネイティブでサポートしており、Androidではビデオメモリを節約します。



グラフィックス（アトラスのロード/アンロード、目的の画像の取得）を管理するために、独自のクラスイメージが作成されました。 組み込みのAssetManagerについては知っていましたが、そのときはもっと便利なソリューションが必要でした。 たとえば、背景画像を取得したい場合は、以前に要求された背景を自動的にアンロードする必要があります。 私の決定により、私はそのようなことをすることができました。



少し離れて-ゲームを書くとき、私はしばしばリソースマネージャーを行います。 多くの場合、標準のAssetManagerに基づいています。 目標は、リソースへのより簡単なアクセスです。 開発の後の段階では、コードの読みやすさが非常に重要な役割を果たします。 本のようなよく書かれたコード。 assetManager.get（TextureAtlas.class、 "data / atlases / buttons"）。FindRegion（ "green-button"）よりも、 images.createButton（ "green-button"）の行を理解する方が簡単です。 このアプローチのマイナス面-久しぶりにゲームに戻ったとき、これらのマネージャーの機能を覚えておく必要があります。 長所から-覚えていれば、何かを編集するのはすでに簡単です。



音。 ゲーム内のすべてのサウンドは.ogg形式です。 なぜmp3ではありませんか？ 当時の一部の電話機モデルでは、.mp3形式で複数のサウンドを連続して再生する際に問題が発生しました。 これらは私の曲がった手だったと認めますが、.oggには問題はありませんでした。 幸い、libGDXは両方の形式をサポートしています; .mp3を.oggに置き換えるのは簡単でした。



最適化するために、サウンドは最小ビットレートに絞り込まれ、形式はモノラルでした。 開発はLinuxで行われ、変換にはSound Converterが使用されました。 私の意見では、Sound Converterは私が今でも使用している素晴らしいユーティリティの例です。 出力形式の設定と「変換」ボタンのある小さなウィンドウ。 巨大なコンバーターへの素晴らしい答え。



フォント ゲームは2種類のフォントを使用します。



最初のタイプは、.ttfフォントとgdx-freetypeライブラリです。 実行時に、.ttfフォントからビットマップフォントを生成できます。 ライブラリの利点は、プログラムの起動時に適切なフォントサイズを設定できることです。 これにより、フォントは常に必要なサイズになります。 欠点の-フォントはテクスチャで「オンザフライ」で生成されるため、これはRAMがあることを意味します。 そして、フォントサイズが大きいほど、より多くのメモリが必要になります。 別の非自明な点-フォントは別個のテクスチャであるため、碑文を描画するときに追加の描画呼び出しがあります（いくつかの碑文を連続して描画する瞬間を除く）。 これに基づいて、.ttfの範囲は「About」画面のみに制限されていました。



2番目のタイプのフォントは、 距離フィールドフォントです。 アイデアは簡単です-Hieroプログラム（公式のlibGDX Webサイトからダウンロード可能）を使用して、フォントの特別なテクスチャが生成されます。 テクスチャでは、各文字に独自の領域があります。 しかし、この領域は「そのまま」描かれていません。 代わりに、特別な方法でこの領域を描画する特別なシェーダーが使用されます（もちろん、これはバッチ処理も中断します）。 利点-比較的小さなテクスチャで、品質を損なうことなく非常に大きなサイズでフォントを描画できます。 短所-フォントを事前に生成する必要があり、フォントの効果（シャドウ、ストロークなど）は使用できません。 また、私が言ったように、これはバッチ処理を壊します。 レンダリング中にのみフォントの色を設定できます。 私たちのニーズにはこれで十分だったので、ゲームのあらゆる場所で使用されるのは距離フィールドフォントです。









これがDistance Fieldフォントの外観です。 背景は透明である必要がありますが、わかりやすくするために黒にしました。



カード。 良いゲームの「チップ」の1つは、コンテンツの量です。 自動的に生成することも、一連のレベルを準備することもできます。 2番目の方法-100を超えるレベルがあります。 レベルはボックスに分かれています-ボックスには15のレベルがあります。 非常に多くのレベルで、それらの便利な編集と保存の問題が生じることは明らかです。 何らかの種類のマップエディターが必要です。 この問題は、2種類のカード-シンプルなものと「オリジナル」（開発中にそのように呼ばれる）があるという事実によって複雑になります。



単純なカードは、このタイプのゲームでは長方形の障害物を持つ標準的な迷路です。 このようなマップを編集するために、Swingをグラフィックライブラリとして使用する単純なJavaプログラムであるエディターを作成しました。 障害物、穴などを手動で配置します。 障害物は好きなように回転、サイズ変更できます-この点で、エディターは非常に便利であることが判明しました。 テスターは不便であり、アクションがキャンセルされるべきではないと不満を言いました-私はそれを理解し、コマンドパターンを研究して、アクションのキャンセル/繰り返しを書きました。





動作中のマップエディター





シンプルな平凡なカード-珍しいことは何もない



チップ-カードをすばやくテストするために、エディターはゲームに切り替えることができました。 すぐに（同じウィンドウで）マップを確認できるゲームが開始されました。 マウスは加速度計として機能しました。 編集者の文章は、「1日を失ってから5分で飛ぶ方がいい」というフレーズに似ていると言えます。



オリジナルのカード。 そのため、アーティストが手書きした写真と呼びます。写真の個々の要素は障害です。 以下はそのようなカードの例です。





サッカー場はすでに面白いです



この場合、標準のマップエディターが適切でないことは明らかです。 次のように問題を考えて解決しました- タイルエディターを使用します。 その中に2つのレイヤーを作成します-1つの背景には、元のレベルの画像があります。 2番目の層はレイアウト層です。 マップには、プリミティブ（円、正方形、多角形）が付いています。 たとえば、穴は「穴」という名前の円です（タイルを張ると、各オブジェクトに名前を割り当てることができます）。 出力では、タイル形式のxmlファイルを取得します。 しかし、この形式は私たちには適していません。 そのため、生成されたタイル化されたxmlを取得し、それをレベル形式に変換する追加のユーティリティを作成しました。 同じ段階で、box2dは4つ以上の頂点で構成されるポリゴン、つまり四角形（少なくともlibGDXのbox2dポート）をサポートしていないことが判明しました。









元の地図をマークアップする



このフランケンシュタイン全体が不器用に見えたが、それはその任務を完全に果たした。 ゲームレベルのほぼ半分は「オリジナル」であり、タイルのおかげで、別のエディターを書くことなくできました。 結論-複雑で大規模な独自の何かを記述する必要はない場合があります。見回すだけで、「自分用に」最小限の仕上げで既製のソリューションを採用できます

ボールアニメーション

ボールが動くとき、それは何らかの方法でアニメーション化され、動きの錯覚を作り出さなければなりません。 このジャンルの一部のゲームはこれに煩わされず、単純な静止画像を使用します。 混乱することにしました。



ガラス、火（溶岩）、サッカーなど、ボールのいくつかの「スキン」があります。 当時、私はlibGDXでの3Dの可能性を知らず、3Dモデルを使用できませんでした。 したがって、フレームごとのアニメーションを実行することにしました。 ボールの完全な回転には約50フレームかかりました。 動きの速度に応じて、フレームレートを変更し、回転が速くなったり遅くなったりするように見せました。 そしてもちろん、これらのフレームの回転を変更しました。 完璧になったとは言えません。3Dモデルは間違いなくより美しい写真を提供しますが、それはそうです。

物理学

ゲームは物理的なbox2dエンジン（より正確には、libGDXのポート）を使用します。 利点のうち、高速であり、多くの機会があります。 マイナスの点-あなたはそれを知る必要があります:)ボールは動的な物体であり、障害物は静的な物体です。 レベルがロードされると、世界の物理モデルが作成され、実際にゲームが開始されます。 一時停止すると、シミュレーションが停止します。 原則として、これが物理学について言えることのすべてです-それに特別な問題はありませんでした。

追加チップ

メニュー画面は複雑です。 また、ゲームの一部として作成されます。 ボールが転がり、加速度計を聞きます。 そして、ボールがボタンに当たると、バウンドします。 また、特定のボタンを特定の順序でボールでタッチすると、ポータルが秘密レベルに開きます:)





ボールが転がり、ボタンから跳ね返る-ピンボールのように



多くの成果があります-レベルを完了するため、一定数の勝利のため、ゲーム内の特定の時間など。 標準のAndroid Google Playアチーブメントは使用しませんでしたが、独自のアチーブメントシステムを作成しました。





成果のごく一部

私が違うやり方をする瞬間

完璧な解決策は存在しないことは明らかであり、経験を積むと、この部分またはその部分が最適化されていないことが理解されます。 今ゲームを作成したら、やり直すと言います。



最初のポイントは、ボックスの選択です。 ゲームを開いてボックスを見ると、各ボックスに点があることがわかります。 複雑さに応じて、これらのポイントは多少なりとも異なります。 したがって、これらのポイントを配置するために、jsonファイルをロードし、この構成ファイルにポイントを配置するクラスを作成しました。 私がこれをした理由は、テクスチャアトラスの場所を節約するためです。 つまり、ボックスの一般的な画像の背景、1つのポイント、および特定のボックスのこれらのポイントの配置順序を保存します。 これが悪い理由は、変更の複雑さです。 各ボックスが個別の画像である場合、画像を修正するだけで十分です。そして、構成ファイルに移動して、何をどのように把握する必要があります。 写真だけで保存する方が良いでしょう。





各ボックスは単なる写真ではありません。 これは、ドットの位置を含む背景+テキストファイル構成です。



2番目のポイント -私は最適化と非常に混同していました（上記の例はこれの確認です）。 すべての画面（メニュー、ボックスの選択、ゲームなど）を1つのコピーで作成し、単純に切り替えました。 これにより、別の画面に切り替えるたびに同じ画面を作成する必要がなくなりましたが、クリーニングの問題が発生しました。 たとえば、ゲーム画面には、特定のレベルの多くのパラメーター（ポイント、時間など）が格納されます。 新しいレベルをロードするとき、最初にゲーム画面の状態をリセットする必要があります。 しかし、新しいチップが追加されたため、何かをクリアするのを忘れがちでした。 これはかなりの時間を「食い尽くし」、そのような問題をデバッグします。 今ゲームを作るときは、そうしません。 画面を変更する必要がある場合は、この画面に必要な設定をいくつかの設定クラスに保存してから、新しい画面を作成します。 新しい画面が作成され、設定クラスから必要なデータが読み取られます。 同時に、より多くのリソースが費やされますが、現代の強力な携帯電話を背景に、今回はごくわずかです。



画面に関する上記の例は、その1つにすぎません。 さらにこのアプローチ-最悪の携帯電話でもゲームは遅れません。 アプローチのマイナスは、それらのどれだけがあり、そのような悪い電話が最適化にそんなに時間を費やすことですか？ 私自身は、このような問題を解決しました。新しいスマートフォンを購入するとき、意図的に平均よりわずかに低い特性を選択しました。 その上でゲームがブレーキなしで実行される場合、私は最適化を気にしません-ほとんどの人にとって、ゲームは正常に起動して動作します。

おわりに

完璧な開発がないように、完璧なゲームはありません。 しばらくして、私たちはゲームを終わらせました。彼女はGoogle Playの光を見ました。 私が言えること-すべてのバンプとレーキにもかかわらず、ゲームの開発は興味深いです。 多くの瞬間があり、解決できない瞬間もあり、回避策を探す必要があります。 しかし、これらの問題を解決すると、開発者としてのレベルが上がります。 私はこのゲームを書くことに興味があり、それをプレイすることは面白いと信じています。