Daedalus - no escape

Featured Games
#341

thanks :wink:

for the client-server, I don’t send the inputs but directly the player positions. I was not able to do the input stuff as in CS for two main reasons:

  • I can’t rollback the physics simulation with box2d
  • box2d is float based so even if I could rollback I’m never sure that the simulation done on the server would be the same as the one done on client side.

So basically I’m not sending inputs because I use box2d :slight_smile:

The way it works now for the player movement:

  • the client and server synchronize their clock when connecting
  • when the client moves, it directly impacts the player position in local (no wait for server validation)
  • the client send his position + linearspeed + orientation + angular speed to the server 30 times per second
  • the server gets the message, and update the player position based on the position received + speed (taking into account the delay to get the message)
  • the server is then sending if necessary all the player positions to all the players 20 times per second (dedicated servers can adjust this value if needed / enough bandwidth)
  • the client update each player position the same way as the server (taking into account the delay) except that the position is not directly affected but there is some interpolation done to avoid as much as possible weird player teleporting :slight_smile:
  • between two updates, the clients and server continue to move the player according to the linear and angular speed …

And when firing a bullet:

  • the client fires the bullet in local and sends a message to the server
  • the server validates that the client can fire a bullet, then fires the bullet taking into account the delay between the server and client.
    So basically the bullet will be fired on the same position as on the client, but is accelerated at the beginning to keep sync with the client.
  • after firing the bullet, the server send to all the other clients the same fire message
  • the clients fire the bullet, applying the same mechanism as the server.

So for the bullets, that’s pretty accurate. But for the player movement it’s less because of the unpredictability of the movements :slight_smile:

With this, the server needs a bandwidth of about 144 kbytes/s for 16 players.

I said it was horrible also to synchronize game states, all the entities and so on. And also it’s limiting in term of visual effects.
In a single player game it’s not an issue if for exemple an explosion effect goes through walls (it’s quite common …), as you don’t see behind the wall :slight_smile:
But here as there may be another player behind the wall, all the effects should be well contained to avoid breaking the purpose of the fog of war.
So this is very limiting … in a single player game I could do way better effects with tons of particles and big plasma waves and so on … without worrying about collisions with the environment …

#342

This is really funny, I have been dedicating the past 3 weeks to synchronize all clients and it succeeded (with the super unfriendly (in respect of networking) library box2d).

  • Actually I was convinced that a rollback with the box2d (world-class) was impossible as well, I asked on multiple forums how to fix this, but nobody was able to give an answer that helped me, but I came up with another way to do it and it even worked.
  • Box2D is indeed float based :-, I have done a lot of tests, over the internet with friends, on desktops and mobile phones, and it was perfectly synchronized on all of them, I had to do a few tricks for that though, (even World.render(delta, velocityIterations, positionIterations), renders 2x a delta of 1.0f/60 else than 1x a 1.0f/30).

Accelerating the bullet is indeed what you have to do all the time to keep the clients synchronized (I do that with everything). And you hit the nail on the head, the server shouldn’t contain any game logic :stuck_out_tongue:

It sends 60 updates per second to server (when needed) and the server sends all those updates to all clients, and it is working very fast, even on my 3/4-year-old single-core 600MHz (with super crappy network-card over wifi) HTC Wildfire S.

If you have any interest, you can get this code, a lot of people have been asking me about it, I don’t know if I should release it as a (very easy-to-use) library yet (including some methods to roll-back/synchronize your World), but if you want to have it, just ask. If it can make the quality of your game better you have to give it at least a try. :slight_smile:

Edit: I am probably a little bit too late with this to be helpful though :stuck_out_tongue: (since your game is almost done)

#343

@Herjan
Polish it if needed and put it on github; sounds like good stuff if a of of people are asking it, plus that kind of thing can be good resume/portfolio material.

#344

This is really funny, I have been dedicating the past 3 weeks to synchronize all clients and it succeeded (with the super unfriendly (in respect of networking) library box2d).

  • Actually I was convinced that a rollback with the box2d (world-class) was impossible as well, I asked on multiple forums how to fix this, but nobody was able to give an answer that helped me, but I came up with another way to do it and it even worked.
  • Box2D is indeed float based :-, I have done a lot of tests, over the internet with friends, on desktops and mobile phones, and it was perfectly synchronized on all of them, I had to do a few tricks for that though, (even World.render(delta, velocityIterations, positionIterations), renders 2x a delta of 1.0f/60 else than 1x a 1.0f/30).

