C ++で書かれたiOSおよびAndroidのモバイルゲーム「Make words from words」にマルチプレイヤーを固定します

以前、私はAndroidとiOSでモバイルワードゲームを開発した経験について書きました。これは非常に人気があり、2人のプレーヤーが互いに競い合うときにマルチプレーヤーモードを固定し、順番に言葉を書き、Sergey Suponevのテレビ番組の最終ラウンドとして時間。」







マルチプレイヤーの学習と実装に1か月半かかりました。この記事では、ソースコードの例を使わずに概念を説明し、実行した作業量から絞り込みます。

ちょっとした歴史

アプリケーションは、Marmalade SDKを使用してC ++で作成されました。 それ以来、ベンダーはこのプラットフォームのサポートを停止し、その種類を日本に販売し、この開発環境の未来は非常に霧になりました。







現在のプロジェクトをさらにサポートするために移植するものについて疑問が生じました。

なぜcocos2d-xではありませんか

Cocos2d-xは、C ++で最も一般的なクロスプラットフォームモバイルゲーム開発エンジンの1つです。 どうやら、その無料でオープンソースのコードのため。 エンジンの文書化は不十分です。 説明はエンジンのわずかな部分をカバーしており、ほとんどの資料は古くなっています。



ある期間の結果に基づいて、アプリケーションのプロトタイプを作成することができました。 しかし、印象は非常に悪かった：それはcocos2d-xが膝の上に組み立てられているように感じる。 抽象化のレベルScene、Sprite、Application Delegateは私には非常に不快に思われました。 おそらく私の手は間違った場所から成長しています。

私の選択はSDLに落ちました

SDLは 、Marmalade SDLと同様に、エンジンではなく、プラットフォームです。 それは低レベルのAPIを提供し、そこから私にとって便利な抽象化レベルを構築します。 これらはすべてCで記述されており、ソースコードは公開されています。



簡単に言えば、SDLは、グラフィックス、サウンド、およびオペレーティングシステムからのメッセージを処理するための無料のクロスプラットフォームライブラリです。 win32ビルドを作成し、Windowsでゲームのロジックをデバッグすると、モバイルエミュレーターと物理デバイスのみがOS固有の機能をデバッグできるため、非常に便利です。



幸いなことにまたは残念なことに、SDLはiOSやAndroid向けのマルチプレイヤーの開発などの狭いタスク向けのツールを提供していないため、対応するサービスと自分で統合する必要がありました。

マルチスレッドアプリケーションアーキテクチャ

アプリケーションロジックとグラフィックのすべての動作は、メインスレッドで実装されます。メインスレッドは、メッセージ処理サイクルであり、メイン関数で開始されます。 このストリームSDLスレッドを呼び出します。 次に、他のスレッドは、処理するためのイベント（SDL_PushEvent）をキューにスローし、SDL_WaitEventおよびSDL_PollEventを使用してイベントを読み取ります。 これらは、システムによってスローされ、そのサポートがSDLにすでに実装されているシステムイベント、またはSDL機能を超えて既に実装されているコールバックとリスナーの呼び出しのいずれかです。







すべてのゲームロジックはC ++で記述されています。 プロジェクトディレクトリには、* .cppファイルのセットが含まれており、3つのグループに分けることができます。

• クロスプラットフォーム-すべてのプラットフォームのアセンブリに含まれるファイル（ゲームロジック）。
• モノプラットフォーム、すなわち いずれかのプラットフォームのアプリケーションに含まれて、その機能を実装します。

したがって、各プラットフォームの設計には3つの個別のディレクトリがあります。

• proj.win32-プロジェクトVS2017 Community Edition;
• proj.android-Gradleを使用したAndroidプロジェクト。
• proj.ios-iOS用のXcodeプロジェクト。

マルチプレイヤーサービスとの統合

ここで、次のような機能を担当する別のレイヤーを接着する必要があります。

• 対戦相手の検索、ゲームへの接続。
• ライバル間のメッセージング。
• ゲームルームを出る。
• リーダーボードのプレイヤーポイントを修正します。

iOSとAndroidの両方のプラットフォームは、リアルタイムマルチプレイヤー（RTMP）をサポートしています。 Androidの場合、Google Play Services（GPS）、iOSの場合はGame Centerと統合します。 以前は、GoogleはiOSとの統合をサポートしていましたが、今年はそれを放棄することにしました。



この記事では、マルチプレイヤーを構成するためにGoogle PlayコンソールとAppStoreConnectで実行する必要があるアクションについては説明しません。クラスと統合メソッドの仕様については説明しません。これらはすべてベンダーのサイトで説明します。



