--- a/Paper/chapter/1-Christie.tex	Thu Feb 10 19:08:25 2022 +0900
+++ b/Paper/chapter/1-Christie.tex	Thu Feb 10 19:47:17 2022 +0900
@@ -12,7 +12,7 @@
 
 
 \section{Christieの基礎概念}
-Chrisiteはタスクとデータを細かい単位に分割してそれぞれの依存関係を記述し、
+Christieはタスクとデータを細かい単位に分割してそれぞれの依存関係を記述し、
 タスク実行に必要な入力が揃った順から並列実行するというプログラミング手法を用いている。
 
 将来的に当研究室で開発しているGearsOS\cite{gears}のファイルシステムに組み込まれる予定があるため、GearsOSを構成する言語 Continuation based C\cite{cbc}と
@@ -141,7 +141,7 @@
 \lstinputlisting[label=src:CGExample, caption=CodeGearの記述例]{src/java/CountUpper.java}
 \lstinputlisting[label=src:CounteObj, caption=DGとして送信されるオブジェクトのクラス]{src/java/CountObject.java}
 
-Chrisiteでは、StartCodeGear(以下StartCG)から処理を開始する。
+Christieでは、StartCodeGear(以下StartCG)から処理を開始する。
 StartCGはStartCodeGear.javaを継承することで記述可能である。
 
 StartCGを記述する際には、createCGMメソッドによりCGMを生成する必要がある(ソースコード\ref{src:StartCGExample} 5行目)。

--- a/Paper/chapter/2-RewriteCS.tex	Thu Feb 10 19:08:25 2022 +0900
+++ b/Paper/chapter/2-RewriteCS.tex	Thu Feb 10 19:47:17 2022 +0900
@@ -130,14 +130,14 @@
 書き換えを行ったとして、ChristieにはJavaとC\#の2種類あることになり、機能の実装などそれぞれに対応する必要がある。
 しかしJavaとC\#それぞれの対応はそこまで難しくないと考える。
 Javaの記法とC\#の記法は非常によく似ており、APIもほとんど同じ機能を持ったものがそれぞれ実装されている。
-そのため、Chrisiteに機能追加をする際にはJavaとC\#両方に対応することでバージョン間のすり合わせを行えると考える。
+そのため、Christieに機能追加をする際にはJavaとC\#両方に対応することでバージョン間のすり合わせを行えると考える。
 
 以上の理由により、ChristieをUnityでサポートされているC\#への書き換えを行う意義を見いだすことができた。
 
 
 \section{Christie Sharpの書き換えの基本方針}
-Javaで記述されたChristieと区別するため、C\#で記述するChristieをChrisite Sharpとする。
-Chrisite Sharpではコードの保守性や、Christie設計時の意図などを守るため、Chrisiteと同じ挙動、同じ動作をする必要がある。
+Javaで記述されたChristieと区別するため、C\#で記述するChristieをChristie Sharpとする。
+Christie Sharpではコードの保守性や、Christie設計時の意図などを守るため、Christieと同じ挙動、同じ動作をする必要がある。
 初めにC\#単体で動作するように、Christieの核となる部分の書き換えを行った。
 
 
@@ -174,7 +174,7 @@
 
 
 \section{TaskによるCodeGearの処理}
-ChrisiteではCGの実行にThreadPoolを利用していた。
+ChristieではCGの実行にThreadPoolを利用していた。
 しかしThreadPoolは管理や生成が煩雑であり、コストパフォーマンスの低下につながりやすい。
 C\#にはThreadをより使いやすく高機能にしたTaskという機能がある。
 TaskはC\#のThreadPoolを拡張しており、内部にThreadPoolと実行待ちQueueを持っている。
@@ -215,7 +215,7 @@
 
 \section{MessagePackの変更}
 Christieではデータを他Nodeに送信する際に、MessagePackを使用してデータをSerializeし、送信を行っている。