Accelerating the bullet is indeed what you have to do all the time to keep the clients synchronized (I do that with everything). And you hit the nail on the head, the server shouldn’t contain any game logic :stuck_out_tongue:

It sends 60 updates per second to server (when needed) and the server sends all those updates to all clients, and it is working very fast, even on my 3/4-year-old single-core 600MHz (with super crappy network-card over wifi) HTC Wildfire S.

If you have any interest, you can get this code, a lot of people have been asking me about it, I don’t know if I should release it as a (very easy-to-use) library yet (including some methods to roll-back/synchronize your World), but if you want to have it, just ask. If it can make the quality of your game better you have to give it at least a try. :slight_smile:

Edit: I am probably a little bit too late with this to be helpful though :stuck_out_tongue: (since your game is almost done)

#345

@Herjan
Polish it if needed and put it on github; sounds like good stuff if a of of people are asking it, plus that kind of thing can be good resume/portfolio material.

#346

@Herjan : indeed it’s a bit to late for me, but i’d be glad to have a look at your code if you have it somewhere :wink:
Otherwise for the float based aspect, from the tests I’ve done, there was clearly differences when running the same simulation on different computers.

For example, when firing the bounce baby in my game ( so with bullets that bounces on the walls … ) on the angle of a wall, depending on the computer the bullet can bounce in one direction or another. It’s easy to understand that two computers running the simulation at two different frame rates can only have differences from very small ones to obvious ones.

EDIT: by the way I just uploaded a new version of the demo with bugfixes and new net layer based on UDP … if you guys want to try it out :wink:
http://daedalus-thegame.com/download.php

#347

@Herjan : indeed it’s a bit to late for me, but i’d be glad to have a look at your code if you have it somewhere :wink:
Otherwise for the float based aspect, from the tests I’ve done, there was clearly differences when running the same simulation on different computers.

For example, when firing the bounce baby in my game ( so with bullets that bounces on the walls … ) on the angle of a wall, depending on the computer the bullet can bounce in one direction or another. It’s easy to understand that two computers running the simulation at two different frame rates can only have differences from very small ones to obvious ones.

EDIT: by the way I just uploaded a new version of the demo with bugfixes and new net layer based on UDP … if you guys want to try it out :wink:
http://daedalus-thegame.com/download.php

#348

Actually, (after a lot of testing) the float based crap killed it. At first it works fine, but sooner or later it got out of sync anyway (with multiple devices).
I did all kinds of NASTY tricks to avoid the float based crap, I only executed steps with a delta of 1/60 (this alone already counters the frame rate thing you spoke of) and I attempted to kill the float difference by multiplying velocities/positions by 1000, making an integer of them, and divide it by a thousand again, but even if I only used small forces (or do even more really nasty tricks like checking how big the velocity is, and based on that do some multiplying/dividing), it gets out of sync after a certain amount of collision happens.

I also wanted to keep track of the game with my server (kills etc.), so you need to simulate the game anyway. And I found out that just sending positions etc. eats less bandwidth (on both sides) than sending inputs does.
Its better to just send positions etc. from the simulating server to the client so you are 100% sure each client is synchronized. Another problem were joining players, I did send all input from the beginning of the game to the player, so the client could update the game to the current state, you probably can imagine how much that is if the game is already going on for 10 minutes … (And then I haven’t even spoken of simulating the 10 minutes)

It was just not worth it, so many nasty tricks, ugly code (and processor overheating ;)) to just get them synced on inputs, and it turned out to be worse for both sides.
It was an interesting time occupation though, I learned so much. :slight_smile:

#349

Actually, (after a lot of testing) the float based crap killed it. At first it works fine, but sooner or later it got out of sync anyway (with multiple devices).
I did all kinds of NASTY tricks to avoid the float based crap, I only executed steps with a delta of 1/60 (this alone already counters the frame rate thing you spoke of) and I attempted to kill the float difference by multiplying velocities/positions by 1000, making an integer of them, and divide it by a thousand again, but even if I only used small forces (or do even more really nasty tricks like checking how big the velocity is, and based on that do some multiplying/dividing), it gets out of sync after a certain amount of collision happens.

