別の.ioゲームを作成する

いわゆる.ioゲームは、ブラウザベースの大規模なマルチプレイヤーアクションゲームであり、多くの人が余暇に苦労しています。 大規模マルチプレイヤー-これは、ゲームが共通の場所でプレイする多数（数百+）のプレイヤーの大規模なマルチプレイヤークラウドであることを意味します。 それはすべてゲームAgar.io （ペトリ皿のセル）から始まったという意見があります。 他の成功例には、 Slither.io （ヘビ）とDiep.io （ tanchiki ）が含まれます。 統計を信じるなら、これらのゲームは毎日何百万人ものプレイヤーによってプレイされています。 今日、さまざまな.ioゲームがあり、そのほとんどはioゲームリストのグーグル検索で見つけることができます。

魚やその他の海洋生物に関するゲームである.io-game Oceanar.ioの作成方法について説明します。また、システム全体の一般的な技術構造に焦点を当て、控えめなヒントを示します。

システムのデバイスは、コードに入らずに、指で最もわかりやすい形式でできるだけ簡単に説明するようにします。

ゲームプレイ

最初に、ゲームの内容を決定する必要がありました。 最も成功した2人の代表であるアガリオとスリサリオのゲームメカニクスを検討した結果、ゲームには次の特性を持たせることが決定されました。

1. 誘導されたキャラクターは、時間の経過とともに徐々に力を獲得しなければならず、この力のセットは視覚的に反映されなければなりません。
2. 非常に長い時間-何時間も続けてプレイするのは理にかなっている必要があります。 5時間負けたプレーヤーは、3時間負けたプレーヤーよりも確実に有利です。
3. ゲームの利点は、ゲームに費やす時間だけに依存するべきではありません。 プレイ時間とゲームスキルの間には適切なバランスが必要です。 数分プレイした人は、数時間プレイしている人を倒すことができるはずです。 それを非常に困難にし、ここで幸運要因を必要としますが、そのような機会があるはずです。
4. 他のプレイヤーの勝利の結果として受け取ったボーナスは、勝者に無条件に授与されるべきではありません-他のプレイヤーはそれらの一部をつかむことができるはずです。
5. 少なくともオリジナルのものがあります:)

ゲームクリーチャーの強度が直接増加するのではなく、これらのクリーチャーの数が増えると、オリジナルになると計算しました。 2番目のアイデアは、弱いクリーチャーのペアを1つの強いクリーチャーに結合する機能です。 したがって、最初はクリーチャーが1つあり、最終的にパックに成長し、パックはより少数のより強力なクリーチャーに戻ります。 最初のレベルのクリーチャーのペアは、2番目のクリーチャーに、2番目のクリーチャーのペア-3番目のクリーチャーに、というように崩壊することができます。 したがって、指数関数的に減速するポンピングを取得し、ほぼ無制限の時間をスイングできます。

芸術的要素を選択することは今でも残っています。 微生物、ウイルス、バクテリア、原生生物、プリオン、海洋生物の群れ-魚、カニ、クラゲの群れから選択しました。 いくつかの考えの後、魚を支持して選択が行われました。 これで芸術的な部分は終了し、技術的な説明に移ります:)

私は本格的なMMOゲームを作成した経験はありませんが、過去のプロジェクトでバンプを蓄積し、さまざまな開発者の経験（ たとえば ）を読んだことで、.ioゲームのクライアントサーバーアーキテクチャは他のものと根本的に異ならないという意見がありましたMMOゲーム-それはほぼ同じアイデアに基づいています。 .ioゲームの重要な（そして単一の開発者にとっては楽しい）違いの1つとして、大幅に簡素化されたゲームルールを選び出します。深刻なMMORPGで、サーバーのゴブリンの頭にxが当たった場合のダメージを計算するには、ルールの束全体をプレイする必要があります。 io-gameは、1行のコードで簡単な式になります。 つまり、.ioゲームは、多数のプレイヤーを持つ同じMMOですが、内部構造を整理するという点でははるかに単純です。 単一のプログラマー（クライアントとサーバーの両方の部分）で作成できるほど単純です。

お客様

