Extremely unprofessional of me, but I finally noticed that I hadn't posted about the release of Space Beast Terror Fright from Steam Early Access on my OWN website!

Since then there have been a number of updates including the much more casual Grind Mode. All relevant update news is here.

Also I finally tired of all the comments about how "very green" nornware.com was, so here's a new style!

I have released an updated version of UfoPilot : The Phadt Menace on Steam.

Inspired by old 16 bit games like Gravity Force and Oids, the game was originally "completed but not really released" in 2002 while I was working at Massive Entertainment, really as just a hobby project. I got to thinking lately that it should really be available via modern digital distribution like Steam, so here it is.

I have released S.B.T.F. Early Access Update Femtio (50) on Steam, read the announcement here.

Hi all,

I've been working with the eminent artist Stan Brown on new level styles (and implicitly) integrating what I call Vaguely Physically Based Rendering (VPBR) into the game, and I'm happy to announce that the first new level style featuring said VPBR materials is imminent. We have been tackling the new materials on a per-level style basis, and the plan is to roll out these new level styles piecemeal as soon as they are done.

Happily the legacy materials work fine side by side the new materials, so there isn't any technical need to go through everything (which wouldn't have been practical in any case). What you will see however in the new styles is both metals and plastics that read much clearer as what they are intended to be. If we find that there are any glaring examples in the old styles that would much benefit from VPBR we will update them on a case-by-case basis.

As mentioned, system requirements will be raised minutely by this change, as the VPBR renderer requires Pixel Shader 3.0 (whereas the game previously only required Pixel Shader 2.0). This shouldn't be a problem, as the PS3.0 is at least 15 years old at this point, and all current hardware will have no problem running this shader model.

I do not at this time plan to implement any fallback renderers (as my VPBR implementation is a bit of an all-or-nothing concept), but I will be watching the forums in case anyone has any problems with this change in the rendering code. Rest assured that I'm committed to making this transition as smooth as possible.

Hi all,

Sorry to have been so quiet since the last update, but I've been coordinating some contractor work, and starting this week I've been working closely with a contractor on upgrading the look and feel of Space Beast Terror Fright.

What we're doing at a high level is incorporating more "level styles" into the game (randomly chosen texture and geometry sets that evoke different looks and feels when playing a mission). I mocked these up long ago, but did so with reference textures, so now we're finally getting to work on re-creating these in order to be able to actually ship them in the game.

What comes along as a by-product of this work is what I like to call an upgrade of the game's graphics engine to "Vaguely Physical Based Rendering" (VPBR); this is because we are using modern art pipelines like the wonderful tools from Allegorithmic, and they all output Physically Based Rendering (PBR) texture maps.

I am hell bent on not increasing the system requirements of the game at this late stage, and as such I have done a lot of research into how to incorporate the main features of a physically based rendering approach into the existing architecture. The main goal for SBTF is to be able to clearly differentiate between metals and plastics (as there is a lot of that stuff in the game), and I'm very pleased with the results to date.

Technically these new VPBR materials will require Shader Model 3 (as opposed to Shader Model 2 that the game uses right now), but that is within the scope of the API that I'm using (DirectX9.0c). This API is at least 15 years old, so I don't expect anyone playing the game to not be able to support that; if that happens to be the case I do indeed have a plan for a fallback that will trade-off reflection quality.

I will be incorporating this work into the game as soon as practical. Stay tuned!

I have released S.B.T.F. Early Access Update Fyrtionio (49) on Steam, read the announcement here.

The user-plan editor is now functionally complete; you can create custom maps, choose all relevant rules settings, load and save them, and play them from the mission setup screen.

Note that the first update with this feature 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 I fully expect user-plans to work in networked games even from this first update, so it will be possible to share 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 just 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).

What I do expect to change if / when Steam Workshop support comes online is the addition of being able to play ANY user-created plan that has been publicly shared by anyone, both locally and in networked games.

I'm moving into final testing after this rather big change to the code base, and will hopefully have an update ready in about a week's time.

I'm still working on the user-plan editor and it's coming along nicely. I've actually relaxed quite a few constraints that are in the procedurally generated maps in order to give hand-made maps a bit more flexibility in combining various visual themes. Maps have always had a main wall type as well as an "alternate" that has only shown up in rare cases (filled rooms), and also of course the "lab" look. I'm looking at allowing these to exist side by side in ways that players will not have seen previously.

This incidentally touches on some work that I've had planned for a long time; namely re-visiting a lot of the level styles and texture, as well as including some new ones that I've prototype. In relaxing the constraints 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.

At this point I'm planning for full support for "user campaigns"; 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 trivial to persist in the Steam Workshop back-end; after all, what is the point of creating awesome hand-made levels without being able to share them with the community?

At this point I'm envisioning a dedicated editor screen available off the main menu so that you can build your levels / campaigns in peace, and then bring them into your local or networked games in a simple fashion. I'm realizing that adding this level of concentrated work into SBTF will require some tasty mood music and / or sound effects to be really compelling; I have indeed planned a game-wide pass on all music and sound effects before release.

Another thing that is being streamlined is the flow between missions. 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.

Expect the next update to be a first pass on user-created levels.

I recently switched version control systems (from svn to git) which has been a long time coming and a very good move. For the first time ever I have the ability to leave the last update alone in the master branch and continue working in a develop branch, which allows for much simpler hot-fixing if the need should arrive.

I have also stopped using my legacy planning software (trio) as much and migrated to plain text file; this is a direct result of needing a better overview over the work that is left leading up to release, and almost laughably it's pretty much the best system (for software development planning and tracking) that I've ever come across. I have had a lot of theories about the process of software development throughout my career and have even written a bunch of software to support such activities (including a commercial product), but it seems like when things need to get serious a text file beats everything.

The text file has helped me come to grips with the big chunks of stuff left to do as well as prioritize them more sanely than before. Sadly this results in fewer pseudo-real-time posts on the feed page of nornware.com, simply because it now has become an extra (manual) step to get stuff up there.

Optimally I would like to be able to automatically grab related commit messages from git and put them up there to retain that communication channel to those who are interested. If anyone has experience with hooking into git don't hesitate send me an email (contact@nornware.com).

Oh yeah I almost forgot; I'm hard at work on a level editor that will allow users to create their own missions...

I have released S.B.T.F. Early Access Update Fyrtioåtta (48) on Steam, read the announcement here.

I have released S.B.T.F. Early Access Update Fyrtiosju (47) on Steam, read the announcement here.

I have released S.B.T.F. Early Access Update Fyrtiosex (46) on Steam, read the announcement here.

I have released a hotfix for S.B.T.F. Early Access Update Fyrtiofem (45) on Steam, read the updated announcement here.

I have released S.B.T.F. Early Access Update Fyrtiofem (45) on Steam, read the announcement here.

Barring insidious bugs, I plan is to release Space Beast Terror Fright - Early Access Update 45 next week. Final testing is in progress right now.

I'm very close to a new update that will include a whole bunch of new goodies. Only a couple of bugs and some texture work left to do...

I have released S.B.T.F. Early Access Update Fyrtiofyra (44) on Steam, read the announcement here.

I have released S.B.T.F. Early Access Update Fyrtiotre (43) on Steam, read the announcement here.

That was really really really hard, probably the hardest update ever to get out.

I've been doing network programming in games for 20 years, but it still scares the crap out of me for some reason. Add to that the limited capacity for testing that I have at my disposal. The decision to replace the network architecture of SBTF at such a late point in development was certainly not a decision that I took lightly, but I believe that the benefits of the new client / server architecture are important for the product.

I fully expect there to be bugs to be fixed and adjustments to be made, not least from a logical / design perspective, but finally the multiplayer part of the game has most of the quality of life features that I felt that the game really needed to meet player expectations.

I'd like to once again thank everyone who has joined me to date on this Early Access journey. Onward towards release!

I was pretty much ready to release Early Access Update 34 of Space Beast Terror Fright when we caught a very weird and confusing bug related to drop-in / drop-out where player slots were getting mixed up.

I'm at least happy that we tested it thoroughly, and hopefully it won't be too hard to fix.

To be continued...

Just tested 56 distinct cases in the new network model (LAN implementation), permutations of the client and server being in various states when either the client or the server crashes out or exits cleanly. 1 case fails, but that looks like the last thing to fix.

Of course I have to run all these tests on the Steam implementation as well... :P

And so another three weeks passed... Sadly I've been quite ill for most of that time, and progress has been slow, but now I'm better and back at it. As has been discussed there are a lot of new complexities that arise from the addition of the switch to a client-server architecture and the goal features of drop-in / drop-out from a party at any time.

I wrote that I was considering making reinforcements a non-option, but I have since reneged on that based on the feedback that has been coming via the forums. What I've done instead is promote certain options to "party level" as opposed to "mission level":

Public/private: as before (open to anyone or just your Steam friends), defaults to public.

Friendly fire: new option that allows for player vs player damage to be turned off, defaults to on (players damage each other).

Reinforcements: as before (whether or not dead players are reinforced after 30 seconds), defaults to on.

With these changes players will have an even higher degree of customization to the experience. 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.

I'm doing final testing now on all permutations of the new features, like players entering/leaving/crashing out of the lobby, entering/leaving/crashing out of the loading screen, entering/leaving/crashing out of the mission, etc.

One thing that is probably not as expected is that drop-in will always spawn the player 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, 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, like for example dying, dropping out, and then dropping back in, which will probably restore the dead character as well as potentially circumventing the reinforcement delay. The expected behaviors in all of these edge cases need to be explored.

I'm still here!

I've implemented and tests most of the new networking functionality, namely being able to come and go as you like from a multiplayer mission without disrupting it (unless you're the host).

What I'm currently grappling with is the subtle changes to how character information flows back and forth between the front-end and the actual simulation (in-mission). This was partly touched on when reinforcements were implemented, but now it needs to be done properly when player slots that weren't even used at the start of the game are suddenly occupied on the fly during the mission. The inverse can also happen, with players leaving the game mid-mission.

As the main goal of all of this work is to make network play more inclusive I'm currently leaning very heavily towards making reinforcements a non-option, as there is no point in doing all of this work if the game can still disallow late-joins as a user option (by turning reinforcements off); these feature would run at cross purposes. I feel after a lot of testing that reinforcements makes the game more accessible without much (or any) loss of tension. Of course you're all welcome to argue this point and prove me wrong.

I'm aware that much time has passed since the last update, but a lot of this stuff has to be done right or not at all, and I'm pushing hard for a release as soon as possible.

It's been a while since the last update, so I wanted to post something about what I've been doing.

Problems & Goals with SBTF Multiplayer
One major issue with the network implementation of SBTF has been at quite a high "game" level, in that it's currently not possible to join games in progress (in-mission) nor is it possible to leave a game in progress (in-mission) without forcing the game to tear down the mission. The reasons for this are quite involved and technical, but stem largely from the fact that the game uses a peer-to-peer topology (internally called peer2).

One upside to peer2 has been that is that the bandwidth usage is relatively low (around 20kbps upstream and downstream per player) because players only need to send their inputs to one another (very few bytes). Also good is that the simulation in peer2 is "perfect" in that everyone is guaranteed to always see exactly what happened. That was indeed one of the main goals with peer2; have it be as close as possible to the single player experience.

The downsides with peer2 (aside from the aforementioned inability to join or leave games at will) start to show up when not everyone in the game has a good connection. The slower a single peer is, the more prediction and re-simulation everyone in the game has to do in order for the game to appear to keep running on everyone's machines while waiting for official inputs to arrive from the slow peer. This theoretically gets exponentially worse over time, resulting in a ton of extra CPU work for everyone and eventually (probably/theoretically) just exploding. I admit that I have rarely seen this myself, but that is probably largely because the internet infrastructure where I live is very good.

It's hard to get a definitive answer from the community, but the "bad connections mess up the game" issue seems to be a driving force when it comes to some players' tendencies to prefer private games. This is probably because knowing who you are playing with and being able to reason about their available bandwidth becomes important with this kind of network topology.

For me as a developer, one of my main concerns has been about how to make the game more accessible to people who want to play multiplayer. To this end having the ability to join and leave games at any time is obviously a desirable feature. Also important is to keep the bandwidth requirements of the game as low as possible.

From Peer-to-Peer to Client-Server
I've been seriously looking into ways to solve the join/leave issues, and experiments have led me down the path of a more traditional client-server architecture (as opposed to a pure peer-to-peer architecture which is the current "peer2" implementation). The reasons for this mainly come down to the fact that peer2 doesn't have a central repository of past player inputs, so late joining is currently technically impossible without a lot of tricky changes. The client-server implementation is still a work in progress, but the implications that I know about can be summarized as follows.

"Client-server" does NOT imply that SBTF will involve any kind of centralized or dedicated servers run by nornware or anyone else. When I say client-server it simply means that one of the players in the game (most likely the party host) will technically act as the authoritative node in the game (the server). As long as the party host (server) stays in the game then all other players / nodes (clients) can join and leave at any time.

The server will experience a game that is exactly like single player, with zero artifacts of prediction nor simulation and the like. This game simulation instance is authoritative, and decides what "actually happens" in the game.

Clients will rapidly receive a stream of state updates from the "official" simulation (running on the server) that directly patches their local state. Clients (as in peer2) will still do complete local simulation in order to perceive a smoothly flowing game, but in truth what they see isn't actually happening; it's just a very closely predicted outcome based on the latest information they have received from the server.

Indeed conceptually this isn't very different from peer2 because peer2 has always done speculative prediction of what will happen in real-time while only doing fix-up when it is possible to do official simulation (in the past) and then re-simulating up to the current time.

The main difference is that client-server allows the game to completely avoid any re-simulation at all (lower CPU usage) at the theoretical / potential cost of more visible artifacts as a result of the server state patching the predicted client state. Finding ways to minimize these artifacts is a large part of the challenge when it comes to client-server, and are quite closely related to bandwidth usage.

In terms of actual network traffic, clients will send their inputs (plus other technical stuff) to the server (compare to peer2 where all peers send their inputs to everyone else; there is no authoritative node). The server will in turn send all the latest inputs from all clients as well as the entire state of the simulation to all clients (compare to peer2 where no such state is sent at all). This makes the server completely independent of the existence or identity of any client, allowing them to come and go as they like.

