ゲームの トピック発表で約束したように、ゲームエンジンのhabraeffectと詳細に関するレポートを投稿します。
まず、エンジンとゲームプレイの最初のバージョンと現在のバージョンのテストに参加しているすべての人（ゲームと実用的な提案とアイデアの両方）に感謝します。 実践が示しているように、 Habraffectの間に、バグがより迅速に発見され、修正されます:)
3週間の統計
登録済みプレイヤー：4,663
プレイしたラウンド：2,252
プレイヤー数（ゲストを含む）：13,402
フラグメント数：469,534
死亡者数：545,957
得点：1,707（ WTF ？）
[habraeffect中]
オンラインのプレイヤー（最大）：453
CPU使用率（muninのスケジュールによる）：168％（16コア-1600％）
メモリ使用量：1.65 GB
トラフィック（最大）：発信24 Mbps | 着信9 Mbps
（チャートはクリック可能です）
[エンジン]接続[ 1 ]
| [エンジン]メインサイクルタイム[ 2 ]
| [エンジン]送信ごとのバイト数[ 3 ]
|
[サーバー] CPU使用率
| [サーバー]メモリ使用量
|
TTX
ホスティング：データセンターVladimirの専用サーバー（habratestingの時点でParking.ruから提供されたもの）
1. JavaおよびJettyゲームエンジン
2. HAProxy-Webソケットのプロキシ
3. Nginx-静的およびノードへのプロキシ
4. Web機能-Node.js（パッケージ：express、mysql、request、nodemailer、validator、moment、forever）
5.クライアントサイド-javascriptでのGWTブロードキャスト
ゲームエンジンの詳細
さらに-Jedi_Knight （エンジンの作成者）を代表して。
キャンバスでのゲームアプリケーションの開発は、エストニアのプロジェクトmightyfingers.comなど、多くの開発グループが現在移動している有望な分野です。
いくつかのアイデアはwww.html5rocks.com/en/tutorials/canvas/performanceから引用されています
HTML5 Canvasタイピングの基本
用語：タイル-32×32などの小さな正方形。 チャンク-8×8タイル。
タイルエンジンの機能を検討してください。 ここに私が来たモデルがあります：
1）タイルのサブピクセル描画は単に必要ありません。
2）いくつかの透明なキャンバスが使用され、互いの上に配置されます。 地形が変更されていない場合、スクロールは行われず、再描画できません。これにより、パフォーマンスがわずかに向上します（キャッシュの最適化と比較して）。
3）ゲームモデルと同様に、フィールド全体が8×8のチャンクに分割されます。 32×32イメージに対する64回のdrawImage呼び出しは、256×256に対する1回の呼び出しよりもはるかに高価であるため、目に見えるチャンクはキャッシュに描画されます。
4）キャッシュは連想です。つまり、canvas'ovのペアはマップ上のいくつかのチャンクで使用されます。座標（X、Y）のチャンクは、座標（X mod A、Y mod B）のキャッシュを使用します（A、B）はキャッシュサイズです。 同時に、キャッシュサイズは、共通のキャッシュを持つ2つのチャンクが画面に同時に表示されないようにする必要があり、競合が発生します。
5）キャンバスに加えて、論理マップによって生成されるテクスチャのタイルのキャッシュ番号もキャッシュに保存されます。 数字で、タイルを一意に描画できます。
6）可視のチャンクを変更すると、キャッシュ内の対応するオブジェクトがダーティとしてマークされ、再描画が必要になります。 同時に、隣接するチャンクをダーティとしてマークすることもできます。知らない、突然新しいシャドウがそこに落ちる、またはそこに石のスライスを描く必要があります。
7）ダーティチャンクまたは新しいチャンクを再描画する必要がある場合、テーブルはバッファー10×10のテーブル（チャンクと周囲のタイル）に配置されます。 このバッファーからタイル番号の配列が生成されます-既に8×8です。 タイル番号には、このタイルにかかる影に関する情報も含まれる場合があります。 タイル番号が前回から変更された場所では、再描画が発生します。
8）タイルの場合、drawImageではなくcreatePatternとfillRectを使用する方が便利です。 fillRectは、複数の同一の連続タイルを描画できるという点でより便利であり、高速になります。
このテストでは、奇妙な効果が明らかになりました。32×32テクスチャでは、iPadの生産性が2.5倍に大幅に向上します。
jsperf.com/canvas-texture-draw-vs-fill
TheShockによる解説
9）最後に、なぜこれがすべて必要なのか。スクロールすると、小さな32×32イメージのヒープを描画する代わりに、キャッシュからの描画が発生します。 drawImageの呼び出しは大幅に少なくなり、これはパフォーマンスに深刻な影響を及ぼします。
緑、黄色、影-最初のレイヤーに描画されます。タイル番号には素材、壁、影に関する情報が含まれているため、各32×32の正方形は他の正方形とは無関係に描画できます。
2番目のレイヤーは赤で描画され、8ピクセル上にシフトされます。
見つかったバグ
そのため、集合テスト中に、次の問題が発見されました。
1）特定のサイズの大きなマップで、タイルキャッシュが突然シャットダウンしました。これにより、クロムのみが処理できるワイルドブレーキが発生しました。 それはすべて定期的なマップの問題でした。マップのサイズ（W、H）をキャッシュのサイズ（A、B）で割る必要があります。
W、H = 7 A、B = 3、コーナーチャンクが1つのキャッシュ位置に落ち、定期的なマップでは1つの画面に落ち、これがレースにつながります。 同じ状況がカードの「シーム」全体に見られます。
2）クライアントプロファイリングにより、Javaコレクションを使用したコードのボトルネックが明らかになりました。 これらの場所では、コレクションは自己記述構造に置き換えられます。
3）ネットワークプロトコルを変更し、サポートされているブラウザ（Chrome、Firefox）でutf8からバイナリWebソケットに切り替えると、平均クライアントトラフィックを12 Kbpsに減らすことができました。 ネイティブのArrayBufferが使用されます。FirefoxはDataViewクラスを実装しないため、通常のUint8Arrayを回避できます。
記事の冒頭のグラフは以下を示しています。
[1] 接続 -サーバーへのアクティブな接続の数。
[2] メインサイクル時間 - メインサイクルのさまざまな段階にかかる時間。 ティックは100ミリ秒続きます。前処理-クライアントからのコマンドをチェックし、ティック-ゲームの状態を更新します。オブザーバー-クライアントへのメッセージを生成します。 合計-すべてを合わせて、さらにメッセージがネットワークバッファに送られる時間。 1秒以内に費やされるミリ秒単位で測定されるため、Totalが1000に近づくと、サーバーが不良であるため、オーバーヘッドが発生し始めます。
[3] 送信ごとのバイト数 -WebSocketフレームのヘッダーなしでクライアントに送信される純粋なトラフィック（バイト/秒）。
ゲームプレイの変更
エンジン、クライアント、およびネットワークプロトコルの高速化にかかったほとんどすべての時間。 最適化とリファクタリングに関して深刻な作業が行われ、多くのバグが修正されました。
しかし、ゲームプレイでは少し行われました。敵をロックするのが簡単になりました。 しかし、最も重要なことは、ボールとゲートが追加されたことです！ 得点した人にはライフシールドが与えられます。 特にアジャイルは3つのシールドを収集し、スーパーヒーローのように走ります:)
新しい負荷振動テスト。 目標-1つのマップで1000人のプレイヤーがオンライン
サーバーが問題と遅れなしで初めて350人のプレーヤーをオンラインに保ちました。 今日、彼は1000の準備ができています。
6月8日、9日、10日、 17〜22 日に全員を招待して、オンラインの新しいレベルのプレーヤーを獲得しようとしています。 参加して 、友人/同僚に電話してください-私たちはあなたを待っています！
（誰かが利用可能なドメインを持っていない場合は、直接行きます： 141.101.245.117-移動後に誰もがDNSを更新するわけではありません）
特にhabrayuzerについては、エンジンとサーバーの現在の負荷のグラフを表示するHabramonitorを用意しました （5分間隔）。
そして、フォースとファンがあなたを守ってくれますように。