戦車の道。 アイデアからゲームへの道

私はいつも質問に答えるのが難しいと感じています。ゲームのアイデアはどこから来たのですか？ しかし、今回は、サイトの1つでWorld of Tanksのバナーを見たときに、このアイデアが思いついたと多かれ少なかれ正確に言うことができます。 広告主のWebサイトにリダイレクトする前に、マイクロゲームでユーザーの注意を引くようなバナーがありますか？ したがって、このバナーには、何らかの理由でレンガの壁を突破することで、クリックすることで1つまたは別の距離をクリックすることができるタンクがありました。 その瞬間から、私は仕事の途中で、タンクランナーランナーについて考え始めました。 すぐに生まれ、タイトルのWargamingからのセンセーショナルなヒットへの参照。 私のゲームの本質は、最大距離をカバーすることを目的とした、特定の道路、パスに沿った動きであることを考えると、私には面白そうに思えました。 habracatの下には、ゲーム、開発、技術的な詳細、および古典的な「gamedevストーリー」にあるべきすべてすべてに関するストーリーがあります。

ゲームについて

ここに何がありますか？ さて、まず、このような戦車があります。



穴穴



これは、実質的に3車線に分割された道路（こんにちは、サブウェイサーファーズ！）に乗っています。 左右にスワイプすると、障害物との衝突を避けるために隣接する車線に再構築できます。 他のランナーとは異なり、ここでの操作は瞬間的ではありません（これはまだ戦車です）。これも考慮する必要があります。 奇妙に聞こえますが、私たちの戦車はジャンプ（スワイプ）できます。 ジャンプしないランナーは何ですか？ さらに、トラップピットを飛び越えて、背後に隠れて対戦車のハリネズミを撃つのも楽しいです。 もちろん、ゲーム内の砲弾は限られていますが、戦車は撃つことができます（下にスワイプ）。 私の意見では、射撃は同じサブウェイサーファーのスケートボードに似ており、操縦の時間がない場所に「強制的に」行くことができます。





本当に陰湿なtrapの1つ



一般的に、Way of Tanksを作ったとき、私はしばしばトップランナーをスパイしました。 もちろん、ルーレット、毎日の競技、Facebookの友達、プッシュ通知など、ARPU、MAU、DAUを増加させるファッショナブルなチップの多くは私にはありません。 しかし、ゲームの主なものは魂で作られたゲームプレイだと信じたいです！ しかし、気が散りました。



第二に、目に見えない敵によって置かれた障害物が戦車の道に散らばっています。 すべての障害物は2つのタイプに分けられます：ジャンプできるもの、地面レベル以下にあるもの（ピットトラップ、地雷原）とジャンプできないが、丸くするか破壊することができるもの（壁、対戦車ハリネズミ、ピルボックス）。 さらに、そのパス内のすべてを単純に破壊しても機能しません。 戦車の主砲のリロード速度は制限されているため、あまり頻繁に射撃することはできません。 したがって、ゲームを成功させるには、反応と運だけでなく、操作するタイミングと射撃するタイミングをすばやく決定する能力も必要です。



当初、私はいくつかのミニボスをゲームに追加することを計画していましたが、いつものように、人生と限られたリソースは独自の調整を行います。 したがって、ミニボスからは、Way of Tanksにまだ爆弾を落としてプレイヤーの戦車を破壊しようとしている飛行機があります。





AI機は非常に単純に配置されており、原始的に言うこともできます。 主な特徴は2つあります。意思決定の速度と、次の爆弾の準備時間、つまり「リロード」です。 そのため、爆弾の準備が整うと、爆撃機はプレイヤーと同じ車線を占領しようとしますが、逆にリロードするときは、リターンファイアラインにいることを避けます。 テストの後、いくつかの複雑な問題を追加しました。飛行機が戦車の回転の始まりを修正し、アルゴリズムが戦車が既に新しい車線に再構築されたかのように動作します。 このように、爆撃機はプレイヤーの反応を「予測」し、ターゲットで予定よりも早く作業することを学びました。 さらに、ゲームのバランスを維持するためのパフォーマンスの段階的な改善（飛行機は5番目または6番目のアプローチからのみ最大の難易度に達します）。



