From a developer point of view we wanted to try to find a way to move the players' eyes back to the main 3d view without completely precluding SOME kind of targeting aid. To this effect we have removed the Auto-Aim upgrade and replaced it with what we call Aim-Assist.
Aim-Assist does not perform any kind of automatic aiming or control of projectiles, but instead is a kind of HUD-space overlay to the action that is going on in the main view. Threats are rendered with an outline (in the color of the HUD) that overlays all 3d rendering, regardless of depth, and can be conceptually thought of as being "in the glass" of the helmet visor.
The goal here is mainly to require manual aiming again, but also try to help the player sort through the massive amount of information that is going on. Aim-Assist requires some getting used to, but with practice it does indeed help you to pick out and target threats through all the chaos.
We certainly anticipate some contention around this change, but please do your best to fairly evaluate if it indeed does the intended job of keeping the the game a first person shooter as opposed to a top-down shooter.
Also note that Aim-Assist and Infravision are mutually exclusive; when one is enabled the other is disabled.
Another good thing that came out of Aim-Assist rendering work is that the Infravision modes no longer color the entire screen, but conceptually now only affect things that are "outside" the helmet / "beyond" the visor. This also means that Downsampling and Brightness options only affect things "outside" the helmet / "beyond" the visor as well.
Positional Audio The changes to the Creep behaviour in Update 20 prompted us to do an initial pass on positional audio in order to make locating approaching Creeps more intuitive. Creep audio cues are now also monophonic and propely panned (along with many other audio sources) to give you a better sense of where they are in relation to your position and heading.
As always, thank you for your support and patience,
/nornware AB c/o johno
Hello all! We are happy to announce a new update to Space Beast Terror Fright.
New Astro-Creeps Behaviour We have changed Astro-Creeps to be both aggressive and dangerous; they will now attack the closest player in line of sight, and once attached they will cause electronics systems damage at random rates.
You definitely still have the chance to shoot them off, but you must be quick as to not be damaged. An attached Creep will eventually cause total systems damage and ultimately death to a player who does not react in time.
In addition to this Creeps also travel faster and are harder to shoot; there was a bug in the collision code where the Creeps used the same radius as Beasts. This has now been corrected. Interestingly enough it may be perceived that Creeps actually try to dodge your bullets, but this is not actually the case; this is an artifact of the way that Creeps try to stay close to surfaces and will jump between them if necessary.
Due to the increased aggression, each spawn event will now create 1 Beast and randomly between 0 -> 2 Creeps, whereas previously each spawn event would create 1 Beast and 4 Creeps.
There is also a new audio cue to indicate that a Creep has you in line of sight, and it occupies a generally higher frequency range than the procedural music. Keep in mind that intense music means that Beasts are near but not necessarily in line of sight (unless you are playing on Mazes), while the new "horror / scrabbling" cue indicates that a Creep is moving to attack you with direct line of sight.
We feel that this clear differentiation of audio cues are a critical part of further informing the player what is going on in the mission. In future the new Creep cue is a strong candidate for panning / better spatialization, so as to further allow the player to make correct judgments about where the threats are.
All in all these changes make for a FAR more intense experience than when Creeps were semi-passive. It is indeed still possible to complete a mission, but it is definitely harder than before. We anticipate that new gameplay systems will probably have to be developed in order to balance difficulty overall as a result of this (and other) changes, but as we very much like the general chaos that these new dangerous Creeps bring we will take things one step at a time.
For those who do not like Astro-Creeps and / or are even further put off by these new changes, it is still possible to turn them off in the advanced mission settings. Astro-Creeps are still on by default.
New Beast Blood As a result of discussions in the community about red blood vs other colors, iterations led to the change of Beast / Creep blood from red to green / yellow (modeled much after the classic Giger's Alien blood from films and games). While not actually "acid for blood", we found the look to be much more suitable in conveying the "alienness" of the Beasts and Creeps, and in general it also seems to work much better color-wise when applied to level textures. Player blood is however still red in those cases it occurs.
Blood Drips A new effect that is used in conjunction with both Beast and player blood is blood / gore dripping from the ceiling. This occurs for a time after a Beast or player has been killed in a certain grid square, and falls off with time. Any new deaths in this space will "refresh" the drips. The sum effect is that the cramped corridors feel much more messy and disgusting, and we feel this complements the general violence of what is going on in the game in a good way.
It is true that the blood drips tend to obscure vision even more than before. These are on by default but may be disabled as doing so may increase rendering performance.
PLEASE NOTE that as these options did not exist before, you will have to turn them on manually and / or reset your options to defaults.
Smoking Gibs Another new effect is the addition of smoke particles to all Beast and player "gibs". These continuously spawn from the time a death occurs (and the gibs are created) to some time after the gibs have come to rest. Additionally smoking gibs will "sizzle" audibly. We feel this also conveys a better sense of the energy being expended.
It is true that the smoking gibs tend to obscure vision even more than before. These are on by default but may be disabled as doing so may increase rendering performance.
PLEASE NOTE that as these options did not exist before, you will have to turn them on manually and / or reset your options to defaults.
Options Update All Video options in the Options menu have been reorganized into Options and Video sections. In general all of these settings may directly affect rendering performance, but those that are under Options are more in the vein of player preference, while those under Video are more purely technical. Or something like that.
There are new options for Gibs Smoke as well as Blood Drips. PLEASE NOTE that as these options did not exist before, you will have to turn them on manually and / or reset your options to defaults.
In general we would like to limit the number of options as much as possible in order to keep the experience as close to our vision as possible, but that is somewhat of a slippery slope when it comes to some of the more extreme things we are doing (like the FOV effects). In general we will probably always include options for things that may significantly affect rendering performance. Again, note that resetting options to defaults reflects our design intentions.
Less Noise In Infravision Infravision noise has been reduced in the "bad" case, meaning when the battery is completely drained. We find this makes the Infravision a bit more usable.
As always, thank you for your support and patience,
/nornware AB c/o johno
Hello all! We are happy to announce a new update to Space Beast Terror Fright.
New Weapon(s) - Hammer(s) Prior to adding the Razor weapon we set out to do experiments with some kind of typical "minigun" type weapon with a high rate of fire and the penalty of a spin-up time. We quickly realized that there were at least two weapons in there; just the high rate of fire without any kind of spin-up penalty made for a very fun weapon, and that is how the Razor emerged. As you know it fires 25% faster than the Rifle and does 25% less damage.
The "other weapon" was intended to be the aforementioned "minigun", but the more we played with it the more we realized the necessity of being able to fire as fast as you can react in a game like SBTF. The Shotgun already has the caveat of having a low rate of fire, but as long as you aren't currently firing continuously you can basically react to anything and fire immediately.
This caused us to drop the idea of the spin-up, which in itself felt cool and sounded cool, but it wasn't something that you would necessarily want to play with. The rate of fire was initially 200% of the Rifle, and while this was awesome and crazy, the sum of everything didn't make for a very useful weapon. We speculated that it might be good in a team situation, but we also reasoned that every weapon should be a viable option for solo play as well.
All of this led us to a new iteration on what we wanted to be our "heavy" weapon, and we finally nailed the name; Hammer. We reasoned that if higher rates of fire required a caveat other than a spin-up or reduced damage (which we felt was wrong for something that was "heavy"), then we would have to go the other direction. We figured we could do something halfway between the Rifle and the Shotgun, and then we realized we could do EXACTLY that; the Hammer (4x) fires 4 rounds per shot, and has 1/4th the rate of fire of the Rifle (and 2x the rate of fire of the shotgun).
This proved workable and mathematically solid in terms of damage output over time, but after a while we started messing with the concept some more and tried a Hammer (2x) that fires 2 rounds per shot and has 1/2 the rate of fire of the Rifle. This ALSO felt awesome, but in a different way, so in the end we simply decided to throw both versions into the game and differentiate between them simply by paint job. Hammer (2x) is red, and Hammer (4x) is green.
A significant difference also is that the Hammer fires tightly grouped shots that do not spread like the Shotgun. This has proven to allow the Hammer to be used as a high-powered sniping weapon, especially in the case of the Hammer (4x), as for example 4 rounds of green ammo striking a single target does an enormous amount of damage and has the potential to penetrate / pass through quite far. We never intended to implement a "rail gun" per se, but the Hammer (4x) comes close.
We are thinking that the community should have the opportunity of speaking there mind on this. Should we have the Hammer (2x), the Hammer (4x), or both? If we indeed do keep both it is probable that we will differentiate the visuals and audio further in order to reinforce the different feels of the two. Hammers now, as well as the Razor, have custom target reticles.
New Music Themes
"Agren" by johno.
"Desperation" by Billy Swartzel.
We have also (in most cases) switched back to the original logic for music mixing, which is based on the distance between the player and the nearest Beast. We have been running with code that also takes line-of-sight into account for a while now, but we felt that this resulted in the music being pushed down to much. This also had the effect of removing some important audio queues that the player originally got, and we think that the game became more difficult as a direct result of this.
The original reason for adding the line-of-sight check was because we felt that the music mix in Mazes was too aggressive. Since then I have decided to be pragmatic over dogmatic, so the line-of-sight check is now only used when Mazes is the current Plan, and the original distance based code is used for everything else.
Miscellaneous
Fixed chat linebreaking for extremely long words (without spaces).
The layout of party screens has been adjusted to minimize overlap with the chat feed.
Auto-targeting indicator is now rendered using gui text instead of being baked into the reticle icon.
Razor and Hammer weapons now have custom reticles.
Frustum culling has been fixed to take field of view into account, there should be fewer instances of cores disappearing at the edges of the screen when adrenaline (and hence field of view) is high.
We are currently also using an experimental pre-calculated Potentially Visible Set to aid in culling. This has been seen to have some bad edge cases where you might see a stray core or door pop in and out erroneously, but we are working on making that more solid. The PVS helps greatly to improve performance, as it allows us to cull out things that are behind walls very efficiently.
Pending Research Much time has been put into research of deferred rendering / light pre-pass. The goal was to switch to a more modern renderer approach that allows for more flexibility when it comes to dynamic lights, thereby enabling one flashlight per player as well as more dynamic lights for things like bullets flying around.
We have chosen to defer (haha) the use of that research for the time being, because the performance tradeoffs aren't completely clear at this time, and we think it's important to not significantly increase the system requirements of the game. Some kind of hybrid approach between what we are currently doing (textured / baked lighting) and a deferred / light pre-pass solution may well emerge in the future, so that we can reach our goal of more dynamic lights without requiring too much more of the CPU / GPU than is the current case.
Planning for exiting Early Access Much more can be said on this matter than will be mentioned here, but we are currently doing final cuts and planning for the longer term, with the ultimate goal of getting out of Early Access and to an official release.
Once the plan is more or less established we want to make some kind of road-map publicly visible but have yet to figure out what the best (and most honest / up to date) way to do it might be. More on that as it emerges.
With that in mind however, now is the time to post suggestions on things you are missing in the game and that haven't really been discussed yet. It has indeed happened before that we have implemented community ideas verbatim, and may well happen again if someone comes up with some good stuff that is in sync with our goals.
As always, thank you for your support and patience,
/nornware AB c/o johno
Hello all! We are happy to announce a new update to Space Beast Terror Fright.
Public and Party Chat In-Mission It is now possible to access both Public and Party chat when in a (networked) mission by pressing ENTER. Note that all interactions except view changes are disabled while chat input is enabled. Press ENTER again to return to normal play mode. It is not possible to access the chat system when playing with an XBox 360 controller.
New Networked Multiplayer Screen Configurations We have implemented a number of screen-split options for networked multiplayer, as follows:
1: Single Player Fullscreen This is the typical fullscreen view, showing a single player's view with text based indicators to the right showing the status of any other players. We have updated these indicators to show both character name and player name. Chat is available on the lower left to the right of the mission log. Note that the chat is limited to 5 messages.
Access: 1 on keyboard / UP on XBox 360 Controller DPAD.
2: Single Player Fullscreen with Picture-in-Picture Same as 1 with the addition of all other player views showing up to the right adjacent to their textual indicators.
Access: 2 on keyboard / RIGHT on XBox 360 Controller DPAD.
3: Community Split The main player view is somewhat downsized and centered at the top, with all other players below. The community chat is exposed in the same way as in the network lobby and pre-mission party screens, including players online.
Access: 3 on keyboard / DOWN on XBox 360 Controller DPAD.
4: Team Split This is the same as the local co-op split, with configuration depending on the number of players in the mission.
Access: 4 on keyboard / LEFT on XBox 360 Controller DPAD.
All of these configurations are freely available at any time when a player is alive or dead, with the exception of live players in a Deathmatch mission which are locked to configuration 1 until they are killed.
Once a player is killed it also becomes possible to select what player to track as the "main" player. This applies to configurations 1, 2, and 3. Use keyboard hotkeys F1 - F4 / XBox 360 buttons A, B, X, Y (color coded to player colors) to choose which player to track.
We have also updated the "dead player" display to both show who was killed (with the correct player color) as well as cause of death. If the player was killed by another player, this is also color coded.
Miscellaneous
We have restored the audio and video options that were accidentally remove in Update 17.
An audio cue is now played when chat messages arrive.
Player weapon selections are now hidden when in the pre-mission Deathmatch screens.
As always, thank you for your support and patience,
/nornware AB c/o johno
Hello all! We are happy to announce a new update to Space Beast Terror Fright.
New Game Mode : Deathmatch Immediately following the Update 16 we were feeling a bit burnt out, so we decided to try to hack together a quick and dirty alternate game mode just for fun. We have had several such modes in mind, but we decided to try a Player vs Player mode, and it turned out pretty well. We're calling it Deathmatch so people will know what it is about; basically it's Player vs Player and the winner is the last one alive.
Beasts, Creeps and Sentries are all disabled in Deathmatch, and the player flashlight and emissive textures on the player models are turned off. Toggling the split-screen team view is also disabled. All of this amounts to a very tense experience, where you tend to try to be as quiet as possible and use all your senses to determine where the other players are.
True to our typical form a player only has a single life, but you can take the usual amount of bullet hits resulting in electronics damage before you are killed. Repair Stations are available so that you have a change to recover from this damage.
Datacores are as usual, with all upgrades available, but in Deathmatch only the player who actually downloads gets an upgrade (no sharing). Other players do not show up as icons in the tracker / map in this mode, but they do instead trigger the motion tracker in the same way as Beasts and Creeps. It is of course very useful to have the various Motion Tracker upgrades, but skilled players will know when to stand still to counter this.
Because you are shooting at other players the various ammo types matter less, as each hit only knocks out a single electronics system. This means that you may want to stick to orange ammo, as this gives the best rate of fire, but there is a caveat; we have enabled ricochets for all player bullets in all game modes. As a result, higher ammo types (with more energy) will ricochet more, and it is therefore possible to shoot quite effectively around corners.
These player bullet ricochets are a tweaked version of what the Sentry bullets do, and behave in a somewhat more realistic fashion. Don't worry, it isn't possible to cause your own bullets to ricochet straight back at you as they take the angle of incidence into account. Player bullets will behave in a consistent manner, and it is posible to become quite skilled at aiming ricochets. Also, after careful playtesting we decided to leave the Sentry bullets as they were, simply because we think the crazy Sentry ricochets are a lot of fun; they can still reflect straight back from a wall.
We have also added much more feedback to the effects of any bullets that hit a player, as Deathmatch needed more explicit hit feedback. These effects are always enabled, and you will see them in all game modes.
All in all we've been having a lot of fun with Deathmatch during internal testing, and we have found it to be an even more tense experience than playing vs Beasts. Long stretches of silence and sneaking often end in furious firefights where all players are unsure of exactly what is going on. Not for the faint of heart!
Oh yes, as a result of there being two official game modes now, we have renamed the previous mode "Breaches" to "Salvage". We have also added a quick selector for game mode to the basic party screen, as well as a number of new statistics that are displayed in accordance with the selected game mode.
New Weapon : Razor We have added a new weapon, the Razor. This is basically a rapid fire version of the Rifle, firing bullets 25% faster. The trade is that the Razor also does 25% less damage. Bullets fired from the Razor will push Beasts exactly the same amount as all other bullets, and in conjunction with the higher rate of fire this allows the Razor to still be viable option regardless of the lower damage per bullet. The Razor also has a slightly smaller muzzle flare than the Rifle.
We have yet to determine what the best weapon for Deathmatch might be...
Miscellaneous
Any bullets that aren't fired by the a given player will register as motion (in the tracker), and boost adrenaline in the same way as other motion. Try firing a Razor next to another player...
Other Things That We've Been Doing And Might Implement Later
We've done some resarch into Physically Based Rendering, and are considering switching our renderer and materials to use that approach.
We've been trying out some VERY speculative alternative user interface schemes, based on 3-dimensional hexagons. Very cool, but still requires a bit of work and evaluation, and we want to prioritize gameplay features right now.
As always, thank you for your support and patience,
/nornware AB c/o johno
Hello all! We are happy to announce a new update to Space Beast Terror Fright.
Public / Private Parties Are Back Following Early Access Update 15 yesterday the community immediately made it clear that we needed to re-implement the ability to have both public and private (friends only) parties. The reasons that it went away are technical and involve how we are leveraging the Steam Lobby system, but we understand that the last update could be viewed as a regression.
What we have added is simply a public / private toggle to the pre-mission screen, which can be set at any time by the party owner. Anyone can join a public party. The rules for private parties are the same as before, meaning that as long as you are Steam Friends with someone in the party, you will be able to join it. Changing a public game to private whilst non-Steam Friends are in the party will simply kick them out.
Some small changes have been also been made to the online player list, so now it shows Steam Friends (including yourself) first, followed by all other players. Players in a party are shown in orange, while players not in a party are blue.
The list of parties will now also indicated public / private state, number of players, and mission state. You can as before only join a party that is in the "pre-mission" state.
We are trying our best to keep all of this configuration stuff as simple as possible. As always we appreciate feedback, so please let us know in the forums if there are features that you are missing.
As always, thank you for your support and patience,
/nornware AB c/o johno
Hello all! We are happy to announce a new update to Space Beast Terror Fright.
Multiplayer Community Features The community has noted that the process of finding other players is a bit "blind", and as a result we have done a big overhaul on how all of that stuff works.
The main visible change is that once a network is selected, all players are automatically placed in a single big "public chat room". You can see all the players that are currently in the chat, get messages when they join and leave, and other typical stuff. When you type a message in the public chat, all players will see it. Currently you are limited to basic ASCII characters (English alphabet, numerals, some punctuation).
The networks available are:
Local Area Network (LAN) - All players on the local D-network.
Steam Public - All players using Steam.
In both cases everyone in the network can see and join any party.
The Steam Friends option (parties only visible to Steam Friends) has been removed. We can / may in future add further controls to manage who is allowed in your party as required / discovered, but initially we simply want to make the process of finding players much easier.
Parties are conceptually the same as before, in that you can create and join them freely, with up to 4 players per party / mission. Once in a party you can toggle between public and party chat using the TAB key. One important change is that the player who creates the party is the one and only party owner, and if this player leaves the party all other players will be pushed out. There are uninteresting technical reasons for this.
A significant benefit of the underlying solution is that your multiplayer character is bound to your Steam ID, not to your slot in a party. This means that as long as you stay in the network, regardless of party, your character will stick to you. For example you can take your character with you even if you change parties. In future we hope to improve this even more by saving your multiplayer character to disk, so you can keep it indefinitely (unless of course your character is killed).
The in-mission system has not changed other than ANY aborts, disconnects or crashes from the mission by ANY party member will drop everyone back to the pre-mission screens. This is the same as a single player mission abort, and characters will revert to the state they were prior to the mission, as if the mission never took place. There are again uninteresting technical reasons to why we cannot support player drops from a mission in progress, but hopefully we will be able to handle this case in the future.
Also note that there is no chat available in-mission yet, but we have grand plans for such, with much better screen splitting, player tracking, and other options for use with networked multiplayer missions. Coming soon.
Miscellaneous
We have adjusted the download time upgrades to the following: 10, 8, 6, 4, 2 seconds. We felt that the maximum upgrade of 1 second was a bit too fast.
Repair Stations are now enabled even when Sentries are disabled (Plan option). Repair Stations were originally disabled along with Sentries since player fire was initially always fatal to other players. Since we changed all projectiles to damage electronics before finally being fatal, we felt it was a good idea to have Repair Stations available in case of friendly fire incidents between players.
Pre-mission music is now shut off just prior to mission load, to avoid hitches / stuttering.
The help screen has been updated.
Right Mouse Button / R are now double mapped to "Interact with Cores".
Gamepads are polled on game startup, so the gamepads that are connected initially should be available on player selection.
Infravision is now disabled by default, so you must enable it manually after upgrade or on mission start.
Fixed some holes in level geometry.
Removed some lights in the "Ristretto" level style to make it generally darker.
As always, thank you for your support and patience,
/nornware AB c/o johno
Hello all! We are happy to announce a new update to Space Beast Terror Fright.
Performance Optimizations This update is basically all about further optimizing general performance, as a follow up to the previous update that was focused on network performance. As many of you know, our new network implementation increases the calculation load on the simulation, and as we started looking into general performance post the previous update we found that many of the changes we had made were sub-optimal.
We proceeded to implement a robust timing toolset and actually measure what was taking all the CPU time. This proved very effective, and we were able to significantly increase performance across the entire simulation.
Network Party Version Checking In preparation for upcoming work on the multiplayer game-finding experience, we have added version checking to the multiplayer parties. The game will notify you if an existing party is of the wrong version and not allow you to join that party. This will in general not happen when everyone is running the same version, but we require this for development as we will be doing tests using the same lobby system that the public deployment uses, and we need to avoid confusion while we are making changes.
Call For Volunteer Testers (Networked Multiplayer) As mentioned earlier we have discovered that Swedish internet infrastructure is awesome. This makes it rather difficult for us to accurately test networking performance on the internet at large. We have managed to do some testing between Sweden and North America with the gracious help of our friend Classic Billy, but we need more coverage.
For this reason we would at this time like to call out for more volunteers to help us make SBTF networking as robust as possible for international play. From time to time we will call on these volunteers to help us test pre-release versions of the game to make sure things are working smoothly. Requirements are as follows:
You own Space Beast Terror Fright.
You live outside of Sweden.
You are available on Steam relatively often and have time to help us test.
You have a microphone that enables you to chat with us while testing. We will be using the Steam Voice Chat system.
You speak English reasonably fluently.
If you are interested, please send the following information via email to: madeleine@nornware.com
Name
Steam Profile URL
Steam Account Name (this is the name you login with, NOT your profile name as this can be changed after the fact.)
City, Country, Time Zone
Further information will be supplied once you have been accepted as an internal tester.
Miscellaneous / Known Issues
Beast textures are now 4x higher resolution. We haven't really noticed the difference... :)
We suspect that there might be some intermittent latency spikes happening at the beginning of networked games. We have been unable to reliably reproduce this, and this is just one of the reasons we would appreciate the help of more international testers.
As always, thank you for your support and patience,
/nornware AB c/o johno
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
UPDATE: A patch is now online to fix the bad Ammo Capacity upgrade texts.
Hello all! We are happy to announce a new update to Space Beast Terror Fright.
Performance Improvements This update is mainly focused on improving rendering performance.
We have observed that many players are reporting increased slow-downs post Early Access Update 10, in which we introduced the Astro-Creeps. This makes some sense, as on a saturated level (maximum enemies) this results in twice the number of animated characters. Networked performance is also directly affected by this, not because of increase bandwidth, but because of the way the game is lock-step synchronized at present. See this post for more information on the technical aspects of this.
As a result we took some time to look at what could be optimized, and found that the way we were rendering static models (pipes, chairs, laptops, lockers, boxes, etc) was rather suboptimal. Especially in big Mazes maps we were seeing a very high count of invididual models. After some experiments we decided to optimize some models and to consolidate all of these model instances into "baked" world meshes, and draw them via the same pipeline that the walls, ceilings and floors are being rendered by. Since we are now baking everything, we will continue to look into opportunities to reduce vertex and triangle counts on all environment models, both present and future.
This change results both in far fewer render calls and also submits larger batches to the GPU, both which are good things. In addition we looked into opportunites to do tighter camera culling on the various pieces of the world, and found many opportunities to further reduce render calls based on where the player happens to be looking.
All in all we have reduced render calls for the in-mission scene by at least 50%, and in some cases by as much as 90%. While we have limited capacity to test these changes on a broad range of hardware, theoretically this should be a big win for all GPUs. Obviously we cannot guarantee anything, and players who are having performance issues should still experiment with the various visual options.
At the moment the game still runs on DirectX 9.0c but with all shaders on shader model 2, a profile that is at least ten years out of date. While we like to have the system requirements as low as possible, we are considering implementing hardware geometry instancing in the future to make even better use of available GPU horsepower. The main reason for this is that we still have a large category of objects (aniamted doors and cores) that are still being rendered relatively inefficiently. This change will require shader model 3 hardware, but even this isn't a very high end requirement these days. In any case the code will still have a fallback to shader model 2 (the current system) for GPUs that cannot support geometry instancing.
Reduced Ammo Capacities We have been seeing games with a high excess of ammo carried over between missions, and as an experiment we have adjusted the ammo capacity upgrades to the following:
No Upgrade - 500 rounds
Ammo Capacity 1 - 750 rounds
Ammo Capacity 2 - 1000 rounds
Ammo Capacity 3 - 1250 rounds
Ammo Capacity 4 - 1500 rounds
Initial tests indicate that this change makes better use of the available Armories.
Increased Repair Usage We have changed Repair stations from single use to 4 uses.
Electronics Damage Repair Priority While HUD electronics are still damaged randomly, Repair stations will now prioritize repairs in the following order:
SYS_TEXT
SYS_FLASHLIGHT
SYS_TRACKER_MAP
SYS_VISOR_ICONS
SYS_WEAPON_DISPLAY
SYS_INFRAVISION
Miscellaneous
The advanced party settings configuration is now properly synchronized to non-owner party members.
The advanced party settings configuration now shows all options for non-owner party members.
Various polish and material adjustments to our level styles.
Sparks have been optimized and now bounce in a more realistic fashion.
Our Plan Moving Forward - Improved Networking We interpret the need for improved long distance internet network play to be a very high priority among our players. We have had a rough technical plan of what to try out in order to improve the quality of the experience for some time now, and this will be our main focus in the immediate future.
As always, thank you for your support and patience,
/nornware AB c/o johno
