Return to Answer

deleted 1 characters in body

Source Link

edited Mar 19, 2011 at 9:27

I'd suggest to keep things apart.

In the Stendhal which is a 2D MORPG written in Java, we did the following things and it works out pretty fine:

The client uses a fast loop for drawing. It does smooth animation and some predictions to minimize lag.
The server uses a loop to process all the game logic. In our case it can be a lot slower than the drawing loop. While the clients make some predictions, the server always wins.

Communication between client and server is done using actions and perceptions:

Actions done by the users like "move up" are sent to the server when they occur. The server queues them up and processes them in its own loop.
Perceptions are sent from the server to the client to update their view of the world.

We did some "tricks" to gain additional performance:

We have two kinds of perception messages: A full one used on login and players joining a zone. And incremental updates used after that. This saves a lot of network bandwidth.
We split perception messages into a public and a private part: All players in the same zone share the same public part so we save processing time because serialisation turned out to be a bottle neck on Java (not JavaScript).

I'd suggest to keep things apart.

In the Stendhal which is a 2D MORPG written Java, we did the following things and it works out pretty fine:

The client uses a fast loop for drawing. It does smooth animation and some predictions to minimize lag.
The server uses a loop to process all the game logic. In our case it can be a lot slower than the drawing loop. While the clients make some predictions, the server always wins.

Communication between client and server is done using actions and perceptions:

Actions done by the users like "move up" are sent to the server when they occur. The server queues them up and processes them in its own loop.
Perceptions are sent from the server to the client to update their view of the world.

We did some "tricks" to gain additional performance:

We have two kinds of perception messages: A full one used on login and players joining a zone. And incremental updates used after that. This saves a lot of network bandwidth.
We split perception messages into a public and a private part: All players in the same zone share the same public part so we save processing time because serialisation turned out to be a bottle neck on Java (not JavaScript).

I'd suggest to keep things apart.

In Stendhal which is a 2D MORPG written in Java, we did the following things and it works out pretty fine:

The client uses a fast loop for drawing. It does smooth animation and some predictions to minimize lag.
The server uses a loop to process all the game logic. In our case it can be a lot slower than the drawing loop. While the clients make some predictions, the server always wins.

Communication between client and server is done using actions and perceptions:

Actions done by the users like "move up" are sent to the server when they occur. The server queues them up and processes them in its own loop.
Perceptions are sent from the server to the client to update their view of the world.

We did some "tricks" to gain additional performance:

We have two kinds of perception messages: A full one used on login and players joining a zone. And incremental updates used after that. This saves a lot of network bandwidth.
We split perception messages into a public and a private part: All players in the same zone share the same public part so we save processing time because serialisation turned out to be a bottle neck on Java (not JavaScript).

Source Link

answered Oct 23, 2010 at 16:15

I'd suggest to keep things apart.

In the Stendhal which is a 2D MORPG written Java, we did the following things and it works out pretty fine:

The client uses a fast loop for drawing. It does smooth animation and some predictions to minimize lag.
The server uses a loop to process all the game logic. In our case it can be a lot slower than the drawing loop. While the clients make some predictions, the server always wins.

Communication between client and server is done using actions and perceptions:

Actions done by the users like "move up" are sent to the server when they occur. The server queues them up and processes them in its own loop.
Perceptions are sent from the server to the client to update their view of the world.

We did some "tricks" to gain additional performance:

We have two kinds of perception messages: A full one used on login and players joining a zone. And incremental updates used after that. This saves a lot of network bandwidth.
We split perception messages into a public and a private part: All players in the same zone share the same public part so we save processing time because serialisation turned out to be a bottle neck on Java (not JavaScript).