It says, right on the mobile mode interstitial, that it "requires the latest mobile/tablet hardware." And yet, you seem surprised when it doesn't work on older hardware?
I was going to disagree because the same countries that really like web games are often the ones using older handsets, but Apple themselves say only 8% of handsets are on iOS < v10: https://developer.apple.com/support/app-store/
Even at it's peak apple only had 23% market share. 1 in 10 out of 23% is 2.3% and not everyone plays this game on a phone so the percentage is even lower in reality.
Please forgive the random reply, but it's the closest to a direct message I can get. :)
Suggestion: place powerups in areas of the map that have not seen combat recently.
It seems like almost all the combat is over Europe, and the other areas of the map are almost always completely unpopulated. The most fun fight I had was when one other aircraft and I got into a dogfight near SA/Antarctica. It lasted several minutes, just the two of us. Even so, it only happened because I followed him there, and apparently he was just exploring the map.
So if you were to track combat activity on something like a heat map, you could spawn upgrades and powerups in cold areas of the map. This would encourage players to go hunting for them. As a result, different areas of the map would see combat regularly, and the hotspots would move around.
Also, if you spawned players in away from other players, it would encourage encounters around the map instead of concentrated in one area.
Finally, I use WASD in home-row position, and I'd like to rebind the the shoot and action keys. If you could make this possible, it'd be great.
When a packet is lost in a TCP stream, it must be retransmitted, and until the client receives it, all further packets are stuck in limbo (received by the client, but cannot be seen). For this reason, most games use UDP instead, and are designed so some packet loss is acceptable (if I received where you are at frame N, it no longer matters if I receive where you were at frame N-1).
Minecraft uses TCP, that's why in very populated servers occasionally you can see the whole world freeze for a second.
In the browser we have UDP with WebRTC data, the problem is that not all browsers support it, it may not work in some places and for now it's more difficult to work with.
An easy compromise is to use several TCP connections, so if one packet is lost, instead of having N packets stuck for a moment, you have 1/N where N is the number of connections. And if important packets are sent through all channels, the chance that they arrive too late is much lower.
I interleave information that becomes redundant (like the position of players, I can handle losing every other packet for a while, interpolating/predicting missing info) but send important data in all channels (like when a rocket is fired, it's just one event that must be seen).
Again, I'm not OP but I did similar things and explained what probably happens with this game.
There's also another important detail. Due to delayed ACKs on Windows and battery-preserving TCP stacks on most mobile devices/laptops, some of your packets will be delayed. Even with TCP_NODELAY. Desktop OSX/Linux do not display this behavior.
The only solution I have found, and it's a rather crude one, is to blast the server every 50ms with a 1-byte packet. It is ugly but it works well.
I tried to create a game similar to this (I spent 6 months on it). Very basic Geometry. Circles. I got the concept working well locally, but I ran into problems on how to deal with the networking. I got things running in Node with SocketIO and so on but there could be 400 players, each made of upto 8 moving pieces, and each can fire several times a second.
I spent a lot of time on a book, "Real time collision detection" and generally I have fond memories of the whole project and trying different partition and slicing up space.
However, how to package and deal with this snapshot of world "over the network" or for example "how to smooth any lag relative to the client"... this middle region was largely undocumented or ill accessible to me.
I will look forward to when/if you write any thoughts.
You've done a great job! It's stayed very responsive for the time I've played. I haven't even noticed any dropped packets, so your method for dealing with them seems to be working very well despite the high load.
Huh wow, thanks :) I need to make bitcoinity working as stable as airma.sh does. Congrats on the well earned success btw, clearly the game is here to stay.
It would be sweet to be able to change fire from spacebar to something else. Spacebar tends to be big and loud.
More stringent validation methods won't help with the ever-present possibility of private key compromise. So long as that's a real possibility and revocation is broken (which it clearly is), longer certificate lifetimes are a liability. Renewal needs to be automated so you don't care how often you have to renew.
Let's Encrypt will sign your ECC keys now, but we'll sign with our RSA keys. We'll likely have our own ECC trust chain some time next year.
Temporal dithering. Also called FRC - frame rate control.
You might not notice it, but if you are on a TN monitor right now (almost all non-professional monitors) this technique is being used to emulate 24 bit color. Most TN panels can only display 6 bits per channel.
