Download as PDF, PPTX
![class Program : BatchBase
{
static async Task Main(string[] args)
{
await BatchHost.CreateDefaultBuilder().RunBatchEngineAsync<Program>(args);
}
public void Generate(
[Option("i", "入力するフォルダ")]string inputDirectory,
[Option("o", "出力するフォルダ")]string outputDirectory)
{
foreach (var inputFilePath in Directory.GetFiles(inputDirectory,
"*.cs", SearchOption.AllDirectories))
{
var tree = CSharpSyntaxTree.ParseText(File.ReadAllText(inputFilePath));
var parseInfo = Parse(tree);
foreach (var item in parseInfo)
{
var template = new KotlinTemplate
{
ClassInfo = item
};
var code = template.TransformText();
var outPath = Path.Combine(outputDirectory, item.ClassName) + ".kt";
File.WriteAllText(outPath, code, Encoding.UTF8); }
CSharpSyntaxTree.ParseTextで.cs
ファイルからSyntaxTreeを取得
テンプレートエンジン(T4)を使って
Kotlinコードを生成
MicroBatchFrameworkによる
CLI定義と実装
ASTを元にテンプレートに当ては
める情報を生成（自前実装）](https://image.slidesharecdn.com/unitycsmagiconion-190904040148/75/Unity-C-NET-Core-MagicOnion-C-Kotlin-22-2048.jpg)
More Related Content
![[CEDEC 2021] 運用中タイトルでも怖くない！ 『メルクストーリア』におけるハイパフォーマンス・ローコストなリアルタイム通信技術の導入事例](https://cdn.slidesharecdn.com/ss_thumbnails/cedec2021-210825103749-thumbnail.jpg?width=640&height=640&fit=bounds)
![[GKE & Spanner 勉強会] GKE 入門](https://cdn.slidesharecdn.com/ss_thumbnails/gke01-200121090059-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Unity C#と.NET Core(MagicOnion) C# そしてKotlinによるハーモニー
Unity C#と.NET Core(MagicOnion) C# そしてKotlinによるハーモニー
- 1. Unity C#と.NET Core(MagicOnion)C# そしてKotlinによるハーモニー 株式会社Cysharp 代表取締役 河合 宜文 2019-09-04 CEDEC 2019
- 2. 講演者プロフィール • 河合 宜文/ Kawai Yoshifumi / @neuecc • Cysharp, Inc. – CEO/CTO • 株式会社Cygamesの子会社としてC#関連の研究開発やコンサ ルティングを行う • メインミッションはC#大統一理論(サーバー/クライアント共にC#で 実装する)の推進 • 株式会社アプリボットの新規タイトル(タイトル未発表)におけ るMagicOnionの導入と周辺の基盤開発を担当
- 5.
- 6. MagicOnion • Unified Realtime/APIEngine for .NET Core and Unity • https://github.com/Cysharp/MagicOnion/ • Cysharp開発のC#によるOSSのネットワークエンジン • リアルタイム系もAPI系も両方OK • HTTP/2 gRPCの上に構築され、高性能とスタンダードを両立 • .NET CoreによるLinuxホスティングと完全なコンテナ対応 • 現在GitHub Starが1000以上と、国内外でも注目度上昇中 • パフォーマンスとC#としての使い勝手にこだわって開発 • C#のエキスパートが最初からUnity C#も前提に組み立てているた め、C#のためのエンジンとして高い品質を誇る
- 7. public class TestService: ITestService { // パブリックメソッドがそのままgRPC定義 public async UnaryResult<int> Sum(int x, int y) { // async/awaitにも自然に対応 // マジカル技術によりasync Task<T>じゃなくてもawait可能 await Task.Yield(); return x + y; } } // 普通のgRPCの接続を作る(MagicOnion用の特別なことはない) var channel = new Channel("127.0.0.1:12345"); // 自然な書き味で、タイプセーフにRPC通信を実現 // C#のasync/await構文により、非同期通信も自然に見える var client = MagicOnionClient.Create<ITestService>(channel); var result = await client.Sum(100, 200); クライアントもサーバーも自 然に繋がっているように見え る（デバッガもサーバー/クラ イアント共有でステップ実行 で繋がって動いていく）
- 9. Why not (plain)gRPC • protoはC#ではない！！！ • 故に言語の持つ • 全ての型(Primitive, Nullable, Dictionaryなど)が使えない • 属性(Attribute, Annotation)付与ができない • リクエスト毎に必ず一つの型が必要になる • 故にIDE(Visual Studio, Rider, etc...)の持つ • シンタックスハイライトが効かない • コードレンズなどのコード追跡機能が効かない • リファクタリング支援（名前一括変更など）が効かない • サーバー/クライアント大統一ならクライアント/サーバー超えて変更 される！
- 10. C#がIDLなら C# as aSchema クライアント/サーバーの実装言語を 共にC#に固定することで、 通信スキーマそのものをC#で表現する プロジェクト参照で済むので IDLのバージョン管理が不要というのも運用上メリット
- 11. しかしいきなりC#は投げ込めない • C#大統一理論 • そんな過激派な意見がいきなり通じるわけがない •良いゲームを作るための開発であってC#を使うための開発 ではない • ↑私はC#を使うための（げふんげふん） • 各社それぞれの都合に合わせた融和のための施策から始める • そしてあわよくば（げふんげふん）
- 12.
- 13.
- 14. 現実解 Microser vices Realtime Server Unity API Server API Serverは各社の得意な言語 (Ruby, PHP,Java, Go, Kotlin, etc…) リアルタイムサーバーはMagicOnion 使うでいいんじゃないか
- 15. Agenda • C#(Unity)と他言語(今回はKotlin)の付き合い方 • C#(Unity)to C#(.NET Core)のコード共有 • MagicOnionによるリアルタイムサーバー実装 • まとめ
- 16.
- 17. C#とKotlinによるロジック共有 • ロジック(計算式など)をKotlinサーバーとUnityで共有したい！ • 例えば戦闘力や経験値算出などをクライアントで計算して表示 •何かを消費するなどして適用する場合、サーバー側でもバリデーショ ンとして計算して適用する • などなど、同じ計算式が必要な場合はままある • 共有方法を考える • 案A. 手書きで両方に作る • 変更耐性が低い！うっかり忘れが発生しても気づかなそう • 案B. 中間定義からKotlin, C#のコードを作る • よくわからないオレオレ中間言語は誰も書きたくない
- 18. C#とKotlinによるロジック共有 • ロジック(計算式など)をKotlinサーバーとUnityで共有したい！ • 例えば戦闘力や経験値算出などをクライアントで計算して表示 •何かを消費するなどして適用する場合、サーバー側でもバリデーショ ンとして計算して適用する • などなど、同じ計算式が必要な場合はままある • 共有方法を考える • 案A. 手書きで両方に作る • 変更耐性が低い！うっかり忘れが発生しても気づかなそう • 案B. 中間定義からKotlin, C#のコードを作る • よくわからないオレオレ中間言語は誰も書きたくない MagicOnionならC#で書いたコードが 全てそのまま無条件でサーバーとク ライアントで共有できてハッピー！
- 19. 案C. C#内部ロジックサービスとの通信 Kubernetes Pod KotlinAPI Server C# Internal Service Unity C# 両方C#なのでコードを共有する
- 20. 案C. C#内部ロジックサービスとの通信 Kubernetes Pod KotlinAPI Server C# Internal Service Unity C# Kubernetesの同一Pod内にサイドカーと して外部と通信するKotlinサーバーと、内 部のみのC#によるサービスを立ち上げ、 gRPC(Unix Domain Socket)で通信して 計算結果を取得
- 21. 案D. C# toKotlinでコード共有(採用) • C#を正としてUnity側中心にロジックを書いてしまい、Kotlin 側はC#からのコードジェネレートで生成する • MicroBatchFramework • https://github.com/Cysharp/MicroBatchFramework • C#(.NET Core)でCLIツール作るのに便利なフレームワーク • Roslyn(Microsoft.CodeAnalysis.CSharp) • C#によるC#コンパイラ • C#のAbstract Syntax Treeが取れる
- 22. class Program :BatchBase { static async Task Main(string[] args) { await BatchHost.CreateDefaultBuilder().RunBatchEngineAsync<Program>(args); } public void Generate( [Option("i", "入力するフォルダ")]string inputDirectory, [Option("o", "出力するフォルダ")]string outputDirectory) { foreach (var inputFilePath in Directory.GetFiles(inputDirectory, "*.cs", SearchOption.AllDirectories)) { var tree = CSharpSyntaxTree.ParseText(File.ReadAllText(inputFilePath)); var parseInfo = Parse(tree); foreach (var item in parseInfo) { var template = new KotlinTemplate { ClassInfo = item }; var code = template.TransformText(); var outPath = Path.Combine(outputDirectory, item.ClassName) + ".kt"; File.WriteAllText(outPath, code, Encoding.UTF8); } CSharpSyntaxTree.ParseTextで.cs ファイルからSyntaxTreeを取得 テンプレートエンジン(T4)を使って Kotlinコードを生成 MicroBatchFrameworkによる CLI定義と実装 ASTを元にテンプレートに当ては める情報を生成（自前実装）
- 23.
- 24. 2019/9/4 Unity C#と.NET CoreC#のコード共有いろは3
- 25.
- 26. vs Unity .csproj •UnityはUnityの管理下のソースコードのみ参照可能 • サーバーのcsprojは柔軟に記述できる • よって共有するコードの実体をUnityのほうに置いて、サー バー側ではコードリンクで参照する <ItemGroup> <Compile Include="..¥Unity¥Assets¥Scripts¥Shared¥**¥*.cs" /> </ItemGroup> シンボリックリンクとか、ビルドしてマ ネージドDLLを配置とかやるとトラブルの 元なので、シンプルな手段が一番 シェアするディレクトリはasmdef で切っておくとより良い
- 27. Unity Shimsの実装 • Unity依存コードの除去 •理想的には完全除去が望ましいが、特に開発中でUnity側主導でコード ができあがっている場合、残ってしまっていることが多い • ダミーの型を用意して回避するのが手っ取り早くは楽 namespace UnityEngine { public class ScriptableObject {} public class MonoBehaviour {} public sealed class SerializeFieldAttribute : Attribute { } // etc... } 意外と問題なく動いたり動かなかったり。 とりあえずコンパイル通す→動かして問題出た とこを何とかする、で工数的にそんな多くかか らず何とかなる、ことも少なくないかな、と。
- 28.
- 29. サーバーロジックを書くということ • MagicOnionはサーバーにロジックを書くためのフレームワーク • データを右から左に流すだけのものではないし、サーバーを「透 明にしない」ことをポリシーにしている •ゲームを面白くするには、クライアントだけが主でもサーバーだ けが主でもない、両方が協調して、乗せるべきコードを乗せるべ き場所に適切に書いていくことが大事 • MagicOnionはそれを最もやりやすくするための選択（の一つ） • C#による統一はサーバー/クライアント間の壁を透明にするための選択
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36. MagicOnion is... • HighPerformance • gRPC(HTTP/2) + MessagePack-CSharp • Modern Architecture • .NET Core, Container, OpenTelemetry • C# Friendly • C# as a Schema • Unity Friendly • Runtime/CodeGen(for IL2CPP)
- 37. 未来を構築する • 新しい時代の新しいフレームワーク • 今やゲームにおいてリアルタイム通信はほぼ必須 •5Gも迫っていてフレームワークも変化しなければいけないタイミング • ならばこそ、より大きな未来を描いていきたい • 完全統合形フレームワークという一つの理想 • クライアントとサーバーを • APIとリアルタイムを • 全てをC#で統合するという夢想を具現化するのがMagicOnion • 理想を理想のままにせず、現実の結果に残すためにCysharpはOSSに よる公開から、開発サポートまで様々なことをしていきます！