Jumpy gameplay

[owenashurst]

I know I'm not the only one to know it's jumpy when playing the game, I think it's better if we optimise the game now, and add features later. This needs to be prioritised before anything, as we don't want another minecraft.

I've noticed that when eating food, it stops for a fraction of a second and continues. As well as jumpiness when just moving about not doing anything. Sometimes it's fine however it needs to be more smoother some how.

I've noticed the original Agar.io is using Twitter Boostrap, maybe this will help in optimisation and more look-alike?

[xizhao]

It says in the readme client is for rendering only. That's no good, there should be 2 full game simulations on both client and server. Then periodically client syncs with server.

[JoeMattie]

Most of the jumpiness was being caused by the HUGE food table being resent over the websocket whenever anything changed. This should be fixed (albeit a bit hackishly) in my recent pull request.

Using a binary websocket protocol and implementing delta compression will fix this as well.

[giongto35]

It's not because of food table. Food table has been resolved I think. It is only updated when a player is eaten. Track the updatereq variable to see it

[JoeMattie]

It is (was) 100% because of the food table. Now that the number of default food per map is in the thousands, the old way of updating the client whenever the updatereq variable evaluated true resulted in several thousand JS objects with verbose color information to be serialized and sent over a websocket, (probably 50 to 100 kb of data) during an intra-frame tick at 60fps.

The way I fixed this was by throwing out the "updatereq" parameter and am instead tracking the client's viewport size. The server then actively restricts the subset of food to be sent to the client to just those within his viewport.

[igorantun]

Might as well send the food information only once and then just re-send the modified parts, i.e. food is spawned -> server sends that info to clients -> no more info sent -> player eats food -> server sends that info to clients

That would prevent spamming the clients and the server with unnecesserary data.

[themuddfamily2]

I guess you could assign an ID to each food then remove/add food into the array?

[Azeranth]

Each food has a date time id already when it is added so you could get that and then change the list only with that one

[themuddfamily2]

if pull #186 fixed the merge conflicts this would be fixed.

[owenashurst]

It's still happening. I reopened the tab again with the game, and I "eat" a few pieces of food before this horrendous lag started, to the point where my mouse direction had no effect on the movement of it until a while later. It was as if I was playing Tetris - something to relate to how jumpy it was. I'm using Chrome on a high-spec gaming PC, so I can't see any reason why it can't handle a simple JavaScript game :p I've tried checking the console for any errors, and there's nothing showing.

The only thing I can think of to duplicate this is to use Chrome, open the game once the server has been started, eat a few pieces of food, and then close the tab and keep re-doing this process until it happens. The first time was fine, but it was no where near as smooth as the original Agar.io.

[abalabahaha]

And where is the server hosted? It's a known issue that the server takes enormous amounts of bandwidth sending stuff to the client because it sends raw food/enemy objects, not binary data. You sure it's not that?

[owenashurst]

I'm getting a 20ms ping to my server, its in France, hosted by OVH.
On 21 Jun 2015 12:57 am, "Jerry" [email protected] wrote:

And where is the server hosted? It's a known issue that the server takes
enormous amounts of bandwidth sending stuff to the client because it sends
raw food/enemy objects, not binary data.

—
Reply to this email directly or view it on GitHub
#190 (comment)
.

[abalabahaha]

Interesting... I also have a OVH server in Canada, ping ~110 and its mostly fine... Has this been partially resolved/worsened by my PRs within the last few days?

[abalabahaha]

And are you sure this isn't #158

[owenashurst]

I'm not sure, I don't think there has been a difference, @abalabahaha. It's just really bad, no where near as smooth as the original game, and when you compare the two, the difference is huge. Eating food is fine now and isn't jumping when eating, but I always keep my version of the game up to date when there's been commits.

If the jumpy game-play is fixed then the game would be fine, and then other work on features can be implemented. I just think this needs to be prioritised over anything.

[abalabahaha]

The fix for jumpy gameplay is probably bandwidth minimization in the form of binary data transfer, along with incremental food/enemy packets instead of the massive visible-food table being sent 25 times a second. Sadly, the people who used to do those helpful optimization PRs haven't done those for a while...

[abstream]

I just tried one of the live demos , it was lagging with a ping of 80ms.
I guess this task will eat a lot of development efforts but it looks like the most important one:
It will change the user experience dramatically. Is there a way to prioritise this and maybe combine efforts?

[dpxcc]

I think the jumpy gameplay is because of the lack of client input prediction.