\chapter{Christie Sharpの評価}

前章まではChristie Sharpの実装やUnity上での動作について述べた。
本章では、Unityで使用可能な通信ライブラリであるPhoton Unity Networking2、MirrorとChristie Sharpの比較を行い、
Unityで使用する場合のChristie Sharpの評価を行う。

\section{Christie Sharpと既存ライブラリの比較}

既存の通信ライブラリとしては前述した、Photon Unity Network2とMirrorをChristie Sharpとの比較を行う。
表\ref{tb:Libraryfeature}はChrisite Sharp、PUN2、Mirrorのそれぞれの特徴をまとめたものである。


\begin{table}[htbp]
  \begin{center}
  \caption{各通信ライブラリの特徴}
    \begin{tabular}{|c|c|c|c|} \hline    %hlineで縦線  |c|で要素をくくる
               & node間の通信方法       & Unity APIの対応 & 拡張可能か \\ \hline
Christie Sharp & p2p           　　　　& 未対応         &  可能\\  \hline
PUN2           & Server Client        & 対応           &  一部可能\\ \hline
Mirror         & Server Client        & 対応           &  可能\\  \hline
    \end{tabular}
    \label{tb:Libraryfeature}
  \end{center}
\end{table}


PUN2やMirrorはnode間の通信方法としてクライアントサーバ方式を取っている。
背景には、PUN2はPhoton Cloudを前提にServerへの接続が行われており、MirrorはMMOでの動作を前提に作成されているからである。
一方Christie Sharpは、Topology Managerを利用して各nodeの接続を行っているためServerは無く、p2pでの接続となる。

Unity APIの対応に関しては、PUN2、MirrorがUnity APIで提供されている独自の型を簡単に同期できる機能があるが、
Christie Sharpにはその機能が存在せず、データの同期にはC\#のプリミティブ型に変換して送信する必要がある。

拡張が可能かについては、Christie Sharp、Mirrorはユーザ自身が拡張可能である。
Christie SharpはGitHubにて公開予定であり、MirrorはOSSなため、プロジェクトの状況に応じた機能の追加や変更などが可能となっている。
一方PUN2はUnity上で動作するClient側のソースコードは公開されているが、Server側はPhoton Cloudを使用する必要があるため、拡張性は他の比較対象と比べ低い。


PUN2ではPhoton Cloudがあるが、無料での使用には制限がかかり、制限を超えると別途Serverの料金が発生する。
Mirrorは自前でServerを用意する必要があり、処理の大半はServerで行われるためServerのスペックを考えて開発する必要があある。
Chrisite SharpはUnity APIへの対応が未対応が目立つ一方、p2pで通信を行うため、強力なServerを必要としない。
またp2pの形式を取っているが、Topology ManagerのHostをServerで作動させることで、クライアントサーバ方式に変更することも可能である。


\section{Christie Sharpの利点}
他の通信ライブラリと比較して、Chrisite Sharpを利用する利点として、以下が挙げられる。

\begin{itemize}
  \item 単体でも並列処理が可能
  \item 通信切断した際にゲームロジックが停止しない
\end{itemize}

他の通信ライブラリでは、並列処理の外部ライブラリを導入する際に、ライブラリ同士の相性や処理方法について考える必要がある。
並列処理や非同期処理のDebugは複雑であり、複数のライブラリで問題が起きていた際に特定と解決は困難である。
Chrisite Sharpでは、CodeGear/DataGearを使用した待ち合わせ処理を基本として処理が行われる。
この処理はMulti Threadで行われているため、ユーザは並列処理や非同期処理を必要以上に意識せずにプログラムが可能である。
並列処理のライブラリを導入しなくても済むため、問題の特定は複数のライブラリを組み合わせた場合と比べ容易になる。


node間の通信において、通信の切断は必ず発生する。
通信が切断された際に、ゲームロジックが破綻しゲーム全体が続行不可能になる場合もある。

通常、切断時にゲームロジックが停止しないような例外処理を行う必要があるが、Chrisite Sharpでは常に参照すべき値をPeekで取得することによって、
通信が切断されても参照データは消えずに参照可能である。
また、Topology ManagerにはCookieの機能が備わっているため、改良することによって通信が切断された場合にでもゲームに復帰することが可能になると考える。