Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 03 Jun 2003
Offline Last Active Today, 11:04 AM

Posts I've Made

In Topic: Server difference regarding input

Today, 09:53 AM

Because the data is already old, does it mean that server-side game loop needs to always read/process the packets from the past based on some maximum tick it allows players to be behind?

sYou have three options:

1) Play it as soon as possible on the server. This is simple, but introduces game play artifacts because of jitter. It also will let the simulation on the client diverge from the server, so continual corrections are needed.

2) Rewind the server simulation and apply the command, with some maximum allowed amount of rewind (to avoid too much cheating.) This is the "Source" / "Counter-Strike" model. This reduces lag when players are not interacting, but causes corrections when players interfere with each other.

3) Make the client schedule the event for the future -- the client actually says "play this on step 12" when sending the command. Similarly, the client then also locally delays the command until that time step. This lets you do 100% deterministic lock-step simulation, but introduces a client-side command lag.

In Topic: What is the top factor for MMO engines limiting world size?

Yesterday, 08:28 PM

I would love to see you succeed in that vision, I really do!

In Topic: Server difference regarding input

Yesterday, 04:59 PM

Do you need to mark the packets with step numbers even if you are using TCP..?

In general, yes, you'll want to do that.

If you don't, then you have to delay everybody's game if one client's stream gets delayed.
And TCP stream delays are worse than UDP delays, because even if the next packet makes it, the TCP stack will wait for the re-transmit of the previous packet before giving you any more data.

In Topic: What about Load Balancer

Yesterday, 04:58 PM

it has nicer syntax than erlang (imo).

My opinion is that it has a syntax that is easier to start learning for newcomers from non-functional languages, but it actually adds additional hidden costs and can lead you to write less efficient code without realizing it.

I'd suggest just tackling the Erlang syntax head on.

In Topic: How would you scale single-threaded server?

Yesterday, 10:54 AM

Take a look at how irc networks work.

I agree that it's an interesting systems design example, and looking at how it grew from the first implementation in the 80s is another interesting case study.
But IRC is not a good architecture for games, for the same reason you said: latency is not a goal there.

It's worth looking into how others solved problems, even outside of the games industry

This is also a reasonable statement, but with some caveats. A lot of companies and individuals in other industries have over the years come in, and thought "we're the best in our industry at doing X, and games seem like they do a lot of X, so our solution will totally rule games!"
That seldom ends well. Doesn't matter if it's physical simulation, networking, visualization, stock trading, media serving, or whatever -- the evolutionary pressures in the game industry are very different from the evolutionary pressures in most other industries.