他のランナーと同様に、戦車に超能力を与える一時的なボーナス（パワーアップ）があります。 リストにはまだ決めていませんが、現在4つあります。



収集されたコインを倍増

「ジャーク」-タンクが障害物を突破できるようにしますが、ジャンプ中のみです

戦車の操縦性を向上

装甲貫通突撃-射撃の際、戦車は自身の前にある障害物の全ラインを破壊します（突撃に対する+1だけでなく）



ああ、Jetpack Joyrideのように、ミサイルを飛ばすという考えがまだありました。 しかし、協議して考えた後、彼らはミサイルの飛行速度が速すぎるか、または見た目が遅くなると判断しました。 その結果、ミサイルはこのような神風の装甲車になり、戦車に衝撃を与えました。







一般的に、ゲームはシンプルであることが判明しましたが、それにもかかわらず、オーガニックでギャンブルです！ 少なくとも、これはすべてのゲームの中で唯一のものであり、私自身がこれらの無限のテストとデバッグをすべて行った後も喜んでプレイし続けています。

技術部

これは、私がAndEngineで作成する5番目のゲームです。 はい、Unityについては知っていますが、クロスプラットフォームを追求していません。 私の意見では、1つのプラットフォーム専用のプラットフォームをより高速かつ優れたものにする方が良いと考えています。 ええ、おなじみの分野でプレイしているということは、いわば、App Storeで何らかの形で自分自身を表現しようとするのとは異なり、多かれ少なかれ成功しています。 私は最近LibGDXを見ていますが。



ゲームの内部構造についてもう少し説明します。 ランナーの主なことは、実際には前進することです。 キャラクターの後のカメラの動きと彼女の目の前の世界の並列生成でアプローチを試みましたが、さまざまな理由で、静的カメラでオプションを決定しました。 つまり、戦車とカメラは静止しており、ゲーム世界全体がそれらに向かって移動し、戦車が前進しているような錯覚を作り出します。 このアプローチは先験的にパフォーマンスを失いますが、すべてが正しく最適に行われていれば問題はないはずです。



背景には、カメラのサイズ（1280x720）の4つのオプションがあります。 同時に、プレーヤーはそれらのうちの2つしか見えません。 したがって、最初のステップでは、SpriteGroupの背景を位置（0、-CAMERA_HEIGHT）に設定し、その中の2つのスプライトをそれぞれ（0、0）と（0、CAMERA_HEIGHT）に設定します。 残りの2つは非表示です。 次に、SpriteGroupをタンクの速度で下に移動します。 座標（0、0）にある場合、元の位置に戻しますが、背景の次のセクションをランダムに選択して非表示にします。 すべてがシンプルです！







しかし、ここで不快なバグに遭遇しました。SpriteGroup内のスプライトは、位置を変更すると「点滅」する可能性があります。 stackoverflowで、この問題に対するこの解決策を見つけました。 SpriteGroupの場合、onManagedUpdateを再定義して次のように記述します。

