The game space is a little crowded i felt. Otherwise pretty cool game !
Do you plan to open source or do you know of a HTML5 game of similar complexity that is ? Would love to read the code.
The gameplay reminds me a bit of an old favorite of mine - Starport: Galactic Empires. I wonder of games of that nature could undergo a revival as browser games.
I can't seem to get my aircraft to move forward using a keyboard. Flying backwards is fine, but using the ^ key is a nogo. Controller works fin theough!
normal, modern dev with automated builds and git creates a build every time you commit (or every push), and you can commit for a missing comma so ... with 10 or more people working on it on a daily basis it can go up very fast
Also I believe that this is the kernel build counter, and it's the same counter that's used since Win95. Someone has published a list: https://www.gaijin.at/en/lstwinver.php
Same issue on both Firefox (57.0.2) and Chrome (62.0.3202.94) on Windows 10 (build 16299.64). At least for me forward doesn't seem to be completely ignored; while holding it down it will occasionally spurt forward a bit.
It's still alive, to some extent. Priit Kasesalu (of Skyroads, Kazaa and Skype fame) wrote an alternative client back in 2001: Continuum. Some of the bigger servers (EG, TW) are still around. Many of the smaller ones like SFSS have long since perished.
WebRTC really isn't suitable for multiplayer gaming due to it being entirely P2P. You need the server to operate as a single source of truth and enforce clients to play by the rules.
Yep. The server provides signaling (who the peers are, what data is being requested/should be snet, etc) but you're absolutely correct: WebRTC primarily envisioned for high-bandwidth peer-to-peer suitable content such as video/audio/file-sharing.
People have tried using it for gaming (e.g. server is the master peer) but it's tenuous and folks should just stick to WS.
UDP low latency links from every client to every other client.
The client code sends a sample of received UDP packets to the server over the TCP connection, who will then verify that all info contained in the packets is true and accurate and nobody was cheating.
It's a nice model because you get the super low latency between clients, and at the same time within a few hundred milliseconds you can detect cheaters and kick/ban them.
Obviously, you have to design your game to handle asynchronous lossy information from many different sources and nobody having a complete and whole view of the game until half a second later or so. Thats quite do-able though by timestamping every event and then running rollback-able or checkpointed synchronous simulation on all clients.
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.
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.
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'm amazed by how well this works on mobile. I literally played this game for about half an hour on my phone in the HN app web view because it's just so much fun. I'm used to normal web pages that don't even really work on mobile and this game just worked seamlessly without any problems whatsoever. Great Job!
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.
315 comments
[ 2.5 ms ] story [ 293 ms ] threadOS: Windows 10 (Build 16251) Browser: Firefox Developer Edition (58.0b10 64-bit)
Is that low, high or normal(expected)?
edit: it's not the kernel build counter and MS has cheated with it in the past, but it has stayed sequential across the whole NT tree (as this is where any post-2K Windows originates). https://www.howtogeek.com/140411/learn-the-secrets-of-the-wi...
please update to ignore case in controls.
also bug, BT KB kills any touch control on an ipad... plus it hangs on a certain direction and contrl dies very fast...
way too buggy to even play on an ipad with a BT KB
I don't have a BT KB so I didn't test that case. Will do!
Subspace Continuum is an anti-hacking fork released in 2001 (Subspace was released in '95) and is now the only official version of the game.
The netcode in subspace was a bit better, probably due to needing to deal with 200ms+ pings that were common back in that era.
People have tried using it for gaming (e.g. server is the master peer) but it's tenuous and folks should just stick to WS.
TCP from a master server to every client.
and
UDP low latency links from every client to every other client.
The client code sends a sample of received UDP packets to the server over the TCP connection, who will then verify that all info contained in the packets is true and accurate and nobody was cheating.
It's a nice model because you get the super low latency between clients, and at the same time within a few hundred milliseconds you can detect cheaters and kick/ban them.
Obviously, you have to design your game to handle asynchronous lossy information from many different sources and nobody having a complete and whole view of the game until half a second later or so. Thats quite do-able though by timestamping every event and then running rollback-able or checkpointed synchronous simulation on all clients.
I use 2 WS connections mirroring some packets on both, to deal with head-of-line blocking.
https://i.imgur.com/oSwGgFA.png
I remember donating back in the day!
It would be sweet to be able to change fire from spacebar to something else. Spacebar tends to be big and loud.
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.
A lot of trial and error.
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.
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.
Probably not worth supporting. :) Adding new features and figuring out ways to keep people playing might be much more worth your time.
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/
Good point about market share though, hadn't considered that.