What might not be obvious is that the "entire state of the simulation" is very much larger than the previous network payload of player inputs, to the extent that this becomes very much a non-trivial problem to solve and has occupied many network programmer hours across time and the game industry. Why? Because bandwidth; simply sending all of the state of the simulation in SBTF at the same rate as peer2 sends data is simply not feasible if I want to keep the bandwidth usage anywhere close to what the game has been using to date.

Because if this most of my time during the past month has been spent looking at various approaches to seriously compress the actual bandwidth usage in the client-server architecture. More to follow, but I'm fairly confident that this approach will work and gain us all the ability to join and leave SBTF games more dynamically (the main goal) as well as at the same time keeping bandwidth usage to a minimum (the secondary goal).

We Might Lose Multiplayer Replays
Among the potential casualties of all of this is the current support for viewable replays of multiplayer games. Conceptually this is no longer possible to do in the current way because the new architecture does not require and hence does not guarantee that all inputs reach every node, but depending where I end up in bandwidth usage I may be able to piggyback official inputs for a replay in a side channel.

Again, work in progress and more to follow.

I have released S.B.T.F. Early Access Update Fyrtiotvå (42) on Steam, read the announcement here.

I have released S.B.T.F. Early Access Update Fyrtioett (41) on Steam, read the announcement here.

I have released S.B.T.F. Early Access Update Fyrtio (40) on Steam, read the announcement here.

I have released S.B.T.F. Early Access Update Trettionio (39) on Steam, read the announcement here.

I have released S.B.T.F. Early Access Update Trettioåtta (38) on Steam, read the announcement here.

I have made an announcement regarding the next update to Space Beast Terror Fright.

I just wanted to write something for those of you who read this feed.

I'm still around, and SBTF is still being worked on, but the pace has been (obviously) very slow since the summer. I'm slowly getting back at it, but both my day job and consulting has been taking a lot of my time.

Dual weapon loadouts have been fully implemented, and I think that they are a good step forward all things considered. As I have noted, for the game to work with the "limitation" of having only a single weapon for a given mission then all those weapons basically need to be exactly equivalent, otherwise it just leads to a dominating strategy where there is obviously a single weapon that is best. Of course if all weapons are equivalent then there is only one weapon; you see the logic.

Allowing for the player to choose any two and swap between them at any time in the mission is my attempt to gain more use out of all the weapons that have been implemented. I would rather do this then the (to me) obvious alternative; just get rid of everything except the rifle. Hopefully interesting player choice will arise from this, especially in team games.

Other than that I am in the process of merging all game modes into one (Salvage and Rescue, with Deathmatch already removed completely). The secret sauce here is that I have some changes planned to the basic function of Civilians that I hope will change the game in a very positive way, but I won't talk about it yet lest it fail in testing since it's not implemented yet. More on that (and updates) as soon as possible.

I have released S.B.T.F. Early Access Update Trettiosju (37) on Steam, read the announcement here.

I have released S.B.T.F. Early Access Update Trettiosex (36) on Steam, read the announcement here.

I have released S.B.T.F. Early Access Update Trettiofem (35) on Steam, read the announcement here.

I have released S.B.T.F. Early Access Update Trettiofyra (34) on Steam, read the announcement here.

I'm getting close to a new update which will feature Rescue Mode.

By no means will this be completely finished (being Early Access and all that) because Rescue Mode adds so many new systems to the game and there are a thousand rough edges, but I'm pretty happy with the core mechanics as they stand right now.

Things that have happened recently include a pretty decent audio system that makes the civilian scientists "express their profound distress" over the situation at hand, i.e. screaming a lot. I find that it's a good balance, doesn't get in the way, and really complements the mayhem when things get out of hand. It even acts as an extra early warning system that a Beast is coming your way, but that doesn't necessarily mean that you can sort the situation out as civilians start exploding like pinatas all around you.

A note on that; I'm making the civilians extremely fragile so that a single shot or being touched by a Beast explodes them instantly. The are currently impervious to Fences (they will shut them off in order to pass) and having Creeps attach to them, but they will still flee Creeps.

Also very new is a change in the plan generation algorithm. The background is that previously civilians spawned in 3x3 "labs" that were isolated from the rest of the level by a heavy door. Heavy doors are just like the legacy airlock door, so they will automatically seal when no human is near and are also completely impervious to Beast damage.

The change implemented today is that the algorithm now attempts to connect labs together. This created a pretty cool feel where the labs can be very expansive, still composed of 3x3 "rooms" but with connecting passages. This leads to a sort of safe zone that the player can use to traverse the map without being at risk, because any cohesive network of labs are always sealed by heavy doors. Prior to that change there was really no reason at all to enter the labs much more than simply opening the doors so that civilians could see you and start to follow.

After this was done I started feeling that the labs constituted too large a safe zone, but after iterating on that a bit I found that I still liked the size, I only needed to figure out at way to make them slightly less overpowered.

I tried having some small percentage of labs generate little dead-ends, which caused the downstream algorithms to generate breaches inside the labs. The problem with this was that once there was a breach in a lab network, everyone was pretty much dead instantly. After a while I started thinking about perhaps having fences between all the individual lab rooms as some kind of security measure, but this brought up some pretty complicated AI requirements on the part of the civilians.

What I'm currently doing is instead introducing yet another type of "force field" to the game, what I'm calling "DNA screens". The lore reasoning here is that civilian scientists have containment fields between their labs in the interest of "specimen containment", and these fields only allow human DNA to pass. On a gameplay level this means that players and civilians can freely pass, no shots are blocked, but Beasts and Creeps cannot pass.

What this ultimately produces is situations where breaches can happen in a lab, but those are contained within a 3x3 lab cell. Any civilian present within the contaminated cell has a good chance of getting out before being eaten (but not for certain due to bad nerves...), and over time this generates pretty scary "meat cells" of dozens of furious nasties frantically trying to get out. Due to the fact that you can shoot them from safety, you may choose to clear out the lab cell in order to pass through, or you can simply take another route. Due to the nature of the map algorithms these contaminated cells may or may not pose a problem when trying to get your precious cargo back to the airlock.

This whole DNA screen thing is very very new, and I'm seeing a bunch of potential issues with crowding, but overall I'm liking how it changes the lab networks from totally safe to semi-safe, with lots or interesting gameplay situations arising from the screens interaction with the various AI components. We'll see how this plays out.

I need to get Rescue mode working with the Mazes/MiniMazes algorithms, but other than that there is only miscellaneous stats and score screen stuff to be done before an update can be released. Again, it's not going to be perfect, but since it's been so long since the last update I'm fine with being a bit messy as long as the core experience is fun to play.

EDIT:
I just played another round in which I was mostly able to only traverse lab space while rescuing the civilians. There were quite a few contaminated cells along the way, and I was forced to clean some of them out from time to time because the civilians were too afraid to pass them by. This was interesting and definitely cool emergent behavior on their part.

On my way to get the two final stragglers the power went out. I reflected briefly over how bright the labs were when the power was on and how completely and utterly dark they were with the power out. Then I heard the two final civilians get slaughtered. Then I saw the beeline of angry alien flesh coming my way on the motion tracker and realized that every single Beast inside the contaminated cells had seen me, and by previously established AI rules they all made a bee-line straight for me with the full knowledge of the pathing system. I died horribly alone in the dark. So awesome.

I've been working all through the long weekend (yay Easter!) and have made significant progress on the civilian visuals for Rescue Mode.

The original artist on SBTF had built and animated a speculative civilian / scientist model about a year ago, and getting it integrated into the game involved both a bit of software archaelogy as well as some modifications to the animation importer.

SBTF is the first project in nornware that has involved anything other than simple looping animation, and it's interesting to me that I find a lot of the stuff needs to be code-driven as opposed to simple looping cycles. For example the player models are directly animated by the speed of the avatars in the simulation, and I'm seeing even more advanced stuff evolving for the civilians; they now properly run their animations forward or backward depending on their direction of travel.

I'm also seeing the need for advanced animation blending between running and standing / idling, because in this game there is a lot of stop and go action when the nervous civilians are following the player around. This means that I can't simply switch between running and standing without having the animations snap, and that looks pretty bad. I'm going to look into "bilinear" animation blending to see if that helps; first interpolate animations as usual for each cycle, and then blend between those results to get the final frame.

I suppose the only potential issue is squashing the animations, as I am still doing shape blending and not actual skinning animation using bones, but by selecting frames intelligently I should be able to get it to work.

I found myself wanting to do a really exhaustive talk about the evolution of my programming style and specifically how working on Space Beast Terror Fright has affected it.

I cover lots of deep information in there about the inner workings of SBTF networking, as well as how that fed into (and really was the tipping point of) the long process of moving away from object oriented programming.

Nerdy and very long. :)

How the Space Beasts Killed my OOP

This past weekend and today I've got the bones of Rescue Mode running, with civilians able to follow the player to the airlock and probably get shot or eaten by a Space Beast in the process.

There are still a lot of finicky details to finish, not least a proper model (I'm currently prototyping using the player model) for the civilians and a whole lot of audio; I want them to be the nervous chatty types as well as scream a whole lot.

Opportunities for fun chaos are emerging, like for example having Astro-Creeps also target civilians and causing them to totally panic and run around blindly. It remains to be seen if it should be possible or not to save them in this state by shooting off the Creep, as that relates to the amount of weapons fire they should be able to absorb. I'm thinking not a whole lot more than a single shot. Currently Space Beasts just steam-roll them, and I think it's important to get the same feel as when a player gets eaten, having it take a little while.

From a rules perspective I'm pretty confident at this point that Datacores will not be present in Rescue mode, but instead the actual rescue of a civilian (bring them to the airlock) will result in a random upgrade for the entire team. This fits well with the realization that I can't keep the civilians around in the airlock because they simply will not all fit in there at the same time, so when they get removed from play it feels reasonable to have them result in an upgrade. Hey, it's a game. :)

What I've seen emerging is interesting player choice concerning whether or not to rescue civilians a few at a time or many at a time. A whole bunch of civilians being rescued at once results in a huge boost of player power in a very short time, so I'm curious as to how this will feel in team games. I'm sure that players will figure out strategies where some players act as defense while others act as escorts.

More on this as it gets implemented.

I've been sick as a dog this past week, but today I finished refactoring the generation of the path map (used by beasts to navigate as well as all the pathfinder upgrades) so it could be done independently of actually starting the mission.

This was mainly done so I will be able to build development tools to debug the placement of pathing nodes for the new level algorithms that are in development for use in Rescue Mode.

This also had the unexpected benefit of speeding up pathmap generation as I could implement a special case of intersection testing specifically for that case.

It's been quite a while since I had time to work on Space Beast Terror Fright, but now I've started work on a game mode I'm calling: Rescue.

The idea is similar to Salvage in that you are tasked with going into a derelict spacecraft to retrieve something, but in this mode the prize is a number of civilian (probably scientists) that are trapped in the infested ship. The twist is that unlike the Datacores in Salvage mode these civilians need to be escorted back to the airlock in order to complete the mission.

Details are still very much up in the air, including things like the presence of Datacores / implications of how upgrades should work if not, etc. I'm currently looking at new map generation algorithms that will generate safe-rooms where the civilians themselves will be located at the start of the mission. I am thinking that these rooms will protected by heavy doors that will work similarly to the airlock door in that they cannot be destroyed by Space Beasts and also will automatically close as a security measure. As you can imagine this has pretty far reaching implications and may even inspire future features (I'm still interested in the idea of some kind of control room).

I hope for the civilians themselves to be a great source of chaos and hilarity; I want them to be very nervous and to be subject to panic attacks when Space Beasts get too near, getting in your line of fire and in general being a pain to manage. I imagine them being very vocal about this and I'm very much looking forward to the voice acting sessions required for this... :)

More info as this unfolds.

I'm currently experimenting with the idea of allowing the player to use ironsights in the game.

If I go with this it will be purely aesthetic and have no effect on weapon accuracy, mainly because I want the game to retain the arcade feel and for players who don't like ironsights to not be penalized in any way. The reasons to add ironsights are along the lines of being able to turn off the HUD-reticle; for the players who feel things like this increase immersion. I think I will make it possible to use both ironsights and the HUD-reticle at the same time, for the greatest number of options for the player.

The main issue is the fact that the weapons are have ammo displays that directly block the ironsights, so I'm experimenting with redesigning the weapons to hopefully allow for both ironsights and ammo displays. Having two versions increases GPU memory load since all of this needs to be displayed properly in split-screen.

I want to avoid adding more buttons to the game if possible, so currently I'm experimenting with enabling ironsights on the interaction button (right mouse button in keyboard / mouse mode).

I'm also thinking that movement-related weapon bobbing will persist as is even with ironsights up, meaning that you have to stand pretty still to aim. I suppose I could decrease weapon bobbing with ironsights up, but in that case I would probably choose to limit player speed as well. Again, iron-sights will be about immersion, and if anything they will be less effective to use when compared to the existing HUD-reticle since the HUD-reticle isn't affected by movement.

I have released S.B.T.F. Early Access Update Trettiotre (33) on Steam, read the announcement here.

After many months of slow progress I'm almost done with Update 33.

There are many small behind the scenes fixes and optimizations included in this update, but the biggest thing is a new Randomize All mode where most settings are randomized. Most interesting is the fact that many Rules settings will mutate periodically in-mission, resulting in among other things a mix of random and fixed Breach positions, as well as difficulty that changes over time.

I have a small bug to fix to make sure that the mutating rules stuff works in networked games, but expect an update in the coming days.

I have released S.B.T.F. Early Access Update Trettiotvå (32) on Steam, read the announcement here.

These days I'm very explicitly moving away from Object Orientated Programming, which I learned back in the 1990s in the context of C++. I've come to feel very strongly that it isn't even "real" and is only in the way, at least when it comes to game development.

I just did a refactoring of the "in-mission menu" that comes up when you press escape in a mission, changing it from a class / object to just the state that is required and a bunch of procedures. I realized that the only state that was there was a single variable that controlled the "state" of the menu, which was either off, showing options, or pending a mission abort. So 3 states, minimally represented by 2 bits (4 possible combinations). I kept it as an enum class, a feature of C++11 that I happen to like because it enforces design decisions on the compiler level.

