Wow, didn't expect to see this. Maybe something is in the air - I've been working on a similar project [0] out of a nostalgia for the "Curve Fever 2" era. I'm actually familiar with your first game, and this one is very fun and polished too, particularly the effects and the UI. Mine is a bit raw at the moment but quite functional. You get dropped in to a shared room of classic "survival," but I've also spent a lot of time making wonkier mode like CTF, zone control, etc. It's a bit of Achtung die Kurve meets Halo 3.
But - we are both very aligned on the "no ads/tracking/monetization" aspect, which I appreciate. best of luck to a fellow curvelike developer.
in curvytron your trail grows behind you as you go, so on each frame most of active players trail "capsule" 3D geometries have changed.
I started by blindly recalculate every geometry on every frame, work well enough for a time but I think you can see the optimisation problem coming...
On each frame the trail gets only 1 new point and the rest of its points (dozens) has not changed, yet you recalculate every segment vertices (and normals, etc) for every point, just to add one new segment at the end and finally add the half-sphere cap.
And this is done by Three.js: so by the CPU, not in GPU yet.
What I did was write a dynamic capsule geometry, with pre-allocated geometry buffer and the capacity to add 1 point at each frame by just filling the missing vertices, normals, etc fo the point. Resulting in a massing performance improvement.
Side note: when the player stop "drawing" and leave a hole behind, the detached trail become inactive and just stop being re-computed at each frame.
Server side — Secured client identification:
When you connect to the game, the server forges and sends you a unique secure token. If you lose connection, your client and player data on the server aren't removed but just "parked" into an offline list of clients. Your player is left without a pilot for a moment. As soon as you reconnect with a valid token, the server is able to restore your client and plug you back into your player's controls. You're back in the game!
Client side — Ubiquitous game data:
For reconnection to work on the player's end, I also need every client arriving in the middle of a game to get the exact same state as a client that connected from the start. This means sending every connecting client all the meaningful data about the current game: state, player positions, speed, size, ongoing bonus positions and timings, etc. I designed the game with this requirement from the very start: each new feature must follow this pattern, and the client must support building the game's world on the fly from this data.
Wow, didn't expect to see this. Maybe something is in the air - I've been working on a similar project [0] out of a nostalgia for the "Curve Fever 2" era. I'm actually familiar with your first game, and this one is very fun and polished too, particularly the effects and the UI. Mine is a bit raw at the moment but quite functional. You get dropped in to a shared room of classic "survival," but I've also spent a lot of time making wonkier mode like CTF, zone control, etc. It's a bit of Achtung die Kurve meets Halo 3.
But - we are both very aligned on the "no ads/tracking/monetization" aspect, which I appreciate. best of luck to a fellow curvelike developer.
[0] https://recurvegame.com/
This is excellent! What was the biggest challenge you found while developing the sequel?
It was clearly dynamic "trail" geometry:
in curvytron your trail grows behind you as you go, so on each frame most of active players trail "capsule" 3D geometries have changed.
I started by blindly recalculate every geometry on every frame, work well enough for a time but I think you can see the optimisation problem coming...
On each frame the trail gets only 1 new point and the rest of its points (dozens) has not changed, yet you recalculate every segment vertices (and normals, etc) for every point, just to add one new segment at the end and finally add the half-sphere cap. And this is done by Three.js: so by the CPU, not in GPU yet.
What I did was write a dynamic capsule geometry, with pre-allocated geometry buffer and the capacity to add 1 point at each frame by just filling the missing vertices, normals, etc fo the point. Resulting in a massing performance improvement.
Side note: when the player stop "drawing" and leave a hole behind, the detached trail become inactive and just stop being re-computed at each frame.
Nice! The game is fun.
How did you handle the reconnection?
Thanks!
Reconnection relies on two mechanisms:
Server side — Secured client identification: When you connect to the game, the server forges and sends you a unique secure token. If you lose connection, your client and player data on the server aren't removed but just "parked" into an offline list of clients. Your player is left without a pilot for a moment. As soon as you reconnect with a valid token, the server is able to restore your client and plug you back into your player's controls. You're back in the game!
Client side — Ubiquitous game data: For reconnection to work on the player's end, I also need every client arriving in the middle of a game to get the exact same state as a client that connected from the start. This means sending every connecting client all the meaningful data about the current game: state, player positions, speed, size, ongoing bonus positions and timings, etc. I designed the game with this requirement from the very start: each new feature must follow this pattern, and the client must support building the game's world on the fly from this data.
[dead]