I am trying to make a RTS game in Unity, and I've got a few non-networked features working and so I want to start working on the multiplayer aspect so I don't dig myself into too deep a hole with mechanics I have to recreate to make it online.

I've done a bunch of research into using either a lockstep model (http://www.gamasutra.com/view/feature/131503/1500_archers_on_a_288_network_.php?page=1), or a more typical client-server model where all of the units' positions, velocities, and other traits are synced every fraction of a second.

From what it seems, using the client-server model used to require way too much bandwidth, hence the development of lockstep, but nowadays internet has improved to the point where people actually have enough bandwidth to do this practically. The client-server method seems like it would be easier to implement in Unity also, although UNET seems to be designed for games where the player controls one character, as opposed to the syncing of possibly hundreds of units required in an RTS. The lockstep model would most likely require going somewhat underneath Unity's high level API and implementing a whole slew of time step stabilizers and checks to make sure all the commands are received and executed in the exact same way.

What I'm curious about, however, is something in between the two, where most of the time, I send simple commands to the other clients, saying something like "at xx:xx game time, the player told this unit to move here." The other clients then receive that, and discover that two ticks have passed since that game time, run the two ticks on that object, and then let it continue running in that state until it receives that next update. Every second or so, I could then sync up all of the positions and other data to iron out any inconsistencies. I feel like this could be the best of both worlds in terms of not requiring the insane amount of synchronicity for lockstep but also not requiring as much bandwidth guzzling. I'm probably missing something big or understating the simplicity of implementing such a system, because to me it seems this would be simpler than implementing pure lockstep.

What networking model should I use?


  • 1
    \$\begingroup\$ Whatever else is said: being able to afford an inefficient choice never makes that the right choice! \$\endgroup\$ – inappropriateCode Jul 24 '17 at 16:09
  • 1
    \$\begingroup\$ I'd have to disagree there. The fastest algorithm isn't always the best choice, it depends on whether or not the fast algorithm has serious limitations that the slower algorithm doesn't (and whether or not tech has advanced enough to make the slower algorithm viable). As technology advances, we can make experiences that were impossible before, because newer hardware allows us to trade efficiency for functionality that wouldn't be viable with the faster algorithm. Efficiency is important, yes, but it's not the only consideration \$\endgroup\$ – Bryan Robertson Jul 24 '17 at 18:37
  • \$\begingroup\$ I just decided to (at least for now) go with the client server model, because I'm very new to networking and that is what unity is made for. Thanks for the input \$\endgroup\$ – Superhq 2000 Jul 25 '17 at 15:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.