So the "object" turned into an instance of said enum class, and all the methods that "did the gui stuff" turned into a single procedure; I'm doing IMGUI after all. There is a bunch of state being manipulated of course because you can adjusted settings via this menu, but that is somewhere else. The state that is purely related to the menu is simply the above noted 3 states.

It still amazes me how much pure crap you can get rid of by just "going back" to procedural programming. Indeed, the current network implementation (Peer 2) that the game is running would not have been possible at all in Object Oriented C++, simply because there would have been a bunch of complex object graphs that I needed to copy around and keep backups of. Now is just a big fat structure that encapsulates all of the mutable state in the entire simulation, and the code is awesome.

The only thing that I really still like from OOP is pure interfaces; like Java has, but you can do it in C++ with pure virtual methods and no state in the baseclass. I still use these to completely abstract implementation details of the "networks" in SBTF (LAN and Steam), as well as Leaderboard implementations. But then, this could be done with a struct of function pointers... :P

I've been (somewhat speculatively) refactoring my vector math / linear algebra stuff to no longer use templates. These days I'm somewhat leery of using templates, and I've never liked the need to include them in header files.

A lot of code could be removed and simplified, but however it looks like some trigonometric optimizations may be responsible for breaking the replay format for SBTF. I will restore the old vector rotation code and check, and if this works I will probably keep the legacy code. Otherwise it's not worth trying to track down; new replays recorded post the refactoring all work.

I just happened to find myself in a special development view that I have for flying around and checking the map geometry while watching a replay, and noticed that the simulation was still running. It was really truly awesome to see the hero running around being heroic and slaying beasts, instant action movie!

I have had ideas about implemented alternative camera alternatives for replays, simply because it is possible, but this accident has really motivated me to get a basic version in there. I'm thinking something automated that just drifts close on the heels of the player, not getting too close and not getting too far, and tries automatically to keep the player in view. Hopefully this will provide for some dramatic action.

Of course providing things like a free camera that the viewer can control would also be possible...

I'm still here, doing sweeping maintenance to my vector math stuff in an effort to both speed up compile times and decrease code size. More SBTF soon.

I have released S.B.T.F. Early Access Update Trettioett (31) on Steam, read the announcement here.

I have released S.B.T.F. Early Access Update Trettio (30) on Steam, read the announcement here.

Replays are actually coming along quite nicely, with local storage in place and tested in local single-player mode. It is very awesome to complete an epic run and be able to play it back to see just how close you actually came to annihilation.

I need to make sure that it is possible to record both local co-op and networked games on all nodes, and when that is validated I think I will roll out local storage of replays as a first step.

After that I really want to have replays stored in the Steam Cloud, because that would be an awesome way for the community to share their greatest moments. All of that requires a bit more work and diving into the inner workings of Steam User Content, but it should be well worth it.

Hi all,

It's been slow going lately, but there are a bunch of smallish changes in the pipeline for a coming update.

I'm also looking into the foundations of replay support, with the ultimate ambition of allowing players to record any mission (local or networked) and optionally share these with the community. This will hopefully be possible via the Steam User Generated Content system. This stuff will probably be pushed to a future update.

The work with replays will also give me insight into the game's potential capacity to support both drop-in / drop-out play as well as spectator mode. This may or may not be possible, but I'm hoping it will be.

I have released S.B.T.F. Early Access Update Tjugonio (29) on Steam, read the announcement here.

It looks like we will be getting "Space Windows" in Space Beast Terror Fright.

I have managed to use a pretty cool and relatively computationally inexpensive inverted cube-mapping technique that I adapted from a shader by Inigo Quilez. With the right texture I could also get away with just a single 1024x1024 starfield that I think works pretty well.

The windows also cast a little bit of light, and I have adjusted the system so that these lights aren't affected by power failures. All together these things give the illusion of outer space existing outside the ship you are conceptually on.

I was careful not to make the starfield texture be too "cheerful" or "romantic" as can often be the case when nebulae and / or multicolored stars are used to heavily. I don't want the claustrophobic mood to be affected too much.

The windows will also only occur on the extreme edges of the map / ship. This is very much in order to not have to deal with the case of looking out a window and seeing the outer hull of the ship, and even worse being able to see back in through yet another window. All of that would require a ton of extra geometry to be rendered (with lots of overdraw), and also I wouldn't be able to get away with the magic shader that I'm currently using (which achieves zero overdraw).

All in all a good trade-off that doesn't cost too much.

I've been away from the compiler since the last update (28) doing some work-related travel, meeting some old friends, general head scratching, and CrossFit. I've been thinking that I need some time off for a long time now, and I figure I might as well continue this small hiatus for a little while.

My living situation will change in the coming weeks, and possibly my work situation as well. This MAY result in a lower development rate on Space Beast Terror Fright, but rest assured that I am completely committed to finishing the game and getting it out of Early Access.

Over the next couple of days I will be spending time with a good friend who is a lead developer on Tom Clancy's The Division, and as you might expect all those guys and girls deserve some time off. It's a good thing it is Göteborg Beer Week this week... :)

Vexpac asked if there was any concept art for the game. It turns out that there isn't much, but here is what I found in a big pile of source material.

It's been a year since we first published this game on Steam Early Access.

I happened to look through some of the previous Early Access Update Announcements that we post in conjunction with all updates, and realized that we've pushed on average an update slightly faster than once every two weeks, something I'm quite proud of. I also realized that I've been thinking about getting out of Early Access for nearly 4 months. That feels like a long time to me.

Having all the update dates and notes right under my nose like this actually helps me look back on the Early Access process for Space Beast Terror Fright much more objectively than was possible when right in the middle of pushing development forwards as fast as possible. I am happy to see that I have since around the beginning of 2016 managed to push hard on adding "big" features to the game.

This has been a very conscious effort, because I've often felt when in Early Access that the level of quality that we've managed to retain with this project can actually be a liability. This is simply because it is easy to get scared of breaking things and undermining this sense of quality, and also because change to the product can easily be perceived as regression.

I decided a while back to push ahead regardless and have faith in my ability to make the right trade-offs and also consciously act like I'm "in a hurry" to finish the game. I have found that this kind of mindset is really what moves things along and makes completion possible, and I can see that the average rate of updates (not to mention the scope of these updates) has increased significantly since around the new year.

I have both posted some of my plans for completion in the forums as well as spoken individually to community members about them, but I'll make a stab at my general thoughts concerning major ideas left to try out (as of today):

• Multiplayer will be getting some love as per this post.


• I want to try the whole idea of "space windows" so you can get a sense of the maps actually being on a ship in outer space.


• I am still considering doing indoor/outdoor areas, even though this implies having missions set on a planet instead of in space. This implies much work on things that are mostly just eye-candy (skies, ground, some kind of alternate escape mechanism like a shuttle), and as such might not be worth the hassle. I also can't seem to motivate the outdoor areas from a gameplay standpoint, because there won't be anything to interact with there. On the other hand Infestation is sort of like that too, and I really like how that turned out.


• I would like to try some kind of "rescue the civilians" mode. There are some assets already prebuilt for this, and it would be a shame to not at least try to get that kind of game mode working. I anticipate awesome chaos with frightened civilians running around, getting in the way of player fire as well as being torn to bits by angry Space Beasts (which will probably favor eating civilians over Marines).


• I don't think Leaderboards work for this game, both because there are simply too many permutations of missions that can be viewed as unique challenges as well as the fact that as long as you complete a mission you will get a very similar score to everyone else. As a result they will most likely be removed.


• Instead of Leaderboards I have ideas for a kind of Campaign of the Week which is a randomly generated series of missions that goes on forever (but is the same for everyone). The idea is that these Campaigns can be played together in local and networked Parties, and the score for each attempt is based on how long players survived and for how many missions. This solves the scoring issue associated with current Leaderboards simply because the best team will be the one that survived the longest, and the procedural Campaigns will never run out of missions. These Campaigns as the name implies will be time limited to a week, and any given Party may attempt the Campaign during that week as many times as possible. This whole idea requires some storage that I still need to figure out.


• I have mentioned the desire to try to generate more advanced levels with varying ceiling and floor heights, but I will not do this for Space Beast Terror Fright. This is because this "feature" is fractal and implies a very large amount of work. It basically invalidates the way the current level geometry is pieced together, and I have no current equivalent solution that isn't a combinatorial nightmare. Levels like this also imply things like Beast A.I. that can navigate vertical spaces, stairs and / or elevators, solving the problem of players falling into pits, etc. Even with all of these risks, I think the biggest reason not to pursue these kinds of levels is simply the risk that once it were all implemented and all the problems sorted some players might simply feel like something was lost with the replacement of the the simpler flat version of the game.


• I want to implement some kind of "star" / "favorite" system that allows players to mark missions that they enjoyed. If this information is available to everyone I anticipate this to be a way to rank all the billions of missions in the game by popularity. However there may be issues with storage here, and also this might simply turn in to a mess of information without meaning in a similary manner to Leaderboards.


• I'm still hesitant about implementing a manual mission editor. This is partly down to things like storage issues, but also questionable; maybe this game should be completely procedural. On the other hand it might be fun to make maps to challenge other players with, and that also leads to ideas like user made campaigns (which however have the same problem as Leaderboards by virtue of being finite).


• Maybe Steam Achievements.

We have released S.B.T.F. Early Access Update Tjugoåtta (28) on Steam, read the announcement here.

Here's a long post about my current thoughts on how to improve multiplayer in Space Beast Terror Fright.

I have, as many programmers probably have, avoided really getting into multi-threading.

However, I have really wanted to be able to do heavyweight stuff like generation of the levels in SBTF on another thread, in order to be able to make sure the networking doesn't block and in general make things more robust right at the start of multiplayer matches. Also it would just be much nicer to have music playing and animation happening while the level loads.

I started looking into all of that stuff today, which involved much refactoring and very careful access to the state that I was going to mutate on the loading thread. I finally got it to work, playing alternate music while loading just to prove to myself that it worked. I didn't initially render anything, but that was on the todo list.

I sidetracked into threading the creation of the "hero presentation" that is shown in the about screen, as it always irked me that going into that screen caused a hiccup. That's when I ran into trouble...

What I wanted to do, and naively thought should be simple, was to have the main thread continue rendering and playing music while a worker thread generated all the texture and loaded them into memory. This would involve a bunch of disk access and pixel manipulation to bake the individual faces into unique textures. This is the same process that it used to generate the hero textures when a mission loads, but it a bit more expensive because it is doing all 4 colors x 2 genders.

What ends up being the show-stopper is that this case calls for Direct3D9 API calls for rendering from the main thread, as well as Direct3D9 API calls for resource creation (textures) from the worker thread. This is simply put illegal unless you specify that you want to do this when the Direct3D9 Device is created on program startup. The downside is that this incurs performance overhead for EVERY API call, even when only a single thread is running (as is them most common case for SBTF).

This basically killed it for me. Apparently newer versions of D3D (11 for example) have sorted all of this much better, but I'm not willing to port the whole engine to a new version just for something like this. Also I want to keep system requirements down as far as I can.

What I will probably do is optimize the crap out of all my on-disk formats (the level pieces in particular could do with some hard core crunching) in order to make the level loads as fast as possible on a single thread.

If that isn't enough I will have to split the work up into a file access and main memory section that can be done on a worker thread, followed by a amortized "GPU resource creation queue" on the main thread that does as little work as it can per frame in order to keep the framerate at 60fps.

This really burns me, as I would expect this case to be one of the simplest examples of multithreading that you could come up with. Goes to show what I know... :P

We have released S.B.T.F. Early Access Update Tjugosju (27) on Steam, read the announcement here.

The upcoming update (27) was mainly intended to add and fine tune more options related to Power Failures, but I ended up also doing a feature that I've been wanting to do for a very long time; Hives!

There is now an option for "Infestation" (none, more, less). When enabled, the ship will be partially infested by "some kind of secreted resin" that the Beasts have (conceptually) built in order to make the ship more like home (for them). The option controls how far from the airlock the infestation will begin, and hence how much of the ship will be filled with this stuff.

This feature is purely aesthetic and has no actual gameplay mechanic, but I have found it to be a very welcome addition in how it breaks up the levels and messes with visibility. As it partially encrusts and encases the walls of the ship, you will often find it much harder to aim at Door and Fence controls as these can be submerged. Sentry control panels, due to their slimness, will also often be submerged and thus harder to find and even read.

All of this combines to make Space Beast Terror Fright even harder, not least when combined with power failures. Then again, I suppose that anyone who plays this game is already a glutton for major punishment...

Today I have expanded on the various Power Failure options, adding more settings with decreasing chance of a Power Failure occurring, as well as options where a Power Failure is a random timed event instead. There are also two new difficulty settings, "easier +" and "hard +".

I have also added tooltips to all of this stuff, so it will be easier to decode it all. Here are all the current MissionConfig options (straight from the code):

static const NameTooltip INVERT_BARRIERS[] =
{
{ "off", "Doors and Fences occur\nin normal positions." },
{ "on", "Doors and Fences occur\nin inverted positions." },
};

static const NameTooltip BIG_ROOMS[] =
{
{ "off", "Open spaces are filled\nwith alternate walls." },
{ "on", "Open spaces are left open." },
};

static const NameTooltip EXTRA_ROOMS[] =
{
{ "off", "The maze is left \"perfect\"." },
{ "on", "Random open spaces are created." },
};

static const NameTooltip BETA_ARMORIES[] =
{
{ "off", "Legacy Armory behaviour." },
{ "on", "Armories swap ammo\nwith the player." },
};

static const NameTooltip RANDOM_BREACHES[] =
{
{ "off", "Breaches occur at dead ends." },
{ "on", "Breaches may occur anywhere." },
};

static const NameTooltip SENTRIES[] =
{
{ "off", "Sentries will not spawn." },
{ "on", "Sentries will spawn at\nstrategic locations." },
};

static const NameTooltip ASTRO_CREEPS[] =
{
{ "off", "Astro-Creeps will not spawn." },
{ "on", "Astro-Creeps will spawn\nfrom Breaches." },
};

