Early Access Update Fyrtiotre (43)
build id: 5BCB03E7
nornware AB is happy to announce a new update to Space Beast Terror Fright.
Network Implementation 3 (Client / Server)
In SBTF networking / multiplayer it hasn't historically been possible to join games in progress (in-mission) nor to leave a game in progress (in-mission) without forcing the game to tear down the mission for all players. This was because... architecture, but all of this changes now.
The party host in a networked game is now technically a server, and all other players are clients. The most important implications of this are that as long as the host remains operative other players can come and go as they please without disrupting the game on a technical level.
It also means that the bandwidth / latency conditions of any given client will only affect that client and not the rest of the game. Conversely it also means that the bandwidth / latency conditions of the party host (being the server) will affect everyone in the game.
Client / non-host players bandwidth usage has decreased from around 20kbps to around 7kbps, and server / host players bandwidth usage has increased from around 20kbps to a maximum of around 100kbps, depending on how busy the mission is (in terms of active enemies).
To be super-clear, this new client-server architecture does NOT imply that SBTF involves any kind of centralized / dedicated servers run in data centers by nornware or anyone else. It simply means that one of the players in the game assumes the role of the authoritative / high bandwidth node in the game (the server).
Bottom line: As long as the party host (server) stays in the game then all other players / nodes (clients) can join and leave at any time, and if the party host (server) is on a decent internet pipe then things will be great.
Caveat: You can't join a party where the host is currently launching. This is simply because the server / host will be busy preparing the simulation and visualization locally while launching, and the network will be temporarily unresponsive. You can see this in the network pub as party buttons getting temporarily greyed out while the host is launching.
Replays of networked games had to go
Replays have always been based both on the deterministic nature of the game simulation coupled with the availability of all player inputs for the entire mission. While this information previously was always available, it is now with the latest network architecture only available for local games (1-4 players).
Previously it also worked in the networked case as Peer2 (the legacy architecture) was based on all players (eventually) getting all inputs for the mission in order to independently converge the simulation to a common place. This meant that replays could be recorded for network games just like for local games.
CLSV1 (the new architecture) doesn't rely on nor guarantee that all player inputs arrive at all player nodes, so replays cannot be stored and hence the simulation cannot be played back. Couple this with the complexity of players potentially coming and going at any time during a mission and you can see why things immediately get very complicated.
To be completely accurate the host / server is there for the entire mission and for all potential comings and goings of remote players / clients, so replays COULD be recorded on host machines. Right now however no network game is recorded regardless, but if someone really really wants the ability to record replays on the host this could be considered in the future; yell at me in the forums.
Party level options
From a "vibe" perspective SBTF runs the risk of changing a bit with the addition of drop-in / drop-out capabilities, as the game as originally envisioned is really about the player having a single chance at tackling a level, with death completely wiping all character progression (permadeath).
The addition of the reinforcement option a while back was originally intended to increase "time in combat" for all players, since dying in a multiplayer game originally meant that you had to sit around waiting for the next mission. This was also a serious problem since a dead player who didn't want to wait around and left the game would tear the mission down for everyone remaining; again, this has now been fixed with the new network architecture.
I am however aware of the "change in flavor" that an option like reinforcements brings to SBTF, and that some players really don't like how it undermines the "hardcore-ness" of the game as played without reinforcements. In the interest of both increasing accessibility of the multiplayer SBTF experience (which reinforcements is an example of) while not completely alienating the hardcore players, I have implemented the concept of "Party Options".
Party Options are separate from Seed / Plan / Rules settings, being as they are at a bit of a higher level and logically more related to the intended play style of the party as a whole. All of these options are available via the Advanced Config screen when setting up a mission, and the new Party Options are as follows:
- Public / Private: As has always existed, you can set the party to accept anyone or just your Steam Friends. This option defaults to public (everyone allowed).
- Friendly Fire: This new option allows for the damage caused to players by other players' weapons fire to be turned off. Note that even when damage is off, all other disorienting effects like aim disruption and screen flash still occur, you will simply not take any electronics systems damage. This option defaults to on (players damage each other)
- Reinforcements: As before, when this is on dead players will be reinforced with fresh characters after 30 seconds. This defaults to on (dead players will be reinforced).
With these changes an even higher degree of customization of the SBTF experience is possible. Most notably this solves the issue of Randomize All randomizing the Reinforcements option, as it is now a party level option and not a mission level (rules) option (Randomize All does not affect Party Options).
The state of Party Options are clearly visible in the party list, hopefully aiding players in selecting the kind of experience they want.
Edge cases and (un?)expected behavior
One thing that is probably not as expected is that a player dropping into a mission in progress will always result in that player spawning immediately, regardless of mission status / reinforcement enabled or not / timings, etc. This is because any other behavior introduces a new state for the player, namely "in the mission but yet to be alive". I'm assuming that players would expect reinforcement rules to be respected (in that if reinforcements are off then players dropping in will NOT spawn), but all the permutations of this are not trivial.
For example I definitely don't want to allow private/friends-only parties with reinforcements OFF to disallow drop-in; that would completely invalidate most of the work that I've been doing these past months and the goal of making the game more inclusive. Even in the case of a friends-only game without reinforcements I want a group of friends to be able to start at any time without waiting for all participants, and then have more friends come to (and go from) the party later at any time (in-mission or not).
Another example is a public game with reinforcements ON that is in-mission, and then a new player drops-in. Should that player automatically have to wait 30 seconds (reinforcement delay) AFTER loading the mission to join play, or is that just irritating?
If the expected behavior in such cases turns out to be that we want the mentioned "in the mission but yet to be alive" / "observer" state for players then that will be implemented, but at the moment there are so many new permutations and play styles emerging from all these changes that I think the community needs to get a feel for it first; that's why I'm keeping things simple for now.
There are also probably a lot of possible exploits regarding characters as well as reinforcement timings now that persistence is implemented for multiplayer characters. For example dying, dropping out, and then dropping back in will currently probably restore the dead character as well as potentially circumvent the reinforcement delay. The expected behaviors in all of these edge cases need to be explored.
Miscellaneous
- Repair stations will now repair as many systems as possible in single go (depending on how much is damaged and how many uses remain in the station). The pre-interaction prompt displays damaged systems to be repaired, and the post-interaction prompt displays systems that were repaired.
- Infravision use now longer drains the battery 4x normal, which should hopefully see more use of this upgrade.
- Ammo reload rate per science level has been lowered from 5 to 3.
- Enemies present in the airlock at the time of reinforcement are silently and invisibly removed, in order to allow the player to at least get their bearings before (potentially) being murdered right outside the airlock instead... :P
- Because of the ability to join missions in progress, it is now possible to select desired weapon loadout even before joining a party (the option also remains in the party lobby).
- There is now only a single button for hosting a party from the pub. The default is always to start a public party, with the new party level options available for modification once in the configuration screen.
- Mission configs are now bit-packed (all options in 32 bits), and strings are now of the format: SEED|OPTIONS, for example DEADFACE|0068FACE.
- Sentries are now a Plan option instead of a Rules option since it is an immutable part of the mission.
- Invert Barriers now properly affects lab doors.
- Door Chance now properly affects lab doors.
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