Yeah that "desync" is because the server mspt (shown next to your latency) was likely very high. It's because of a memory leak, I'll investigate when I get a chance.
I'll look into that game, I've never heard of it. Not sure how I'd incorporate NPCs in a fast paced game like this, if you have any ideas let me know!
You ultimately will need to try to kill the player who is chasing you. Choose one tank you think will kill them, and keep trying until they die. That's basically the point of the game; choose tanks adapted to your environment and get as many points as you can.
Hey, thanks for the suggestions! By the way, you can hold K to level up to max, this is temporary though.
Levels are determined by halving your XP then finding the correct level, just like Diep.io. I agree with you though; I'll probably make it less harsh.
Level scaling is already exponential (its harder to get levels as you progress).
I actually really like the noob flag idea; when spectating, a bunch of people were confused on what to do and kept dying to a higher level person. I will definitely add this feature in the following week.
WebRTC is complicated; there are many more edge cases compared to websockets. Off the top of my head, I know I'd need to run a TURN server for people behind symmetrical NAT or CGNAT networks, which would be a pain. WebSockets are much more accessible for everyone. In the future I'll investigate UDP protocols, but its likely I'll always use TCP for web games.
Not at the moment, no. I'll add a tank editor in the future which could technically be ported offline, but I don't have too big of a desire to port it to a native app.
The base game is inspired from Diep.io with extensive features already to differentiate it, but you're right the base game is still essentially Diep.io. The game is still relatively new and I haven't implemented all my ideas yet, but when I'm done the base game mechanics will be completely different.
I don't think it's abuse, but just server degradation from 50 players playing for hours. I restarted the server and it's better, I'll fix the degradation later today.
I used Axum for the websocket server, MySQL for the database, and the glicko2 crate for elo management. Those are the only 3 that come to mind, I didn't use any libraries/engines for the game itself.
There are some features in-game which I don't want abused by bots (creating sandboxes for instance). There's also a 1v1 system which needs a Google account to associate your rankings with. Other than those two sections, you are able to play FFAs and join other people's sandboxes without a Google account.
Yeah, I didn't actually expect this many people to play. I've ran benches locally of 100 bots playing together, and the game server ran at a decent 5-7 MSPT. I didn't run the benchmark for hours though, so I never got performance degradation. I'll run the bench for a few hours today and inspect why performance degrades.
There already is. The lag you were experiencing was likely from the game server degrading; did you check what the MSPT of the server was when you were playing? (It was listed at the bottom near your ping.)
I like the idea of UDP, but protocols like WebTransport aren't 100% supported and are still relatively new compared to websockets. But you're right, using UDP would be a less latent approach and clientside prediction can account for any lost packets.
Hey sorry, overnight there was performance degradation which made the server run very slow (~100MSPT). I restarted the server for a temporary fix and will fix it sometime today.
Hey, thanks! You're right, I should've probably labeled it as a multi-player game, not an MMO. The connection issue you faced was because of a (probably) faulty clientside fingerprint implementation I made; your fingerprint probably collided with others. I'll rework it in a few hours.
Hey, sorry about that; there was some performance degradation overnight which caused the game server to run very slowly. I restarted the server to temporarily fix it, I'll look into it today.