【Unity道場京都スペシャル4】Unityによるリアルタイム通信とMagicOnionによるC#大統一理論の実現

1. 河合宜文 / Kawai Yoshifumi / @neuecc Cysharp, Inc. Cygames C#大統一理論 C#

2. MagicOnion MasterMemory UniTask https://github.com/Cysharp SlnMerge RuntimeUnitTestToolkit RandomFixtureKit

3. ConsoleAppFramework ValueTaskSupplement https://github.com/Cysharp LitJWT Ulid Difference

4. UniRx MessagePack-CSharp ZeroFormatter Utf8Json https://github.com/neuecc LINQ to GameObject SerializableDictionary CloudStructures Open on GitHub

5. Unified Realtime/API Engine https://github.com/Cysharp/MagicOnion 特徴

6. 全てのロジックをC#サーバー上で実行 AI・演算・結果処理など全てサーバー側で処理

7. Realtime Network

8. Microser vices Realtime Server Unity Native App Browser API Server P2P

9. Microser vices Realtime Server Unity Native App Browser API Server P2P

10. P2P Dedicated Server

11. P2P Dedicated Server

12. Microser vices Realtime Server Unity Native App Browser API Server

13. ⚫ Unity Connected Games ⚫ Photon Engine ⚫ Monobit Engine ⚫ DIY - WebSocket + Server App ⚫ DIY - WebSocket + mBaaS ⚫ DIY - TCP(UDP) + Server App ⚫ DIY - TCP(UDP) + Unity Headless

14. Unity Connected Games

15. Photon Engine Monobit Engine

16. WebSocket + ServerApp WebSocket(TCP/UDP) + mBaaS(mobile backend as a Service)

17. TCP(UDP) + ServerApp TCP(UDP) + Unity HeadlessApp

18. TCP(UDP) + ServerApp TCP(UDP) + Unity HeadlessApp

19. About MagicOnion

20. C#の型が通信定義となる単方向/双方向RPC // 自然な書き味で、タイプセーフにRPC(Remote Procedure Call)を実現 // C#のasync/await構文により、非同期通信も自然に見える var client = MagicOnionClient.Create<ITestService>(channel); var result = await client.Sum(100, 200); public class TestService : ITestService { public async UnaryResult<int> Sum(int x, int y) { return x + y; } }

21. C#の型が通信定義となる単方向/双方向RPC // 自然な書き味で、タイプセーフにRPC(Remote Procedure Call)を実現 // C#のasync/await構文により、非同期通信も自然に見える var client = MagicOnionClient.Create<ITestService>(channel); var result = await client.Sum(100, 200); public class TestService : ITestService { public async UnaryResult<int> Sum(int x, int y) { return x + y; } } クライアントもサーバーも自然に繋がっているように見える（デバッガもサーバー/クライアント共有でステップ実行で繋がって動いていく）

