network game design question
Is the following a good approach, I have a single threaded game (bomberman like) which should run at say 20 ms (50 fps).
Every client is associated with (at least) one player.
The client sends the players input (one byte: 4 directions, 2 buttons, enter key, and maybe one bit to leave the game) to the server and waits for the servers Update object (this contains the update on moves of other players and is probably allways under 32 bytes and around 12 bytes on average). All the client really needs to do is collect input, draw stuff and then sleep a bit (and this continuously). There is no real game logic at the client side.
There is one server: this continuously waits for all players input byte, then the logic is updated and the update object broadcasted. The disadvantage with this is probably that the game will run as fast as the slowest client, therefor I probably need to set a time out on reading a byte from a client and presuming a no movement byte when it doesn't come in time (and a time out of say 15 seconds should just remove the client players from the game).
Any stupid things I said (very likely) or suggestions ?
jpwinne
[1184 byte] By [
jpw35a] at [2007-9-28 9:58:32]
Sounds good to me.What happens if a client sends more than one move within a given timeslice?
JN_a at 2007-7-11 23:31:57 >
Presuming a no-movement byte may or may not be what you really want, depends whether "no movement" means leaving the 'joystick' in the center, or not moving it from where it already is.
e.g. if you were playing a racing game, that required e.g. A to be held down most of the time, you wouldn't want to assume the player had let go of the button if their packets lagged on the way in.
To save network bandwidth also, it could help to *only* transmit when there is a change, so when the user is holding a but not moving the joystick, nothing has to go to the server, and you save both ends some money.
The idea of a 'dumb' terminal game is a quite workable one, I had one going myself, but I had to stop it due to the immense time being consumed by graphic design (and of course, nobody would step forward to do the drawings.)
> Presuming a no-movement byte may or may not be what
> you really want, depends whether "no movement" means
> leaving the 'joystick' in the center, or not moving it
> from where it already is.
I think it is what I need, because than the man just stays put, one can argue if the bomberman should just keep going into his current direction (this may put him towards a save place or danger, who's to tell).
> e.g. if you were playing a racing game, that required
> e.g. A to be held down most of the time, you wouldn't
> want to assume the player had let go of the button if
> their packets lagged on the way in.
Presuming that the bomb key is down is not needed too, I guess.
> To save network bandwidth also, it could help to
> *only* transmit when there is a change, so when the
> user is holding a but not moving the joystick, nothing
> has to go to the server, and you save both ends some
> money.
If I presume a no movement byte (central joystick, nothing pressed),
I cannot use this strategy: the missing input byte indicates either it got lost, or that the previous input byte has to be used. I will have to experiment with this to see what is best.
> The idea of a 'dumb' terminal game is a quite workable
> one, I had one going myself, but I had to stop it due
> to the immense time being consumed by graphic design
> (and of course, nobody would step forward to do the
> drawings.)
That's not a real problem, there are plenty of bomberman games out there to rip of images. And I am not focussing on graphics, but rather on fast gameplay. Too many bomberman games look nice (Atomic Bomberman, Bomberfun) but play like ****.
jpwinne
jpw35a at 2007-7-11 23:31:57 >
> What happens if a client sends more than one move
> within a given timeslice?
Use this next input byte as his next move ?
One question: how fast can I send input bytes to be "reasonable" to work on say:
1) a fast LAN of 2 PC's (that's home to me)
2) a shared fast LAN with a lot of pc's
3) the internet with everybody on a fast cable connection
4) modem connection ?
I would want to let the user set the fps, so I can adjust the sleepTime of the main game loop according to this.
jpw35a at 2007-7-11 23:31:57 >
A) Have a thread for each client that does:
while(true) {
command = readCommand();
doAction(command);
sleep(250);
}
So each player can do 4 actions per second, although there would be a problem with sending more packets than 4/s as they'll be queing, and thus give a 1/4 second lag for each qued packet
B) Try client-side prediction
See thus:
http://forum.java.sun.com/thread.jsp?forum=406&thread=348808&start=71&range=1&hilite=false&q=
The idea is that in the update packet you give an object's direction and speed as well as position, then while the client waits for an update it can guess where each object should probably be
C) Speeds:
A modem can do 7KBytes/sec (56Kbits), a packet of (object ID, xPos, yPos, direction, speed, health / powerup / time to explode), should be ~7 bytes depending on header, so in *theory* you can get 1024 packets/sec/total, although 4/sec/player should be reasonable (and less bandwidth hogging)
I'd go for at least 10/sec/player, because in bomberman in particular, lag is very, very noticeable, and players get irate when they've moved out of the way of a bomb but their character didn't. At least, that's what the official Bomberman95 taught me. :-)
Mind you a lot of 3d games go for 100/sec/player, and they probably send a lot more data than a bomberman clone.
As for some controls wanting default-on, and some wanting default-off, good point. Although with particular powerups bomberman can drop multiple bombs in a line as he walks along, so you'd probably just do the logic for that on the server.
> Mind you a lot of 3d games go for 100/sec/player, and
> they probably send a lot more data than a bomberman
> clone.
100/sec would be ideal.
> As for some controls wanting default-on, and some
> wanting default-off, good point. Although with
> particular powerups bomberman can drop multiple bombs
> in a line as he walks along, so you'd probably just do
> the logic for that on the server.
I would do ALL the logic on the server, what I need to do on the client is draw a two dimensional grid with stuff on every position (bomb, fire, portal, mirror, brick, rock, arrow, bonus) and draw all players. All the client needs to do is have all images and sounds preloaded in memory and keep track of the "grid state" (I would send the level to the clients at the start of a new game, which is just an array of int).
If I only send updates (remove_bomb_x_y, add_bonus_x_y_type) and this every 10 ms, very little will be needed to send. For fires I better send the center position (x,y) and 4 length's for the 4 directions.
jpw35a at 2007-7-11 23:31:57 >
I'm working on a JAVA Bomberman myself (with a friend)!!!
To save time, the game is actually being designed in text mode (no graphics), but it still look good.
The multiplayer feature is not available yet, but we are implementing it using a 'coordinator'. That is, collecting input packets from clients, evaluating some basic (or none) logic, and re-sending all collected packets to clients. I don't know really how well will this work. The server only collects packets and re-send; it have no info of the actual game (other than players). I have not tested how many packets/sec are needed for a smooth game.
I hope we both finish our proyect and check each others bomberman.
Excuse my english, i'm from Argentina =).
> check each others bomberman.That sounds dirty :)
> To save time, the game is actually being designed in
> text mode (no graphics), but it still look good.
I wouldn't start form a textual version.
Why not start with drawing basic things with Java2D instead of text mode ?
(circle for a Bomb, rectangle for squares, ...)
When your game is finished, you can replace those dull graphics by ripping of gifs from other games.
jpw35a at 2007-7-11 23:31:57 >
one question...you said one byte for 4 directions and buttons, etc...could you give me a breakdown of that byte and how you put it together?M
bitmasks and bitwise operators.
static final int LEFT = 1; //1<<0
static final int UP = 2; //1<<1
static final int RIGHT = 4; //1<2
static final int DOWN = 8; //1<<3
static final int FIREA = 16; //1<<4
static final int FIREB = 32; //1<<5
static final int UNDEFINED1 = 64; //1<<6
static final int UNDEFINED2 = 128; //1<<7
//Your receive code will look something like :-
int actions = inputStream.readByte();
if((actions&LEFT)!=0)
{
//left
}
//etc etc.
//and your send code :-
int actions = 0;
if(left) actions|=LEFT;
//etc etc.
outputStream.writeByte(actions);
Abusea at 2007-7-11 23:31:57 >
goofy assumption....
somewhere between the read and write, the server takes your actions, calcs result, etc... ?
For multiplayer overhead tankshooter, asteroids, Ultima(early, like I or II) games, is it better to send left and rights to server, let server calc move and send postion back to palyers?