ゲームクライアントは、htmlページが開かれたブラウザです。 テクノロジーは、他のほとんどの.ioゲームのテクノロジーと同じです。つまり、プログラミング言語-JavaScript、グラフィックス-WebGL 、ゲームサーバーとのやり取り-WebSocketsを介しています。 そのため、.io-ゲームは発言することが認められていないので（これに関する技術的な可能性はすべて利用可能ですが）、ゲームをサイレントにすることを決定しました（職場のボスからあまり注目されないようにするため）。

簡単に言えば、すべての動きはサーバー上で発生し、クライアントはこの動きのモニタービジュアライザーにすぎません。 クライアントが受動的な視覚化以外にできることは、プレーヤーのアクションをサーバーに送信することだけです（この場合、マウスカーソルの座標とボタンの状態）。 クライアントはこれ以上何もできず、できません。クライアントでゲームロジックを実行しないでください。そうしないと、即座に不正行為の機会になります。 したがって、ソフトウェアの観点から見ると、クライアントは次のようなオブジェクトです。

1. ユーザーアクションをサーバーに送信できます。
2. サーバーからメッセージを受信し、それらをディスパッチすることができます。
3. 視野内にゲームの世界のコピーを保持します。
4. ゲームワールドの保存されたコピーをレンダリングします。

クライアントがメッセージを処理するためのメッセージとアクションの例を次に示します。

位置位置にあり、速度ベクトル速度を持ち、owner_id識別子を持つプレーヤーに属し、creature_type_idタイプの魚である、creature_id識別子を持つ魚を表示します。

JavaScriptの観点からは、次のようなオブジェクトになります。

