C SDK for Photon Realtime

Hello,

I am making a small from the ground up no game engine project in native C17, and I thought about taking the opportunity to delve into Photon's native SDK(already having used the Unity and Unreal plugins) but despite finding bindings for Lua, Python and JavaScript(Which as I understood requires the use of their respective C APIs) I could not find a C SDK or C headers within the C++ (Windows) SDK.

Digging around the threads here I found mentions of a C SDK from around 12 years ago, is there still active development of a C SDK or a C++ to C official wrapper? Or has support for C been dropped?

Best Answer

  • Kaiserludi
    Kaiserludi admin
    edited July 5 Answer ✓

    Hi @Altarya.


    "but despite finding bindings for Lua, Python and JavaScript(Which as I understood requires the use of their respective C APIs) I could not find a C SDK or C headers within the C++ (Windows) SDK."

    We do not provide a Python Client. The Lua and JavaScript clients both do not use any C APIs under the hood and do not have any dependencies on the C++ Client.


    "Digging around the threads here I found mentions of a C SDK from around 12 years ago, is there still active development of a C SDK or a C++ to C official wrapper? Or has support for C been dropped?"

    We did indeed offer a C Client in the past, but discontinued it in 2013 for a lack of customer demand.


    "I also was not able to find a native version of the Server SDK, is the server only provided in C# now?"

    The server consists of a C++ core and a C# application layer on top of it.

    For customizations on the server side you have two options: Either directly enhance and modify the application layer or using the C# plugin API to write custom server plugins. The latter is the recommended way. It is perfectly possible to write most of your custom server side code in C or C++ and to only use C# as a tiny wrapper to communicate with the plugin API.


    "I am making a small from the ground up no game engine project in native C17"

    Is there any particular reason for why you are using pure C and not a mixed C and C++ project?

    Visual Studio does not even offer a C compiler. With GCC and clang it is perfectly possible to compile some code files as C and some as C++ inside the same project and the C++ parts can also absolutely be C-style C++, using only the common subset of C and C++ without any classes or templates.

    This way you could easily use third-party C++ libraries in your project.

