Introducing Cysharp
I’m based in Japan, and the company I founded, Cysharp, is not as well known in besides Japan. However, you may know the OSS I’m making, as several of them have received many stars on GitHub as well.
.NET people will know of my work in high-performance serializers such as MessagePack for C#. It is used by SignalR’s binary protocol, ASP.NET Core Blazor, Visual Studio, etc.
Unity people will know of my work in UniRx — Reactive Extensions for Unity.
Cysharp was founded in 2018 as a subsidiary of Cygames, one of the largest known mobile gaming companies in Japan. Cysharp’s main mission is to develop the C# ecosystem in the gaming industry through OSS.
Unity uses the same language (C#), the same framework (.NET Standard), but with its own ecosystem (Asset Store, Unity Package Manager) and its own AOT runtime (IL2CPP) so, many libraries for .NET Core do not work in Unity.
We focus on both .NET Core and Unity, ensuring that it works with both and the high performance required for the game. We also recommend an architecture where both the server-side and client-side are written in C# through a network framework called MagicOnion.
This twitter moment is a list of games(100 titles) that use Cysharp’s (and my) OSS.
These are just some of the ones I’ve found, and many of them are Japan-only mobile games, but when it comes to games with a worldwide reach, they include KINGDOM HEARTS Melody of Melody SUPER MARIO RUN, Dragaria Lost, etc.
The OSS provided by Cysharp is listed at https://github.com/Cysharp/. Now 16 libraries are available.
MagicOnion
MagicOnion is our flagship network framework. Server (.NET Core) and Client (Unity) are both implemented in C# to share an interface and provide a transparent RPC.
MagicOnion is built on gRPC so fast(HTTP/2) and compact(binary) network transport. However, instead of using Protocol Buffers, MessagePack-CSharp is used for the messages. This makes it possible to share schemas with the C# interface instead of using .proto.
Many popular web real-time frameworks don’t think about Unity (e.g., it would be difficult to run SignalR in Unity). Network frameworks for games are confined to their own environments and are far from modern development.
MagicOnion provides a modern development environment by ASP.NET Core and completely integrated for Unity.
The latest user case is D4DJ Groovy Mix, which uses MagicOnion Unary(for API) and MagicOnion StreamingHub(for Realtime multi-play).
UniTask
Unity generally doesn’t use async/await, the lack of support for the game engine framework, and the performance of the standard Task, which is not suitable for games.
Unity’s Overview of .NET in Unity document says “Avoid using async and await”.
But we all know that the language syntax of async/await is great. And I’ve become aware that the extensibility of C# can provide a fully integrated async/await into Unity, without all the shortcomings of the standard Task.
UniTask provides an efficient allocation-free async/await integration for Unity with its custom AsyncMethodBuilder. This allows you to use async/await without worrying about performance penalties.
It also makes Unity’s AsyncOperations and coroutines awaitable instead of the Unity game engine. It is now possible to replace most unity coroutines.
MasterMemory
MasterMemory is a fast, embedded, read-only database. 4700 times faster than SQLite and achieves zero allocation per query. Also the DB size is small. When SQLite is 3560kb then MasterMemory is only 222kb.
This was originally made for an RPG game. The system is designed to manage and fast reference many items and parameters. You can use it in both Unity and .NET Core, so you can handle shared data without duplicate management.
ZString/ZLogger
Strings are always a performance bottleneck. Similarly, loggers are a regular bottleneck in performance.
ZString eliminates performance issues by providing a zero-allocation string binding utility.
ZLogger is a library for Microsoft.Extensions.Logging that has ZString as its foundation and is tuned for best performance by default (async/buffered). It is ready to use with ASP.NET Core with no configuration required.
ConsoleAppFramework
Many batches are required for the development of a game that uses server. NET Core is also a good environment for creating CLI tools, i.e. batches, but it lacks a high-level framework.
ConsoleAppFramework is built on top of a .NET Generic Host, similar to ASP.NET Core.
This allows a sharing sets of configurations, loggers, etc.
Also, as a framework, it automatically routes Class/Method as a command. This makes it easy to create a lot of batches.
Ulid
The traffic on the game can be many. The games I’ve made in the past have had far more traffic than Stackoverflow, a famously high-traffic system built in .NET.
If a large amount of traffic is to be handled by an RDBMS, the division of the database is essential.
Ulid is an excellent specification for an ID. It combines the randomness of Guid with the sortability of a timestamp.
However, performance depends on the implementation; Cysharp’s performance of Ulid is far superior to that of other C# implementations.
RuntimeUnitTestToolkit
Because Unity’s IL2CPP is AOT, it may not behave the same as the JIT environment. RuntimeUnitTestToolkit is a library for efficient IL2CPP unit testing on CI and real devices.
We guarantee many libraries to work on Unity and to work on IL2CPP, so a library that supports this kind of automation is also essential. And we want to give it all back to everyone as OSS.
There are more. Cysharp/LogicLooper, for example, provides a game loop that allows you to run game logic on the server side. It would be rare to see such a library out to the .NET Ecosystem.
There are also lightweight JWT libraries for authentication, Cysharp/LitJWT.
On the client side (Unity), Unity has yet to unleash the power of C#. We will increase the power of C# in Unity with libraries using advanced C# technologies like UniTask.
We want to increase the presence of C# in server-side game development.
API server written in other languages (PHP, Python, Java, Go, etc…) , to use C# instead of it. Real-time server often be written in C++, or Node.js for light-weight stuff, but I want to be able to replace it with C#.
C# has the potential to make this happen, and it’s worth it. Cysharp’s library is proof of that and should help to make it happen.
