question

I'll lay out what we're doing here. We're a real time CCG, so somewhere between turn based and real time (not many messages going back and forth, 1/s/player or less). All our gameplay logic is on the server; the client is effectively a display terminal (though it does do some prediction, so players don't always have to wait for a server response before seeing the results).

Language: Server is C#, just like our Unity project. This lets us reuse code pieces easily; it also means less switching context during development (we don't share any game code, but we do share the messaging/sockets code, and we have moved code pieces between client and server in the past). Game data is zipped json; player data is human-readable json in PlayFab.

Sockets: We use TCP connections for everything. Adding a reliable UDP connection for gameplay is on our long-term to do list. We're running on a home-grown scalable tcp sockets implementation. There was about 2 weeks of implementation work here getting things working perfectly, making message queues scale, making performance good enough. If I were recommending something now, I'd recommend implementing using WebSockets if you can (or just reliable UDP if you're running on PlayFab's server hosting).

Messages: We're using Protobuf for all client-server messages (and all server-server messages too). Protobuf is awesome, but be careful when using it on iOS/Android, as you have to precompile, and that can make changes a little more tricky (it handles versioning very well, though). I'd still recommend protobuf, but the big thing I've learned is to not make it do everything. For example, our keyword abilities and subtypes each have a lookup dictionary in our data files, so we can add a new one without having to recompile the protobuf.

Servers: There's a lot of startup & memory costs with starting a server executable. For us, loading & parsing all the data and booting up etc is approx 100x more CPU expensive than running a single game, and the memory usage is ~30x more memory for the base data & executable running than what's required for each incremental game. So our server is designed to run multiple games on a single instance. This means it doesn't work nicely with PlayFab's custom servers, so we're hosting ourselves (still on AWS). I could go into a giant post just on hosting and devops for this stuff...

Architecture: We've got edge servers (client connections, client data, PlayFab calls), a single matchmaker server (player list and matchmaking), and game servers (just handle gameplay, no external communication). It's all auto-scaling on AWS. This is a LOT of work to put together; if you don't have our efficiency concerns, and can use PlayFab's server system, I'd highly recommend it. One big advantage - we have persistent client-server connections, so we can cache player data, and that's a huge performance boost over Cloudscript.

Automation: We're not as automated as I'd like, but we're better than I've had on other projects. Logging errors/info to Loggly or similar is vital; having some kind of tool that can review the status of running servers is vital (we have a simple html-based admin page that lets us review what's going on and do some simple actions); having a push-button system for putting up a new server stack is vital*10. We use CloudFormation to automate the AWS stack creation, PowerShell to push server builds and automate startup tasks, and a custom tool to pull game data from Google Sheets and package it up for clients and servers. It's a lot of work to set up, but means we don't make as many mistakes.

Photon: We use Photon for chat, and that's about it. We do overload the chat messages for a few special functions, such as player-to-player challenges (though if I were doing it again, I'd run all that through the server messages)

Thank you both for these extremely detailed posts, I'll spend some time looking through these options (and some others like TNet, uLink? SmartFoxServer?)

Ideally I want to write in C# so that I can reuse existing code.