-Chrisiteで使用しているMessagePackはmsgpack java 0.6.12\cite{mspack}を使用しており、現在はサポートされていない。
+Christieで使用しているMessagePackはmsgpack java 0.6.12\cite{mspack}を使用しており、現在はサポートされていない。
 そのためJavaでサポート対象となっているmsgpack java 0.7.x以上のMEssagePakckとは記述方法が異なっている。
 ソースコード\ref{src:JavaMspackExample}はChristieで使用してるmsgpack java 0.6.12の使用例である。
 
@@ -241,7 +241,7 @@
 
 \section{送信パケットの修正}
 MessagePackのバージョンを更新した影響により、Remote nodeにデータを送信するパケットの形式を変更する必要がある。
-図\ref{fig:SendPackt}はChristieと、Chrisite Sharpにおける送信パケットの構成である。
+図\ref{fig:SendPackt}はChristieと、Christie Sharpにおける送信パケットの構成である。
 msgpack javaではreadメソッドの引数にClass$<$T$>$を渡すことでデコード可能であり、RemoteMessageのDeserializeにデータ長を指定する必要はない。
 DGはジェネリスクで記述しており毎回デコードするクラスが異なるため、デコードの際にデータ長を必要としている。
 
@@ -259,7 +259,7 @@
 
 
 
-\section{Chrisite SharpのDebug}
+\section{Christie SharpのDebug}
 Christie Sharpの開発にはJetBrainsが開発・提供しているC\#向けのIDE、Rider\cite{rider}を用いている。
 Christie Sharpは並列分散プログラミングを行っているため、MultiThreadでのDebugが必須である。
 RiderにはDebugerの標準的な機能が搭載されているが、Christie Shapを開発する際、MainThread以外で処理をする箇所に対して張ったBreak point
@@ -270,10 +270,10 @@
 
 
 \section{Christie Sharpの記述方法}
-ソースコード\ref{src:CSStartCGExample}、\ref{src:CSCGExample}、\ref{src:CSCountExample}はソースコード\ref{src:StartCGExample}、\ref{src:CGExample}、\ref{src:CounteObj}をChrisite Sharpで書き換えたものである。
+ソースコード\ref{src:CSStartCGExample}、\ref{src:CSCGExample}、\ref{src:CSCountExample}はソースコード\ref{src:StartCGExample}、\ref{src:CGExample}、\ref{src:CounteObj}をChristie Sharpで書き換えたものである。
 JavaとC\#は大きく記述方法は変わらず、annotationがattributeになっている点が一番の違いである。
-そのためChristieとChrisite Sharptには互換性があると言える。
+そのためChristieとChristie Sharptには互換性があると言える。
 
-\lstinputlisting[label=src:CSStartCGExample, caption=Chrisite SharpにおけるStartCodeGearの記述例]{src/cs/StartCountUp.cs}
-\lstinputlisting[label=src:CSCGExample, caption=Chrisite SharpにおけるCodeGearの記述例]{src/cs/CountUpper.cs}
-\lstinputlisting[label=src:CSCountExample, caption=Chrisite SharpにおけるDGとして送信されるオブジェクトのクラス]{src/cs/CountObject.cs}
\ No newline at end of file
+\lstinputlisting[label=src:CSStartCGExample, caption=Christie SharpにおけるStartCodeGearの記述例]{src/cs/StartCountUp.cs}
+\lstinputlisting[label=src:CSCGExample, caption=Christie SharpにおけるCodeGearの記述例]{src/cs/CountUpper.cs}
+\lstinputlisting[label=src:CSCountExample, caption=Christie SharpにおけるDGとして送信されるオブジェクトのクラス]{src/cs/CountObject.cs}
\ No newline at end of file

--- a/Paper/chapter/3-WorkingInUnity.tex	Thu Feb 10 19:08:25 2022 +0900
+++ b/Paper/chapter/3-WorkingInUnity.tex	Thu Feb 10 19:47:17 2022 +0900
@@ -31,12 +31,12 @@
 % やったこと全部書いたほうがいい/できたこと
 % 多重継承の話
 