@Override protected void onManagedUpdate(float pSecondsElapsed) { final SmartList<IEntity> children = this.mChildren; if (children != null) { final int childCount = children.size(); for (int i = 0; i < childCount; i++) { this.drawWithoutChecks((Sprite) children.get(i)); } submit(); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

背景の動きとともに、障害物を作成する必要があります。 これを完全に偶然に行うのは正しくありません。この場合、通行不可能なセクションの出現が可能だからです。 私のすべてのtrapもセクションに分割され、事前に準備されています。 これらは、ほぼ次の構造のJSONファイルに保存されます。

{

「ルート」：{

「セクション」：[

[

["CELL_EMPTY"、 "CELL_EMPTY"、 "CELL_EMPTY"]、

["CELL_COIN"、 "CELL_EMPTY"、 "CELL_EMPTY"]、

["CELL_COIN"、 "CELL_EMPTY"、 "CELL_EMPTY"]、

[「CELL_COIN」、「CELL_EMPTY」、「CELL_HEDGEHOG」]、

["CELL_PIT"、 "CELL_WALL"、 "CELL_WALL"]、

[「CELL_EMPTY」、「CELL_EMPTY」、「CELL_EMPTY」]

]、

...

私はすべてのオプションを繰り返しテストしましたが、失敗した場合は変更するか、単に拒否します。 その後、世界の生成の各ステップで、トラップのある新しいランダムセクションを選択するか、現在のセクションの現在の行を表示します。



最新のAndroidゲームと同様に、Google Playゲームサービス（実績とリーダーボード）と統合されています。 すべてがかなり平凡であり、マニュアルのオンオフで詳細に説明されています。 ウェブサイト： developers.google.com/games/services/android/quickstart 私は、新しいゲームのたびに一度書いたコードを使用するだけで、ほとんど変更はありません。

最適化

AndEngineでの最適化について少し説明したいと思います。 アニメーションスプライトではなく、onManagedUpdateをオーバーライドせず、エンティティ修飾子を使用しないすべてのオブジェクトについては、作成直後にsetIgnoreUpdate（true）を設定することを忘れないでください。 これは、エンジンの各クロックサイクルでonUpdate呼び出しの数を減らすことにより、パフォーマンスにプラスの影響を与えます。 また、オブジェクトを非表示にする場合はsetIgnoreUpdate（true）を実行する必要があります（setVisible（false）を設定）。



さらに、シーン上で動的に作成され、単一の数量ではないすべてのものは、プール（オブジェクトを再利用するための特別なクラス）に配置する必要があります。 私はtracks、爆発、戦車の線路などから地面に痕跡があります。 たとえば、ここでは、トラッププールのように見えます。

 public class TrapPool extends GenericPool<Trap> { @Override protected Trap onAllocatePoolItem() { return new Trap(0, 0, Assets.trapRegion, ContextHelper.getVBOM()); } @Override public synchronized Trap obtainPoolItem() { return super.obtainPoolItem(); } @Override protected void onHandleRecycleItem(Trap pItem) { pItem.setVisible(false); pItem.detachSelf(); super.onHandleRecycleItem(pItem); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、新しい障害物がステージに現れた場合、次のことを行います。

 Trap trap = trapPool.obtainPoolItem(); trap.setPosition(nX, nY); trapLayer.attachChild(trap);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、トラップが不要になったとき（カメラの視界外）：

 trapPool.recyclePoolItem(trap);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

レンダリングを高速化するために、すべての背景を1つのSpriteGroupに入れました。 ここでの唯一の注意点は、SpriteGroupには1つのアトラスしか使用できないということです。 したがって、すべての背景スプライトは20％縮小され、2048x2048の最大テクスチャサイズに適合します。 私は真実を知りません、それが今どの程度関連しているか、まだ進歩が止まっておらず、すべてのテストデバイスが4096x4096をサポートしていますが、これは画質に特に影響を与えないので、余計なことではありません また、イメージ形式をRGBA8888ではなくRGBA4444に設定するのも理にかなっています。 このような「漫画」グラフィックスの場合、画像は変更されず、使用されるメモリ量は半分になります（TexturePackerを使用する場合は、アトラスを公開するときに適切なオプションを選択するだけです）。



しかし、「AndEngine for Android Game Development Cookbook」で私がスパイしたトリック-アクティビティ背景のレンダリングを無効にし、どこにも見られず、使用されず、FPSに著しく影響します。 これを行うには、res / valuesで独自のテーマを作成します。

 <resources> <style name="Theme.NoBackground" parent="android:Theme"> <item name="android:windowBackground">@null</item> </style> </resources>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

マニフェストで、アクティビティに設定します。

 android:theme="@style/Theme.NoBackground"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

フラグメンテーション

興味深いのは、Androidデバイスのさまざまな画面解像度との闘いです。 当初、ゲームは16：9のアスペクト比で開発されました。 他の画面に画像を拡大縮小するための3つのオプションを検討しました。それらを呼び出してみましょう。



1.元のサイズ-正しいアスペクト比、画像は画面を垂直に完全に埋めますが、これにより、未使用の領域が側面に表示されます

2.ズーム画面-同じことですが、画像が画面を水平方向に満たし、上下の背景の「余分な」部分がトリミングされ、インターフェース要素が中央に移動します

3.画面の拡大-アスペクト比を考慮せずに、画面に合わせてゲームを拡大します



最も不適切なアスペクト比の例でどのように見えるかを示します-4：3





左から右：元のサイズ、ズーム画面、ストレッチ画面



明らかに、4番目のオプションは、4：3でグラフィックを再描画しますが、ゲーム要素には16：9領域も使用することを示唆しています。 つまり、オプション1を取得しますが、側面のフレームの代わりにレベル装飾があります。 実際、素晴らしい選択肢は、彼から遅く促されたのは残念なことです。結局のところ、グラフィックの再描画はそれほど単純でも高速でもありません。 しかし、内部の完璧主義者は落ち着きたくなかったため、結果としてグラフィックが再描画され（すべてではなく、主に背景）、タブレットではスマートフォンよりもゲームの外観が良くなりました！





タブレット（4：3）およびスマートフォン（16：9）のスクリーンショット



誰かが言う：「Pffff！ 彼はアメリカを発見しました！」、しかし、他人の過ちから学ぶことは常に可能ではありません、時々、あなたはそれをより良くする方法を理解するためにあなた自身の「自転車」を発明しなければなりません。 特に、「すぐに使える」AndEngineには、結果として私が決めたカメラのタイプがありません。 そして、チュートリアルでは、そのようなアプローチについて特に書いていません。

費用と謝辞

収入について話すことは何もないので、費用についてお話します。 Google Playでの公開への最初のコミットからゲームの作成にかかった時間は、ほぼ3か月でした。 プログラマーとしての私の純粋な時間を約1か月半評価しました（ゲームは暇なときに行われ、もちろん他のチームメンバーからの結果を待たなければなりませんでした）。 レートで〜3000ドルにしてみましょう。 プロの非常に才能のあるアーティストであるYegorでは、可能な利益を共有することに基づいて、すでに2番目のゲームに取り組んでいるので、ゲームのアートを作成するための絶対コストを考慮する方法はわかりません（時間を除く）。 Google Playページの主要言語でのローカライズには、約60ドルかかりました（スクリーンショットの簡単な説明とキャプション）。







サウンドデザインについては、Gamingearzの皆さんに感謝します。 いつものように最高レベルで最短時間で彼らと協力したのはこれが初めてではありません。 彼らは自分の仕事に非常に気配りがあり、愛情があり、私のようなインディー開発者にとっても、限られた予算内でオプションを提供する用意があります。 Way of Tanksでは、象徴的な200ドルで素晴らしいサウンドトラック（およびいくつかのゲームサウンド）を録音しました。 また、 diforb.comサービスを使用して、あらゆる種類のインターフェイスサウンドを自分で作成しました。



ゲームのプロモーションビデオは、プロの写真家であり、良い人であるミンスクのセルゲイムラトフによって作成されました。 そして、彼も私のゲーム用のビデオを作るのは初めてではありません。 私は、他のすべての人と同じように、私が以前に成功した仕事の経験をすでに持っている人々にアピールする傾向があります。 これはさらに100ドルです。 それは実質的にすべての費用です。 もちろん、マーケティングへの投資についてはもう少しアイデアがありますが、これはオプションです。 まず、Way of Tanksがプレイヤーに私が好きな方法でアピールするかどうかを理解したいですか？



すべてのコストを合計すると、Google Playの単純なランナーは約3,500ドルかかることがわかります。 それはたくさんまたは少しです-自分で決めてください。 私にとって、これは興味深く、よくできた作品の喜び、開発者コンソールの切望された「公開」ボタンを押すこと、すべてのインディーズが演じる「Store Lottery」をプレイする機会のための公正な価格です。 そして多分何かを勝ち取ります。