Early Access Update Tretton (13)
build id: 55EF30B7
Hello all! We are happy to announce a new update to Space Beast Terror Fright.
Networking Implementation 2
This update has been focused on improving the networked multiplayer experience over the internet, specifically for long-distance / higher latency scenarios. This will get technical, so the bottom line is simply that the networking should work better / be more smooth / not stall when playing long-distance / high latency games.
Input Synchronized Peer-to-Peer Networking With Prediction
As many of you know, we have been running a Peer-to-Peer (P2P) network architecture from the start. While this is an uncommon choice these days for games of this type, this approach brings with it many technical wins for us. Implementation 2 is still Peer to Peer, for a number of reasons.
Besides allowing us to treat both the local game and the networked game in a very similar manner in most parts of the code, running P2P also allows us to trivially support replays of both local and multiplayer games. While this feature is not in the current build it is something that we want to expose to players in the near future.
Aside from the basic functionality of watching past missions, we anticipate replays to be a tool for making / capturing better videos. We will potentially be able to support things like re-camming a captured mission after the fact; both a way to watch the mission from other angles as well authoring of interesting video content.
Our first P2P implementation was tightly lock-stepped and practically bound by latency constraints in roughly the 60 millisecond range (we buffered 4 ticks of input). While this worked in all of our local, cross city, and cross country (in Sweden) tests, we were well aware that this constraint didn't necessarily hold for international play, not least due to the fact that Swedish internet infrastructure is very awesome.
The result was that for any game where peer-to-peer latency was higher than roughly 60 milliseconds, the game would simply stall in order to wait for the required inputs to arrive at the local node.
For Implementation 2 we had two main goals:
- Completely remove perceived input latency for the local player.
- Completely eliminate networked induced stalls.
To achieve this Implementation 2 adds a robust prediction layer to the network code. With this in place the game will never stall, but will in cases where it doesn't have the required "official" inputs for a given simulation step simply "predict" what would have happened assuming that all remote peers simply continued to do whatever it was they did for the last step.
In order for the game to still converge to the same result for all involved players, we periodically perform a time-warp of the simulation state back to the last known step where official inputs (from remote peers) HAD arrived, and re-simulate back to where we have previously predicted the simulation would be.
Because of all of this time-warping, peers communicate both their officially simulated tick as well as their predicted tick to each other. This is the primary synchronization mechanism that allows peers to know where they should be in time; everyone chases the highest predicted tick.
All of this can, depending on the total latency between all peers, result in a lot of re-simulation work from time to time. Exactly where the breaking point is is not yet known; we have done rigorous packet loss and latency simulation tests to try to figure out where the sum of all the prediction and re-simulation work starts to tip over and make the situation unrecoverable. This is the main speculative part of our implementation, and is something that we need to watch closely.
Initial tests have shown that this system feels very good for the local player, regardless of the amount of latency, simply due to the fact that the prediction always runs and always uses the available local inputs. All of this is of course not magic, and the main trade-off is that temporal paradoxes will occur if prediction strays too far from what "officially" happened. This is most apparent when it comes to the movement of other players, and can also be seen in remote player viewing angles / mouse look when in split-screen mode. It is also possible to perceive bullet hits somewhat later than what your local machine had predicted.
Since a simulation step is potentially simulated multiple times, we strive to reduce or completely eliminate any duplicate events that inevitable follow. In high latency / packet loss situations this may result in the perception of missing events, particularly when firing your weapon. Messing with time is not without consequence.
Regardless of the complexity of the prediction / re-simulation, we managed to isolate all of this stuff away from the main game code and keep most things the same as before. This is both a big win for us in terms of development resources, but we are also very happy that the networked game and the local game feel very very much alike.
Future Multiplayer Plans
Assuming P2P Implementation 2 holds we want to move forward with improving the game finding / community aspects of multiplayer. As many of you know and have commented, the current system is a bit blind. Here are the main things we want to address:
- We want to add some kind of public lobby / chat system where it is immediately obvious what players are online and looking for games.
- We want to add the ability to chat via text in both the pre-mission party lobby as well as in-mission.
- We want to add the ability for players to be in a party but not necessarily be in the mission. This will allow for players to join parties with available slots at any time, and / or opt out of a mission while keeping their slot in the party.
- There are currently issues with people switching slots in the party depending on who comes and goes. This is an artifact of our implementation and something that we want to address in order for people to be able to hang on to their characters properly.
- P2P Implementation 2 currently requires all players in a mission to remain in that mission until the mission is complete, regardless of whether they are alive or dead. We want to relax this requirement and allow players to drop out without disrupting the mission in progress. This ties into being able to be in the party but not in the mission.
Miscellaneous
- Fixed bug where the repair station interaction audio would not shut down properly.
- Added many more character names.
Windows 10 Compatibility Issues
We have been getting reports that some users cannot run the game on Windows 10. We have yet to test on that operating system, but will work out the kinks as soon as possible.
As always, thank you for your support and patience,
/nornware AB c/o johno
nornware Dev Feed
nornware on Facebook
nornware on Twitter
nornware on YouTube