Scala + Akka Game Server：ケーススタディ

前回 、ゲームサーバーでのAkkaの使用について概説しました。

次に、単純ではあるがそれでも動作するサーバーの例を分析します。

免責事項

主題に手探りする人は、説明に不正確さと単純化を見つけるかもしれません。 だから、それは考案されました。 私は、それが何であり、どのように使用できるかを知らない人に一般的なポイントを示したかった。 与えられた例は、実稼働の準備ができたコードと見なされるべきではありません。 むしろ、実験の作業用テンプレートとして。



前の記事で、akkaが優れている理由についてはすでに概説しました。

したがって、すぐにサーバーの作成を開始します。

建築

私たちの仕事は、マルチプレイヤーゲームを作成することです。

ソースのgithubには、サーバーとクライアントの両方があります。 ただし、ここではサーバーのみを考慮します。



サーバー自体はいくつかのサービスで構成されます。

各サービスは、メッセージを受信するアクターです。 実際のシステムでは、このアクターは、メッセージを直接処理するアクターのスーパーバイザーになる可能性があります。 つまり サービスのアクター自体は何もしません。



彼はアクターの作業を開始し、必要に応じて再起動するなど、作業を監視します。 私たちの状況は単純化されています。 したがって、俳優はすべての作業を自分で行います。



それでは、最初に私たちが何をするかを描きましょう。



これは私たちの見当違いのクライアントです。 ちなみに、フル3D：







そしてこれがサーバーです：







矢印は、アクター間のメッセージフローを示します。

1. TCPサービス -クライアントの接続を担当するサービス。 TCPを備えたバージョンがあります。

2. セッション -ゲームセッションのアクター。 クライアントとのメッセージングを担当します。

3. タスクサービス -一般的なタスクを実行するためのサービス。

4. 認証サービス -プレーヤーを認証するサービス。

5. GMサービス -ゲームメカニックスサービス。 部屋と一般的なゲームアクティビティの管理を担当します...

6. 部屋 -これらはゲームが行われる部屋として機能する俳優です。

7. ストレージ -データストレージを操作するためのサービス。 SQLデータベースまたは他の何か。



取得したものをより詳細に記述します。

ここではコードの一部のみを提供します。 すべてのコードはgithubに投稿されました。

TCPサービス

Akkaは現在、標準でTCPおよびUDP接続をサポートしています。 また、実験ブランチにはWebSocketがあります。 TCPを使用します。 Akkaのネットワークスタックは、そのルーツをSprayから取っており、たとえばNettyよりも効率的に機能します。 Nettyは、同時により多くの機能を備えています。



したがって、クライアントはTCPサービスに接続します 。 接続アクターが作成され、接続を直接担当します。 接続が確立されたら、 セッションアクターを作成します。このセッションアクターはゲームセッションを担当し、 connectionを介してクライアントとメッセージを交換します。



TCPを使用する場合、いくつかのニュアンスがあります。 TCPは永続的な接続です。 また、システムがクライアントがまだ接続されているかどうかを確認できるとは限りません。



したがって、クライアントを確認するには、いわゆるハートビートを使用します。 サーバーは、接続がまだあるかどうかを理解するために、空のパケットで定期的にクライアントにpingを送信します。

これを行うには、 セッションでShedullerを開始します。この場合、10秒ごとにクライアントにpingを送信します。

scheduler = context.system.scheduler.schedule(10.seconds, 10.seconds, self, Heartbeat)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さらに、クライアントとの接続が確立されるとすぐに、サーバーに認証コマンドを送信します。 アクターSessionが必要です。

セッションは、メッセージをタスクサービスにリダイレクトします。 彼はそれがどんな種類のメッセージであり、それをどうするかを理解するだろう。 次のようになります。

 case class CommandTask(session: ActorRef, comm: PacketMSG)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

はい、説明するのを忘れました。 トランスポートとしてProtobufを使用します。 したがって、 PacketMSGはprotobuffオブジェクトであり、クライアントからのメッセージです。 セッションは、プレーヤーセッションアクターへのリンクです。

タスクサービス

このサービスは、サーバーで実行される一般的なタスクを担当します。 私たちの場合、それはクライアントからのコマンドのメインルーターです。 しかし、これはもちろん、特効薬ではありません。 Akkaのメッセージングシステムは非常に柔軟です。 また、組み込みツールを使用して、非常に巧妙にメッセージルーティングを構成できます。 ただし、単純なものから複雑なものに移行する必要があります。 すぐにすべての可能性をカバーするわけではありません。