static const NameTooltip DOORS[] =
{
{ "none", "Doors will not occur." },
{ "more", "Doors will occur at\neach corridor end." },
{ "less", "Doors have a 50% chance of\n occuring at corridor ends." },
};

static const NameTooltip FENCES[] =
{
{ "none", "Fences will not occur." },
{ "more", "Fences will occur in\ncorridors." },
{ "less", "Fences have a 50% chance\nof occuring in corridors." },
};

static const NameTooltip DIFFICULTIES[] =
{
{ "easier", "Breaches: 10 - 60 sec\nSpawns: 10 - 20 sec" },
{ "easier +", "Breaches: 10 - 30 sec\nSpawns: 7 - 15 sec" },
{ "hard", "Breaches: 5 - 10 sec\nSpawns: 5 - 10 sec" },
{ "hard +", "Breaches: 3 - 5 sec\nSpawns: 4 - 8 sec" },
{ "insane", "Breaches: 1 - 2 sec\nSpawns: 3 - 5 sec" },
};

static const NameTooltip POWER_FAILURES[] =
{
{ "none", "Power Failures will not occur." },
{ "1 / 8", "Power Failures have a 1 in 8\nchance of occuring on interaction."},
{ "1 / 16", "Power Failures have a 1 in 16\nchance of occuring on interaction." },
{ "1 / 32", "Power Failures have a 1 in 32\nchance of occuring on interaction." },
{ "50% @ 30-60", "Power Failures have a 50%\nchance of occuring at\nintervals of 30 - 60 seconds."},
{ "50% @ 60-120", "Power Failures have a 50%\nchance of occuring at\nintervals of 60 - 120 seconds." },
{ "50% @ 120-240", "Power Failures have a 50%\nchance of occuring at\nintervals of 120 - 240 seconds." },
};

As all of these options are ever expanding, I have implemented saving of the local party MissionConfig (all Seed, Plan, and Rules settings) in order to let players keep their favorite settings more easily. This works for both Random and Explicit Seed settings.

I anticipate this persistence system mutating into a system where you can at any time "star / favorite" any given MissionConfig and having them all saved online. This way all players would be able to see everyone's "favorites", and also for there to be statistics based on multiple players "starring" the same MissionConfig. In this way the game could automatically offer a way to look at the most popular configurations and seeds.

I was recently interviewed by That Cooper Fellow, and we talked in depth about my origins as a developer, AAA vs indie development, and of course Space Beast Terror Fright.

We have released S.B.T.F. Early Access Update Tjugosex (26) on Steam, read the announcement here.

I think people are really going to like the way that Power Failures are evolving.

The latest iteration involves Power Failures randomly happening only when the player does something that could (in game logic) reasonably change the amount of amperage used by the whole spacecraft. This includes things like interacting with a Core / Sentry / Armory / Coolant / Door / Fence. There will probably be Rules options that control how big this chance is.

At that point the power is out; all lights are off and all functionality is down. The only way to get the power back on is to find a Breaker Box and manually reset the fuses. The HUD will now replace the distance to the nearest Datacore with the distance to the nearest Breaker Box; this in order to relieve some of the pressure on the player who may well be battling Beasts and Creeps with only a depleted flashlight.

In order to deal with closed Doors when power is out, I have implemented the ability for players to push them open slowly by simply trying to walk through them, and after opening enough to let the player through they cannot be closed again while power is out. There is some suitable grinding audio for this as the Door slides open.

This in turn required solving the issue of the player flashlight being inside level geometry and "hiding" the light altogether (something that has always been an issue), because pushing up against a Door is required to get it open and through it. This turned out to increase the utility of the flashlight across the board, a welcome change.

All of this is starting to feel pretty solid. I'm still not decided on whether or not the actual causes of power failures should be player interactions or random timed events of some combination of both.

The icing on the cake however came from some buggy behavior that happened when Beasts tried to get through Doors that were pushed open by the player. Once Beasts have line of sight to the player, which they will have as soon as a Door is open even a crack, they will move to intercept. Since the player is smaller than Beasts they would often get stuck and proceed to bash down the Door as usual in order to get at the player. Beasts bashing down Doors is however something that has never been seen, only heard, and it didn't look very good since there is no actual "bashing down the Door" animation.

What I did then was to simply have Beasts also push Doors open when the power is out. I didn't think too much about it. But then I had a power failure occur and started hearing the new audio of a Door grinding open in it's track, and I wasn't doing it! That was a truly awesome moment, because it was a Beast who had yet to see me and had just randomly bumped into a Door, but the effect was that it felt like the Beasts were being scary on purpose.

This has further implications.

Beasts that have yet to sight a player (passive) have always moved in a random fashion, and if they happen to hit a Door (with the power on) they will damage it for a single point of integrity. They might by accident break a Door in this way.

However if a Beast which has sighted a player (active) is impeded by a Door, the pathing logic will simply have the Beast try to move through the Door in order to get to the player by the nearest path. This is what causes the behavior of enraged Beasts systematically breaking down Doors to get to you.

Consider then what happens when a passive Beast happens to touch a Door when the power is out. That Door will be pushed open a little bit, even though the Beast isn't specifically trying to get through it. This results in a situation where the Door no longer completely blocks line of sight, and hence all Beasts behind that Door immediately become that much more dangerous to the players simply because they will now potentially see the players and become active, pushing or breaking down the Door (depending on what the power state is).

When emergent behavior like this happens I start to feel very good about my design choices. During the process of having SBTF in Early Access I have started to reflect on the way that game development is starting to feel very much like music production, in that when things start to work it is almost like the whole project is being "baked" much like a cake. The individual ingredients disappear and the whole becomes much greater than the sum of the parts.

I have consciously tried lately to prioritize features that will have a big effect on gameplay. Fences was a feature like that, and they also felt very "baked" once they were implemented, adding a lot of depth to the game. Further refinement to the control boxes only reinforced this.

Now with power failures, Breaker Boxes, and Door pushing I think the potential for interesting gameplay scenarios will only increase exponentially. I'm very much looking forward to Update 26 and hearing what people think about these new features!

Today I've been working on the concept of breaker boxes / fuses that the player can and / or needs to reset when there is a power failure. It is already feeling better in that the player has the ability to actually "solve" the situation of a power failure, as long as they can locate a breaker box (which are sparse).

I'm starting to feel like completely random power failures probably shouldn't happen; they should instead have a CHANCE of happening when players do some interaction, like for example turning on a Fence. Couple that with breaker boxes as the "solution" to a power failure, it is possible that it might even work that power failures MUST be "solved" by resetting a breaker box.

We'll see how it plays out.

I have reverted to the first version, and changed it so that Doors and Sentries (once active) still work when the power is out.

Sadly I don't think that it feels all the good, both because it is to arbitrary and also such a huge disadvantage to the player. With the music coming and going it also sort of feels like a carousel being switched on and off.

One good thing that came of of this however was that I think it might be cool if Doors don't actually function when power is out, but instead can be pushed open using game physics. This should allow the player to push doors open just enough to get through, but after that not be able to close them without power.

I'm going to try this speculative mechanic together with having sections of the map be without power instead of having power failures be timed events.

It is also possible that some kind of low power mode could be an option for players that want a really crazy challenge. This would require all systems to work, but I'm thinking that simply cutting down on the amount of light in the maps would be cool.

I'm currently experimenting with various ways to integrate the concept of power failures into the game, as a random event.

The first test was simply that EVERYTHING shut down, including all functionality of cores, doors, sentries and all lights turning off. As suggested by the community I also turned off the music. This was very much the effect I was going for, but the problem was that it rendered the player extremely defensive and effectively "turned off" a lot of the gameplay and related choices that the player could make. They would simply have to wait out the power failure (random time) and hope they didn't get cornered and / or run out of ammo. While the general look and feel of the feature was awesome, I felt like there needed to be more proactive options available to the player.

The next test was to have a number of "power bits" which controlled different aspects of the spacecraft and that could fail randomly. I isolated general lights, doors, fences, cores and sentries into separate systems. The theory was that this would create more interesting situations. This didn't however prove to be the case, and without my debug information showing it was hard to even understand which systems had failed and which ones were still available.

My next attempt will be to revert back to the "single power bit" but incrementally re-enable specific systems to see which ones offer better gameplay. My hunch is that Doors should at least still work to some extent when power is out, in order to allow the player to still move around. It is possible that they could cycle more slowly however, just for effect.

I think the most significant aspect of this feature will be look and feel, so it is probably important to kill as many light sources as possible when power is out in order to reinforce the feeling of being alone in a pitch black space with just your failing flashlight...

We have released S.B.T.F. Early Access Update Tjugofem (25) on Steam, read the announcement here.

We have released S.B.T.F. Early Access Update Tjugofyra (24) on Steam, read the announcement here.

I just finished the audio for the fences, and they are coming along nicely.

I have updated rules for Fences, with the major change being that everything except players is completely stopped by Fences, including bullets and beast gibs. Players will suffer one point of electronics damage for each passage through the Fence. As a result of this change Sentries can no longer see beyond fences, to avoid them wasting ammo on things that they cannot hit.

All that remains really is figuring out all the permutations of Planner options for fences. I imagine a setup where it is possible to control the enabling of Doors and Fences individually, plus begin able to invert where Doors and Fences appear Fences appear (which is not the same thing). All of this means many more maps total as well as enabling fine grained control over difficulty beyond what is controlled by the Rules alone.

The game definitely feels deeper now that I have had the chance to play a while with Fences, and also a little bit easier / less stressful as it is now possible to create safe havens for the player at multiple points in the level. It is of course best when making for such a safe zone between two fences to switch them off before passing through, but being able to choose to just run through the Fence and suffer the one point of electronics damage adds a nice last resort strategy, especially with Beasts hot on your heels.

I have been working on a pretty significant feature, originally suggested by the community I think, namely Security Fences.

These fences are laser grids that will kill all Beasts and Creeps that come into contact with them, and as such act as indestructible barriers behind which the player is perfectly safe. Fences have the same kind of control boxes that Doors do, and are interacted with in the same way. Fences however are toggled instantly.

The downside is that the player will suffer electronics damage when in contact with the laser grid of a fence. If this happens, the player is always kicked out the other side of the fence at a safe distance after suffering a single point of electronics damage. This is to ensure that you don't get caught in the fence and die very quickly as a result.

All of this leads to interesting trade-offs. For example it is possible to be too close to a fence when activating it, causing immediate damage and a kick to the player. It takes some practice when fleeing through fences to get the timing of activation just right. Another interesting strategy is too activate all fences behind you, and if you are forced to flee through an active fence you can simply choose to take the electronics damage hit. The same rules as for Sentry damage and Creep damage apply, so as long as all your systems haven't been knocked out you will survive passing through the fence.

Fences are always put in as the last thing in a map after all walls, doors, cores, etc are laid down by the generation algorithm, and are always an addition / don't replace anything else except for empty floor cells. The algorithm tries to put in as many fences as possible in a diagonal raster with a spacing of a single tile, but as the map can be pretty filled up with other things this doesn't result in too many fences being placed. The rule is also that fences can only be placed in single-width corridors, so you won't see them in big rooms. The number of fences depends highly on the specific map geometry that you happen to roll, with some corridors having several in a row while others have none at all.

There is still some work to do on audio and general aesthetics, but it already seems like fences both add new interesting strategies as well as potentially making the game somewhat easier.

We have released S.B.T.F. Early Access Update Tjugotre (23) on Steam, read the announcement here.

I've been pushing hard towards a cleanup of the internal Plan representation, both in preparation for experimental external tools for generating Plans as well as an integrated mission editor.

The main change is related to data compression and removing ambiguity from the data format. Not that the Plans ever took very much memory (around 1 kilobyte), but I've become quite the stickler for representing program state in the most compact and unambiguous way possible. For example previously each cell of the Plan contained information about wall/floor along with a separate piece of data for the type of core, sentry, etc that might be placed there. Since it isn't logical to have cores / sentries inside of solid walls, I wanted to remove this possibility.

Also the concept of "big rooms" was always an implicit calculation based on specific data that could arise, namely a "floor" cell completely surrounded by other "floor" cells. When big rooms are enabled, these cells will remain "floor". When big rooms are disabled, all of these cells are converted to what we call "tech", which is basically "wall" with an alternate tile set.

What I have gained now is to have each legal data value represented by a fixed numerical constant, with the addition of having a bit that signifies "floor". "wall" and "tech" are now also explicit values, so even if the existing generation algorithms still do the trick to replace "floor" with "tech" in specific cases, we get the bonus of being able to place "tech" anywhere when a manual editor is implemented.

There are a lot of other edge cases that the generation algorithms work to avoid and that the code relies on, and a manual editor will probably allow the user to break some of those cases, but we'll sort all of that as it arises. For example it will probably be possible to place multiple airlock doors, which are indestructible, but this might be a good thing that can be used for some creative level design.

We have released S.B.T.F. Early Access Update Tjugotvå (22) on Steam, read the announcement here.

We have released S.B.T.F. Early Access Update Tjugoett (21) on Steam, read the announcement here.

We have released S.B.T.F. Early Access Update Tjugo (20) on Steam, read the announcement here.

Just to be clear for those of you who follow this feed; I have implemented a very basic A.I. "input bot" that plays the game as best it can using the same interface that a human player has.

This is not intended to be a feature of the game but rather to aid in initial testing of networking features. The idea is run one or more input bots while testing on both the LAN and Steam networks, thereby freeing up developers who might be otherwise occupied and don't have time to act as monkey testers.

This is a significant improvement when it comes to quality control, because I don't want to have to worry about breaking networking determinism all the time.

You didn't hear it from me, but maybe in the future these bots could be expanded to be actual viable team members for local co-op games... :)

We have released S.B.T.F. Early Access Update Nitton (19) on Steam, read the announcement here.

It works if you have visibility information...

Hearken to the legacy of The Carmack; indoor scenes tend to have high depth complexity even if you are doing frustum culling, because often you can be staring at a wall right in front of you, but you are actually looking right across the entire scene and doing tons of (conceptually) redundant processing.

