heroiclabs / nakama-unity

Unity client for Nakama server.
https://heroiclabs.com/docs/unity-client-guide
Other
407 stars 75 forks source link

Could you please provide original C# code for nakama.DLL? #140

Closed Bruce-Chan closed 1 year ago

Bruce-Chan commented 1 year ago

We implemented a lot of new feature for the server-side code, it is easy to modify the API IDL by regenerating the PB. But on the client side, the response struct is defined in the nakama.DLL. That makes us feel hard to customize it.

For example, we would like to modify the ApiUser struct to support FriendInviteEdgeCount and FriendBlockEdgeCount instead of EdgeCount. Now, we cannot finish it on the client-side.

lugehorsam commented 1 year ago

Hey @Bruce-Chan it's unclear to me exactly what your workflow is, but I am assuming you are talking about adding custom .proto files for your RPC responses. The solution isn't to modify the original C# source code but instead to parse the bytes from the RPC response into your generated custom .proto structs. Does this make sense?

Bruce-Chan commented 1 year ago

Hey @Bruce-Chan it's unclear to me exactly what your workflow is, but I am assuming you are talking about adding custom .proto files for your RPC responses. The solution isn't to modify the original C# source code but instead to parse the bytes from the RPC response into your generated custom .proto structs. Does this make sense?

Thanks for your reply. Actually, We are not only adding custom RPC function, we also want to modify the prebuilt struct and API method from Nakama. Just like my example above. "For example, we would like to modify the ApiUser struct to support FriendInviteEdgeCount and FriendBlockEdgeCount instead of EdgeCount. Now, we cannot finish it on the client-side."

Bruce-Chan commented 1 year ago

image

lugehorsam commented 1 year ago

We definitely don't support extending the Nakama API this way. We'd rather encourage a layering approach on top of the existing APIs as well as using our RPCs.

Bruce-Chan commented 1 year ago

image

Bruce-Chan commented 1 year ago

We definitely don't support extending the Nakama API this way. We'd rather encourage a layering approach on top of the existing APIs as well as using our RPCs.

But if we just use the custom RPC, we need to defined a lot of struct again on the client side, e.g. the User Struct, match struct, Party struct, etc... Extending the Nakama API seems easier for us.

lugehorsam commented 1 year ago

Are you talking about redefining the structs provided by the Nakama SDK in order to parse RPC responses? Why would the former necessitate the latter?

lugehorsam commented 1 year ago

By the way, the original source code is in our .NET library: https://github.com/heroiclabs/nakama-dotnet

Bruce-Chan commented 1 year ago

A lot of work doesn't support with RPC. For example, we feel hard to support mobile phone message auth, because this framework assumes all the users have already login.

Bruce-Chan commented 1 year ago

By the way, the original source code is in our .NET library: https://github.com/heroiclabs/nakama-dotnet

That is exactly what I want! Thanks a lot!!!

lugehorsam commented 1 year ago

It's still pretty unclear to me why you need to take this approach, so be careful, but that's where it lives 😄

lugehorsam commented 1 year ago

Hey @Bruce-Chan could you actually either file an issue on Nakama or reach out to support so we could have a further dialogue about this? We want to further understand what you’re trying to do and potentially integrate some of your needs into Nakama. Otherwise you won’t be able to run on Heroic Cloud or use Nakama Enterprise.