Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
河合 宜文 / Kawai Yoshifumi / @neuecc
Cysharp, Inc.
Cygames
C#大統一理論
C#
MagicOnion
MasterMemory
UniTask
https://github.com/Cysharp
SlnMerge
RuntimeUnitTestToolkit
RandomFixtureKit
ConsoleAppFramework
ValueTaskSupplement
https://github.com/Cysharp
LitJWT
Ulid
Difference
UniRx
MessagePack-CSharp
ZeroFormatter
Utf8Json
https://github.com/neuecc
LINQ to GameObject
SerializableDictionary
CloudS...
Unified Realtime/API Engine
https://github.com/Cysharp/MagicOnion
特徴
全てのロジックをC#サーバー上で実行
AI・演算・結果処理など全てサーバー側で処理
Realtime Network
Microser
vices
Realtime
Server
Unity
Native App
Browser
API
Server
P2P
Microser
vices
Realtime
Server
Unity
Native App
Browser
API
Server
P2P
P2P
Dedicated Server
P2P
Dedicated Server
Microser
vices
Realtime
Server
Unity
Native App
Browser
API
Server
⚫ Unity Connected Games
⚫ Photon Engine
⚫ Monobit Engine
⚫ DIY - WebSocket + Server App
⚫ DIY - WebSocket + mBaaS
⚫ DIY - ...
Unity Connected Games
Photon Engine
Monobit Engine
WebSocket + ServerApp
WebSocket(TCP/UDP) + mBaaS(mobile backend as a Service)
TCP(UDP) + ServerApp
TCP(UDP) + Unity HeadlessApp
TCP(UDP) + ServerApp
TCP(UDP) + Unity HeadlessApp
About MagicOnion
C#の型が通信定義となる単方向/双方向RPC
// 自然な書き味で、タイプセーフにRPC(Remote Procedure Call)を実現
// C#のasync/await構文により、非同期通信も自然に見える
var client = Ma...
C#の型が通信定義となる単方向/双方向RPC
// 自然な書き味で、タイプセーフにRPC(Remote Procedure Call)を実現
// C#のasync/await構文により、非同期通信も自然に見える
var client = Ma...
リアルタイム通信のための双方向の型付きRPC
public interface IGamingHub : IStreamingHub<IGamingHub, IGamingHub
{
Task<Player[]> JoinAsync(strin...
il.Emit(OpCodes.Ldloc_0);
il.Emit(OpCodes.Ldloc_0);
il.Emit(OpCodes.Call, typeof(AsyncDuplexStreamingCall<byte[], byte[]>)...
C#で自然にサーバーとクライアントを繋げる
機能として提供するものはシンプルなRPCのみ
あとはアプリケーションの作り込みで何でも作れる
Unityにも依存しないことであらゆる使い方ができる(サーバーtoサーバーなど)
一つのシンプルなやり方で...
エコシステムには全部乗る
未来で償却する
エコシステムには全部乗る
未来で償却する
All in Oneではない
RPCしかない
API Services
Microser
vices
Realtime
Server
Unity
Native App
Browser
API
Server
Microser
vices
Realtime
Server
Unity
Native App
Browser
API
Server
PROS
CONS
中間言語からコード生成する
IDL(JSON/XML/proto/etc...)
サーバーコード
(PHP/Ruby/Go/C#/etc...)
クライアントコード
(C#/Swift/JavaScript/etc...)
PROS
CONS
protoはC#/* 任意の言語 */ではない
C# as a Schema
C#に固定することで
通信定義そのものをC#で表現する
言語の違うREST
Response型を別々
に書く
APIクライアント
を手書きする
(ザ・マイクロ
サービスみたいな
構成)
中間IDLを書く
そこからクライア
ント・レスポンス
型自動生成
(←を嫌う時によ
くある構成、一番
メジャー)
...
認証、課金、クエスト、ミッション、etc...
https://logmi.jp/tech/articles/322333
適切なコードを適切なところに書く
作り込みを現実のものにする
適切なコードを適切なところに書く
作り込みを現実のものにする
MagicOnion is
Unified Realtime/API Engine
Microser
vices
Realtime
Server
Unity
Native App
Browser
API
Server
サーバーとクライアントの距離が限りなく近い
ConsoleAppFramework
https://github.com/Cysharp/ConsoleAppFramework
引数の自動割当
複数コマンドのルーティング
コンフィグ処理
ロギング処理
ライフサイクル管理(Daemon)
...
Realtime
Unity
API
Service
Realtime
Unity
API
Service
Conclusion
時代の変わり目を超える
リアルタイム通信がほぼ必須だったり、5Gが迫っていたり
旧来のフレームワークから変わっていくタイミング
一歩先の理想形へ
クライアントとサーバーを、APIとリアルタイムを
全てをC#で統合するという夢想を具現化するのがM...
Unityによるリアルタイム通信とMagicOnionによるC#大統一理論の実現
Unityによるリアルタイム通信とMagicOnionによるC#大統一理論の実現
Unityによるリアルタイム通信とMagicOnionによるC#大統一理論の実現
Unityによるリアルタイム通信とMagicOnionによるC#大統一理論の実現
Prochain SlideShare
Chargement dans…5
×

Unityによるリアルタイム通信とMagicOnionによるC#大統一理論の実現

6 280 vues

Publié le

Unity道場 京都スペシャル4

Publié dans : Technologie
  • Soyez le premier à commenter

Unityによるリアルタイム通信とMagicOnionによるC#大統一理論の実現

  1. 1. 河合 宜文 / Kawai Yoshifumi / @neuecc Cysharp, Inc. Cygames C#大統一理論 C#
  2. 2. MagicOnion MasterMemory UniTask https://github.com/Cysharp SlnMerge RuntimeUnitTestToolkit RandomFixtureKit
  3. 3. ConsoleAppFramework ValueTaskSupplement https://github.com/Cysharp LitJWT Ulid Difference
  4. 4. UniRx MessagePack-CSharp ZeroFormatter Utf8Json https://github.com/neuecc LINQ to GameObject SerializableDictionary CloudStructures Open on GitHub
  5. 5. Unified Realtime/API Engine https://github.com/Cysharp/MagicOnion 特徴
  6. 6. 全てのロジックをC#サーバー上で実行 AI・演算・結果処理など全てサーバー側で処理
  7. 7. Realtime Network
  8. 8. Microser vices Realtime Server Unity Native App Browser API Server P2P
  9. 9. Microser vices Realtime Server Unity Native App Browser API Server P2P
  10. 10. P2P Dedicated Server
  11. 11. P2P Dedicated Server
  12. 12. Microser vices Realtime Server Unity Native App Browser API Server
  13. 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. 14. Unity Connected Games
  15. 15. Photon Engine Monobit Engine
  16. 16. WebSocket + ServerApp WebSocket(TCP/UDP) + mBaaS(mobile backend as a Service)
  17. 17. TCP(UDP) + ServerApp TCP(UDP) + Unity HeadlessApp
  18. 18. TCP(UDP) + ServerApp TCP(UDP) + Unity HeadlessApp
  19. 19. About MagicOnion
  20. 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. 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. 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. 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. 24. C#で自然にサーバーとクライアントを繋げる 機能として提供するものはシンプルなRPCのみ あとはアプリケーションの作り込みで何でも作れる Unityにも依存しないことであらゆる使い方ができる(サーバーtoサーバーなど) 一つのシンプルなやり方で応用が効く(土管にもなるし土管以外もOK) サーバープログラムを透明にしない どちらにも平等に配置できることを意識したフレームワーク サーバーもクライアントもどちらも大事 適切な場所に適切なコードを書くことで、サーバー/クライアント全体を通し たアーキテクチャの最適化を支援する
  25. 25. エコシステムには全部乗る 未来で償却する
  26. 26. エコシステムには全部乗る 未来で償却する
  27. 27. All in Oneではない RPCしかない
  28. 28. API Services
  29. 29. Microser vices Realtime Server Unity Native App Browser API Server
  30. 30. Microser vices Realtime Server Unity Native App Browser API Server
  31. 31. PROS CONS
  32. 32. 中間言語からコード生成する IDL(JSON/XML/proto/etc...) サーバーコード (PHP/Ruby/Go/C#/etc...) クライアントコード (C#/Swift/JavaScript/etc...)
  33. 33. PROS CONS
  34. 34. protoはC#/* 任意の言語 */ではない
  35. 35. C# as a Schema C#に固定することで 通信定義そのものをC#で表現する
  36. 36. 言語の違うREST Response型を別々 に書く APIクライアント を手書きする (ザ・マイクロ サービスみたいな 構成) 中間IDLを書く そこからクライア ント・レスポンス 型自動生成 (←を嫌う時によ くある構成、一番 メジャー) サービスを普通に 書く、そこからク ライアントを自動 生成、リクエス ト・レスポンス型 はC#のDLLとして 共有 サービスを普通に 書く、クライアン トはそのプロジェ クト参照から実行 時動的生成
  37. 37. 認証、課金、クエスト、ミッション、etc...
  38. 38. https://logmi.jp/tech/articles/322333
  39. 39. 適切なコードを適切なところに書く 作り込みを現実のものにする
  40. 40. 適切なコードを適切なところに書く 作り込みを現実のものにする
  41. 41. MagicOnion is Unified Realtime/API Engine
  42. 42. Microser vices Realtime Server Unity Native App Browser API Server
  43. 43. サーバーとクライアントの距離が限りなく近い
  44. 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. 45. Realtime Unity API Service
  46. 46. Realtime Unity API Service
  47. 47. Conclusion
  48. 48. 時代の変わり目を超える リアルタイム通信がほぼ必須だったり、5Gが迫っていたり 旧来のフレームワークから変わっていくタイミング 一歩先の理想形へ クライアントとサーバーを、APIとリアルタイムを 全てをC#で統合するという夢想を具現化するのがMagicOnion ただの旧来のXXの置き換えなどではなく、 誰も見たことのない究極的な理想の形に近づけていく 銀の弾丸はないので、相応の困難は発生するかもしれないけれど ぜひ一緒に乗り越えていきましょう!→お、コンタクトフォームが https://cysharp.co.jp/contact/

×