nornware AB is happy to announce a new update to Space Beast Terror Fright.
USER PLANS I've implemented first pass support for user created plans (the data that generates a mission). The editor is completely integrated into the game and is available via the main menu, where you can build your levels / campaigns at your own pace and later bring them into your local or networked games in a simple fashion.
Creating user plans basically entails manually editing the same data that the legacy mission generation algorithm manipulates; a 33x33 grid of cells. Starting from a default template that is guaranteed to fulfill all gameplay constraints you can carve out open spaces (floors), put up additional walls, place elements like datacores, armories, sentries, etc, as well as choosing all relevant rules settings and the visual style of the mission. Once saved user plans are available for play via the mission setup interface.
This is deceptively simple, as manual editing of plans allows you to potentially create quite a broad range of experiences beyond what has been available in the game to date. There are quite a few constraints on what is legal in order for gameplay to function, but I've implemented a full suite of tests that run in real-time on the data, and the editor will show you exactly what is wrong with your creation with information about how to fix it. There is even a button that can fix a lot of the problems for you automatically. Note that you are not allowed to save a user plan when errors exist; this is indeed to make ensure that all plans that are available for play are possible to complete.
With that said I've decided to relax some of legacy constraints in user plans that the procedurally generated plans still abide by in order to give hand-made missions a bit more flexibility in combining various visual themes. Missions have always had a main wall/floor look as well as an "alternate" that has only shown up in rare cases (filled rooms), and also of course the "lab" look. User plans will allow these to exist side by side in ways that players will not have seen previously.
This incidentally touches on some work that I've been planning for a long time; namely re-visiting a lot of the level styles (geometry and texture themes) as well as including some new ones that I've already prototyped. In relaxing the constraints of what cell values are allowed to exist side by side I'm seeing a lot more holes in the level geometry than before, and that will definitely need to be tightened up. Beyond just the planned new graphical themes, I find the requirement of seamlessness motivates me even further to expand the visual diversity of SBTF.
Note that this update will only support loading and saving user-plans locally. This is because I have deemed the Steam Workshop integration (that I am still intending to do) as a sizeable chunk of work, and I think it's better to get the editor in the hands of the community as quickly as possible as issues will undoubtably crop up. I think there will always be value in the ability to work on your creations in isolation before deciding to share them with the world, so this isn't throwaway work.
The upside however is that user plans already work in networked games, so it is already possible to play your user-plans with other players if you host a party and select one of your creations to play. Don't see this as a stop-gap; it's an artifact of how the system works, and I don't expect this mechanism to change even moving forward as it is after all the party owner that decides all attributes of the plan to play (including this new feature of explicit user plans).
The benefits that potential Steam Workshop support brings is the ability to play ANY user-created plan that has been publicly shared by anyone, both locally and in networked games. I'm also thinking that it might be interesting to be able to create "user campaigns / playlists", meaning several user-created maps stringed together to cohesive units. I haven't looked into the technical details yet, but I'm assuming all of this will be possible to do within the scope of Steam Workshop.
While building the editor I also realized that bringing this kind of concentrated work to SBTF required some kind of "mood music", and so I'm currently experimenting with running the in-game themes at a low level of intensity. We'll see how that works out, it might need a dedicated volume slider...
POTENTIAL EDITOR GLITCHES Breaches cannot be placed manually but are automatically created at the end of dead-end corridors (unless Random Breaches is enabled) up to a limit of 16 per mission, and such valid Breach locations are indicated in the editor by a purple square. Note that you are allowed to have more than 16 valid Breach positions in your plans, but Breaches will only spawn from 16 of them.
Similarly, Doors and Fences are automatically rotated to fit the context they are in (unless they are in an invalid position, indicated by the cell flashing red).
All of this is done via a special lookup table that I must set up manually, and as such there may be cases where valid Breach locations aren't flagged correctly as well as cases where Doors or Fences aren't in the expected orientation. If you see anything like this please take a screenshot of the plan you are building in the editor and send it to contact@nornware.com and I will fix it.
MISSION SETUP SIMPLIFICATION I have collapsed the Basic and Advanced mission setup screens into a single screen, with both team stats and mission outcomes available now as mouse-over overlays. This has the effect of making a whole bunch of information available very quickly without being overly obstructive, while simultaneously streamlining and simplifying the meta-game flow for those who just want to get into the action.
MISCELLANEOUS
Reinforcements in Kit Mode now have the proper upgrades.
Fixed player low ammo warning in the mission log for guns that fire lots of bullets.
The game now attempts to detect and display the number of players in-game (single and multiplayer) at the top left of the screen. This information is from Steam internally, and is updated every ten seconds. While similar information was already available for players in multiplayer mode, I thought this might add a sense of community for all players without being overly intrusive.
As always, thank you for your support and patience. /nornware AB c/o johno
nornware AB is happy to announce a new update to Space Beast Terror Fright.
HOTFIX BUILD A hotfix build is now online (build id: 5D6BC610) that addresses the following issues identified in Early Access Update 48:
The display of remaining time in the current Campaign of the Week (CotW) has been corrected. Note that campaigns start on Mondays and use ISO week dates based on UTC without taking daylight savings time into account.
Long names on the Campaign of the Week leaderboards are now elided as to not clip into the medals.
KEYBINDING I have implemented the option to modify keybinding (applies to the keyboard + mouse input device for player 1). This functionality is accessed via the settings menu.
I had been shying away from this feature for a long time mainly because of the limitations of font / text / character rendering in SBTF. The game is limited to rendering a subset of ASCII, and hence cannot render Unicode. For non-english users, I was worried that it might be hard to visualize a keybinding interface if the player cannot see the key that is bound.
I am using Windows Virtual Keys to detect input, and found a table that identifies what all the virtual keys are named (in English). I simply used this table to name all the keys, and hope that this will suffice to make the feature work. In addition while in the settings menu you can press and hold any bound key and it will highlight the action that is bound to that key, even if the display of that key might be wrong for your input locale.
I would appreciate feedback in the forums on how this feature works for non-english keyboard layouts.
CAMPAIGN OF THE WEEK DIFFICULTY PROGRESSION As was suggested by the community, a few changes have been made to the difficulty progression of CoTW:
Armories now start at "more" and will eventually later change to "fewer" instead of the other way around. This does not strictly speaking making things more difficult over time, but the compelling argument is that failing later missions due to ammo depletion isn't very much fun.
The Difficulty setting will now progress as follows: easier, random all, random each, easier +, hard, hard +, insane. This progression is based on measuring the time it takes for a single / same map to become saturated with space beasts.
CAMPAIGN OF THE WEEK SCORING As was warranted, I received a lot of feedback on the scoring algorithm that was deployed along with Campign of the Week (CotW). As some players are aware, I had simply used the existing experience calculation verbatim as the "score" for a CotW run. There are multiple reasons why this is sub-optimal and encourages some weird behaviour in the pursuit of the highest scores.
I realized that a scoring scheme very much emphasizes the "intent" of how the player should be acting from a design perspective, and as such I considered what I wanted CotW to be about. After many iterations I realized that I should be awarding the player for achieving the objectives as presented by the main game itself; for download datacores, disable coolants, and escaping the ship.
By awarding score for only these things, it is indeed true that any players that complete a certain number of missions will achieve exactly the same score. That might seem like a bad design, but it enforces my intent of having CotW be about progression; the player who "progresses" the furthest in the campaign should be the one who wins the CotW. Furthermore, awarding points for each datacore and coolant achieves a more fine grained way to measure progression in the campaign, as you can of course die at any time after achieving any number of objectives.
In addition to points for the main objectives, I am also awarding points for fully opening the reactor shield (required), opening panic rooms (optional), and for rescuing scientists (optional). The reactor shield score is again in line with my intent of progression, because if you manage to open the reactor shield before dying you will achieve more points than if you didn't. The hunt for scientists is of course not required to complete any mission, but they seemed like a good source of potential additional points for those players who take the risk of going for them.
The new CotW scoring calculation is as follows:
coolant disabled: 100 points
datacore downloaded: 100 points
escaped the mission: 1000 points
opened a panic room: 10 points
rescued a scientist: 100 points
opened the reactor shield (fully): 10 points
Of course most activities in SBTF have additional benefits aside from score that directly affect your survivability (such as getting upgrades from datacores, using fences and sentries, repairing damage, upgrading ammo by rescuing scientists, etc), so the game is still full of a lot of interesting trade-offs that will conspire to affect your ultimate progression in CotW.
As always, this new scoring algorithm is a just a theory. It has survived some internal discussion as well as implementation and initial playtesting, but of course the true test is deploying it live to see how the community reacts. Feedback is always welcome.
NOTE: How potential tied scores are ordered is an internal detail of the Steam Leaderboards backend. We'll have to see how this plays out.
CAMPAIGN OF THE WEEK LEADERBOARDS SCREEN I've added an explicit leaderboards screen for past and current Campaigns of the Week. Because bragging rights. This is accessible via the main menu.
In this screen it is possible to browse all past campaigns as well as the current one and see the scores for each. The top three players are displayed using Steam avatars and names on classic gold, silver, and bronze medals. Note that for the current CotW standings will change as new scores are submitted.
MISCELLANEOUS
The airlock cell in the tracker / map is now white instead of the regular floor color.
As SBTF font rendering is limited to a subset of ASCII, unicode / illegal characters are now rendered as question marks.
As a result of new Campaign of the Week scoring, some character statistics have been generalized; your persisted characters may be affected.
When loading the local team data, the game will reset your current CotW attempt if that attempt was started prior or later to the current week, as well as if it was tampered with in any way (hash check). The game will display a relevant notice if this happens.
As always, thank you for your support and patience.
/nornware AB c/o johno
nornware AB is happy to announce a new update to Space Beast Terror Fright.
PUB PARTY LAYOUT / GRID / LIVE MAP I have created an alternative layout for viewing available parties, namely a grid in addition to the legacy list. The main reason for this is that I realized I could make live information available about missions in progress to everyone, not only the players in the mission. It's now possible to "watch" up to 15 missions in progress on the grid screen (15 is what fits), or a zoomed in version of any single mission.
The in-mission information available is of course not "full" information (as you have when you are actually playing), but a compressed and stylized version that looks similar to the plan previews already available in the mission settings screens. It almost looks like a classic ASCII rogue-like.
Even when not in-mission, more information about current settings for each party can fit in the grid mode than can fit in the list mode.
Of course all of this is highly experimental, but I thought it would be cool to get a better sense of what is happening in the entire multiplayer community at a glance.
CAMPAIGN OF THE WEEK / MISSION OF THE DAY For a long time now I've been contemplating adding more high-level variation to SBTF, specifically an idea I've had for ages I call "Campaign of the Week" (CotW). "Mission of the Day" (MotD) has been in the game for a long time now, but one of the main realizations that came out of that system as well as the legacy single mission leaderboards is my firm belief that for a leaderboard to be meaningful the game has to be practically infinite. This is required so that players may play as long as they are able, achieving as high a score as possible.
I realized that this would be possible to implement; choose a "campaign seed" instead of just a single mission seed and use that to deterministically generate an infinite sequence of missions. That way a leaderboard could be made meaningful again, because it would be tied to the specific campaign which in itself is infinite. Add to that the modern trend of having "seasons" in games (in this case a "season" is only a week) and perhaps we have a compelling and recurring challenge for the community. After all, once the week is over, you can no longer submit high scores to that campaign, and hence someone will "win" that campaign by getting the furthest and achieving the highest score = permanent bragging rights.
The current implementation is of course quite experimental, but it includes some new map generation tweaks that allow for campaign missions to start off small and increase both in size and difficulty as the campaign progresses. All of this can surely be improved upon, but the general feel at the moment is pretty good. In particular I felt quite strongly that the early missions need to be quite small in order to be possible to complete quickly, because player investment in CotW is quite bit more that in legacy modes; if you die you not only lose your character and upgrades, but if you want to continue the campaign you need to play it from the beginning again.
Of course for this to be reasonable you are indeed allowed to attack the campaign over several play sessions, with your progress being saved after each successful mission. Your score is also submitted upon the completion of every mission, and is always replaced with any higher scores that may come later.
CotW leaderboards are only for single player / local, but it is possible to play CotW in network mode. The use cases are a bit different, as characters in networked games come across the wire, and I didn't want to get into the complexity of securely tracking multi-user CotW attempts. I also realize that this is really one of the first pseudo-player-vs-player features of SBTF, so I have taken some steps to make sure submitted scores for CotW are legitimate (potential bugs aside).
Mission of the Day (MotD) is still there, but has been moved into the mission setup screens, so it is hence also possible now to play MotD in networked mode. MotD will track completion locally as well, so you will see an record of this in the user interface.
In order to make all the legacy modes (Random Seed, Explicit Seed, Randomize All) able to exist alongside both CotW and MotD, there are now several characters and science values persisted for both local and network modes. It was important to me to make sure that switching modes back and forth didn't corrupt any potential CotW in-progress, and of course each mode has specific implications for how characters work. The legacy modes all share the same characters and science (as before), while CotW has its' own copies. MotD generates a new character (and 0 science) for each attempt, so nothing is persisted for that mode. Weapon loadout is however global (per player slot) across all modes.
"KIT MODE" PROTOTYPE While working out the implications of Campaign of The Week and in general preparing the game for more user customization I realized that it might be interesting to have a mode where you specifically select what upgrades you had going into a mission. I personally like fast and crazy SBTF that Randomize All tends to offer, so I tried a mode based on Randomize All but where you also always start the mission with the following upgrades:
AMMO CAPACITY: 900 rounds
DOWNLOAD TIME: 2 seconds
BATTERY LIFE: 180 seconds
BATTERY CHARGE: 12.5 seconds / second
MOTION TRACKER: directional + scientists
PATHFINDER: airlock
AIM ASSIST
I found that this combination encouraged very fast play (fast downloads / activations / repairs), as well as the option to rescue scientists with perfect information (including being able to find the airlock easily). I specifically chose a motion tracker combo that isn't available in regular modes (you would normally have all motion tracker features once you get scientists) that gives you a little bit of a hint (directional) while still forcing you to keep your eyes on the action. To this end I also added aim-assist to the mix.
I also added the rule that in kit mode, by its' very nature, datacores will not give you any upgrades at all; you start the mission with the "kit" that I designed.
What I wasn't prepared for was the emergence of mistakes being quite punishing. Due to the recent addition of the rule that non-fatal damage may randomly knock out upgrades instead of repairable systems, the effect of losing your upgrades is permanent within the scope of the current mission. Also interesting was that because I had only set the upgrade bits for the specific upgrades I wanted (like AMMO CAPACITY: 900 rounds), losing that upgrade meant that you go from 900 to 500 (the un-upgraded default). This turned out to be a really cool and quite devastating twist to things.
If it turns out that the community likes the feel of the "kit mode" prototype, it would be rather trivial to allow complete customization of the "kit" in this mode by the party host. I'm sure the community will find a lot of cool combinations that lend a unique flavor to the game when combined with all the other options that already exist.
I realize that the investment in your character decreases quite a bit in this mode, because regardless of surviving or not you will go into the next mission with a full kit, but maybe that's ok in the light of my intent; make a new mode where you can immediately smash your head against some fast and furious SBTF action.
Kit Mode also has a specific character tied to it, so it will not mess with any of the other modes.
POTENTIAL USER MAPS While implementing this update, one of the core changes internally has been to make the game independent of the method by which a plan (map) is created. Everything is currently still procedurally generated from a mission seed / option combo, but the code is now in place that will allow for hand-crafted maps.
Of course I'm unsure of how compelling it might be to both create and play custom maps in the context of SBTF, but I grew up with games like Racing Destruction Set and Boulderdash Construction Kit and had a lot of fun with them. Also the Steam SDK has good support for storing user content, so I see potential for lots of creativity from the community.
MISCELLANEOUS
The reactor overload screen effects have been toned down.
Mission settings in network parties will now send immediately upon change instead of once per second, so other players will see updates as soon as possible.
Panic rooms are now equipped with toilets for scientist use while waiting to be rescued.
KNOWN ISSUES
I have seen that network game reinforcements can sometimes be buggy in that players are re-spawned twice on consecutive simulation ticks. This is a bad artifact of the current network implementation, and as I plan a re-write I will defer fixing this for the time being. In practice this should mean that you will have exactly half as many reinforcements as you set in the mission setup (players please confirm this if possible.)
As always, thank you for your support and patience.
/nornware AB c/o johno
nornware AB is happy to announce a new update to Space Beast Terror Fright.
HOTFIX BUILD A hotfix build is now online (build id: 5D240A1F) that addresses the following issues identified in Early Access Update 46:
Fixed joining private parties (bug introduced with the shift to the latest network implementation). The caveat is that you must now be friends with the party host, it is no longer sufficient to be friends with someone in the party.
NEW REINFORCEMENT RULES Ever since it was introduced, the option to have reinforcements in-mission (dead players will respawn as new characters after 30 seconds) has been quite contentious. The original intent was to effectively increase the amount of time a given player was actually playing the game as opposed to being dead and waiting for the next mission; as this was when peer2 was the current network implementation the game was technically limited by needing to tear down the mission for everyone when someone left the game.
Since then the current client-server network implementation has been deployed, and as it is now possible to join and leave a mission at any time the dynamics of having reinforcements changes somewhat. I have opted to keep the option in the game for the time being as it appears from feedback in the forums that some players appreciate how reinforcements make the game a bit more forgiving, not least for beginner players. However, I completely understand the opposing feeling that reinforcements undermine the hard-core nature of the game.
While upcoming (planned) changes to the networking implementation may change things further, in the short-term I have opted for a slight modification of reinforcement rules. As of this update the reinforcements option is no longer binary (no reinforcements / infinite reinforcements), but rather has 8 different settings:
No reinforcements.
1 extra character per player.
2 extra character per player.
4 extra character per player.
8 extra character per player.
16 extra character per player.
32 extra character per player.
64 extra character per player.
The reasons to do it this way and not just as an arbitrary number are technical, but to paraphrase a famous computer science quote: "64 reinforcements should be enough for anyone..."
NEW REACTOR OVERLOAD EFFECTS I have implemented some more "flavor" to the reactor overload sequence, definitely a work in progress:
Music now behaves like in power failure mode while reactor is overloading, emphasizing the klaxon and warning announcements.
Emissive textures now flash more wildly while reactor is overloading.
More "noise in the air" / heat shimmer and color modulation.
MISCELLANEOUS
Party host mission settings are now persistent in networked mode.
The Randomize All option now randomizes properly in networked games.
Fixed layout of character info text in minor screens in splitscreen mode 3.
Moved science display to make room for picture-in-pictures.
Fixed the font scale for picture-in-picture player info.
Protected from rare case when a creep is fenced and attaches during the same tick; effects would reference an invalid creep.
Attached bullet marks to the reactor shield.
Fixed gibs spinning / bleeding in fences.
Fixed "ghosted" gib sizzle.
As always, thank you for your support and patience.
/nornware AB c/o johno
nornware AB is happy to announce a new update to Space Beast Terror Fright.
HOTFIX BUILD A hotfix build is now online (build id: 5CFE6693) that addresses the following issues identified in Early Access Update 45:
Added plan generation check for lab door collisions.
Fixed science display in mission outcome (tracking minimum across all characters).
Fixed tour of duty statistics accumulation bug (introduced very long ago).
Fixed crashes when toggling vertical sync in fullscreen mode.
Fixed crash on 30 hz toggle in-mission.
When players reinforce, network screen mode and player tracking is now properly reset for reinforcings players only, not for all players.
NOTES
Settings persistence has changed, you will want to check or reset your settings.
The change in tour of duty statistics may invalidate some data in characters on disk (live or dead).
SYSTEM / UPGRADE DAMAGE When mulling over ways to make the game feel like it has more progression / goals to achieve, I stumbled upon the idea of having non-fatal damage (i.e NOT beasts) do more things to the player.
Previously things like getting zapped by a creep, shot by a sentry (or player), or walking into a live fence would all damage a random "electronics system" of your HUD. I realized that if these events could instead have a chance of knocking out a random upgrade (while still sometimes doing systems damage instead), upgrades would no longer be permanent and there would overall be "more stuff to do" in the game.
While this might seem like a cheap shot, it seems to me in playtesting to have numerous advantages. It certainly causes more interesting scenarios; for example when you previously might have felt much more secure once you had acquired the short range motion tracker, now that "major" upgrade is suddenly no longer permanent but instead always at risk. Some player might recall that one of my long standing design tenets has been "extend the tension".
Another thing that feels good about this change is that it causes a player with many or all upgrades to have significantly more "effective health"; there are 37 upgrades available plus 6 systems, so a player with maxed upgrades has a much greater chance of surviving a lot of non-beast damage. On damage the game will roll a 50% chance of losing an upgrade over a system, and if that is the case having a lot of upgrades results in "having more hit points" effectively.
Note also that for upgrades that depend on each other (like motion tracker tiers), downgrades will always happen in the reverse order that upgrades happen, so in the motion track example you will lose long range before short range, and (now) short range before directional (see below).
All in all I think this is a very good change, and adds both to a constant sense of (potential) progression as well as adding some more constant risk to the game. Also it has the added twist of making a highly upgraded character much more robust to non-beast damage, something that I think is kind of cool and follows naturally from the concept of "being upgraded".
Note that when losing upgrades like ammo capacity and battery charge, the game will clamp your current values to the new maximum. There are also new character statistics for the number of upgrades gained and lost over the life of a character.
Finally, all upgrade and systems damage is now clearly announced in the HUD, just like when you gain an upgrade (as long as your text systems aren't knocked out...) I have also for clarity added a text display of what systems are functional at the bottom right of the screen, just so it is clear what is going on; this display will always function, regardless of text system status.
INFESTATION UPDATE / NEW BEAST BEHAVIOUR I have worked on improving the overall quality and creepiness of infestation in the game. Improvements include:
Infestation color palettes now match both beasts and creeps, in the interest of camoflauge. They are now smart enough to not have skin colors that clash wildly with the infestation that they generate... :P
There is now a graphics setting that controls infestation quality, with the high quality being an experimental mode that allows the infestation to penetrate more deeply into the geometry of walls. This of course uses more triangles and will probably be revised some more before the game is released. Note that this changes to this setting will take effect the next time a mission is started (the infestation meshes are "baked" like with the rest of the level geometry on mission startup).
There is now a plan option for "total" infestation, which means that the entire map is covered in infestation. This has more implications than you might think...
Breakers have always suppressed infestation, but this has been fine tuned to look much better than before (less blocky).
Players, scientists and beasts now have alternate step audio for when they are traversing infestation (squishy).
Moisture will now randomly drip from the ceiling in infested areas, with audio.
Infestation will now generate animated "Ridley Scott Mist" that I think really contributes to the overall spookiness / ickiness of the infestation.
Also, prepare to soil your trousers; beasts will now sometimes hide in the infestation, waiting to pounce on the unsuspecting player who fails to notice them. When they are doing this, motion tracking technology is not able to detect them, and audio cues such as music intensity are not affected either. Infravision might still useful however...
Also a small change that deserves to be more than just "miscellaneous"; sentry bullets now "daze" beasts for two seconds, during which time they cannot eat humans (players or scientists). The idea here is to avoid the unfair feeling of player deaths caused by sentry fire pushing beasts into players.
DIRECTIONAL MOTION TRACKER I have added a new first-tier motion tracker, which shows motion in octants relative to the player. This is in response to some (rather old) player feedback that the short range motion tracker has often been too powerful. The upgrade path is now:
No Upgrade: Motion within 10 meters causes audio cues and text showing the distance to the nearest motion.
Directional: Adds motion octants, showing the general direction where motion is occurring relative to the player.
Short Range: Adds positional blips for motion within 10 meters.
Long Range: Adds motion beyond 10 meters as small blips around the periphery of the map/tracker.
BATTERY CHARGE NEAR BREAKERS I wasn't happy with the manual aspect of recharging the player battery at breakers, so now just standing near a breaker will automatically recharge the battery. There is now also ambient audio for breakers (which incidentally helps you somewhat to find them during power outages). Also, all charging of the player battery is now accompanied by an audio cue, both when charging at breakers and during interactions with datacores / armories / repairs / sentries.
HOLOTABLE The idea of having some kind of "control room" has been bouncing around for a long time, and as it fit the fantasy of the game I wanted to give it a try. I knew right away that it should include a kind of map-table (hello James Cameron), and I proceeded to adapt the map/tracker code from the player HUD for this purpose. I was also thinking that the room should have some kind of functionality that empowers the player, like manipulating doors, fence, and sentries.
However when I actually implemented that kind of stuff it didn't feel like it added much to the game, but rather detracted from it by making it a bit too controllable (for example if you closed all the doors and turned on all the fences and sentries). I did think it looked cool though, so I just left the map-table in there; players might find still find it useful as it shows everything in the mission, but you can't take it with you... :)
MISSION LAYOUT / FEWER LABS Many players were feeling like there were too many labs being generated in the maps and that they were messing the general flow of the game. I agreed, so labs are now constrained more to the center of the available space, resulting in far fewer labs total and a generally better feel to levels (and making the game generally a bit harder). I have also compensated by doubling the chance of panic rooms occuring in labs, so there are still scientists to be found.
PLAN OPTIONS There is now more fidelity in plan settings. Complete options are now:
Infestation: none / less / more / total
Doors: none / more / fewer
Fences: none / more / fewer
Barriers: normal / inverted
Rooms: empty / filled / pillars
Sentries: none / more / fewer
Datacores: more / fewer
Armories: more / fewer
Repairs: more / fewer
GENERAL SETTINGS / MISSION SETTINGS UI In general I have tried to compact all settings user interfaces (general settings / mission settings). Combos / drop-lists have been compacted, and anything with only two settings works like a binary toggle (no drop list). Sliders now also fit the style of everything else, resulting in a cleaner look overall.
MISCELLANEOUS
Sparks now have lensflares.
Library layout is now compacted a bit.
Options are now called Settings consistently.
Predator is now the default infravision mode.
UI text now includes drop shadows again.
Added more character names at the request of Ian Urquhart.
There is now only a single legend for all door types in the mission setup plan preview.
The aiming reticle now animates when firing, increasing feedback.
Added columns of steam around the reactor.
I finally smartened up and started calling civilians scientists... :)
Bullet marks on doors now shake along with doors, and also now properly stick to to panic room doors.
Bullet marks have been optimized / limited to a rolling buffer of 256 instances. This is so that really long firefights won't adversely affect performance.
Sounds have been optimized; channels won't play or stop when a call comes in with zero volume, saving mixing resources as well as avoiding cutting off sounds that are still playing.
Sentries are now rendered using classic mesh skinning, optimized to render in a single call.
Meshes in general have been optimized at import time to use fewer vertices.
The player light is now called 'lamp'.
Gibs sizzle at a slightly lower volume.
Gibs are now rendered filtered.
Gibs have been optimized / limited to a rolling buffer of 1024 instances. This is so that really long firefights won't adversely affect performance. As a result I have also removed the 'gibs stay' setting.
Blood drips now have audio effects.
Fixed plan bugs where panic rooms could occur right next to a door or a fence.
Science upgrades now announce more visibly.
'Reloading' is now called 'Re-Arming'.
Beasts now have better collision bounds, so that shooting them from the side is more accurate.
Lensflares are now rendered properly in infravision mode.
Lighting is now updated properly when sentries run out of ammo.
All buttons in the user interface now have audio for 'cursor inside' as will as 'button pressed'.
As always, thank you for your support and patience.
/nornware AB c/o johno
nornware AB is happy to announce a new update to Space Beast Terror Fright.
Network Implementation 4 (Client / Server version 2) The last update (43) introduced a new networking architecture to SBTF, with the express goal of enabling joining and leaving the mission at any time without any disruptions. Unfortunately it appears that many players are experiencing a much higher degree of latency as a result of this change, even to the point of making the game unplayable.
This update (44) is concerned with minimizing this perceived latency, and explicit high-latency simulated tests have shown it to be quite robust; of course, testing in the wild in real internet conditions will always be required to know for sure.
One side-effect of the techniques utilized is that both clients and hosts use more bandwidth than in Update 43. If bandwidth usage proves to be a problem, I have some ideas on how to reduce this if necessary.
Miscellaneous
It appears that some user have trouble starting the game for the first time on a clean install, and that starting in windowed mode seems to solve this. For this reason the game will start in windowed mode by default (without a settings file). Alt+Enter will as always switch between windowed and fullscreen modes at any time, and the current mode will be saved in the settings file on program exit.
The creation of the world / environment / "spaceship" mesh now uses a deterministic random number generator (based on the current mission seed) to ensure that it is generated exactly the same for all players in a networked game; this was not previously the case.
A bug where fences would sometimes be rotated 90-degrees wrong has been identified and fixed.
Party options (private / reinforcements / friendly fire) are now shown in the non-interactive advanced mission config screen (applicable for non-hosts)
As always, thank you for your support and patience.
/nornware AB c/o johno
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 AB is happy to announce a new update to Space Beast Terror Fright.
Reinforcements Have Arrived As has been discussed as a potential change to multiplayer I have implemented the option (on by default) to reinforce the team in any multiplayer games (networked or local co-op). When this option is enabled, the rule is that as long as some team member is alive in the mission, new reinforcements will arrive 30 seconds after a team member has died. The intent is for everyone who is dead to be reinforced at the same time, so the practical implication is that you will maximally have to wait 30 seconds after death to be reinforced, but if more than one player has died then some players may end up waiting a shorter period of time; tldr is that you will maximally have to wait 30 seconds to be reinforced. However if the last player dies while the others are waiting to reinforce then the mission will fail; someone must always be alive.
While some people might instinctively feel that this might undermine the tension of the game, initial playtests indicate the opposite; the tension is extended instead. As this is one of the core design goals of Space Beast Terror Fright I'm feeling quite happy about how this seems to be playing out. One example is a single surviving player hiding in the reactor room under cover of several sentries and with access to a nearby breaker, while another player continually reinforced / respawned any number of times trying unsuccessfully to fight their way out of an overrun airlock to get to their stranded teammate. Eventually the reinforcing player was actually able to break out and get back into the game, but ultimately after epic fighting both players died within 30 seconds of each other, and according to the rules the mission was scrubbed.
I'm seeing that the inherent chaos of the game is definitely not being undermined by this rule change, but is rather being intensified. In previous versions a crazy mission would simply result in the death of all team members, but now that isn't quite as binary as it might have been before, and I anticipate a lot of crazy tense and heroic stories to arise from the addition of this feature. It is pure madness, and that's exactly as it should be for this game.
Of course, if you are a player who feels very strongly that "death should be death, end of story" it is possible to turn off the reinforcements feature (among the rules options). Note also that you will never be able to reinforce once the reactor has started to overload.
Character Persistence As has been requested for the longest time, both Local Area Network and Steam characters are now persistent across program executions, including loadout selection (this is also persisted for local games). The relatively recent addition of the science concept is also persistent, and for networked games the science value of the party host is used.
Miscellaneous
Obituary upgrade icons now fade correctly.
The splash screen now has animated elements.
As always, thank you for your support and patience.
/nornware AB c/o johno
nornware AB is happy to announce a new update to Space Beast Terror Fright.
Beast Spawn Animations As has been discussed over the years, I've felt that the fact that Space Beasts have always spawned instantly from Breaches has been a bit unfair, especially when Random Breaches are enabled. Trying to interact with anything right next to a Breach has for this reason always been extremely risky. Also it hasn't been the best thing aesthetically, as Beasts are just suddenly there on the floor or ceiling.
For these reasons I have now implement as very short (0.75 seconds) spawn animation where the Beast climbs out of the Breach onto the ceiling or onto the floor. During this animation the Beast is not dangerous and can neither interact with players nor civilians. This practically means that there is a chance to escape even if you are standing directly under a Breach when a spawn occurs, not least because that kind of proximity to a Beast will almost certainly max out your adrenaline level and thus give you the highest possible movement speed.
Also interesting is the fact that Sentries near Breaches are that much more effective as they have additional time to kill the Beast before it is completely out of the Breach and moving at normal speed.
Note that Astro-Creeps still spawn instantly.
New Space Beast Paint Jobs I was always a bit irked by the rather colorful collection of textures that the Space Beasts were using, so I spent some time doing lots of re-texturing and color correction, resulting in a new set of 13 different Beast textures that I feel are more in line with the way the Beasts are supposed to feel. And no, they no longer have eyes, something that I think H.R. Giger really got right... :)
Better Door Damage Feedback Another pet peeve of mine has been the limited amount of feedback available for the current integrity of any given door. There is an indicator on the side of every door interaction panel, but it's small and hard to see from a distance. While doors that get hit by a Space Beast have always made a noise, vibrated and briefly shown the current integrity, I wanted something more obvious. I have implemented mesh warping / displacement functionality in my toolset, so now the doors cycle through 16 distinct deformations to reflect their current integrity, getting more and more deformed before breaking as before. I expect to work on this aesthetics of this some more, but already it's been good to come upon a door that you hadn't earlier observed to find it quite obviously damaged, giving good hints about Beast activity in the proximity.
Updated Sentry Safety Protocols and Bullet Behaviour After the last update which included updated Sentry behaviour (aiming speed and lasers among other things) it became obvious that while the new code had more accurate checks for friendly fire it actually resulted in far more frequent "accidents". I can only speculate, but I think this had quite a bit to do with the fact that more accurate hit test code when checking for humans (from the actual barrel to the enemy position) caused Sentries to fire bullets just slightly over the top of or to the side of a player bounding volume. This meant that they would tend towards extremely near misses in the interest of firing as often as possible, but that kind of logic simply doesn't play well with humans moving through the field of fire.
As a result I have switched back to the previous much more conservative "safety check" code, while keeping the new aiming behaviour in place. This definitely results in far fewer cases of the game feeling like the Sentries are deliberately firing on you.
After some testing I finally decided that my very long lived opinion of "ridiculous sentry ricochets being funny" is not appropriate for the game, so now all bullets use the same ricochet code (as the player bullets have for a long time) in that ricochets will happen if the bullet has energy left AND wins a 50% roll AND has a reasonable angle of incidence to the collided surface. The bottom line is that Sentry bullets will no longer reflect straight back from perpendicular walls as has been the case for the longest time. I'm thinking that there are enough things in the game that can kill you, so I think this change is the right thing to do.
Note however that Fences will still reflect all bullets, so watch your background when firing down long corridors with active Fences, not to mention shotgun fire near Fences... :P
Icy Space Windows I initially felt that the addition of space windows really made the game feel more friendly instead of less so. This probably had a lot to do with it not constantly being a cramped indoor space, but feeling like there was something beyond, as well perhaps as the fact that the windows let in a little bit of light that can be used for navigation even during a power failure with a broken flashlight.
I happened to be watching a lot of Star Wars Clone Wars (the animated series) lately, and I noticed that they always used the indication of ice around the edges of all "space windows" on that show, so I tried it out and found that it really sells the fantasy pretty well.
As always, thank you for your support and patience.
/nornware AB c/o johno
nornware AB is happy to announce a new update to Space Beast Terror Fright.
Updated Sentry Behavior Sentries no longer aim at infinite speed, but rather take a little time to zero in on a target. When no target is in sight or range, they will patrol a pre-set number of directions. I have also added lasers to Sentries that indicate both the current potential firing direction as well as range, along with audio for Sentry aiming motion.
Miscellaneous
Ammo reload audio is now more in sync with actual reload events.
Breakers now emit light / glow in the dark even when power is out, making it easier to find them even without a flashlight.
Datacore statistics we erroneously counting as Coolant statistics; this is now fixed.
Reordered science display in HUD to match mission config screen order.
Cassettes / replays are no longer saved when a mission is aborted.
Library contents are lazy loaded; this results in less hitching.
Infestation now has more low frequency noise in order to be more varied throughout the maps, and can now also occur inside of labs.
Player selection drop list now displays properly as text when launching a mission.
Starscape outside windows now rotates and has better texture projection.
As always, thank you for your support and patience.
/nornware AB c/o johno