Any light pre-pass renderer I have done, including an uncompressed version today that requires support for multiple render targets (MRT), simply spends too much time calculating lighting information. Most of that is stuff that doesn't even affect the final pixels, due to the depth complexity of the scene coupled with the fact that I'm doing the reverse culling / inverted depth test stuff to render the 3d light shapes. 2d light shapes are better, but they require lots of fudging with z-bias, and that isn't perfect.

What I ended up trying was a quick and dirty intersection test based cull of what lights the viewpoint can actually see. This is very rough currently (has some false positives), but it got the rendered lights from 6000 down to 60 in some extreme cases. I am going to do a more lenient version that is precalculated (no more tracing thousands of lights) and it looks like we should be fine.

I'm thinking that the final version of the renderer will exist in both a low quality compressed 32 bit G-Buffer version for GPUs that don't support MRT, and a hi-quality uncompressed (32 + 16 but G-Buffers) version for everything else. The uncompressed MRT version has the ability to calculate the specular term in the initial geometry pass (storing it next to the normals), whereas the compressed version has to do that in the final composite (because all the channels of the 32 bit G-buffer are used for compressed normals and compressed depth), but I'm still not sure which one performs better.

As mentioned before we will most likely look into combining some kind of fake global illumination into the lighting mix. The current renderer has something like that due to how the lighting is baked into textures, and there are a lot of cases where it just looks better than the analytic solution. I think this is mostly because completely black spaces in the lighting are jarring to the eye, and having some kind of fill light (apart from a simple flat ambient term) just seems to look better.

One might argue that since the current renderer (with texture lights) performs better and also has the fake global illumination we should simply stick to that. It kind of depends on what we want to do with the dynamic lights, but certainly if I cant't get the PVS stuff working to satisfaction (and without introducing a bunch of new binds) the light pre-pass renderer is out due to performance reasons alone.

There is a fallback solution where we do a hybrid with the baked lighting for everything static, but do the lighting as a pre-pass regardless. This will allow us to add a more limited (sane) number of dynamic lights for the things that we were originally shooting for; per-player flashlights, muzzle flares, and lights on projectiles. This would probably work just fine, and also has the added benefit of simplifying the current forward rendering uber-shader I have to deal with. I'm pretty sure that even if we do crazy dynamic lighting stuff we can get away with re-baking the fake global illumination once per frame anyhow...

I finished my first Light Pre-Pass renderer today, in the process learning how homogenous clip space actually works...

3d light shapes work the best, but the are the most expensive because there is lots of redundant filling going on. Camera facing quads work much better, but need to be managed to handle perspective distortion and cases where the viewpoint is in the light.

In any case both light types are too expensive for our target. This is much due to the fact that we are shooting for 60fps on 2560x1440, and the light stuff is very costly per pixel. Downsampling the geometry and light buffers (/4 pixels) works of course, but it really makes everything look quite muddy. Proper anisotropic filtering might help there.

I will try some more optimizations, but before that I want to try a version which uses fatter g-buffers; one for normals + specularity and one for depth in order to avoid compression. Currently I am packing both normals and depth into a 32 bit buffer, and reconstructing specularity in the final compositing pass. I want to see side by side if the compression / decompression is worth the memory tradeoff.

We are finding ourselves in a bit of an artistic dilemma with all of this, as we find that there are a lot of aspects of our cheap baked solution that look more like fake global illumination, and this stuff is missing in the new "proper" light-pre pass lighting. Hybrid solutions may well arise...

In hindsight it seems like my idea of baking lighting into seven 3d textures wasn't such a bad one after all...

I have never seen myself as a "graphics programmer", as in my career at big game studios I tended to work on everything EXCEPT graphics. I think I need to revise my self-image.

A little while back I hacked together a "poor man's Physically Based Rendering" in order to see what it would entail. We have been getting into using both Quixel's Suite and Allegorithmic's excellent Substance Painter, and the value of "normalizing" how content should work was immediately apparent to me. I did the basic code for a PBR-style material system, but we have yet to integrate it into Space Beast Terror Fright as it would require us touching a lot of content.

Now I find myself looking into the very broad field of deferred rendering. It has irked me for a long time that we are limited in how many dynamic lights we can have in the game, namely one. We try our best to hide this fact, which involves juggling both the local player's flashlight as well as all player muzzle flares and sentry muzzle flares. Rarely you can see artifacts when something firing far away from you "steals your light".

All of the main world lighting, including interactive cores, is baked into 3d textures that work as a per-grid ambient cube. Happily this is extremely low resolution (33x33x3 for the whole map) and as such it is possible to re-bake all of that every time a core is brought online / offline. The problem is that our use of normal maps in our lighting equation requires that we know where lights are coming from, so we have a combination of one texture for uniform light as well as one for each of the 6 axes (xyz positive and negative). This allows us to approximate where the light is coming from when doing lighting with the normal maps, even though it is not completely correct.

All of this combines to LOTS of texture reads per pixel in a forward renderer; 1 uniform light, 6 axis lights, 1 albedo, 1 normal, 1 emit, 1 fake environment map / specular = 11 texture lookups per pixel. Combine that with options for turning off normals and specular, as well as being able to run "low quality lighting" which is just the uniform light pass, and you get shader permutation hell. All the permutations are still written by hand as multiple techniques in a big ubershader. It is pretty painful.

Most AAA game developers seem to be doing some form of deferred rendering these days, with the big deal being the ability to have more dynamic lights. I have shied away from this kind of things as I neither prioritize super-high end graphics nor feel like I have the skills for it. However Space Beast Terror fright as a project has sort of been nudging me more and more into graphics land; while not "realistic" per-se it is definitely the most high-end graphics programming I have ever done.

So just the other day I started thinking about what deferred lighting might entail, again most specifically to "solve" the issue of needing more dynamic lights. The first priority is to have each player have their own flashlight in co-op multiplayer; we think that would look really special.

I read up on the subject and finally found a blog post that was sufficiently "simple" for my taste. It was also several years old. That is something that I tend to look for; the simplest possible solution that gives me the functionality that I want, at the cost of the fewest resources. I certainly take pride in the community saying that Space Beast Terror Fright "runs on a potatoe", and the game is also hard-coded to require the machine to be able to sustain 60 frames per second at all times.

With the gracious help of Wolfgang Engel over at Confetti Special Effects as well as Martin Rystrand at Ubisoft Massive I have managed to hammer together the basis of a "light pre-pass" renderer, still staying on my target of DirectX 9.0c on shader model 2 (a suitably archaic target platform). I have some issues to sort out regarding how to best represent light shapes, and I am still worried a bit about performance, but in general it looks like it will be possible to remove ALL baked lights (several thousand per level) from Space Beast Terror Fright and switch them to dynamic lights.

If I manage this it will enable pretty significant changes to the game. Of course allowing each player to have their own light is our first priority, but it also means that every single bullet and every single spark can potentially have their own dynamic light source. It will also allow us to modulate world lights based on game events, like pulsing and strobing when the reactor is overloading. We are also thinking of adding game events where the power goes out completely for a limited time, leaving the player with only their own flashlight in a pitch-black spaceship filled with nasty beasts. Finally we are also thinking about having bullets actually damage ship systems, permanently blowing out lights in a shower of sparks...

More info and pictures when I have something to show!

We have released S.B.T.F. Early Access Update Arton (18) on Steam, read the announcement here.

We have released S.B.T.F. Early Access Update Sjutton (17) on Steam, read the announcement here.

Today we did a whole bunch of experimental work on trying to make our materials be more towards Physically Based Rendering. This is largely motivated by our move towards Substance Painter, as well as a desire to be able to control our materials better.

We have just released S.B.T.F. Early Access Update Sexton (16) on Steam, read the announcement here.

I have been evaluating Substance Painter the last week. My texturing workflow before Substance Painter was: I created a normal map in Quixel NDO2, Texture base (albedo and specular) in Quixel DDO, jumped to Photoshop and did a lot of manual stuff and finally emits. Now I can use one program and don't have to do anything manually and the result is also much better. I'm working on a new weapon that we plan to show you soon!

We have just released S.B.T.F. Early Access Update Femton (15) on Steam, read the announcement here.

After squashing a ton of bugs we finally have a release candidate for the next update (15) ready for internal testing tomorrow. Fingers crossed!

After trying a whole lot of alternatives, we managed to implement a version of our new community features on top of the Steam Lobby system, and it is looking pretty good. Some final fixed, but then we will proceed with internal testing and look forward to an update in the coming days.

On another note; I never thought I'd write this, but we are looking into a more modern Physically Based Rendering approach. Not that our renderer will be state of the art, far from it, but there are certain aspects of the emerging "standard" that are attractive. In particular we are looking at tools like Substance Painter to radically increase our output as well as significantly increase the quality of our materials.

We we will probably do is approximate actual PBR by supporting the Metalness / Roughness approach. Our lighting will still be pretty arbitrary, and our reflection model will be approximated, but we will need to get the basics of Metal vs Non-Metal (matte vs shiny) combined with Smooth vs Rough in there (sharp vs blurry reflections) This will allow the completely awesome real time previews available in Substance Painter be at least somewhat representative of the in-game look of materials.

Our initial tests in-game have already inspired us a lot, as we can already see the potential of different roughness values in our existing materials.

I've have been hard at work lately ripping out our technical concept of a "lobby" and replacing it with a "pub". Let me explain.

In regard to the game's need to punch NATs and in general let players send network packets directly to one another, Steam has been a great help. My initial take on the Steam Lobby system was that such a "lobby" was a good one-to-one match with our game's concept of a pre-mission "party". Time has however shown that a we need some kind of "meta lobby" in order to let our players find and talk to each other, and from there coordinate how to team up into specific parties.

To this end we have removed our use of lobbies and are instead (conceptually) just throwing all the players into a big public room. This happens as soon as you select a network; our prototype is the LAN network implementation, and there will also be a Steam network implementation. From there you are automatically in the public chat for that network, and you will be able to see every single player who is currently on the same network.

The creation of a party is technically much simplified, but it will basically look the same as it has before. You can still only join a single party at a time, but you will always be able to see all players on the network and chat with both the public channel as well as your party.

This changeover also has the benefit of keeping players matched to their characters, so you won't see the swapping that is currently happening with the current Steam implementation when the members of a party change.

We are currently looking at what the best back end solution might be for the Steam implementation. The Steam Lobby system isn't quite right technically for what we want to do, so we will be looking into a proprietary solution running on some external dedicated server. Once this community server is up, we will probably do an intermediate update.

In the longer term I want to look into consolidating all of the local and network options into a single experience, with the ultimate goal of being able to mix and match local and networked players in the same party; for example two players on one machine and two players on a remote machine. This has been requested by the community and it turns out it might actually be doable.

We have just released S.B.T.F. Early Access Update Fjorton (14) on Steam, read the announcement here.

Mad has, being smarter than johno, actually had a real vacation in Italy this past week. johno did his best to stay away from the codebase, and managed pretty well.

Now we are both back to work on SBTF, and looking to get an even more optimized version out there as soon as possible in hopes of making general performance as well as networking even better.

I've been consciously trying to take some time off from nornware these past few days, seeing as I've been working flat out since January.

It's not going very well; I find I can't really stay away from creative projects involving programming and / or music, but I'm forcing myself to NOT work directly on SBTF.

I will be back at it in a few days.

Implemented the sync point, tested internationally again, same problems with sync at the beginning of missions. Scratching head. Back at it!

We did some international multiplayer testing this evening, and while things seemed to work we're seeing some crazy sync spikes right at the beginning of the mission. This is kind of funny, because the optimizations that we have done actually make this problem worse, as this allows all machines to simulate and re-simulate "more efficiently" and thereby cause sync to quickly diverge even more than it ever could before.

What is encouraging is seeing these enormous de-sync problems and then seeing the code sort all of it out after a little while. This suggests that the algorithms are solid.

In hindsight it is kind of obvious that different machines will load any given mission at different rates, as a function of hard drive speed, CPU, cache, etc. I'm thinking that because of our crazy prediction algorithms we need to put in a sync point right at the start, and hopefully that will solve this problem.

The optimization work we have been doing lately was motivated, as previously explained, by details in our new network implementation. After doing all the infrastructure work to get detailed and useful program timing / profiling in place I have to say it is a toolset I have been missing for a long time.

There were a lot of things that regressed performance-wise as a result of internal restructuring required by the network sim / re-sim stuff, but now we have been able to go through all of that and optimize it for the current case. The game should in general perform much better now. The next thing to see is if it is enough to make the new networking solution work for everyone.

The whole optimization thing is very open ended, and you can always try to squeeze out more, but we are in a pretty good place right now. We will be doing more regression testing starting tomorrow, and expect being able to push a new update in the coming days.

Well into profiling and optimizing the game, I found out that polling the XBox 360 Controllers the way I was doing was crazy expensive.

This is one of those things that I NEVER would have suspected or checked for without proper timing of the code.

I have been doing a lot of timing and profiling on the code base recently in order to figure out what is REALLY the cause of performance problems (not speculating anymore).

I had previously been focusing on the rendering code, assuming it was the biggest issue, but now that I've actually timed the code it turns out that the simulation stuff needs a lot of optimization work. This fits with the observed performance problems in the new multiplayer code, since it is doing a lot of extra simulation work. As I noted in the last update announcement, this is the big speculative part of the new network implementation.

Looking further into the code I found a lot of really stupid linear searches going on, and immediately recalled that this was one of the aspects of the new structuring of the simulation that was required for the new networking to function. So now I need to go back and figure out ways to keep the basic structure but also avoid doing lots of slow searches.

It's kind of a pain, but also really interesting how there are so many interrelated parts in game development, and how finding the right trade-offs is where a programmer spends a lot of time.

We have just released S.B.T.F. Early Access Update Tretton (13) on Steam, read the announcement here.

We have just released S.B.T.F. Early Access Update 12 on Steam, read the announcement here.

We have just released S.B.T.F. Early Access Update 11 on Steam, read the announcement here.

I posted this explanation here, but thought it might be interesting to be a bit more visible about it.

In the interest of full disclosure! :)

There are two aspects to all of this which are currently tightly coupled.