I also wanted to keep track of the game with my server (kills etc.), so you need to simulate the game anyway. And I found out that just sending positions etc. eats less bandwidth (on both sides) than sending inputs does.
Its better to just send positions etc. from the simulating server to the client so you are 100% sure each client is synchronized. Another problem were joining players, I did send all input from the beginning of the game to the player, so the client could update the game to the current state, you probably can imagine how much that is if the game is already going on for 10 minutes … (And then I haven’t even spoken of simulating the 10 minutes)

It was just not worth it, so many nasty tricks, ugly code (and processor overheating ;)) to just get them synced on inputs, and it turned out to be worse for both sides.
It was an interesting time occupation though, I learned so much. :slight_smile:

#350

I can only see the floor :frowning: even if i turn off all the graphics options.

#351

I can only see the floor :frowning: even if i turn off all the graphics options.

#352

@Herjan: ok, that’s too bad, but I’m not really surprised from the tests I’ve done myself :slight_smile:

oh cool, a bug! :slight_smile: Can you post a screenshot please and tell me about your hardware and OS ?
Thanks :wink:

#353

@Herjan: ok, that’s too bad, but I’m not really surprised from the tests I’ve done myself :slight_smile:

oh cool, a bug! :slight_smile: Can you post a screenshot please and tell me about your hardware and OS ?
Thanks :wink:

#354

this one is with most of the graphics options turned off

this one is with default settings, appart from screen size.

it looks like the line of sight is occluding all the objects perhaps? i could see the bots lights.

windows 7, looks like the graphics in the laptop is intel HD graphics 3000.

#355

this one is with most of the graphics options turned off

this one is with default settings, appart from screen size.

it looks like the line of sight is occluding all the objects perhaps? i could see the bots lights.

windows 7, looks like the graphics in the laptop is intel HD graphics 3000.

#356

ok thanks, the issue here is the stencil buffer that is not working. I use the stencil for all the shadows, for the fog of war, and also to draw the background. That’s why without stencil the game lokks like this :slight_smile:
I already had one guy reporting me the issue and I’ve found this on the net at the time:
https://communities.intel.com/thread/30834

I did an attempt of a fix but obviously it doesn’t work, so maybe Intel haven’t fixed this, on my side I don’t have a clue about what I can do.
Have you tried to use the stencil buffer yourself on your game maybe ?

Next week I will have access to a machine with a Intel HD GPU, so I may be able to find a solution, but I’m kind of pessimistic :frowning:

EDIT: by the way, do you have the latest drivers for your GPU ?

#357

I just tried updating the drivers but the intel driver updater said its custom driver and it cant fix it. so ugh dunno.

I havn’t tried using stencil buffer, just an fbo for lighting and depth buffer for culling hidden areas.

#358

ok thanks, the issue here is the stencil buffer that is not working. I use the stencil for all the shadows, for the fog of war, and also to draw the background. That’s why without stencil the game lokks like this :slight_smile:
I already had one guy reporting me the issue and I’ve found this on the net at the time:
https://communities.intel.com/thread/30834

I did an attempt of a fix but obviously it doesn’t work, so maybe Intel haven’t fixed this, on my side I don’t have a clue about what I can do.
Have you tried to use the stencil buffer yourself on your game maybe ?

Next week I will have access to a machine with a Intel HD GPU, so I may be able to find a solution, but I’m kind of pessimistic :frowning:

EDIT: by the way, do you have the latest drivers for your GPU ?

#359

ok so I’ve got another possible fix, just uploaded it here:
http://daedalus-thegame.com/tmp/daedalus-windows32-0.8.14demo.zip

Basically what I’m doing is just creating the GL context with a stencil buffer even if I don’t use it (I use the stencil only on FBOs and not on the main buffer).
I’ve read it here but the issue is not exactly the same so not sure that this will change anything: https://communities.intel.com/message/182032#182032

Can you please give it a try ?

#360

I just tried updating the drivers but the intel driver updater said its custom driver and it cant fix it. so ugh dunno.

I havn’t tried using stencil buffer, just an fbo for lighting and depth buffer for culling hidden areas.