This is a request for a Unity C# SDK for the Hedera Hashgraph


Is there any support or plans for support for Unity/C# developers to build on the hashgraph? It looks like Satori (which is or may in the near future be built on the Hedera Hashgraph), has a Unity C# SDK, but support for that has been lacking and I’m not even sure it’s using the hashgraph all the way yet. Any help is appreciated. Unity has a thriving community and it has a big push for realtime everything, including realtime film-quality rendering, which would pair well with hashgraph for VR/AR experiences really worth experiencing!


Swirlds.jar (Swirlds platform) will be running specifically in Java (JVM). There are multiple efforts to build interfaces that allow access to the consensus layer from other languages. There are some JNI Bridge projects that may be interesting to watch as soon as the maintainer releases them.

I do know that there is a project called Exo that is exposing the platform as a REST API and you are welcome to stand that up and interface via that API.

I expect that there will be lots of wrappers that will incorporate language-specific SDKs as we move forward.


Thanks for this reply Ken. I’ve also been waiting to implement networking in my Unity game with hopes of using hashgraph at some point. However I didn’t want to run the Swirlds process in the background unless I had to.

So I’m not too familiar with JNI Bridge, but am I to understand that if there was an implementation for Swirlds, then I’d essentially be able to plug into the API without necessarily running swirlds.jar? How likely do you think this is to happen?


If you use a JNI Bridge, you would be running a JVM. Swirlds just needs that to do gossip and calculate consensus. There’s not really a way around that without just separating the Swirlds node from the game.

I’m really interested to see someone run Swirlds underneath their game…basically create a serverless multiplayer game. That would be legit. Swirlds has a pretty light footprint, but it is Java…so there is that exciting piece. It’s not as simple as “install game => run”. It would have to be, “install multiplayer java app => run” then “install game => run”. Definitely do-able. I’m sure you could batch those processes though.


Got it, thanks for the response. I tried a while back to wire up my Unity game with Swirlds. Using Google’s Flatbuffers helped a lot. I got two game instances talking, but I had some trouble at the time with getting C# (via the Unity framework) talking tcp asynchronously with Swirlds. There was a bottleneck in the communication I couldn’t quite figure out. But maybe I can take another crack at it.

Also, at the time, the Swirlds SDK ability to ‘add new users to an existing network’ was not yet implemented as I understood it.

However, agreed I’d love to get it working. Using Unity’s built-in networking gets you up and running quickly, but in my experience it turned into writing some gnarly code. Plus I’d have to pay for a server :slight_smile:


I had some thoughts this last week:

  • you’d probably want to build a socketed interface on top of the Swirlds platform. This would give you the best interface between game and Swirlds app.
  • there would have to be a discovery of shared world players (get their IP address & name)
  • build a “game loader” that runs through the process of building the config file with the player info, starting Swirlds, connecting to the network, then starting the game

It wouldn’t allow mid-game joining, but it would allow serverless gaming. Once adding new nodes is supported you could add that to game.

Anway, just a few thoughts.


Hey awesome, thanks for the suggestions!

Actually I didn’t think about manually building the config file myself, that’s an interesting idea.

Do you think discovery of shared worlds will be incorporated into the platform eventually?

I’m trying to envision how discovery would work in the interim. For instance, how might I get a list of registered players so that I can in turn build the config file? Perhaps I could do the following:

  • Stand up a central game “hub” running on a dedicated server with a database where users can “create” and “join” games.
  • Joining in this context just means associating the player IP address & name with a unique game ID (or shared world).
  • When the player fires up swirlds, it makes a call to the db, getting all IP addresses associated with the player under the same game ID. We now have the list of players to build the config file.

Of course, I always get myself confused when I start talking about server-based solutions in a “serverless” world, but it’s the way my brain tends to go at the moment :slight_smile:


You may even be able to have a way for players to just “share” their IP/Swirld ID in an easily portable way. Imagine sending a Base64 message or something via your Facebook messenger to tell a friend to join. They copy/paste into their client and the game loader parses, generates a new config.txt, reloads the Swirlds app and the game starts.

You could do a discovery mechanism via servers and the benefit would still be there because the majority of the work for game data exchange would be via the Swirlds app, just the small discovery data would be served via the centralized server…that or do discovery on Hedera when the public net goes live ;p


@ken, from your answer I understand that each player needs to have their own instance of Swirlds app in order to take part in the game.

I agree that in this case it would be a complete serverless game. Though, I’m thinking of an architecture where there will be a web-tier between players and the Swirlds layer. And the players would be able to play the game via web-browser. This would avoid having each player downloading, installting, and configuring UnlimitedJCEPolicyJDK8 in order to run Swirlds from their device.

Would that work?


So I finally got off (or on) my lazy rear and started working on this again from scratch. Here’s a pretty crude example of two Unity games using the Swirlds SDK for networked gameplay.

I’ve gotten this far before. There was an issue I encountered previously (which I think still exists in Unity) where I process tcp requests from the Swirlds SDK asynchronously in Unity, however the Unity engine uses a single main thread for things like player movement, etc.

So if I receive an async “Player Move” message from Swirlds, I can’t update the Player on the async thread, it has to be invoked on the main thread. This can be done with a type of “dispatch” mechanism, however it requires the use of a queue for executable actions, which I think can turn into a bottleneck and really slow things down. We’ll see how far I get.