Rendering Performance
The game currently absolutely requires that you can run the simulation and render at 60Hz, otherwise it will drop frames. Sometimes this only happens intermittently, depending on what is on the screen, but if you are consistently missing the frame time the game will effectively run at 30Hz and will feel like slow motion (it is running at half speed). This is because it will drop an entire frame; input, simulation, and rendering.

The game is highly bound by graphics performance, and there are a lot of visual options that can be turned off if you are having issues with slowdowns. A more heavyweight option is to enable the 30 FPS option, which will run input sampling and simulation at 60Hz but only render every other frame. Thus it will not slow down, but the visuals will appear more choppy.

All of this aims to reduce the load on the GPU by doing fewer calculations on fewer pixels overall.

I do not expect this aspect of the game engine to change much. There are HUGE benefits to running everything at a deterministic fixed rate, and having the rendering just follow along at 60Hz is the simplest thing.

Some games will enable rendering decoupled from simulation in order to allow for HIGHER frame rates than what the simulation might be clamped to, but this is a lot of work and effectively requires an extra simulation for things like animation, particle effects, etc.

If this was enabled for SBTF as it currently works, you would possibly get a higher frame rate (if your machine could handle it), but you would only be drawing the same picture several times in a row.

I suppose one thing that could be realistically attempted would be to only drop the rendering (and not the simulation) if 60Hz cannot be maintained. I have never tried this, but I suspect you could get it to try to keep 60Hz and then just sometimes drop below that without impacting the speed of the simulation. Just speculating...

Of course, your machine absolutely needs to be able to sample input and run the simulation at 60Hz no matter what, but I don't expect this is be a big issue.

Networking
The game currently uses a input-synced peer to peer architecture. This means that every machine in the party samples and sends input for a given simulation tick to everyone else before simulating that tick. In order for this to work at all, the game buffers 4 ticks of input ahead of the current simulation tick, so what you are doing at any given moment will be used as input to the simulation 4 ticks in the future. This is why networked play feels a little bit mushy, even on a local network.

This means (as people have discovered) that latency needs to be under a certain max, otherwise everyone is waiting for inputs to arrive. One can trade this stuff off; buffer more and you are more robust for high latency, but your input feels even more mushy / out of sync.

This also means that if ANY machine in the party cannot keep up, then everyone is affected by that machine. The weakest link in the chain etc.

Client / Server architectures combined with various prediction techniques work to get around the pitfalls of the P2P architecture, but there are lots of other tradeoffs. We are trying hard to balance all the issues of player to player visibility, Steam Lobbies, NATs, etc with the specifics of our game design in order to make the best technical tradeoffs. Not to mention limited development resources.

Without getting even more technical, I do have a clear idea about how to leverage what we currently have in order to deliver a more solid networking experience. Perception is everything, and people expect to play a game that feels smooth on their machine, as well as the fact that they will always care the most about the responsiveness of their own input and player avatar (as opposed to the other players in the game). The current model is really much more fair to everyone in that regard, but that's not how psychology works.

This is high priority to us, and while the game is designed to be equally playable / functional in single player, local co-op, and networked multiplayer, we understand that robust networked multiplayer is a big deal for people.

More info on this as we roll out the updates.

We just played some SBTF over the internet with Space Game Junkie and friends.

This was really our first test of truly international networked play, and while it wasn't as good as we would have liked (from a purely geeky coder point of view) it actually worked to some extent. We are very motivated at this point to make the networking more robust for these kinds of situations, and we have a concrete plan to that effect.

We would like to thank everyone involved for putting in the time and encouraging us in what we are trying to achieve!

/mad & johno

We have just released S.B.T.F. Early Access Update 10 on Steam, read the announcement here.

Today we did audio passes on all our new cores and monsters, and things are sounding good! With all of the new stuff the game is more crazy than ever!

This coming update (Early Access Update 10) has taken the longest to date, but it also includes the most significant improvements to gameplay since the initial Early Access release. We are committed to making all interdependent pieces feel cohesive and polished.

We will be doing final testing of Early Access Update 10 tomorrow, and if nothing untoward happens you can expect a release sometime during the day.

Thanks for all your support and patience!

We're right in the middle of moving our offices, but we managed to squeeze in a work day today. We are finalizing HUD updates, new cores functionality and appearance, revised color palettes, and new enemies. Things are looking good, and we will be pushing a new update as soon as possible.

The previous log turned out to be a bit premature after all...

We actually switched back to having a separate core / machine / thing for Ammo again, as well as a new one for Repair. Repair needs more work, but the mechanics of the Ammo core ended up being a bit different from the regular Datacore / Coolant stuff. We think it works pretty well.

We are still torn about whether or not Repair should have unlimited capacity or be one-off, but we will be looking into that next.

With the addition of two new "cores" we are running into some color palette issues, and things are currently looking a little bit too much like a space disco for our tastes. We need to consolidate lots of stuff here.

The HUD is getting some attention also. We have removed the arbitrary download text removed and the mission / combat log moved over to the left side instead, as well as adding many more notifications. All players now get the exact same notifications; our thinking is that the mission log is more of a global thing, and this also helps to propagate information throughout the team.

We will be moving our offices in the coming week, so there will be a bit of a delay, but we are pushing hard for a new update as soon as possible.

We've been experimenting a lot lately with a new enemy type, and we're at this point pretty confident that it will stick. The mechanics are very different from the Beasts. Initially we will have an option to turn it off, as it does change the gameplay somewhat and we want to see if people like it or not. More in depth info when we roll out the next update.

We have also been trying to move the ammunition pickups out of the datacores, but honestly this really didn't work very well so we reverted to the previous model of getting everything from the datacores.

We have however moved the electronics repair functionality out of the datacores and into a new "repair core". These are single use only, and are statistically as likely to show up as the datacores, so there are many of them.

All of this is really in support of the new enemy type which basically increases the all around chaos of the game. The sentries go nuts trying to take these guys down as they are very numerous and agile and navigate differently from the way the beasts do. This has all resulted in far more instances of sentry friendly fire, and while we love the chaos we want to make sure the player still has a fighting chance by assuring there are lots of opportunities to repair damage.

There are still a bunch of rough edges to fix. More info with the next update.

We have just released S.B.T.F. Early Access Update 9 on Steam, read the announcement here.

As a result of recent work on consolidating the local and network experiences, a lot of refactoring and discovery has been done on the concept of a Party. This has led to a lot of user interface work, and most recently this has led to some work on new and existing mission generators and related options.

The next update will see a much clearer user interface, with the clickable / interactable parts actually looking like buttons, spinners, and combo boxes. This stuff is very much a result of the need to add more and more options to the advanced party settings screen.

We have now exposed options to the existing Crawlers mission generator (now renamed to Corridors), including the options to turn off Doors and Sentries, as well as an option for bigger rooms. Turning off Doors has a huge affect on the feel of a mission, both due to the fact that you have fewer strategic options but also because Doors are a significant light source.

We have also added new generators called Dungeons and Mazes. These result in more cohesive collections of rooms and classic mazes, respectively, each with a set of options. Although we don't feel that these offer gameplay of the same quality as Corridors, we are including them regardless in order to let the community experiment. What we suspect at this point is that maps need a lot of intersections and alternate routes in order to work well with the current Beast A.I., and we will be experimenting with more generator algorithms based on this observation.

With the addition of these new algorithms in conjunction with the available options, the number of available maps to play has increased by tens of billions. Procedural stuff is awesome.

We have also added a new procedural music theme to the game, more in the vein of progressive heavy metal. Also, we have invited a number of composers to create their own music themes, in the hope of having as large a musical variation as we are aiming to have in the graphics styles. More graphical styles will be included as well in the next update.

The nornware dev team plus friend plays some SBTF co-op after a few beers. Sneak peeks include some new level styles, ricocheting bullets and some new music.

We have just released S.B.T.F. Early Access Update 8 on Steam, read the announcement here.

We are still working out all the kinks of the changes in networking persistence, character progression, etc.

There are a lot of fun quirks in the rules pertaining to Steam lobbies, in particular access rights when it comes to various bits of data. Apparently you can read all data registered in about a lobby even if you aren't a member, but you cannot see the Steam IDs of users in a lobby, nor can you see data that they have personally registered in the lobby.

This has some bad implications now that the lobbies are persistent for the entire lifetime of a given network game / party. Specifically we cannot externally see the in-mission state for specific players, and hence we cannot know if the party is OK to join (i.e. in the lobby state) or not.

...at least not based on my current implementation. I will have to do things differently...

We're still hammering away at the general robustness of the multiplayer experience, and that has in general affected how the whole "playing in a group" experience of SBTF. We have consolidated a lot of the local co-op stuff with the network / multiplayer co-op stuff so that the experience is the same. In any given networked game, like a local game, your party will stay together with full character progression, stats, upgrades kept, etc.

We are also fixing some of the irritating implications of the peer-to-peer networking; things like the game locking up when someone is in a menu, not letting individuals drop out of the game, etc. We are still not sure that the peer-to-peer model will stay, but we need more testing and data to know for sure before we make any major architectural changes.

The coming new weapon, the shotgun, is completely awesome in our opinion, the HUD weapon model is done and it is getting final texture polish in the days to come. More audio polish too. It maybe isn't the safest weapon to use in the context of a game like SBTF, but it feels really powerful and adds some interesting dynamics now that the team can carry different weapons. We plan to experiment with other weapon types as well moving forward.

Today we got the basics of networked "Parties" working, meaning putting a team together in a lobby and having that team stay together across missions. Character progression now works the same as it does in local co-op, but the characters themselves are unique to the party / lobby in question. Character upgrades are carried over between missions as long as the Party stays together, but the characters do not persist once the party / lobby disbands.

Playtesting this brought up a lot of ideas of some kind of Party Campaign. We're thinking that you could have a fixed sequence of maps to defeat, and need to keep chipping away at any given map with new recruits until you defeat that map. This would of course with in single play and local co-op as well.

Hardcore mode could be that your party is disbanded / the campaign is scrubbed if all team mates die, but as long as someone survives the campaign is still deemed viable, or something like that... :)

What that actually got us thinking about in general was reinforcements in all forms of co-op games. Our initial thoughts we're some kind of waves, where dead players could respawn as new recruits in the airlock at given time intervals. A better version (we think) would be having teleporter stations that only sometimes are available within a given mission, and you can interact with them to beam in reinforcements (dead players that respawn as new characters). This is in keeping with a lot of things that we have found to work best as fixed features of the map, like Sentries. Repair stations (to fix Electronics Damage) also follow this axiom.

In any case, we are looking at getting a new update out as soon as we can validate that the Party progression works properly as well as some more polish to the new shotgun class (which is a blast, pun or no!)

Today I did a quick pass on shotgun audio as well as put in all the code needed to be able to select "classes" in multiplayer. You can now select "rifle" and "shotgun", with "shotgun" being our new experimental weapon type.

With the audio in place the whole experience started to feel really really good, and the initial balancing of using 8 x ammo and 1 / 8 x rate of fire seems like it is a solid place to start. The whole dynamic of running around with a team with varying weapon types is awesome.

Coming soon to an Early Access Update near you!

We did some initial tests with a shotgun-type weapon yesterday. What we did was have the regular weapon fire regular bullets in bursts of 8 with a bit of spread, and the rate of fire was simply 8 times slower. As the original weapon has varying fire rates per ammo type, so does the "shotgun".

This is kind of interesting in play as it give you more power per shot, but also forces you to time your shots better. It is also very hard to deal with massive "trains" of Beasts.

This is in any case the basic framework for experimentation with different weapon types.

We have just released S.B.T.F. Early Access Update 6 on Steam, read the announcement here.

We have just released S.B.T.F. Early Access Update 5 on Steam, read the announcement here.

Happily the core networking stuff worked for both cross-city and cross-country plays today. This doesn't necessarily mean that the peer-to-peer architecture will hold up under all "real world" internet conditions, but it looks like it is worth a try before seriously considering an architectural switch (if necessary).

Granted, we do have rather good internet infrastructure here in Sweden, and we ideally want to be as robust as possible for varying conditions / connection qualities.

There is some Steam Lobby logic left to hammer out, but as soon as that is sorted I think the best thing is just to get it into peoples hands for serious testing - after all, that's what Early Access is for, and we have limited capacity for "real" testing in-office anyhow.

Today we tested Steam Lobbies and Networking at the office with good success, with support for both public and friends-only games. There are some small adjustments to make but we will be testing non-local play (across town) tomorrow, followed by cross-country play. If that goes well we are in a position to push out "real / proper / online" networking in the very near future.

It it DOESN'T go well there are some adjustments that can be tried, but I suspect / speculate that we may have to switch the networking architecture from peer-to-peer to client-server. I am however confident that we will find the architecture that best fits the game and has the right trade-offs.

We were getting very angry at the perceived low quality of Quixel NDO local maps today, before doing some research and realizing that there was some bad math going on in our shaders... Bad coder, no cookie. Regardless of my bad math, I still suspect that some of our maps are not normalized, and will be looking into that programmatically.

This resulted in a subtle but noticeable quality improvement in all of our local / bump maps. This will probably result in us having to go back and tweak the aesthetics a bit, but overall it's a good thing to have that extra bit of fidelity. Currently it's in there as a user option (but enabled by default) because it adds a few cycles per pixel, and some people might not have the fill rate to spare.

With this in place I also finally fixed the uv problems on the main screen shader. Some people were reporting weird tearing going on at regular intervals, like a beat frequency, and I finally fixed that. The result overall (along with the local map fix) is that the game feels like it is running at a much higher resolution.

The way we build our levels results in lots of polygon edges in the image, and since we don't have support for any kind of full screen antialiasing all of todays fixes combined for a much more pleasing and crisp experience overall.

We updated S.B.T.F. on Steam Early Access yesterday, read the announcement here.

We've finally integrated our new hero characters, here's a shot of all the versions available.

Today has seen more significant testing of LAN multiplayer, and things are looking good.

We have also reworked the pre-mission screen tiday to better expose all the options, not least the ability to select explicit mission seeds. Cosmically we found DEADFACE to be especially hard.

