filmov
tv
Network game basis: Whiteboard drawing system

Показать описание
Previously I had created a simple chat program. In order to support multiple clients, I created a system that modeled a network connection like a pair of queues. You place a byte array on the output queue on one end, and it will eventually appear in the input queue on the other end. This of course required a healthy amount of threads. One for each queue, and one for the client.
This is my first integration of that code with my game engine. It's a little online whiteboard system. The client lets you see the whiteboard buffer and draw on it.
I was able to implement compressed message transfer which I used in the initial buffer transfer. The client doesn't immediately render the drawing strokes, they first echo back off the server and are processed along with strokes from other clients. It serves as a nice lag time test and guarentees that things occur in the same order for all clients (otherwise you might have a case where two clients draw over the same spot with different colors and there will be a race condition that might end with them seeing different things). Speaking of lag, it turns out that it is a really good idea to use buffered streams. I was just using the raw streams you get from sockets, and there was considerable lag when I used my full ip rather than "localhost". When I tried putting them in buffered streams, the lag was significantly reduced.
This program works as a nice practice online game/program. The buffer is the full game state. It all has to be sent when the client first connects, but afterwards the client can work with small state updates in the form of drawn lines and erased lines. I believe I can use similar game state update systems for many future online games.
This is my first integration of that code with my game engine. It's a little online whiteboard system. The client lets you see the whiteboard buffer and draw on it.
I was able to implement compressed message transfer which I used in the initial buffer transfer. The client doesn't immediately render the drawing strokes, they first echo back off the server and are processed along with strokes from other clients. It serves as a nice lag time test and guarentees that things occur in the same order for all clients (otherwise you might have a case where two clients draw over the same spot with different colors and there will be a race condition that might end with them seeing different things). Speaking of lag, it turns out that it is a really good idea to use buffered streams. I was just using the raw streams you get from sockets, and there was considerable lag when I used my full ip rather than "localhost". When I tried putting them in buffered streams, the lag was significantly reduced.
This program works as a nice practice online game/program. The buffer is the full game state. It all has to be sent when the client first connects, but afterwards the client can work with small state updates in the form of drawn lines and erased lines. I believe I can use similar game state update systems for many future online games.