[onemandevteam]

The 200 users are on a $5 per month server. I'm guessing a better server could support more, but there are scaling challenges if everyone wants to be in the exact same location. In that case, you're sending 200 updates to 200 people each tick which gets slow since it scales O(n^2).

I used 600ms because that's a reasonable rate for walking one square and it's also what is used in the largest similar game Old School Runescape. Even at 600ms ticks, I had to do some tricks to make it feel smoother. For example, I calculate the average latency variation in the client and delay updates so that they fall more closely to exactly 600ms apart. I think 50ms could work if the players are geolocated, otherwise I think that's pushing it. You would need to figure out a very intelligient way to deal with lag at the start.

[Madmallard]

Do you think gafferongames algorithms would be good enough or need like a scheme for basically every game mechanic that would need to be synchronized?

[onemandevteam]

That's above my paygrade I think. All my logic is rule based at the 600ms tick level. If you pick a berry, each tick take one step closer, then do a pick animation, then add the berry to your inventory and remove it from the bush. The client is responsible for tweening between those ticks. It might be a whole different thing to try physics/fine movements etc.