All of the single player mission options are available in LAN networked mode as well. The only thing that we are currently not supporting is any kind of character progression between missions, as there is more design work to be done there, and we did not want to risk messing with people's hard won local characters in networked games without first thinking all of this through. Rest assured however that we will figure out a satisfying approach to networked character progression in the coming updates.

We expect to push an update tomorrow.

Hi all,

We know that many people are anxiously awaiting networked multiplayer, so here's an update of the current status as well as our roadmap moving forward.

There have been some insidious bugs (related to determinism) in the network stuff that have caused it all to take longer than I would have hoped, but stability and solidity is very important to us so we have persevered and happily today things finally stabilized.

Our current implementation as of today is a peer-to-peer architecture. The reasons for this are both simplicity (though after all the problems with determinism one might beg to differ) but also because this automatically (on a technical level) gives us support for replays and save games. It will also potentially be possible to support "continue" functionality, so that you could watch someone elses replay and choose at any point to continue playing the game yourself.

We currently only support LAN. This is because we have not yet started using Steam's stuff for lobbies and NAT-punch thru, which will be required to play over the internet as well as to find and play with your Steam friends. We have limited ability to test as there are only 3 of us at the office, but it looks solid as of today. I think the best thing will be to put an initial update out that supports LAN in order to allow the community to help us test it. Remember that testing software can only ever prove that said software HAS bugs, not that it HAS NO BUGS, so lots of testing (on more machine configurations than we have ourselves) is required.

The next step will be to implement said Steam lobby and friend support and allow you all to play over the internet with the current peer-to-peer implementation. I highly suspect that the current implementation may not work well in a non-LAN environment, but I'd rather test it than speculate. If it indeed proves to be unsuitable for internet play we will implement a client-server architecture which may or may not be used for both LAN and internet play.

Furthermore we have added the ability to specify custom mission seeds. These seeds are 32 bit unsigned integers, and the game now allows you input them as 8 digit hexadecimal numbers. For example DEADFACE, BAADF00D, or 1337FEE7. This means that you can replay any mission as many times as you like, as well as share your favorite seeds with your friends.

We expect to expand on this system of explicit seeds even more, including things like "map of the day" and even "campaign of the week" with campaigns of perhaps 10 missions of increasing difficulty. With achievements. Awesome.

We expect to push an update in the coming days.

Looking forward to selecting a map of your choice?

Hi everyone,

We've just now spent a few hours hammering away at networked multiplayer tests (3 players on LAN), and it's looking pretty solid. The experience is CRAZY intense, with all the awesomeness of local co-op with all the advantages of full-screen display.

We need to do some more tests over the internet to see if the current networking architecture will hold up to more real-world connection qualities, but we will definitely roll this out to Early Access just as soon as humanly possible.

There are also some pure design issues to deal with, like what characters you play with in networked mode, whether or not those characters can / should be usable in local play, how team lobbies should work, etc. We are also talking a lot about some kind of official leaderboard system for both solo and team play, and that also has some design implications to work out.

All in all it's looking very promising!

Hi all,

We are making a tiny detour from SBTF right now to get UfoPilot : Astro-Creeps Elite (ACE) ready for immediate Steam launch. ACE was originally released in 2011 on BeamDog, later on Gamersgate, and was recently greenlit.

ACE will be a full / final / not-Early Access release, and will feature integration with Steam Leaderboards. It will thereby be possible to prove that you are indeed the best ACE player in the universe.

Other minor tweaks include a change to from 16:10 aspect ratio to 16:9 aspect ratio. The reasoning behind this is that most screens are 16:9 these days, unlike the laptop I originally developed on. This technically results in a slightly larger game field being mapped to your 16:9 display, though I doubt anyone will notice. The big deal however is that the backdrops will no longer have squashed planets; they will be round!

There has been some contention regarding Sentry friendly fire in the game. This feature came for free when we implemented player vs player friendly fire since bullets are all the same in the game. We initially felt that it was very much in the spirit of the game to make Sentry fire dangerous to the players. Of course, they have always and continue to try to avoid firing when a player is in their field of fire.

With the introduction of the highly experimental game mode option to have Breaches appear randomly in the map we however found that instances of Sentry friendly fire increased and in many instances felt quite unfair. It is technically always the case that the player is to blame, as the only way to get shot is to be mobile within the Sentry field of fire. If you are static and obstructing a Sentry, it will never fire and just angrily beep at you.

The edge cases have always been what happens in the short time the bullet is in flight, as well as the cases where the Beast is between the Sentry and the player. This is clear shot as far as the Sentry is concerned, but there will often be more shots fired than are required to kill the Beast (as bullet damage is random to some extent), and as a result the extra bullets will often kill a player who is in a bad position.

This has been a hard problem to solve, as simply removing this feature seems (to us) to be dumbing down a nice hardcore aspect of this game. I have however come up with possible alternative, as follows.

Sentry bullets will no longer kill the players, but instead they will cause large changes to view angles on impact. This significantly messes up player aim. In addition they will push the players in the same way as they do with the Beasts, so getting shot may well push you into a bad position.

The big change however is the introduction of Electronics Damage. There are now 5 systems that control various aspects of the player Heads Up display: Flashlight, Text, Visor / Icons, Weapon, and Tracker / Map. When a Sentry bullet strikes a player, in addition to the above noted effects, a random system will become damaged, as follows:

Damage to Flashlight will completely remove the player light. Firing the weapon will still cause muzzle flare lights.

Damage to Text will completely remove all text from the heads up display, including objectives, live battery and ammo counts, as well as distance to objective and motion information.

Damage to Visor / Icons will remove all upgrade icons from the heads up display, including the aiming crosshair. Visor can be disabled as a user option, but if enabled it will be removed with damage to this system.

Damage to Weapon will remove all emissive textures as well as ammunition display from the weapon. Ammo warning audio will also be removed.

Damage to Tracker / Map will completely remove the Tracker / Map.

If a player survives a mission with damage to Electronics these will be restored upon starting the next mission. No upgrades are lost.

All of this was implemented in the past hour or so, and has not been extensively tested, but it looks promising as an alternative to instant-death. If things work out we will be including this in the next update.

The feed doesn't currently reflect that fact that I am actually working, but don't worry, I am.

I am right in the middle of a bunch of research-ey tests related to networked multiplayer, still trying to figure out what the best architecture is for Space Beast Terror Fright. Every game is a little different when it comes to networking, and there are a couple of different approaches that I want to try before committing.

That did it; I wrote a quick and dirty import pipeline based on the baked .obj files, no problems at all.

Now we finally have a working (albeit messy) pipeline to get our own character models all the way from our brains, thru a bunch of tools, and finally into the game.

Look forward to an update with this new hero model included as soon as we have tweaked the style of the animations and given it a good paint job!

Among other things we're getting ready to import our own custom marine / hero character into the game. We've been evaluating Blender as a content creation tool, and while that seems to work well the FBX export stuff is completely broken.

We have been using FBX earlier for our sentry model, as it had a relatively complex hierarchy of rigid objects, and also for our beast and hero characters (from 3drt.com) which were supplied in FBX format. For those cases things worked fine, but for our current case everything just breaks.

On a whim today we tried just baking all the animation frames into .obj files, and after some trickery and the realization that we should pre-triangulate, we got all the frames into our own tools and they look good. From here I just need to write a new exporter to our .blendmesh format.

Yes, we are still using blendshapes / morphtargets for our animations (just like Quake 2!), partially due to the fact that we can GPU accelerate all aspects of the animations this way, and not least due to exporter / importer hell. Whatever works right?

Today we released Steam Early Access Update 1.

We are currently evaluating using the Steam Community Hub for Space Beast Terror Fright as our main discussion forum. Please post your feedback there!

After two months of hard work on new level styles, XBox 360 controller support, and most importantly split screen co-op mode, we have finally made our submission to Steam for approval. We are hoping to get the game into your hands in the coming days!

EDIT: We are now live on Steam Early Access!

Here's a screenshot from the latest heads-up display, still a work in progress.

This is from two player mode on a 16:9 screen, hence the super wide 32:9 aspect ratio. The helmet design might seem confining, but in 16:9 single player you won't even see the sides.

The round-robin upgrade idea didn't play out so well; we found that we were running out of both ammo and battery.

We quickly switched to a scheme where each download results in every team member getting a random upgrade, and this feels much better.

This new scheme both promotes cooperation and saves us from having to completely re-balance everything at this early stage.

Today we played more co-op internally here at nornware, for the first time with proper screen-splits and user interfaces. You can already totally get the sense of the gains of having someone watching your back while you download, being able to watch several directions at once, etc.

We want to promote cooperation and not competition, so we're currently thinking that everyone should share the downloaded upgrades somehow. We're thinking that a round-robin approach might work, or everyone getting the same upgrade when someone downloads, or maybe even everyone getting a random upgrade when someone downloads. We will have to try all of these.

I'm back to working on co-op after a few days of tool support in our level editor The Swörd. Mad has been hard at work crafting normal maps for some upcoming new level styles, so the toolset needed some love.

The screen layouts for co-op are looking pretty final now. I opted for having having player 1 use the whole top of the screen in 3 player mode, but otherwise the reasoning is the same as in the earlier post.

I am currently working away on the model for SBTF's co-op character(s). My ambition is to get it modeled, textured, rigged, animated and implemented into the game before the big release. There is quite a lot of work left to do as you probably can imagine. Since we want to get the game out on Steam as soon as humanly possible we have implemented a placeholder character which roughly represents our art direction. They definitely look O.K. but it would be real cool to get our own custom character made and animated into the game before release.

Speaking of art direction; we feel it is of great importance to make the characters look like they have armor suited for the task at hand while still being vulnerable enough for the aliens to kill instantaneously, since this is an unforgiving, difficult and totally awesome game. I am giving the characters big bulky armor but still making sure to leave parts of the characters body less protected to really sell this idea. The armor looks like it can protect the character from most attacks from the front, back or above but if an aggressor would come up close it could easily attack the weaker parts of the armor.

By the way, I am using Blender for modeling, rigging & animation for the first time. My first impressions of Blender are really positive, you can do a lot with the program. And best of all, it's free! I intend to use Blender for every part of the character creation pipeline.

Today we learned that we really had designed our heads up display for a pretty wide display. Johan has always been working on a 16:9 monitor, while I worked for a while prior to the demo being released on a weird 2560x1080 Dell monitor.

My instinct when setting up the display for co-op (initially focusing on the 2 player case) was to split the screen vertically to get a left and a right "panel". The gui and the heads up stuff wasn't at all prepared for this kind of thing, so I focused on fixing all the related bugs and restructuring the architecture to more properly support several players and rendering panels.

Once all of that was finished however it became apparent that we would have to completely restructure all of the HUD text, the icons, as well as the 3d helmet / visor stuff for what was effectively two 8:9 ratio displays. This was depressing.

I recalled that Burnout 2 did two-player mode by splitting the screen horizontally, resulting in a top and bottom, so I tried that real quick and found that it was a much better solution. All of the HUD and gui worked fine for this type of super-wide display.

The field of view we are using did immediately become kind of ridiculous on 32:9, so I played around a bit with compensating for the fact that the display is twice as wide. That in turn looked a bit too cramped, like cropping to the mid 50% of the screen vertically, so we are fudging the field of view a bit to give you back a bit of vertical view.

This whole solution is feeling pretty good. You do in fact have a wider field of view in 2 player split screen mode, which is probably a good thing to have in SBTF and may even feel like a bit of a cheat, but the downside is of course that everything is half sized since we are splitting the screen vertically.

We're thinking that 3 and 4 player modes will probably have to use quarter sized render panels, but at least those will be the same aspect ratio as the display itself, so there shouldn't be any problems with that.

Just now we were able to play some very very early 2 player co-op, with one player using the keyboard / mouse and the other using an XBox 360 controller. There are tons of graphical glitches and tons of logical ones, but we are getting closer!

Today was first of all refactoring my earlier XInput code (for supporting XBox controllers on Windows) into something that would expose all the controllers. All my previous games have only used a single controller, so that's all had ever coded support for.

After that I got back to working on the implications of local co-op. The simulation code was already there to support multiple player avatars, and yesterday saw some quick validation of that stuff.

What actually did bog me down for most of the afternoon today was mainly design; how do the randomly rolled characters work in a team situation? After all, in any given mission some of the team members may die while others may survive, and those that survive need to be carried over into future missions.

I will try to keep it similar to what the single player version is, in that you always play with your most experienced character (indeed there is only ever a single character alive) until that character dies, and then a new character is automatically re-rolled. This would directly map to keeping teams intact; everyone that survives is baked into that slot, and new characters are rolled to fill the slots of characters who died.

Of course you can choose for each given mission how many players are going to participate (the plan is to support 4 initially, depending on the graphics implications of split-screen). This would mean that if 4 players played a mission and all survived, and then someone played in single player mode for a while, that the remaining 3 characters would carry over and be ready to play future missions. The only way to clear a character slot on the team is to have that character die. This feels (on paper) very hard-core; very SBTF.

So I guess the next thing is implement a rudimentary way to allow players to choose how many people will join a given mission, and then on to rendering in split-screen mode. Hopefully SBTF is still bound by pixel shader complexity, so rendering a first person view (potentially) 4 times may work.

I do however know better than to assume anything at this point... :)

Yesterday we finally got our dev machines and set them up in our new office. It is very green!

We are in a bit of a mad scramble right now due to all the awesome love we have been receiving lately. Here's what is going on:

* SBTF was Greenlit early yesterday morning!

* johno and Mad are switching to work full time on game development.

* Johan will be hired as artist.

* Mad is in the process of acquiring office space.

We have spent the past three days (and nights) working on a presentation of Space Beast Terror Fright, and we are happy to officially announce our Steam Greenlight campaign for the game.

There is brand new trailer for the game, as well as a "making of" feature that goes into a bit more depth. We hope you enjoy both!

Please support our Steam Greenlight campaign here!

Try the demo here!

At long last I am happy to announce the initial release of Space Beast Terror Fright (DEMO version)!

The last few months have seen hectic development on this project, and with the aid of our intern Johan Angelison we have finally managed to put something together that shows off the core experience of the game.