{ message_type_id: 1, creature_id: 68328, creature_type_id: 2, owner_id: 9306, position: { x: 1.436, y: -39.32 }, velocity: { x: -0.17235, y: -0.1157 } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このようなメッセージを受信すると、クライアントは魚のマップに魚を追加し、ゲームシーンのレンダリングに関しては、画面に魚が表示されます。

id idの魚はid id2の魚を噛みました。

このメッセージを受信すると、クライアントはid id2の魚の座標を取得し、同じ座標のバブルをバブル配列に追加し、血液染色を血液染色配列に追加します。 さらに描画すると、画面に表示されます。

したがって、サーバーからクライアントへのメッセージは、基本的にクライアントの視野で何かが起こったという通知であると言えます。 これを適切かつ理解できるように（グラフィックで）プレーヤーに通知するために、クライアントが知っておくべきこと。 他の種類のメッセージの例-「ゲームがこのようなスコアで終了しました」、「その名前のプレイヤーがゲームに参加しました」、「トップ10プレイヤーのリスト」、「すべてのプレイヤーとその座標のリスト」（マップに表示するため） 、など。

サーバー

サーバーは、ゲーム全体が実行されるアプリケーションです。 サーバーはゲームルームで構成されています。 ゲームルームは、ゲームロケーションのインスタンスです。 この部屋には、ゲームプレイに適した幾何学的な寸法と、そこにいるプレイヤーの数に制限があります。 すべてのゲームルームがいっぱいになると、サーバーは新しいルームを作成し、プレイヤーは徐々に占有ルームと空きルームに均等に分散されます。 ゲームルームは相互に接続されておらず、互いに完全に独立して動作します。 最高レベルでは、サーバーは着信接続を受け入れ、必要に応じて適切なゲームルームを選択し、新しいゲームルームを作成して、選択したルームにプレーヤーを送信できます。

サーバーはC ++で記述されており、サードパーティライブラリのBoostが使用され、ネットワーク部分はBoost.Asioです。 開発とテスト-Visual Studio / Windows、運用サーバー-GCC / Linux。

ゲーム室

これは、すべてのゲームロジックが発生する場所です。 部屋とは、特に次のものを含むオブジェクトです。

1. ゲームオブジェクトのコンテナ（クリーチャー、食物、オブザーバー）を格納します。
2. クライアントからメッセージを受信して​​ディスパッチできる。
3. 部屋で発生したイベントについて顧客に通知することができます。 一部の通知は、これらのイベントがクライアントの視野で発生した場合にのみ送信されます。
4. An状態からAn + 1状態への部屋の遷移の機能を実装します（ゲームワールドの更新）。
5. 定期的にゲームワールドの更新を実行します（この例では、1秒間に10回）。

擬似コード上のファットフリーゲームルームインターフェイス：

 class room { methods: join(user); update(dt); dispatch(protocol::kill_creature); dispatch(protocol::consume_food); dispatch ... dispatch ... dispatch ... properties: container<creature> creatures; container<food> foods; container<observer> observers; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ゲームワールドアップデート

これは、一定時間dt（この場合は0.1秒）にわたって発生したゲームワールドの変更を実装する関数です。この関数をupdateと呼びます。 一般的に、ゲームルームの更新は、ゲームオブジェクトの更新呼び出し、つまり、一般的なものから特定のものへの集約ラダーのさらに下の更新呼び出しです。 簡単な例：魚が位置座標にあり、速度ベクトル速度で移動しているとします。 その更新関数は、dt時間での位置の計算です。

 next_position = position + dt * velocity;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

魚は移動することに加えて、このために他の場所に移動することを決定できます。そして、更新の結果として、座標の更新に加えて、速度ベクトル速度が変化する場合があります。 擬似コードでは、部屋の更新は次のようになります。

 room::update(dt) { message_queue.dispatch(); //  ,  ,    foreach(creature in creatures) { creature.update(dt); } foreach(food in foods) { food.update(dt); } foreach(observer in observers) { observer.update(dt); } spawn_food(); spawn_npc(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

基礎となる更新（たとえば、クリーチャーの更新）の実行の結果として、メッセージが部屋に送信され、次の更新で処理されます。 たとえば、カニが魚を噛み、魚が死んだ。 魚のコンテナから死んだ魚を取り除き、死んだ魚の場所に食べ物を作り、プレイヤーに魚の死と食べ物の出現について通知する必要があります。 これを行うために、更新内のカニは魚を殺したことを示すメッセージを部屋に送信し、このメッセージの送信中に部屋は必要なすべてのアクションを実行します-魚の除去、食べ物の作成、顧客への通知。

プレイスペースを分割する

ゲームのロジックを実装する多くのアルゴリズムでは、このオブジェクトに最も近いオブジェクトを整理できる必要があります。 たとえば、ユーザーに視界内のすべての魚を見せたり、この魚が自分の環境から誰かを噛まないかどうかを確認したりします。 「それぞれとそれぞれ」の原則に従ってオブジェクトのペアを整理する場合、2次の複雑さを得ることになり、CPUでもトラフィックでも、これは必要ありません。

2次の複雑さを取り除くために、次の方法を使用します。スペースはセルに分割され、各セルにはゲームスペースのこのセクションにあるオブジェクトのリストが格納されます。 座標によるセルのリストへのアクセスは、常に複雑です。

これに最も近いオブジェクトのリストに関心がある場合、指定されたオブジェクトが配置されているセルのリストと、隣接するセルのオブジェクトのリストを要求します。 合計9セル。

セルへの分割は、2つの独立した重なり合ったレイヤーで行われます-衝突、咬傷、食事などの近くの相互作用を確認する小さなセルと、視界の問題を解決する大きなセル-プレイヤーの視界にオブジェクトを入れます。

したがって、アルゴリズムの複雑さは2次のままですが、部屋内のゲームオブジェクトの総数は2乗せず、アルゴリズムの視野内の数のみです。

プロトコル

別の問題は、サーバーとクライアントの相互作用のプロトコルです。 プロトコルとは、サーバーとクライアントが交換するメッセージのセットと構造、送信時のシリアライゼーション、受信時のデシリアライゼーションとディスパッチの説明を意味します。 私は、独自の単純化された自転車ソリューションを使用しました-JSONパッケージ記述子からのコードジェネレーター（たまたま起こった）。 自転車ではなく、既製の本格的なソリューションが必要な場合、それはru.wikipedia.org/wiki/Protocol_Buffersであり、これもコードジェネレーターです。

なぜコード生成なのか？

1. 手で書く必要があるコードを最小限に抑えることができます。
2. 速度-コードジェネレーターでは、ルールに制限されず、使用する言語のフレームワーク内で最速のコードを生成できます。
3. 転送されるデータの量-必要に応じてデータを密にパックでき、トラフィックを最小限に抑えることができます（これについては後で説明します）。 コードジェネレーターでは、これらのフィールドのパッキングルールを指定する追加の属性をメッセージフィールドに導入すると特に便利です。

メッセージキュー

ルームメッセージの送信には、複数のプロデューサーと単一のコンシューマキューが使用されます。 顧客にメッセージを送信する-単一の生産者、単一の消費者。 どちらのタイプのラインも自己循環型です。 おそらくBoost.Lockfreeを使用できますが、繰り返しますが、まさにそうなりました。 サーバー内を移動するメッセージをシリアル化およびディスパッチするには、ネットワーク経由でメッセージを送信する場合と同じコード生成メカニズムが使用されます。

システム全体の構造を完全に把握できるように、ゲームの一般的な構造と、私の意見の瞬間に重要な個別に取られたいくつかの構造を説明しようとしました。 私がやったことを願っています

ヒント

.io-gameを作成する場合は、1つだけ言うことができます-それを取り、それを行う！ :)そして、いくつかのささやかなヒントがあります：

ボット

クライアントおよびサーバーと一緒に、すぐにボットを作成します。 さらに、ボットは、クライアントと同じプロトコルを使用してネットワーク経由でサーバーにアクセスし、実際のプレーヤーと同じ情報を「見る」必要があります。 これによりデバッグが大幅に容易になり、戦闘に近い状況で消費されるリソースを評価することもできます。 サーバーは何人のオンラインプレーヤーをプルしますか？ CPUやネットワークの帯域幅が枯渇するのはいつですか？ ボットは、これらの質問やその他の質問に答えるのに役立ち、リリース後の不愉快な驚きからあなたを救います。 さらに、ボットは、ライブプレイヤーがほとんどいない限り、ゲームを退屈にしすぎません。

ネットワークトラフィック

したがって、ネットワークトラフィックを最小限に抑えます。 通常、ホスティングプロバイダーのトラフィックは、カウンターで支払うか、購入オプション付きのプリペイドパッケージ、または無制限ですが、実際にはそれほど無制限ではないという免責条項付きの脚注があります-特定の金額が使用されるのを待っていますたとえば、チャネルの幅を切るなどの形での懲罰的措置、または上から支払う必要があります。 したがって、プロトコルを慎重に検討し、すべてのバイトを節約してください！ 日中にプレイした10,000人のライブプレイヤーがいて、この日中に約200ギガバイトのゲームトラフィックを生成しました。 おそらくこれはそれほど多くないように思えるかもしれませんが、消費されるトラフィックの量が視聴者とともに増加することを忘れないでください。 1つのパケットに数バイトを保存すると、1日に数百メガバイトまたは数ギガバイトのトラフィックを節約できます。

ゲームパックの種類のレイアウトを使用して、トラフィック統計を保持します。 ほとんどの場合、数十種類のゲームパッケージがあるという事実にもかかわらず、トラフィックの大部分はそれらのいくつかに当てはまることに気づくでしょう-それらには特別な注意を払う必要があります。

Https

VKontakteでiframeゲームを含むゲームを作成する場合は、vk.com自体がHTTPSを介して機能するため、HTTPSに強制切り替えする必要があります。その場合、内部のiframeから同じプロトコルが必要になります。 HTTPSで実行されているサイトは、SSL Webソケットでのみ機能します。

技術リスト

.ioゲームを作成するために必要なテクノロジーの完全なリストは次のとおりです。

1. HTML / CSS-ページレイアウト。
2. JavaScript-ゲームのクライアント部分をプログラムします。
3. WebGL / OpenGL ES Shading Language-グラフォンを作成します。
4. WebSocket-ネットワークを作成します。
5. プロトコルバッファ/自転車-クライアントサーバー通信のプロトコルを作成します。
6. ゲームサーバーが記述される言語。 ここでは、Java、Scala、C ++、Rust、Erlang、Haskellなど、選択肢が膨大です。あなたの魂だけが望むものです。
7. ...
8. 利益！

結果

私たちのゲームはまだベータ版ですが、結果を今すぐ見ることができます： oceanar.io （これまでのところ、デスクトップ、モバイル、タブレットのバージョンでのみ動作します）。

ご清聴ありがとうございました。 コメントで私はあなたの質問に答えます。