私たちは技術リーダーとそれを理解します
ロシア銀行の教育プロジェクトのために、印象的なウェブゲーム「失われた貯金箱の秘密」を作成しました。彼女は学童の注意を金融リテラシーのトピックに引き付け、用語を紹介し、賢くお金を管理する方法を教えます。このゲームは子供だけでなく、ロシアのさまざまな都市の大人にも好かれ、3万人以上がプレイしました。
私たちは長い間、技術リーダーにWebゲームの開発について教えてくれるように頼んでいます。彼は、このプロジェクトでの私たちの経験、発生した困難についての激しい記事を書いただけでなく、ブラウザゲームの開発におけるライフハックについても共有しました。その結果、有用性に満ちた素材になります。読む。
Webゲームは、通常のコンピューターゲームやブラウザーの通常のWebサイトとは根本的に異なります。通常のゲームでは、すべてのゲームリソースがオフラインで利用可能であり、ゲームエンジンは、コンピューターのプロセッサー、メモリ、およびビデオカードに関する情報を認識しています。通常のサイトでは、必要なコンピューターリソースはほとんどなく、問題が発生した場合は、ページをリロードするだけです。
ブラウザゲームの機能についての仮定がありました。RAMの使用可能サイズと使用サイズに大きな制限があり（たとえば、モバイルデバイスには1 GBのRAMで十分であるとTORに記載されています）、ゲームリソースの品質（画像、テクスチャ、スプライト、サウンド、ビデオ）とそれらのダウンロード速度。
これに加えて、クライアントからの要件がありました。ゲームは、宣言されたすべてのモバイルおよびデスクトップブラウザ（IE 11を含む）で、可能な限り低いハードウェア特性で実行および動作する必要があります。これらの要件は、ゲームが都合の良い機会に、たとえば学校などで手元にあるデバイスで表示されることになっているという事実に基づいていました。
エンジンの選び方
私たちはすでにゲーム開発の経験があるので、エンジンを選択するための指示がすぐに示されました：
- Phaser — /.
- Unity Web — .
- LibGDX, Godot, PlayCanvas.
未知の選択肢は明らかな理由で落ちました-それらは習得して研究する必要があり、それは不可能ではないように見えましたが、何らかの方法でおびえました。Unityオプションは、エンジンとエクスポートの制限により、たとえばIE 11でオーディオを使用できないために失敗しました。また、UnityからエクスポートされたJavascriptが非常に大きく、IE11の解析とコード実行が最新のものよりもはるかに遅いためです。ブラウザ。
そのため、Phaserエンジンの新しいバージョンを使用することが決定されました（開発時には、バージョンPhaser 3.11でした）。このエンジンを選択した理由も、すべてのロジックとレンダリングがソフトウェアであるためです。つまり、コード内の将来のゲームのあらゆる側面を完全に制御できるということです。
彼らが書いたように
当初、精巧なメカニズムはありませんでしたが、それが間違いなくプラットフォーマーになることはわかっていました。そのため、エンジンに関する知識を更新し、消費されたリソースとブラウザの負荷を概算するために、少なくともいくつかのプロトタイプをまとめることにしました。
ドキュメントに用意されている「キャラクターの動き」と「タイルマップ」の例から、組み立てられ、起動されました。これは機能します。キャラクターはプラットフォーム上を歩き、ジャンプし、動きます。利用可能なすべてのデバイスで起動-引き続き機能します。 「仮想ボタン」の例から仮想制御ボタンを追加し、モバイルで起動しましたが、引き続き機能します。プロトタイプには、打撃、敵、ダメージの与えと受け、コインの収集などの小さなメカニズムを追加するだけで十分でした。
プロトタイプでは、必要以上のものがありました。たとえば、2つのキャラクターを制御するメカニズムが実装され、いつでも切り替えることができました。
プロトタイプが成功した後、アーキテクチャがどのように実装され、コードが編成されるかを理解しました。インフラストラクチャの部分について言えば、これはリソースのロード、ゲームオブジェクトの作成、画面の切り替えという点でエンジンと連携しています。ゲームロジック自体に関しては、これはキャラクターの実装、戦利品、トラップ、敵との相互作用のメカニズムの実装です。
開発スタックは、同様のプロジェクト（webpack、webpack-dev-server、babel、babel /プリセット-typescript）で非常に一般的です。
どんな困難でしたか
パフォーマンス要件を満たすこととチームのコミュニケーションで問題が発生しました。新しいツールを使って作業し、新しい形式で資料を相互に転送する必要があったため、最初はすべてがスムーズに機能するとは限りませんでした。
たとえば、TORでは、ゲームが起動時にデバイスのパフォーマンスを判断しようとすることが規定されており、パフォーマンスが低い場合は対応する通知が表示されます。この段階で、2つの問題に直面しています。第一に、ブラウザはこの問題に関する情報を実質的に提供しません。次に、特定の時間における特定のブラウザタブのパフォーマンスは、外部要因（開いているタブの数、他のタブに重いサイトがあるかどうか、ブラウザが最小化されているかどうか）に大きく依存します。
いくつかの理論的および実際的な仮説がテストされ、そこから最終的な解決策が生まれました。解決策は次のとおりです。
- 進行状況が0から100％であるゲームの読み込み画面では、リソースの実際の読み込みは92％で終了します。
- その後、画面の外側にシーンが作成され、その上に重いアニメーションと小さな物理学が配置されます。
- 次に、5秒以内に、1フレームの平均レンダリング時間が測定されます。
- その後、デバイスのパフォーマンスが決定され、進捗状況は100％に達します。
非常に重要なのは、ゲームがIE 11で完全に機能する必要があることであり、これも不便を引き起こしました。開発者ツールを実行すると、このブラウザですでに遅いJavascriptの実行がさらに遅くなることが判明しました。
つまり、ゲームのブレーキに直面し、開発者ツールを開いて理由を見つけると、ゲームの速度がさらに低下します。
ゲームの仕組み
ゲームの仕組み自体は複雑ではなく、主に既存のゲームに触発されています。
たとえば、主人公は武器を持ったワンピースのアニメーションスプライトです。このソリューションは、スイングと武器のアニメーションの非同期を回避するために選択されました。したがって、損傷のチェックは次のように行われます。インパクトアニメーションの特定のフレーム（およそ3番目からのフレーム）の瞬間に、交差領域を計算します。これは、さらにいくつかのアニメーションフレームに有効です。このようにして、私たちは武器の現実的な操作を達成することができました。
主人公のアニメーションにおけるこの決定の欠点は、各レベルの性別ごとに、武器を備えた準備されたアニメーションの個別のセットが必要になることです。そして第2レベルでは、クレジットスニーカーで別の追加セットが必要でした。合計で、キャラクターごとに4つのフルセットのアニメーションを取得しました。
ここでのもう1つの面白い点は、最後の戦いで武器を選択するときに、実際には対応するレベルからキャラクター全体を選択することです。したがって、剣を持ったすべてのヒーローは通常のスニーカーになります。
胸から鍵をとる仕組みが面白かったです。キャッチする必要のあるキーについては、トリガー領域をキーの視覚的なスプライトよりも小さくし、ランダムに横にわずかにオフセットしました。これは、「私のキーは最初に組み立てられない」という望ましい効果につながりました-時々、その操作の領域に到達するために、キーを数回収集しようとする必要があります。それ以外の場合は、簡単すぎましたが、最終リリースでは、失敗した試行の割合を減らすためにトリガー領域がわずかに増加しました。
他のすべてのメカニズムは実際には同じです-特定の時点とアニメーションでキャラクターとゲームオブジェクトのアプローチと交差をトリガーします。
Dragon of Insuranceのメカニズム、割れ目の上の飛行、そして最後の戦いはもう少し複雑でした。テクニックは同じですが、この時点で他のキャラクターのアニメーションを再現するために、一時停止と非アクティブが追加で調整されました。
結論とアドバイス
非常に早い段階でジャンルを決定します。
Web上のゲームは実際の現象であり、独自のオーディエンスと独自のルールがあります。このようなゲームはインストールを必要とせず、短いゲームセッションを手配することができ、見た目よりも多くのメカニズムを引き付けます。
ヒント-Webゲームの開発は、単なる「ページ上のスクリプト」ではなく、実際のゲームのように扱ってください。テスト、プロファイル、およびメモリリークとCPUオーバーヘッドの回避。プレイヤーとそのデバイスのバッテリーは幸せになります。