Anixias
Member
I'm pretty able to write a client-server system really easily, and all of my past attempts (over 40 different projects, I'm sure) had client-server networking topologies (is topologies the right word here?).
However, I almost always have weird workarounds to making a direct real-time multiplayer game for various reasons that I know theoretically how to fix, but not practically. Basically, I either don't sync enemies/obstacles and don't make the server authoritative over client positions so that basically each player sees where other players say they are, and don't do any fact checking (this system was used in an obstacle-course multiplayer game I made).
In my game Sona's Tower, my most well-polished and content-filled game thus far (none of my games are online so you won't find it), I used a system where enemies were client-side, and you could just see other players and not interact with them in any way (same in the obstacle-course game, EXCEPT in the obstacle-course game, if a player died, other players could touch them on their screen to revive them within a certain time limit before that player auto-used a limited number of revives).
So basically, my past games usually avoid having to directly sync stuff in real-time multiplayer because of these common issues I faced:
However, I almost always have weird workarounds to making a direct real-time multiplayer game for various reasons that I know theoretically how to fix, but not practically. Basically, I either don't sync enemies/obstacles and don't make the server authoritative over client positions so that basically each player sees where other players say they are, and don't do any fact checking (this system was used in an obstacle-course multiplayer game I made).
In my game Sona's Tower, my most well-polished and content-filled game thus far (none of my games are online so you won't find it), I used a system where enemies were client-side, and you could just see other players and not interact with them in any way (same in the obstacle-course game, EXCEPT in the obstacle-course game, if a player died, other players could touch them on their screen to revive them within a certain time limit before that player auto-used a limited number of revives).
So basically, my past games usually avoid having to directly sync stuff in real-time multiplayer because of these common issues I faced:
- Players who weren't hosting would get jerked around on their screen at any latency because on the server, when receiving player input, I didn't back-track (physics-wise) the amount of latency, apply the input, then reapply the physics, and instead just tacked the input onto current positions, ignoring latency.
Why I didn't fix this: I have no idea how I should properly back-track "x-frames" (where x is almost guaranteed to be a floating-point number) and then apply input, and then reapply physics with multiple frames worth of input. Just... how would I even go about doing that?? - Lag from syncing enemies' positions, targets, states, graphics, stats, etc.
Why I didn't fix this: I don't know the best way to efficiently keep up to 50 objects and their physics and AIs and stats all synced in a fast-paced real-time networking system. - Strange glitches and bugs usually crept into playtesting and I couldn't effectively back-track the source because *.exe GM games have unusual error messages that give no help at all.
Why I didn't fix this: I actually did usually just make my friend host, then connect with the source code project, so I could see errors more directly and get lines of code that they occurred on, but it didn't always help.