22. リアルタイム通信のための双方向の型付きRPC public interface IGamingHub : IStreamingHub<IGamingHub, IGamingHub { Task<Player[]> JoinAsync(string roomName, string userName, Vec Task LeaveAsync(); Task MoveAsync(Vector3 position, Quaternion rotation); } public interface IGamingHubReceiver { void OnJoin(Player player); void OnLeave(Player player); void OnMove(Player player); }

23. il.Emit(OpCodes.Ldloc_0); il.Emit(OpCodes.Ldloc_0); il.Emit(OpCodes.Call, typeof(AsyncDuplexStreamingCall<byte[], byte[]>).GetProperty("RequestStream").GetMethod); il.Emit(OpCodes.Ldarg_0); il.Emit(OpCodes.Ldfld, serializerOptionsField); il.Emit(OpCodes.Newobj, (typeof(MarshallingClientStreamWriter<>).MakeGenericType(def.RequestType).GetConstructors().Singl il.Emit(OpCodes.Ldloc_0); il.Emit(OpCodes.Call, typeof(AsyncDuplexStreamingCall<byte[], byte[]>).GetProperty("ResponseStream").GetMethod); il.Emit(OpCodes.Ldarg_0); il.Emit(OpCodes.Ldfld, serializerOptionsField); il.Emit(OpCodes.Newobj, (typeof(MarshallingAsyncStreamReader<>).MakeGenericType(def.ResponseType).GetConstructors().Singl il.Emit(OpCodes.Ldarg_0); il.Emit(OpCodes.Ldfld, serializerOptionsField); resultType2 = typeof(DuplexStreamingResult<,>).MakeGenericType(def.RequestType, def.ResponseType); il.Emit(OpCodes.Newobj, resultType2.GetConstructors()[0]); MethodType t; string requestType; string responseType; ITypeSymbol unwrappedOriginalResponseType; ExtractRequestResponseType(y, out t, out requestType, ou var id = FNV1A32.GetHashCode(y.Name); return new MethodDefinition { Name = y.Name, MethodType = t, RequestType = requestType, ResponseType = responseType, UnwrappedOriginalResposneTypeSymbol = unwrappedOrigi OriginalResponseTypeSymbol = y.ReturnType, IsIfDebug = y.GetAttributes().FindAttributeShortName HubId = id, Parameters = y.Parameters.Select(p => {

24. C#で自然にサーバーとクライアントを繋げる機能として提供するものはシンプルなRPCのみあとはアプリケーションの作り込みで何でも作れる Unityにも依存しないことであらゆる使い方ができる(サーバーtoサーバーなど) 一つのシンプルなやり方で応用が効く（土管にもなるし土管以外もOK）サーバープログラムを透明にしないどちらにも平等に配置できることを意識したフレームワークサーバーもクライアントもどちらも大事適切な場所に適切なコードを書くことで、サーバー/クライアント全体を通したアーキテクチャの最適化を支援する

25. エコシステムには全部乗る未来で償却する

26. エコシステムには全部乗る未来で償却する

27. All in Oneではない RPCしかない

28. API Services

31. PROS CONS

32. 中間言語からコード生成する IDL(JSON/XML/proto/etc...) サーバーコード (PHP/Ruby/Go/C#/etc...) クライアントコード (C#/Swift/JavaScript/etc...)

33. PROS CONS

34. protoはC#/* 任意の言語 */ではない

35. C# as a Schema C#に固定することで通信定義そのものをC#で表現する

36. 言語の違うREST Response型を別々に書く APIクライアントを手書きする (ザ・マイクロサービスみたいな構成）中間IDLを書くそこからクライアント・レスポンス型自動生成（←を嫌う時によくある構成、一番メジャー）サービスを普通に書く、そこからクライアントを自動生成、リクエスト・レスポンス型はC#のDLLとして共有サービスを普通に書く、クライアントはそのプロジェクト参照から実行時動的生成

37. 認証、課金、クエスト、ミッション、etc...

38. https://logmi.jp/tech/articles/322333

39. 適切なコードを適切なところに書く作り込みを現実のものにする

40. 適切なコードを適切なところに書く作り込みを現実のものにする

41. MagicOnion is Unified Realtime/API Engine

43. サーバーとクライアントの距離が限りなく近い

44. ConsoleAppFramework https://github.com/Cysharp/ConsoleAppFramework 引数の自動割当複数コマンドのルーティングコンフィグ処理ロギング処理ライフサイクル管理(Daemon) などCLIの面倒ごとに対応 class Program : ConsoleAppBas { static async Task Main(string[] args) { await Host.CreateDefaultBuilder() .RunConsoleAppFrameworkAsync<Program>(args); } public void Run(string name, int repeat = 3) { for (int i = 0; i < repeat; i++) { Console.WriteLine($"Hello from {name}"); } } }

45. Realtime Unity API Service

46. Realtime Unity API Service

47. Conclusion

48. 時代の変わり目を超えるリアルタイム通信がほぼ必須だったり、5Gが迫っていたり旧来のフレームワークから変わっていくタイミング一歩先の理想形へクライアントとサーバーを、APIとリアルタイムを全てをC#で統合するという夢想を具現化するのがMagicOnion ただの旧来のXXの置き換えなどではなく、誰も見たことのない究極的な理想の形に近づけていく銀の弾丸はないので、相応の困難は発生するかもしれないけれどぜひ一緒に乗り越えていきましょう！→お、コンタクトフォームが https://cysharp.co.jp/contact/