-Chrisite SharpではStartCGにMainメソッドを記述してChrisite Sharpを実行したが、Unityで動作させるためにはStartメソッドやUpdeteメソッドを使用す必要がある。
-そのため、Chrisite Sharpの実行にStartCGを使用せずに実行できるよう変更を行った。
+Christie SharpではStartCGにMainメソッドを記述してChristie Sharpを実行したが、Unityで動作させるためにはStartメソッドやUpdeteメソッドを使用す必要がある。
+そのため、Christie Sharpの実行にStartCGを使用せずに実行できるよう変更を行った。
 
-\lstinputlisting[label=src:CountUpScript, caption=Unit上でのChrisite Sharpの実行Script]{src/Unity/CountUpScript.cs}
+\lstinputlisting[label=src:CountUpScript, caption=Unit上でのChristie Sharpの実行Script]{src/Unity/CountUpScript.cs}
 
-ソースコード\ref{src:CountUpScript}はソースコード\ref{src:CSStartCGExample}をUnityで動作するように書き換えたものであり、StartCGを使用せずに、Unity APIであるStartメソッドよりChrisite Sharpを実行している。
+ソースコード\ref{src:CountUpScript}はソースコード\ref{src:CSStartCGExample}をUnityで動作するように書き換えたものであり、StartCGを使用せずに、Unity APIであるStartメソッドよりChristie Sharpを実行している。
 StartCGは、CGMの初期化や処理の開始位置を明確化させるためのクラスであるため、Christie Sharpの実行に必須ではない。
 また、C\#では多重継承が禁止されている。そのため、StartCGを継承しつつ、MonoBehaviourを継承してStartメソッドを使用する、と言うことはできない。
 そのため可読性が下がってしまう可能性はあるが、CGMの初期化やSetupメソッドを直接Startメソッド内に記述できる。
@@ -65,11 +65,11 @@
 ソースコード\ref{src:TransformMoveTest}を付与したGameObjectの位置より、常にx軸に+3、z軸に+3離れた位置に他のGameObjectであるotherTransfromが移動をする。
 19行目のLateUpdateメソッドはMonoBehaviourから継承している関数であり、全てのUpdateメソッドが実行された後、次のフレームに移行する直前に実行される関数である。
 
-UnityでChrisite Sharpを使用する際に一つ問題が起きた。
+UnityでChristie Sharpを使用する際に一つ問題が起きた。
 Unity APIでサポートされている関数や型はMain Threadで動作時のみ処理が行われるという仕様がある。
 これはUnityの根本的な考え方であり、Unityでは基本的にシングルスレッドでの動作を想定してる。
 非同期処理を行うための機能として、CoroutineやInvoceなどの機能が提供されており、擬似的にMulti Threadのように処理を行うことが可能である。
-しかしChrisite SharpではCodeGearをTaskで処理させている。
+しかしChristie SharpではCodeGearをTaskで処理させている。
 このためCGに直接Transformを操作しても処理が実行されない。
 
 
@@ -115,14 +115,14 @@
 ソースコード\ref{src:ObjectMoveListener}は何もデータをPutしておらず、LateUpdateメソッドでSetupを行うことでソースコード\ref{src:ObjectMoveServer}から受け取ったデータを基にGameObjectの位置を変更している。
 
 
-以上のテストにより、Chrisite Shrapの機能が問題なくUnity上でも機能することが確認できた。
+以上のテストにより、Christie Shrapの機能が問題なくUnity上でも機能することが確認できた。
 
-\section{UnityでのChrisite Sharpの役割}
+\section{UnityでのChristie Sharpの役割}
 UnityでCodeGearを動作させる場合、特にUnity APIを使用して処理を行う際は、MainThreadDispatcher.Postメソッドを利用してMain Threadに処理を以上する必要がある。
 他方、UnityではUpdateメソッドやFixedUpdateメソッドなどUnityの実装に従って、フレーム単位や時間単位でのメソッド呼び出しが保証されている。
 CG内でMainThreadDispatcher.Postメソッドを使用しGameObjectの移動などのUnity APIを利用した処理を行うことで、処理が行われるタイミングが不安定になることがあると考えられる。
 