In conjunction with this release we are also trying out a new approach to getting our games out to players, namely the nornware launcher. This is super-minimal and unobtrusive HTTP-client that is intended to deliver all our free games and the demo versions of our retail games.

The main point of the launcher is to facilitate automated updates to our games, as bugs do happen, we really want bugfixes to happen as well, and finally we want to get our games into your hands as simply as possible.

Check out all our games here!

Mad forced me to put up this screenshot... :)

Gabe Newell said (in regards to Half Life 2):

"It doesn’t matter what we cut, so long as we cut it and it gives us the time to focus on other things, because any of the options will be bad unless they’re finished, and any of them will be good if they are finished."

I'm totally feeling this right now. I have previously blogged about the ideas of rage and also of the melee weapon in SBTF, but they are simply (at this point) things that aren't finished and / or completely thought through, so it is better to cut them and focus on other things.

I want to be done with the public demo of SBTF by next friday. Trio (our project planning / tracking tool that feeds this blog) projects that we will be done by XMas. This simply means that more things need to be cut.

I have been forced to seriously thing about ways to increase performance since we added the hud scene stuff (weapon / helmet), and also because I have been developing on a screen that is 2560x1080. I knew I was probably fill-rate bound as decreasing resolution helped, but I wasn't sure. And that means speculation.

So I installed nVidia Nsight and got my ass handed to me. I will need to fundamentally restructure my batching...

I have a new theory about what makes a game feel like a game.

Today I integrated the hud icons that Mad recently created. These are supposed to visualize the various upgrades that are available as well as the current "level" you possess for each, at a glance, and replace the current implementation of just printing text out at the side of the screen.

I was surprised how much this changed the game experience. Having them in your face at all times really helps to clarify the "variables" in the game that are important to your progress. Of course it helps that they look much nicer than the text versions.

What I am getting at is something that I experienced earlier this year on another project, namely that once there is some form of hud or gui that outlines the important variables of the game, the game suddenly starts to feel like a game.

This has some implications as to the importance of gameplay systems over stuff like visual fidelity. I have often wondered why some of my prototypes often don't feel "gamey", and I'm starting to suspect that it is due to the fact that I rarely implement any kind of hud or gui at the early stages of development.

I fully intend to take this to heart and make sure that my huds / guis get the attention they deserve in future projects, as well as always trying to strive towards better ways to visualize information that is important to the players' understanding of game state.

Currently working on the reactor shields; getting collision to work, as well as the interactions and the raising of the shields once you have downloaded all cores.

This stuff caused some changes in the core interactions in general. Previously you could interact with a core as long as you were in the same map cell, but now that is too inclusive since you should not be able to get at the coolants from outside the shield. Maybe I should have isolated that change to the coolants, but I felt that it was ok to just make the iteraction distance a bit tighter in general for all cores.

Trying to get away with rendering more 3d objects (the insides of the player helmet) in the same scene as the hud weapon without having to clear the z-buffer yet again...

The last few days have been about building a better airlock. This has been low priority for a while, but seeing as we are very close to a public demo I wanted to finish up all the things that the player sees all the time, and the airlock is such a thing.

The basic forms were done this past weekend, and a basic texturing pass was done today. The combination of clean textures and high levels of light really make the airlock stand out now as a safe and desirable place as opposed to the rest of the spacecraft / level.

I have also just now finished implementing door locks; the airlock door will now automatically close when the player leaves it. The external door control also locks so that there is no way back into the airlock without completing the mission (disabling the reactor coolants).

While there was previously no way to complete the mission without disabling the coolants, I find the combination of the new airlock visuals with the fact that the door closes and locks you out to be very satisfying (in a scary way), and pushes you into completing the mission as fast as possible.

The next step in reinforcing the mission goals will be to have the reactor inaccessible to the player until all datacores are downloaded. This will be done with a physical reactor shield that is locked, a similar mechanic to what is going on with the airlock.

Currently you can "happen to find" the reactor long before you get all the datacores (in fact you almost invariably do), and I want to reinforce the intended tension and length of the mission even further. I think the coolest thing would be to be able to actually see inside the reactor shielding via windows of some sort, so you can see your goal but not be able to access it.

Today saw an aborted attempt at solving shader permutation hell via #ifdefs. Currently I'm considering continuing on with just writing the permutations by hand, but in the long run this is a problem that needs to be solved programmatically.

As the code currently stands it is kind of icky that figuring out what permutations that are actually used is (as opposed to what is possible) is hard. It is partly data driven and partly code driven, but you only really know at run-time when you try to actually render something.

I need to research this some more...

Mad ended up playtesting today for the first time, which spawned a lot of good discussions about difficulty and progression.

After feeling a bit lost for a while I'm coming to realize that this game currently most resembles a NetHack / "rogue-like". This means, theoretically, that it is ok for the game to be hard / unforgiving, with things like perma-death and loss of hard-earned powerups.

Thomas Wingate often mentions that managing player expectations is key, and I think he's very right in this case. This game shouldn't be presented first and foremost as a retro-style shooter (even though it has a lot of that in it) because that might have players expecting a Doom what with linear level progression, statically placed enemies, evenly spaced upgrades, etc. It should be clear that SBTF WILL KILL YOU, and that trying to survive for as long as possible is what it is about.

This brings to mind things like high-score lists (perhaps even online ones like ACE). It also makes me a little tired of myself, in that I seem to be creating a game similar to things I've done before.

I have been wanting to "make a Doom" ever since I originally played Doom as a high-school teenager, and I have come to realize in the years since that that kind of game is very much about level design. I have been messing around a lot in recent years with procedural content (including levels as in SBTF) and have been sort of prejudiced against the idea of building levels manually, but it really is hard to get the same kind of feel out of something that doesn't have a designer brain behind it.

The main reason for my prejudice is simply the amount of time it takes to design levels / content for a game combined with the fact that those kinds of things have a distinct END. I have been reasoning that procedural / infinite levels makes for a bigger / longer game, but it certainly does seem like it doesn't necessarily make for a game that feels the same as a well crafted linear experience.

The current plan is to release a freely playable demo of SBTF soon, and from there transition to building another game that I've had on the back-burner for a while. The goals of this are both to get actual player feedback on SBTF, as well as give our intern Johan Angelison an opportunity to work on some different stuff for the rest of his internship.

This "other game" will, at least as the plan looks right now, be a single player linear experience with actual "levels". It will be interesting to see how this plays out.

Better was not better! When I A-B tested the new projectile graphics (much higher resolution) against the old low res ones they simply didn't work as well. Probably something related to the downsampling, but also that the new ones were doctored to look good at slow (observable) speeds. When I switched back to correct speed they simply looked weaker (not as bright), so I switched back to the low-res versions.

Ok, we give up; the motion tracker needs to be usable, so it won't be on the weapon model. Cool but not useful, so not so cool really...

While it is indeed cool to have all HUD elements on the weapon model, the usefulness of this feature can be questioned due to the amount of animation that is going on with the HUD weapon as a result of player motion and / or firing.

Since the tracker / map is an integral part of the experience and a very critical information source, I suspect there will have to be an option to turn off weapon animation. Probably a slider come to think of it, so that player can scale the animations to personal liking.

Another way to go might be to separate the tracker from the weapon and have it be more "steady-cam", thereby allowing for all the immersive weapon animation stuff without completely killing usability.

The main reason for implementing non-instant movement for the player avatar was really to make the weapon animation smoother, but it does indeed add a level of quality to the experience of walking around. I have been careful to match the previous max speed so that balance doesn't change.

In truth I guess that the player is a tiny bit weakened by this as it takes a little time to get up to max speed, but it is minimal.

The beasts now properly walk on all surfaces with animations and hit bounds to match. Really good nastyness!

I have implemented the basics of having beasts walk on walls in addition to floors and ceilings. Currently it's just trickery in the rendering, but the look of it is so awesome that it motivates me to do it "for real" in order to have the bounding volumes match up with the visuals.

The look is very "swarmy", something that I've wanted to have from the beginning. It seems that the mind focuses on the very inhuman nature of the motion and just identifies it as creepy.

This also makes aiming a bit harder, as you cannot as easily predict where the beasts are going to be; no more stupid beelines for the player.

Today saw more goodness related to the hud weapon, including subtle animation to mirror player motion, view bobbing etc, as well as the addition of a muzzle flare. Again interesting how much these things add weight to the gameplay / shooting experience.

I guess that a good rule of thumb when working on speculative development is to focus on the things that the player experiences all the time. By that tenet the hud weapon model is pretty critical, as in a shooter it is the instrument with which the player interacts with the world.

Funny how the core of this project has been going off and on for honestly about 10 years without me prioritizing the hud weapon model at all...

Today we finally managed to fix all the issues with the FBX export, and the new sentry gun is now in the house with the correct orientations and animations.

Piggybacking on that is the addition of a "hud model" for the main weapon. Very first pass right now, but it's amazing how much it helped to increase the satisfaction of shooting in the game. Seeing it in the context of the game also spawned a bunch of ideas related to how we can further integrate hud elements like ammo counts, battery, map / tracker into the weapon itself.

I find the Autodesk FBX SDK to be a tad too flexible for my taste. There is just way too many options, and Maya seems to make use of most of them.

What I've been trying to do is let Johan build parent-child structures (for the sentry turret) with the intent of leveraging the scene description that FBX exposes, instead of having to manually export parts of a hierarchy and measure the various pivot offsets.

In hindsight that would have been easier, especially now that we are trying to scale and rotate the initial pose of the scene. This doesn't get "baked" on export as I would like, but needs to be calculated in code based on the scene information.

The addition of the melee weapon without ammunition requirements does indeed "solve" the issue we had with the player being stuck in an impossible situation without ammo (which is I suppose quite subjective in a game as hard as SBTF). It also adds strategy, where the player can balance the risk of engaging beasts using the melee weapon in the interest of conserving ammo.

Another thing that came out of last weeks discussion was the concept of "rage"; a kind of bonus meter that fills up as a result of kills. Once the meter is filled, the idea is that player will "freak out" due to adrenaline overload, and for a short time become invulnerable.

We're thinking that there should be accompanying screen effects (rage vision), audio effects (screaming), along with the temporary boost of adrenaline to max. This will cause the player to run at the maximum speed. Invulnerability will be achieved by having any beasts that come into contact with the player immediately explode.

The rage meter will hopefully change the interaction between player and beasts significantly. Currently interactions with beasts are always negative, in that you risk death as well as expend ammo, and there is no real upside. Of course the addition of a melee weapon optionally curbs this, letting you conserve ammo if you want to. With the "gain" of "earning rage" from each kill, the player can be selectively aggressive in order to fill up the meter and switch to rage mode. This means that player-beast interactions have a potential upside.

I think that this mechanic will work pretty much exactly like the aggression meter in UfoPilot : Astro-Creeps Elite, in that the quicker you kill, the more you fill the meter. Hopefully it will work well in this new context!

After a design discussion last week we are attempting to "solve" the case where the player runs out of ammunition by adding a melee weapon. As this whole project borrows lots of inspiration from Games Workshop we're thinking along the lines of some kind of electrified chainsaw...

Currently I'm working on the weaponmodel for the player. I'm modeling several prototypes in order for us to choose which of them will meet up with our art direction the best. This also gives us the opportunity to mix n' match between elements of the different prototype models to finally produce the final weapon model.

Note to self - Remember to cleanup FBX SDK objects BEFORE deallocating static stuff (like the application). Otherwise Visual Studio calls it a memory leak.

Sometimes you just have to learn how things work...

I have historically avoided some aspects of linear algebra, particularly matrix math. While this is a pretty fundamental aspect of 3d graphics programming, it has been always been made easier by my use of the D3DX9 utility methods for manipulating matrices, so I never had to REALLY understand what was going on.

With the integration of a multi-jointed / articulated sentry gun, courtesy of our awesome intern Johan Angelison, I finally had to learn how to construct parent child relationships. In the end it wasn't so terrible; just a question of what order to multiply the matrices together (again aided by the utility methods); but it's interesting how I could avoid something like this for so long.

Evaluated and discarded the use of traditional ambient cubes, going with the texture based solution.

I am also mixing the simple bakelite solution (uniform light from all directions) with the ambient cube texture solution, as bakelite is too uniform and ambient cube is too directional.

One thing that I like the look of is the modulation of the spotlight with the ambient occlusion term from the bakelite. This has issues when shining the light into "holes" that our outside the map; these are not lit properly, but in general it looks better and less flat.

I have implemented the textured ambient cube idea, and it works very well; now the normal maps are popping with the baked lighting.

There are issues with the cores in that they should be be lit by their own light when they in fact aren't. This was initially a little hard to understand until I realized that they are really an edge case of the textured ambient cube implementation. They sample based on a cube that is behind the light that should be illuminating their front face, so the vector to light used is inverted from what it should be.

After figuring this out I realized I can probably just use a more traditional ambient cube shader for all objects and cores, since these are all separate render calls. I should probably go through everything on a case by case basis, as for example the doors look completely reasonable using the textured scheme.

Mixing in traditional ambient cubes will require an emulation of the way the textured lights "fall off", which is really just texture filtering.

There are / have been problems with the combination of the normal mapped spotlight and the bakelite stuff. This is because bakelite is really just ambient light and has no directionality. This simply doesn't work for anything besides ambient occlusion, which granted is still very cool as bakelite is very simple and cheap (just a 3d texture lookup).

What happens is that anything beyond the range of the spotlight simply looks like it has no normal map, and since the albedos are authored to not have any baked lighting it just looks flat.

I tried faking things by using the half lambert term between the surface normal and the vector to the viewpoint (which is the same as the vector to the spotlight), and while this makes the normal maps work in the bakelite, the vector to light is still wrong, and everything went from a sort of ambient warm look to a very hard arc-welder look, and very dark. This is of course because the vector to light is always to the viewpoint, and this is just wrong.

Beyond going to lightmaps, which would require Valves 3x storage in order to use the normal maps, I'm thinking that the way to go is to treat the bakelite like an ambient cube. This means 6x texture storage and access in the shaders. The actual storage isn't a problem as each bakelite pass (one per directional cardinal axis = 6) is 33x33x3, but I'm worried about the complexity of the shader.

Perhaps I will have to give up on shader model 2 after all these years... ;)