dasilvacontin / ag-drift Goto Github PK

And pools for other commonly created objects, to avoid GC.

Default official weekly race: Tuesday 5PM UTC.

What should happen?

• If the server is up when it becomes Tuesday 5PM UTC...
  • the active race is forced to stop (race end countdown starts). A system chat message is broadcasted: 🔥🔥🔥 It is Tuesday 5PM UTC, time for AG DRIFT's official weekly race 🔥🔥🔥\n\nStopping the current race to give way to the official race.
  • the next race that starts is a race of type "Official". The server verifies with the Notion database that this race hasn't happened yet (there should only be one official weekly race per week), and proceeds.
    • it has no bots
    • boosting is disabled
    • the race lasts 30 laps
    • once the first player finishes the race, there's a 1 minute grace period to finish the race
    • the start countdown is 1 minute. A system message is sent every 5 seconds that says The official weekly race starts in X seconds, with the text changing every second to reflect the remaining time to start
    • the starting order of the players who were connected at the start of the countdown is randomized

Other requirements:

• The "Tuesday 5PM UTC" time for the weekly race should be hardcoded – I will simply modify it in the code if necessary.

Mixpanel says that 10AM Tuesday is the most popular race time.
11:39AM is 7:39PM London.
London is in UTC +1 BST. Which means that Mixpanel's time is UTC -7.
Which means that Tuesday 5PM UTC is the most popular race time.

A player connected about 30 idle ships. Server became non-responsive.

Excerpt from logs:

2017-03-01T12:23:39.397946+00:00 app[web.1]: ci: 1, cj: 9, oldC: 4, c: NaN
2017-03-01T12:23:39.398090+00:00 app[web.1]: ci: 5, cj: 10, oldC: 1000, c: NaN
2017-03-01T12:23:39.398182+00:00 app[web.1]: ci: 5, cj: 10, oldC: 1000, c: NaN
2017-03-01T12:23:39.441265+00:00 app[web.1]: ci: 2, cj: 8, oldC: 4, c: NaN
2017-03-01T12:23:39.449498+00:00 app[web.1]: ci: 5, cj: 10, oldC: 1000, c: NaN
2017-03-01T12:23:39.449558+00:00 app[web.1]: ci: 5, cj: 10, oldC: 1000, c: NaN
2017-03-01T12:23:39.449631+00:00 app[web.1]: ci: 5, cj: 10, oldC: 1000, c: NaN
2017-03-01T12:23:39.489322+00:00 app[web.1]: ci: 5, cj: 8, oldC: 9, c: NaN
2017-03-01T12:23:39.500274+00:00 app[web.1]: ci: 5, cj: 10, oldC: 1000, c: NaN
2017-03-01T12:23:39.500377+00:00 app[web.1]: ci: 5, cj: 10, oldC: 1000, c: NaN

This log statement comes from the following line:

It's meant for debugging the checkpoint system (which sucks big time). Not sure how oldC becomes 1000 -> investigate.

Still, not sure if that detail is at fault for server's irresponsive behavior. A large amount of ships from which we don't get new inputs shouldn't be a big performance hit on the simulation (at least on the network side, since we only send inputs).

I should be logging key numbers for each simulation step, like simulationTime, player#, input#.

Also, it may be possible that, in the client, background tabs are not stepping their simulation, yet receiving new inputs and becoming "lost", thus requiring a sync-back from the server, which IS network intensive. Log also sync-back requests over time.

should make a map selector to go to the old map if wanted too

• players joins
• count of players by username
• ms of turn logic
• cpu / network usage
• active players

You can get knocked out of bounds on certain turns on the main map making it impossible to finish a race.

and maybe some other properties. It may be causing part of the desync between client - server.

Socket.io probably optimises data serialisation when using .broadcast() in groups of sockets.

Currently, it is probably serialising the data once for each socket, since we are currently iterating and executing .emit() for each socket.

When hitting:

• other players
• walls

HP, and then blow up.

When the round ends it does not restart properly, it just freezes up and you have to refresh to enter the next match. This could also just be a connection issue on my end.

The map is formed by a combination of square colliders. We need an algorithm that combines/joins squares to form larger colliders.

It's an optimisation plus it fixes the bug where ships sometimes get stuck at walls, between two squares.

and please change the turn sfx

No need to broadcast inputs as soon as we get them. Buffer them and broadcast them in batches. Results in lower network usage, and a decreased number of re-simulations, both in the client and the server. Increasingly useful with the # of players.

eg. out of 40 players, 15 players change inputs in a given time range. Instead of producing 15 re-simulations, both in the server and the client, it produces a single re-simulation. Top gain.

The build status that appears on the README seems to be broken.

Sometimes, in a requestAnimationFrame, there's not enough delta to tick() the game, and therefore, the ship's position is the same one as in the last frame.

We should generate a non-logical turn to smooth the game/animation.

press on the side to side-boost to that side. swipe left or right to turn 90 deg.

Extreme lag when opening up the site sometimes. Requires multiple refreshes before it allows me to start running smoothly.

• display them next to the ships
• display them next to the ships but only when spacebar or some key is pressed
• dont display them next to ships but on a leaderboard on the side, using the ships' color
• try and test all of them y0l0

To avoid people rendering the present and playing in the past.