次に、各プラットフォームのプロジェクトで行う必要がある変更を簡単に説明します。

Android

どうやって？ 私はまだこれを言っていませんか？ Android NDKは 、C ++コードのコンパイルに使用されます。 ただし、Android開発者であれば、すでに知っています。



Google Play ServicesをAndroidプロジェクトに統合するための一般的な手順は、Android開発者向けのサイトで説明されています。 私のプロジェクトでは、次の依存関係を使用します。

implementation 'com.google.android.gms:play-services-games:16.0.0' implementation 'com.google.android.gms:play-services-nearby:16.0.0' implementation 'com.google.android.gms:play-services-auth:16.0.1'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初は、ソースなしでコンパイルされた静的ライブラリの形式で提供されるC ++ APIを使用することでした。 ライブラリのリストにx86_64プラットフォーム用のアセンブリがないという事実のため、GoogleのスタッフはこのSDKの関連性を実際に監視しないと判断し、 JNIラッパーでラップしてこの層をJavaで記述するためにバイクを発明することにしました 。 そして、なぜJavaの内部でJavaをプルするソースコードのないlibsの形で余分な依存関係が必要なのですか？ Javaクラスの関連性に加えて、これらのライブラリの関連性も監視する必要があります。



ガイドとして、 Google Samplesの良い例を使用しました。 googleに感謝します。 アップル、グーグルから例を挙げてください！

iOS

Game Centerと統合するには、GameKitフレームワークを接続する必要があります。 Game Centerとの統合レイヤー全体を1つの* .mファイルで記述し、別の* .hファイルを介してインターフェイスを提供します。 C ++はObjective-C言語のサブセットであるため、1つのプロジェクトでの* .cppおよび* .mファイルのアセンブリに問題はありません。



公式ドキュメントに加えて、彼はこのプロジェクトGameCenterManagerのガイドを受けました。 確かに、この例の一部はすでに古くなっています。Xcode10はこれを示し、古い機能を新しい機能に置き換えます。

マルチプレイヤーレイヤーでの作業の原則

単一のエントリポイント

両方のプラットフォームでマルチプレイヤーを使用する機能を研究した後、アプリケーション用に単一のC ++抽象化を作成し、コンパイル時に、対応する実装が特定のプラットフォームに応じて「適合する」ようにしました。 つまり、私のアプリケーションは、Google Play Services、Game Center、およびそれらの機能については知りません。 提供されるC ++ APIのみを認識します。たとえば、次のようなメソッドがあります。

 SignIn() //     SignOut() //     LeaveRoom() //    SendMessage(...) //    ShowLeaderboards() //    SubmitScore(...) //    ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

相手を探す

プレーヤーは、連絡先のリストから友人を招待するか、ランダムな相手とゲームを開始できます。 招待を受けたプレーヤーは、招待を受け入れるか拒否することができます。 これらのすべてのシナリオでは、使用するサービスの標準インターフェイスを使用します。 Googleの銃口はiOS iOSよりもずっと見栄えが良いことに注意してください。 いつか私の手が届き、ドミノや若い女性とのインターフェースを書くかもしれません。

ゲームルームに接続する

2人のプレイヤーが仮想ゲームルームに接続すると、対応するコールバックを受け取ります。 次に、ホストとなるユーザーを選択する必要があります。

ホスト選択

プレイヤーの中からホストを選択し、ゲームの初期状態を決定する必要があります。

一般的な場合、プレーヤー間でメッセージをルーティングする可能な方法を検討してください。 第２の実施形態では、ホストにはルータの役割も割り当てられていることに留意されたい。







ゲームには常に2人のプレイヤーしかいないため、ピアツーピア接続の特殊なケースがあることがわかりました。 したがって、初期状態の定義のみがホストの役割、つまり、単語を構成する単語の選択に当てはまります。



そのため、プレーヤーがゲームルームに接続した後、各プレーヤーは開始したゲームの参加者の識別子のリストを知っています。 それをParticipantIDのリストと呼びます。 ParticipantIDは、ゲーム参加者の特定の一意の文字列識別子であり、サービスによって割り当てられます。 あなたはそれらのどれがホストになるかを選択し、ホスト自身に持ってきて、相手がホストとして選択されていることを相手に伝える必要があります。 どうやってやるの？

Androidホストの選択

Google Dockでホストを選択する際のアドバイスは見つかりませんでした。 彼らは沈黙している、パルチザン。 しかし、 stackoverflow.comの善良な人々は、次の原則を詳細に説明するビデオへのリンクを投げました。