Answers

  • I also was not able to find a native version of the Server SDK, is the server only provided in C# now?

  • Meep
    Meep ✭✭✭

    There is a C++ and Objective-C SDK as you say, but they are outdated mostly and lack newer protocols and features of the LoadBalancing application.

    All of the logic for the Photon server and its protocols are on the managed layer. So that is C# only again as you say. I haven't seen any of the engineers talk about changing that. They are busy with Fusion and creating a native Linux port of the server I think.

  • So support for native C has been dropped then and only the C++/objC SDKs exist now?

  • Hi @Meep.

    "There is a C++ and Objective-C SDK as you say, but they are outdated mostly and lack newer protocols and features of the LoadBalancing application."

    What features and protocols are you referring to? The C++ Client API is very up to date. The only major feature of the C# Client that is missing in the C++ Client is serialization protocol 1.8, which isn't currently available in any other client than the C# one, but will soon be added to the C++ Client as well. What else are you missing that is available in Clients for other programming languages?

    The objective C Client API is indeed a bit behind and has only been getting updates very sparsely in the recent past. Customer demand is simply far bigger for the C# and C++ Clients than for any other languages, so we are focusing our resources on those two.

  • Kaiserludi
    Kaiserludi admin
    edited July 5 Answer ✓

    Hi @Altarya.


    "but despite finding bindings for Lua, Python and JavaScript(Which as I understood requires the use of their respective C APIs) I could not find a C SDK or C headers within the C++ (Windows) SDK."

    We do not provide a Python Client. The Lua and JavaScript clients both do not use any C APIs under the hood and do not have any dependencies on the C++ Client.


    "Digging around the threads here I found mentions of a C SDK from around 12 years ago, is there still active development of a C SDK or a C++ to C official wrapper? Or has support for C been dropped?"

    We did indeed offer a C Client in the past, but discontinued it in 2013 for a lack of customer demand.


    "I also was not able to find a native version of the Server SDK, is the server only provided in C# now?"

    The server consists of a C++ core and a C# application layer on top of it.

    For customizations on the server side you have two options: Either directly enhance and modify the application layer or using the C# plugin API to write custom server plugins. The latter is the recommended way. It is perfectly possible to write most of your custom server side code in C or C++ and to only use C# as a tiny wrapper to communicate with the plugin API.


    "I am making a small from the ground up no game engine project in native C17"

    Is there any particular reason for why you are using pure C and not a mixed C and C++ project?

    Visual Studio does not even offer a C compiler. With GCC and clang it is perfectly possible to compile some code files as C and some as C++ inside the same project and the C++ parts can also absolutely be C-style C++, using only the common subset of C and C++ without any classes or templates.

    This way you could easily use third-party C++ libraries in your project.

  • Meep
    Meep ✭✭✭
    edited July 5

    Hello @Kaiserludi, you are right. Outdated wasn't really the word to use there when talking about both SDKs. As for what features the C++ SDK is missing; as you say, there is protocol 1.8 but some RoomFlags are missing implementations too. Like SuppressPlayerInfo but this is a relatively new feature from what I understand since not even the Photon Plugin SDK supports this flag yet. But maybe this is one of the more important things which stick out in my mind.

  • Thanks for the insight!

    Well, there are a few reasons, some features of C17(such as Variable Length Arrays) as well as some general features of C(such as void pointers which are essential for my entity component system) would be the technical reasons for why I stuck with pure C, but for a personal reason its just well I simply know more C than C++ and I generally prefer to write mixed procedural-OOP-DOP code which C lends itself a bit more.


    "Visual Studio does not even offer a C compiler. With GCC and clang it is perfectly possible to compile some code files as C and some as C++ inside the same project and the C++ parts can also absolutely be C-style C++, using only the common subset of C and C++ without any classes or templates."

    I use LLVM-Clang myself just from within Visual Studio Code, with external profilers(Such as Orbit and RenderDoc) when needed. I am aware of that and technically I have done that, albeit its technically an independent thing from the game itself(Its a C++ to C wrapper for the Bullet Physics Engine), its not the end of the world to write one for Photon considering it is already a tool to talk to a server(and generally C++->C wrappers run the C++ program in shared memory and talk to it with internal packet commands) but I was hoping for at least an auto generated one.


    "We did indeed offer a C Client in the past, but discontinued it in 2013 for a lack of customer demand."

    I had a feeling that'd be the case, and perfectly understandable.


    "The server consists of a C++ core and a C# application layer on top of it.

    For customizations on the server side you have two options: Either directly enhance and modify the application layer or using the C# plugin API to write custom server plugins. The latter is the recommended way. It is perfectly possible to write most of your custom server side code in C or C++ and to only use C# as a tiny wrapper to communicate with the plugin API."

    Interesting to talk to a C# VM from native code to then have said VM talk back a different set of native code, its certainly doable. The reason I was looking for a native version was I was hoping I'd be able to have players host their own servers either for the purposes of multiplayer or a local and offline server for when they are playing single player, as to merge client and server code and allow for said player to quickly turn a singleplayer world into a multiplayer world.


    "We do not provide a Python Client. The Lua and JavaScript clients both do not use any C APIs under the hood and do not have any dependencies on the C++ Client."

    I must've misread then, interesting that neither the Lua or JS clients dont use their language's respective C APIs, as far as I got into using Lua myself I was under the impression the C API was the only way to give it functions(save it for LuaJIT's FFI library) then again, I suppose Photon is just a plugin being loaded by another engine which in tern does that translation would that be a correct guess?

  • Hi @Altarya.


    "such as void pointers"

    Those can still be used when you compile the code as C++. The Photon client uses them quite a lot internally as well. The only difference is that, unlike C, C++ requires explicit casts from void pointers to other types of pointers, which can be a nuisance in the beginning, when you have to add lots of those casts to make it possible to compile the existing code as C++.


    "and I generally prefer to write mixed procedural-OOP-DOP code which C lends itself a bit more"

    I have to disagree here. C++ is a lot more suited for this as it works just as well for procedural code (as with very few exceptions it's a superset of C) and DOP as C, but a lot better for OOP.

    C++ does not enforce any OOP: You can absolutely write a whole engine without a single class, if you want to. Just write the code exactly like you would in C except for the few C features that are not supported in C++ like variable length arrays (see https://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B for an overview)


    "I simply know more C than C++"

    That's of course a valid reason against using the full feature set of C++, but I don't see why this would be a reason against writing code in C style and just compiling it as C++ instead of as C.


    "I use LLVM-Clang myself just from within Visual Studio Code"

    Note that Photon only supports the most common commonly used compiler OS combinations, MSVC for Microsoft platforms, clang for Apple platforms and for Android and GCC/G++ for Linux.

    So at least a C wrapper API around it would need to be compiled with MSVC on Windows.

    AFAIK with sticking to pure C compilers and not making your code compile-able in MSVC as well you are making your engine incompatible to Xbox consoles.


    "The reason I was looking for a native version was I was hoping I'd be able to have players host their own servers"

    Photons legal terms do not permit the distribution of the server to player, so you can't do this with Photon anyway, even if there was a native version. I don't see how fully native vs a mix of native and managed code would make a difference here, though as a couple of years ago, distribution was permitted and possible despite the fat that the application layer always has only been available in C#.


    "as far as I got into using Lua myself I was under the impression the C API was the only way to give it functions(save it for LuaJIT's FFI library)"

    I am not a Lua expert, but https://www.lua.org/pil/5.html disagrees.

    You could also just download the Photon Lua Client SDK and have a look at the Lua functions in the .lua files for yourself.

  • "Those can still be used when you compile the code as C++. The Photon client uses them quite a lot internally as well. The only difference is that, unlike C, C++ requires explicit casts from void pointers to other types of pointers, which can be a nuisance in the beginning, when you have to add lots of those casts to make it possible to compile the existing code as C++."

    That I did not know, I was aware that VLAs were not something C++ supported(And I have used them a fair bit, particularly within structs) but I was under the impression it'd be a little more strict with pointers, good to know.


    "I have to disagree here. C++ is a lot more suited for this as it works just as well for procedural code (as with very few exceptions it's a superset of C) and DOP as C, but a lot better for OOP."

    It being better for OOP is undeniable since classes exist naively, but I meant more as a way to mix and match those 3 different styles, which C++ does seem pretty good for regardless or at the very least pretty much on par with C's versatility.


    "Note that Photon only supports the most common commonly used compiler OS combinations, MSVC for Microsoft platforms, clang for Apple platforms and for Android and GCC/G++ for Linux.

    So at least a C wrapper API around it would need to be compiled with MSVC on Windows.

    AFAIK with sticking to pure C compilers and not making your code compile-able in MSVC as well you are making your engine incompatible to Xbox consoles."

    Hooking it up as an external project with CMake set to compile with MSVC is no big deal, I've had to do that with a few other libraries. As for Xbox consoles, at this moment I'm only really interested in targeting desktop windows and linux(and within these OpenGL and Vulkan) beyond those would already be a challenge due to a few other dependencies which may not be as portable to consoles.

    Compiling on C++ mode is something I'll do if it becomes absolutely necessary, but hey in that case using a extern "c" {} might be enough, otherwise I prefer compiling the C++ wrappers separately and adding them as external projects that CMake will update when needed as opposed to compiling them alongside my game's executable. It is possible to link static libraries that were compiled in C++ with C programs after all(If your compiler supports it).


    "Photons legal terms do not permit the distribution of the server to player, so you can't do this with Photon anyway, even if there was a native version. I don't see how fully native vs a mix of native and managed code would make a difference here, though as a couple of years ago, distribution was permitted and possible despite the fat that the application layer always has only been available in C#."

    That's a shame but understandable, I suppose coding my own server software is inevitable at this point. I'd still use Photon for lets say if a player wishes to host a server with greater stability or simply does not wish to host the server on their own machine and it would in tern connect to a Photon server otherwise use my own client-server code.


    "I am not a Lua expert, but https://www.lua.org/pil/5.html disagrees.

    You could also just download the Photon Lua Client SDK and have a look at the Lua functions in the .lua files for yourself."

    That is for creating lua functions from within Lua scripts themselves, I was referring more to the process by which Photon's native functions were ported over to Lua. I did of course download the SDK and look but Photon seems to be contained in a compiled(was not aware Lua could even be precompiled, quite interesting) Lua file.


    At the end of the day, I suppose as is the nature of C projects most of this will have to be handcrafted, which hey it gives me an excuse to finally learn how bare metal networking works.


    Cheers and thanks for the help!

    Altarya

  • Hi @Altarya.


    "but I was under the impression it'd be a little more strict with pointers"

    Well, it IS a little more strict.

    In C you can just write

       int* p = malloc(sizeof(int));
    


    In C++ you need to write

       int* p = (int*)malloc(sizeof(int));
    

    as it won't compile without the cast.

    That's what people are usually referring to, when they say that C++ is more strict.


    "That's a shame but understandable, I suppose coding my own server software is inevitable at this point. I'd still use Photon for lets say if a player wishes to host a server with greater stability or simply does not wish to host the server on their own machine and it would in tern connect to a Photon server otherwise use my own client-server code."

    With Photon you have 2 options: Either you as the developer host your own servers on your own Windows server machines and let your clients connect there, or you let the clients connect to Photon Cloud, if you don't want to deal with hosting.

    The C++ clients also offer the feature of communicating with each other via p2p without the messages going through the server. To use this feature, the clients need to be connected to be connected to a Photon server and inside the same room on that server, though, so you would still need a photon Cloud subscription or host your own Photon servers. However if all clients are on the same LAN, using p2p will obviously bring the latency down to effectively 0, even without a locally hosted Photon server, if that#s what you are after. Each client still needs an internet connection, though.


    "I was referring more to the process by which Photon's native functions were ported over to Lua."

    The Lua Client is a full port with all functionality written in Lua without any dependencies on other clients.

    The C#, the C++ and the JavaScript clients are also full ports with all functionality written in their respective languages.

    The objective C client however is a mix with the Chat and LoadBalancing libs being full ports, while the Common and Photon libs are just wrappers around their C++ equivalents.

  • "The C++ clients also offer the feature of communicating with each other via p2p without the messages going through the server. To use this feature, the clients need to be connected to be connected to a Photon server and inside the same room on that server, though, so you would still need a photon Cloud subscription or host your own Photon servers. However if all clients are on the same LAN, using p2p will obviously bring the latency down to effectively 0, even without a locally hosted Photon server, if that#s what you are after. Each client still needs an internet connection, though."

    While that is a useful feature the always online nature is something I'd rather avoid(Since I intend for singleplayer to also run on the same infrastructure as multiplayer just locally). The way I'm seeing this going in my head is you'd have two multiplayer "modes", similar to lets say an older Paradox Interactive game.

    In those you would have the option to host a game on a Gamespy server or locally in your own machine, the former was simpler and faster but with the drawback of it requiring an internet connection(and of course is not something you can do nowadays since Gamespy no longer exists) while the latter was meant mainly for local lan parties but it could be used for full online games if the host forwarded the right ports.

    What I have in mind right now is a system very similar to this, wherein upon starting a singleplayer or multiplayer local world the client would host their own server(of which I will be coding myself) with sp worlds being disconnected from any network and only allowing the host player to join(aka an integrated server) but with the option to be toggled online whilst ingame at which point other players would be able to join either from LAN or with the host's IP address and mp worlds being as so from the get-go. However if the players don't wish to host the game on one of their machines they would have the option to use Photon where they'd instead connect to the same match on a Photon Cloud server and it would be the one actually handling the game logic which would lead to a better experience overall since the host player wouldn't have to handle any of the game logic and their internet connection would not be used to sync everyone else's. Ideally I'd want to hose the Photon Server myself, but that's for the future if things go well of course.

  • Hi @Altarya.

    The Photon client only needs a connection when you want to talk to other clients.

    For single player just don't connect and run all logic locally outside of Photon.

    Then if at a later point the ongoing single player match should be transformed into a multiplayer match, simply connect at that point in time and transfer the then current state of the game to the server / other clients as a starting point.