-そこで、ネットワーク上で通信が必要なものだけをChrisite Sharpで通信を行い、受信データをMonoBehaviourを継承したクラスで処理・動作させるという方法を考えた。
+そこで、ネットワーク上で通信が必要なものだけをChristie Sharpで通信を行い、受信データをMonoBehaviourを継承したクラスで処理・動作させるという方法を考えた。
 Unityには非同期処理としてCoroutineやTaskなどがあるが、シングルスレッドでの動作を前提として利用されている。
 この手法を取ることにより、Unity上の処理を行うタイミングが保証されると共に、
 並列処理やデータのやり取りをChristieに一任することができ、Multi Threadによる並列処理が可能となる。

--- a/Paper/chapter/4-LibraryComparison.tex	Thu Feb 10 19:08:25 2022 +0900
+++ b/Paper/chapter/4-LibraryComparison.tex	Thu Feb 10 19:47:17 2022 +0900
@@ -7,7 +7,7 @@
 \section{Christie Sharpと既存ライブラリの比較}
 
 既存の通信ライブラリとしては前述した、Photon Unity Network2とMirrorをChristie Sharpとの比較を行う。
-表\ref{tb:Libraryfeature}はChrisite Sharp、PUN2、Mirrorのそれぞれの特徴をまとめたものである。
+表\ref{tb:Libraryfeature}はChristie Sharp、PUN2、Mirrorのそれぞれの特徴をまとめたものである。
 
 
 \begin{table}[htbp]
@@ -38,12 +38,12 @@
 
 PUN2ではPhoton Cloudがあるが、無料での使用には制限がかかり、制限を超えると別途Serverの料金が発生する。
 Mirrorは自前でServerを用意する必要があり、処理の大半はServerで行われるためServerのスペックを考えて開発する必要があある。
-Chrisite SharpはUnity APIへの対応が未対応が目立つ一方、p2pで通信を行うため、強力なServerを必要としない。
+Christie SharpはUnity APIへの対応が未対応が目立つ一方、p2pで通信を行うため、強力なServerを必要としない。
 またp2pの形式を取っているが、Topology ManagerのHostをServerで作動させることで、クライアントサーバ方式に変更することも可能である。
 
 
 \section{Christie Sharpの利点}
-他の通信ライブラリと比較して、Chrisite Sharpを利用する利点として、以下が挙げられる。
+他の通信ライブラリと比較して、Christie Sharpを利用する利点として、以下が挙げられる。
 
 \begin{itemize}
   \item 単体でも並列処理が可能
@@ -52,7 +52,7 @@
 
 他の通信ライブラリでは、並列処理の外部ライブラリを導入する際に、ライブラリ同士の相性や処理方法について考える必要がある。
 並列処理や非同期処理のDebugは複雑であり、複数のライブラリで問題が起きていた際に特定と解決は困難である。
-Chrisite Sharpでは、CodeGear/DataGearを使用した待ち合わせ処理を基本として処理が行われる。
+Christie Sharpでは、CodeGear/DataGearを使用した待ち合わせ処理を基本として処理が行われる。
 この処理はMulti Threadで行われているため、ユーザは並列処理や非同期処理を必要以上に意識せずにプログラムが可能である。
 並列処理のライブラリを導入しなくても済むため、問題の特定は複数のライブラリを組み合わせた場合と比べ容易になる。
 
@@ -60,6 +60,6 @@
 node間の通信において、通信の切断は必ず発生する。
 通信が切断された際に、ゲームロジックが破綻しゲーム全体が続行不可能になる場合もある。
 
-通常、切断時にゲームロジックが停止しないような例外処理を行う必要があるが、Chrisite Sharpでは常に参照すべき値をPeekで取得することによって、
+通常、切断時にゲームロジックが停止しないような例外処理を行う必要があるが、Christie Sharpでは常に参照すべき値をPeekで取得することによって、
 通信が切断されても参照データは消えずに参照可能である。
 また、Topology ManagerにはCookieの機能が備わっているため、改良することによって通信が切断された場合にでもゲームに復帰することが可能になると考える。

Binary file Paper/images/SendPackt.graffle has changed

Binary file Paper/images/SendPackt.pdf has changed

Binary file Paper/master_paper.pdf has changed