![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/85/Unity-C-NET-Core-MagicOnion-C-Kotlin-22-320.jpg)
![[CEDEC 2021] 運用中タイトルでも怖くない！ 『メルクストーリア』におけるハイパフォーマンス?ローコストなリアルタイム通信技術の導入事例](https://cdn.slidesharecdn.com/ss_thumbnails/cedec2021-210825103749-thumbnail.jpg?width=560&fit=bounds)
More Related Content
What's hot (20)
Similar to Unity C#と.NET Core(MagicOnion) C# そしてKotlinによるハーモニー (20)
![[OracleCodeTokyo2019] Kubernetesで実現する運用自動化の新しいアプローチとは](https://cdn.slidesharecdn.com/ss_thumbnails/oraclecodetokyo19b-2-2k8soperatorkshigeruv1-190522024836-thumbnail.jpg?width=560&fit=bounds)
![[Cloud OnAir] 開発ツールと踏み出す Kubernetes への第一歩 2019年9月19日 放送](https://cdn.slidesharecdn.com/ss_thumbnails/0919-190919090717-thumbnail.jpg?width=560&fit=bounds)
More from Yoshifumi Kawai (20)
Recently uploaded (10)
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の導入と周辺の基盤開発を担当
- 6. MagicOnion ? Unified Realtime/API Engine 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 a Schema クライアント/サーバーの実装言語を 共にC#に固定することで、 通信スキーマそのものをC#で表現する プロジェクト参照で済むので IDLのバージョン管理が不要というのも運用上メリット
- 11. しかしいきなりC#は投げ込めない ? C#大統一理論 ? そんな過激派な意見がいきなり通じるわけがない ? 良いゲームを作るための開発であってC#を使うための開発 ではない ? ↑私はC#を使うための（げふんげふん） ? 各社それぞれの都合に合わせた融和のための施策から始める ? そしてあわよくば（げふんげふん）
- 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によるリアルタイムサーバー実装 ? まとめ
- 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 Kotlin API Server C# Internal Service Unity C# 両方C#なのでコードを共有する
- 20. 案C. C#内部ロジックサービスとの通信 Kubernetes Pod Kotlin API Server C# Internal Service Unity C# Kubernetesの同一Pod内にサイドカーと して外部と通信するKotlinサーバーと、内 部のみのC#によるサービスを立ち上げ、 gRPC(Unix Domain Socket)で通信して 計算結果を取得
- 21. 案D. C# to Kotlinでコード共有(採用) ? 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を元にテンプレートに当ては める情報を生成（自前実装）
- 24. 2019/9/4 Unity C#と.NET Core 颁#のコード共有いろは3
- 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... } 意外と問題なく動いたり動かなかったり。 とりあえずコンパイル通す→動かして問題出た とこを何とかする、で工数的にそんな多くかか らず何とかなる、ことも少なくないかな、と。
- 29. サーバーロジックを書くということ ? MagicOnionはサーバーにロジックを書くためのフレームワーク ? データを右から左に流すだけのものではないし、サーバーを「透 明にしない」ことをポリシーにしている ? ゲームを面白くするには、クライアントだけが主でもサーバーだ けが主でもない、両方が協調して、乗せるべきコードを乗せるべ き場所に適切に書いていくことが大事 ? MagicOnionはそれを最もやりやすくするための選択（の一つ） ? C#による統一はサーバー/クライアント間の壁を透明にするための選択
- 35. 2019/9/4 まとめ5
- 36. MagicOnion is... ? High Performance ? 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に よる公開から、開発サポートまで様々なことをしていきます！