一般に、実サーバーのタスクサービスはそれ自体何もしません。 すでにすべての作業を実行する子俳優のみを起動します。 または、独自の子アクターを生成して特定のアクションを実行することもできます。 一般に、すでに多くのオプションがあります。 この場合、 タスクサービスはこれが認証要求であると判断し、指定された認証パラメーターを持つプレーヤーが存在するかどうかを確認するタスクを使用して、 Authサービスにメッセージを送信します。

  def handlePacket(task: CommandTask) = { task.comm.getCmd match { case Cmd.Auth.code => authService ! Authenticate(task.session, task.comm) case Cmd.Join.code => gameService ! JoinGame(task.session) case Cmd.Move.code => gameService ! PlayerMove(task.session, task.comm) case _ => log.info("Crazy message") } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

認証サービス

認証を担当するサービス。 非常に原始的です。 ユーザーのデータベースにのみアクセスできます。

  override def receive = { case task: Authenticate => handleAuth(task) case task: SomePlayer => handleAuthenticated(task) case task: AuthenticatedFailed => handleFailed(task) case _ => log.info("unknown message") }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

彼がAuthenticateを受け取った場合、データベースにアクセスして確認する必要があります。

 case class GetPlayerByName(session: ActorRef, comm: PacketMSG)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

SomePlayerが受信した場合、認証は成功し、この良いニュースを関心のあるすべての人に伝えることができます。 プレイヤーとGM。

  task.session ! Send(Cmd.AuthResp, login.build().toByteArray) gameService ! task
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、AuthenticatedFailedの場合、プレーヤーが見つからなかったため、この悲しいニュースはすべての関係者に報告する必要があります。 この場合、プレーヤーのみ。 ちなみに、実際のサーバーでは、そのような試みを考慮し、永続的に処罰することができます。

 task.session ! Send(Cmd.AuthErr, Array[Byte]())
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際に、誰もそれを完全に台無しにしないで、さまざまな認証オプションを提供します。

保管

Akkaでのデータベースの操作は別のトピックです。 なぜなら 内部では、通常のスレッドで作業が行われます。 アクター用の「長時間にわたる」タスクを多数作成することにより、システム全体を一時停止できます。 アクターは軽量でなければなりません。 通常のリストを「DB」として使用します。 したがって、何も遅くなりません。 しかし、実際のデータベースは長い間フローをブロックします。 したがって、実際のプロジェクトでは、データベースを操作するアクターに個別のスレッドまたはスレッドのプールが割り当てられるため、システム全体の速度が低下することはありません。



プレーヤーが見つかった場合、認証に成功したメッセージがセッションアクターに送信されます。 セッションアクターは既にそれをパックしてクライアントに送信します



さて、ゲームに参加しました。

次に、クライアントは「ゲームを開始してください」というメッセージを送信します。 タスクサービスは GMサービスメッセージをリダイレクトし、ルームを作成してプレーヤーを配置します。



その後、彼はクライアントにゲームの開始を通知します。

ただし、実装は簡単なので、最初のプレーヤーを接続するとすぐに、サーバーは自動的に部屋を作成し、その部屋にプレーヤーを配置します。 したがって、接続されているすべてが同じ部屋になります。

GMサービス

これがゲームのメインサービスです。 彼は、接続されているすべてのプレーヤーについて知っています。 彼は自分が作成した部屋の数を知っており、負荷分散システムの一部として機能できます。 セッションゲームがあるため、ゲームの仕組みはすべて部屋で計算されます。 ルームアクターは彼らのために作成されました。



そして微妙な違いがあります。 ゲームがターンベースの場合。 まあ、チェッカーやカードのように。 つまり、一般に、部屋全体に負荷を分散するために、何もする必要はありません。 利用可能な鉄資源はすべて、Akkaによって均等に処分されます。

私たちのゲームがリアルタイムである場合、最適化を行うことができます。



実際のところ、負荷はわずかですが。 プレイヤーが少ないか、ゲームの仕組みが簡単な場合、スレッドの一般的なプールでのゲームの仕組みの計算が遅くなることはありません。 しかし、負荷が増加するとすぐに、遅延が顕著になります。



次に、これで何ができるかを説明します。



それまでの間、ルームを立ち上げてプレーヤーを追加しました。 ゲームはリアルタイムであるため、ゲームの状態の変化についてプレイヤーに定期的に通知する必要があります。 さて、100msごとに言ってみましょう。 もちろん、この時間はゲームごとに異なります。



リアルタイムゲーム、特に物理シューティングゲームの世界は、決定論的に計算されます。 ステップバイステップ。 このステップでは、ゲームワールドを取得し、その時点で受け取ったプレイヤーのコマンドを適用し、物理学、衝突、ヒット、ゲーム内イベント、NPCなどを計算します。したがって、ゲームの状況の計算が速くなるほど、より多くのフレームサーバーを配る。 そして、ゲームがよりスムーズに進みます。



これを行うために、100msごとに「ティック」を送信するシェダーを開始します。

ゲームの状況を再確認する時が来たことを意味するイベント。

 scheduler = context.system.scheduler.schedule(100.millisecond, 100.millisecond, self, Tick)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

各部屋自体が定期的に「ゲームを再集計する時間です」と言うことがわかります。

再計算結果は、ルーム内の接続されているすべてのプレーヤーに送信されます。

私たちの場合、プレイヤーの動きのみが考慮されます。

  players.keySet.map(p => getPoint(move, p)) players.values.map(s => s ! Send(Cmd.Move, move.build().toByteArray))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際、基本的なことをカバーするシンプルなゲームサーバーを作成しました。 接続、認証、データベースの操作、部屋。



コードを見る経験豊富な読者は次のように言います。

-Semyon Semenych、はい、問題なくシンプルなスレッドで同じことを取得します。



まあ、一般的にはそうです。 メッセージシステムは、数時間で膝の上に書かれます。 Nettyを接続し、次の夜明けに向かって進みます。 各サービスをストリームに割り当て、コレクションを介してメッセージを交換します。

なぜある種の複雑なAkkaを使用するのですか？



しかし、この場合、Akkaは何を提供できますか？..

さて、すべてのコードが非常にシンプルでシングルスレッドであるという事実について。 そして、他のAkkaのアメニティについては、すでに書いています。 繰り返しません。



一般に、単純な実装は実際のアプリケーションの問題の多くを反映していないため、悪いです。 たとえば、1つのスレッドでこのサーバーに書き込むことができます。 そして、当分の間、彼は働きます。



さて、たとえば、仕事でCPUに負荷をかけることができる（そしてほとんどの場合に）部屋です。 通常のバージョンでは、部屋をストリームに分割する必要がある場合、それについて考える必要があります。 この分離のためのコードを考えて記述してください。



今何があるの？



部屋、これは単純なクラス、俳優です。 彼はとてもシンプルです。 すべてのコードは、共通のスレッドプールで実行されます。 一対のプレーヤーによるテストでは、ローカルでは、これはそれほど感じられません。



ただし、ここでは、たとえば50人のプレーヤーでサーバーを既にテストする必要があります。 各部屋をストリームに割り当てることにしました。 これを行うには、このアクターが共有プールではなく別のスレッドを使用することを示す必要があります。 それだけです。同期については考えませんでした。一般的なデータについては考えませんでした。 さらに、Akkaにはすぐに使用できるクラスターがあります。 つまり、ネットワーク上の個々のマシンに部屋を移動することは大きな問題にはなりません。 部屋自体のコードはまったく変更されません。 それは同じ俳優であり、彼だけが別のマシンで作業します。



各アクターにはアドレスがあります。 そして、彼とのすべての仕事は彼を通して行われます。 システム全体は、このアクターがどこで機能するかを気にしません。 共有プール、別のスレッド、別のマシン、または別のマシン。 メッセージの送信先アドレスがあり、その背後にあるものは、設定でストリーム、マシン、またはクラスターをすでに決定しています。 これにより、一方でゲームが突然踏みにじられ、ゲームの仕組みを使ってサーバーを迅速に上げる必要がある場合、便利で高速なスケーラビリティが得られます。 一方、開発の利便性。 1つの開発者のマシンとクラスターの両方でクラスター全体を上げることができます。 これは、設定によってのみ決定されます。



つまり システム内の任意のアクターまたはアクターグループは、一般的なスレッドプール、個別のスレッド、個別のスレッド、または構成を変更するだけで個別のマシンの両方で起動できます。 シンプルなシングルスレッドコードを維持しながら。



ゲームサーバーの場合、これは非常に大きなプラスです。 Akkaは非常に大きな層の仕事を引き受けます。 そして同時に、実際には開発者を制限しません。 実際、適切なディスパッチャ、ルーター、またはメールボックスがなければ、いつでも独自の実装を作成できます。 特定の機会に最適です。



トピックが興味深い場合は、リファクタリングを続行して、コードをより実際の生産に近づけることができます。



サーバーとクライアントを含むすべてのコードはGitHubに投稿されます 。