| I did something similar to what you describe by writing a custom Python server to communicate with a Unity client. Most highly interactive games can't just use TCP, because it has too much overhead and you want different reliability for different kinds of game-data. For instance, if you're sending a constant stream of position updates, you don't need them all to be reliable. E.g. just send the last N frames of updates in each unreliable datagram. That way if one is missed, you can just interpolate / extrapolate. Triggering particle effects or other non-critical eye-candy can also be unreliable. Check out RakNet. It's a really solid C++ networking library optimized for games and similar soft-realtime use cases. Internally, this is what Unity's built-in networking is implemented with. Since I couldn't access Unity's RakNet directly, I wrapped the DLL for access from my own client-side
Unity code. I used custom Python on the back-end. Another option to consider is SmartFox Server. It does things like lobbies, IP block ranges, and sessions management. Chances are you'll end up re-implementing a lot of functionality that they've written already. I was okay with that, because I wanted to learn how. Hope this helps. You should decouple your network polling from the game update loop to avoid headaches later. I.e. don't do it in Update. Also, Update is frame-rate / display-dependent, whereas FixedUpdate is not. |