• 各参加者は、participantIDリストを並べ替えます（昇順または降順-重要ではありません。主なことは、全員が同じ順序で並べることです）。
• 各参加者は、参加者IDをリストの最初の参加者IDと比較します。
• それらが一致する場合、現在のプレイヤーは誰がホストになるかを選択する権利を与えられます。 彼はコインを投げ、ランダム（）を引いて既存の参加者からホストを選択し、ホストであるすべての人に伝えます。

iOSでのホスト選択

iOSには、 chooseBestHostPlayerWithCompletionHandlerメソッドがあります。これは、Androidについて説明したものと比較して、ホスト選択シナリオを大幅に簡素化します。 ただし、このメソッドの呼び出し中の顕著な遅延によって判断すると、ネットワークの応答パラメーターを推定し、pingを測定し、これらの統計に基づいて誰がホストになるかを決定します。 これは、ホストがルーターとして機能する上記のクライアント/サーバーアーキテクチャにより適しています。 プライベートピアツーピア接続の私のバージョンでは、これは意味がありません。時間を節約するために、Androidで行ったのと同様の原則を使用します。

プレイヤー間のメッセージング

メッセージとは何ですか？ メッセージはバイトの配列です。

• Javaでは、これはタイプです：

   byte[]
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

• Objective-Cでは、これは次のとおりです。

   NSData *
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

• C ++では、上記のすべてをマッピングします

   std::vector<Uint8>
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

送信メッセージには2つのタイプがあります。

• 信頼性-キューを介した保証付き配信。 重要なメッセージを配信するために使用されます。
• 信頼できない-保証されていない配送。 配信の成功を無視できる使用済みメッセージ。

Unreliableは一般にReliableよりも速く配信されます。 詳細については、ベンダーのWebサイトをご覧ください。

• Google Play Services：リアルタイムマルチプレイヤー
• Game Centerプログラミングガイド：リアルタイムマッチ

この配列をどのように使用しますか？ 非常にシンプル：

• 最初のバイトに、メッセージのタイプを書き込みます。
• メッセージにパラメータがある場合、次のバイトにそれらを入れます。 追加のメッセージの種類ごとに。 パラメータ、シリアル化および逆シリアル化の機能を実装します。
• メッセージの最後に整合性をチェックするためにチェックサムを入れます。

そのため、ゲーム中にプレイヤーが相互に交換するメッセージのタイプを列挙型で定義します。

• 私はホストに選ばれました。 初期状態を伝えます。 これで私の動き（パラメーター：メッセージングプロトコルのバージョン番号、ソースワード）;
• ホストによって選択されます。 あなたからのお便りを楽しみにしています。
• 私はその言葉を開きます（呼びます）。 今度はあなたの番です（パラメーター：名前付きの単語）;
• あきらめます。 あなたは勝ちました。
• 移動中に一言も言えませんでした。 あなたは勝ちました。
• 私は復venに同意します。
• ゲームを終了しました。
• メッセージの解析エラー。 切断されました。
• メッセージングプロトコルのバージョンが古くなっています。 アプリケーションの更新を確認してください。 切断されました。
• メッセージングプロトコルの私のバージョンが古くなっています。 アップデートを確認する必要があります。 切断されました。
• Ping（システムメッセージ）;

アプリケーションが相手から着信メッセージを受信すると、対応するコールバックが呼び出され、処理のためにメインSDLスレッドにメッセージが渡されます。

接続監視

ゲームサービス（Googleのサービス、Appleのサービス）には、何らかの形で、相手からの切断を通知するように設計されたリスナー機能があります。 しかし、プレーヤーの1人がインターネットから切断されている場合、2番目のプレーヤーは、最初のプレーヤーが切断され、誰もプレイしていないことをすぐには知りません。 このような場合、コールバックは呼び出されないか、かなり長い時間後に呼び出されます。 この場合、2番目のプレイヤーは山でガンが口whiを吹くのを待たないように、接続の監視を独自に行い、原則に基づいて作業する必要がありました。

• 各プレイヤーは1秒ごとに相手にpingメッセージを送信します。
• 各プレイヤーがチェックします：相手から5秒以上メッセージがなかった場合、接続が失われ、ゲームを終了します。

結果

仕事の結果、友人や家族と一緒にプレイするゲームを手に入れました。 iOSとAndroidの両方でプレイしています。



確かに、iOSには微妙な違いがあります-何らかの理由で、リーダーボードでメガネが固定されていません。これについては、現在Appleサポートに対応しています。



この記事が私のチームのメンバーとモバイルアプリケーションの開発に興味のある人の両方に役立つことを願っています。 ご清聴ありがとうございました。