Follow @nornware

(c)2011-2016 nornware AB | email: contact (at) nornware (dot) com
  News     Feed     Games     About  

S.B.T.F. Early Access Update Trettiotvå (32)

posted by johno on July 29, 2016, 19:53:09 in sbtf

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

Object Oriented Programmers Anonymous

posted by johno on July 25, 2016, 12:38:39 in sbtf

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

Finished Big Refactoring

posted by johno on July 22, 2016, 21:34:35 in codebase

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.

Action Movie Maker!

posted by johno on July 07, 2016, 22:32:14 in sbtf

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...

Maintenance

posted by johno on July 07, 2016, 16:42:48 in codebase

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.

S.B.T.F. Early Access Update Trettioett (31)

posted by johno on June 20, 2016, 19:06:07 in sbtf

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

S.B.T.F. Early Access Update Trettio (30)

posted by johno on June 16, 2016, 21:34:19 in sbtf

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

Replay Progress

posted by johno on June 13, 2016, 23:00:20 in sbtf

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.

Working on Replay Support

posted by johno on June 08, 2016, 23:48:35 in sbtf

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.

S.B.T.F. Early Access Update Tjugonio (29)

posted by johno on May 02, 2016, 17:46:52 in sbtf

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

Space Windows

posted by johno on April 27, 2016, 20:17:07 in sbtf

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.

Vacation-ish?

posted by johno on April 18, 2016, 08:09:51 in sbtf

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... :)

Misc Concepts

posted by johno on April 15, 2016, 15:46:14 in sbtf

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.












Trying to finish the game

posted by johno on April 12, 2016, 02:10:23 in sbtf

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):


There are also very many other miscellaneous things to do that are too numerous to list here. Also note that all of the above may change at any time.

I want to say in closing that I have been getting very much love from the community lately, and I want to say that I appreciate that very much. It is a honor and a privilege to have so many people care about something that is the product of my overly creative mind.

S.B.T.F. Early Access Update Tjugoåtta (28)

posted by johno on April 11, 2016, 21:24:14 in sbtf

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

Thinking About Networked Multiplayer

posted by johno on April 04, 2016, 15:18:54 in sbtf

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

Multithreading Woes

posted by johno on March 31, 2016, 22:43:38 in sbtf

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

S.B.T.F. Early Access Update Tjugosju (27)

posted by johno on March 28, 2016, 23:19:01 in sbtf

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

Into The Hive!

posted by johno on March 25, 2016, 21:24:10 in sbtf

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...

Some Quality of Life Fixes

posted by johno on March 16, 2016, 19:21:54 in sbtf

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.

Interview

posted by johno on March 14, 2016, 13:50:16 in sbtf

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.

S.B.T.F. Early Access Update Tjugosex (26)

posted by johno on March 11, 2016, 18:40:27 in sbtf

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

Power Failures Part 4

posted by johno on March 04, 2016, 19:09:02 in sbtf

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!

Power Failures Part 3

posted by johno on March 02, 2016, 22:46:12 in sbtf

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.

Power Failures Part 2

posted by johno on March 01, 2016, 19:09:11 in sbtf

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.

Power Failures

posted by johno on March 01, 2016, 17:53:38 in sbtf

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...

S.B.T.F. Early Access Update Tjugofem (25)

posted by johno on February 29, 2016, 00:03:47 in sbtf

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

S.B.T.F. Early Access Update Tjugofyra (24)

posted by johno on February 18, 2016, 22:27:00 in sbtf

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

Fences Almost Done

posted by johno on February 16, 2016, 00:39:47 in sbtf

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.

Security Fences

posted by johno on February 10, 2016, 01:21:45 in sbtf

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.

S.B.T.F. Early Access Update Tjugotre (23)

posted by johno on February 07, 2016, 00:18:30 in sbtf

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

Refactoring The Plan Format

posted by johno on January 29, 2016, 19:23:37 in sbtf

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.

S.B.T.F. Early Access Update Tjugotvå (22)

posted by johno on January 20, 2016, 00:49:13 in sbtf

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

S.B.T.F. Early Access Update Tjugoett (21)

posted by johno on January 18, 2016, 20:28:26 in sbtf

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

S.B.T.F. Early Access Update Tjugo (20)

posted by johno on January 02, 2016, 22:29:40 in sbtf

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

Bots

posted by johno on December 31, 2015, 19:29:04 in sbtf

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... :)

S.B.T.F. Early Access Update Nitton (19)

posted by johno on December 16, 2015, 17:39:27 in sbtf

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

MRT + PVS

posted by johno on December 03, 2015, 00:20:13 in sbtf

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...

More Light Pre-Pass

posted by johno on December 01, 2015, 22:18:39 in sbtf

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...

Light Pre-Pass

posted by johno on November 26, 2015, 00:27:55 in sbtf

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!

S.B.T.F. Early Access Update Arton (18)

posted by johno on November 23, 2015, 15:24:29 in sbtf

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







S.B.T.F. Early Access Update Sjutton (17)

posted by johno on November 20, 2015, 15:09:42 in sbtf

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



More PBR-ish Tests

posted by johno on November 03, 2015, 23:17:17 in sbtf

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 are using the Metalness / Roughness workflow, and here you can see some examples of old vs new.



We are currently using a simple spherical environment map. We take a typical "chrome ball" image and blur it to 16 different levels, and simply use the Roughness channel to select which version we sample. This technically only gives us only 4 bits of resolution, but we are currently taking two reflection samples and interpolating. I want to see if I can get away with just flooring to the nearest version and using that sample; you might not even see the difference.



Our reflection model has always been very arbitrary and one-dimensional, so doing spherical mapping is an upgrade I guess. I am very much leveraging the fact that humans (according to an book I read about Renderman) have a hard time reasoning about what is or is not a physically accurate reflection. Pixar have used this creatively on many occasions, "forcing" things to reflect when they really wouldn't have.



I also though that I would get away without the whole Fresnel business, but it turned out that it wasn't possible to get good plastic without it. We are incorrectly using 0% base reflectivity for all non-metals (looks better) as well as hard coding 75% base reflectivity for metals. We combine that with a dot product to the power of something to scale the reflectivity (Fresnel-ish term). This achieves the typical shiny plastic look where you see more reflections on the outer edges and none in the interior. It also makes shiny metals burn out a little less. Oh yes, we are arbitrary scaling down the Fresnel effect on non-metals with increasing roughness, as this is supposed to happen and we really don't like the soft kind of rim-lighting that occurs if you don't do this.



The think that irks me the most about PBR Metalness / Roughness is that it requires 5 channels, namely RGB, Metalness, and Roughness. Metalness is binary, and if Roughness ends up being 4 bits of resolution I want to see if we can just pack both Metalness and Roughness into the alpha channel of our albedo textures. This is where we have been storing "shininess" all along for our current shading model, and if we can keep doing that it will be awesome. Mashing those two channels together makes it sort of tricky to edit in Photoshop, but I expect we will do programmatic batch conversion of existing assets anyhow, and from there most our our work will be in Substance Painter instead of Photoshop / Quixel.



The textured shots here are exported "smart" materials from Substance Painter. Most of the goodness comes from creative variations in the Roughness channel.



S.B.T.F. Early Access Update Sexton (16)

posted by johno on October 29, 2015, 20:38:25 in sbtf

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

Texturing tools and workflow

posted by mad on October 29, 2015, 17:46:26 in sbtf

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!

S.B.T.F. Early Access Update Femton (15)

posted by johno on October 28, 2015, 15:03:54 in sbtf

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

Final Testing of Community Features

posted by johno on October 28, 2015, 00:52:47 in sbtf

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

New Multiplayer Community Features Soon + PBR

posted by johno on October 22, 2015, 23:41:54 in sbtf

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.

PBR-ish

posted by johno on October 21, 2015, 14:30:18 in sbtf





I happened to read up on the new-fangled Physically Based Rendering that is all the rage these days. My initial reaction was to lament the risk that all of this will make all games look the same.

After I calmed down I realized that this could solve an issue that we have in SBTF; we've never been able to nail a good mix of matte and shiny materials to a satisfactory degree. Part of this is because our environmental reflections / specular stuff is completely bogus and approximated, but I realized after reading up on PBR that it is also much because I had absolutely no idea what actually makes shiny metal look like shiny metal.

We are currently (old method) using the alpha channel of the albedo texture to control how "shiny" materials appear. This simply adds the fake reflections, scaled by the alpha component, and results in things only ever getting brighter as well as looking like they have a plastic film on them.

The new approach is similar. In order to not increase texture memory usage (cheapskate that I am) I'm approximately combining "metalness" and "glossiness" and taking the whole energy conservation aspect into account. Now alpha means metalness / glossiness, and when something is completely glossy it only shows reflections, while when something is completely non-glossy it shows only the albedo color.

Shiny stuff also modulates with the albedo color, hence everything is actual fully "metal", but this works well in practice as alpha values decrease. You can sort of get shiny plastic as well as matte painted metal and the like. Oh yeah, there should be a separate texture for the reflection colors, but looking at a lot of reference (and due to energy conservation) diffuse/albedo and specular/reflective colors are pretty much mutually exclusive, so we just combine the concepts.

One thing that is definitely very wrong about our approach is that the shape / blurriness of the reflections doesn't change based on glossiness. Typically you see rough / non-glossy materials with a very blurry reflection. We tried to get our reflection approximation to do that, but it resulted in other artifacts when we tried to do things like chipped paint on something very shiny. We are accepting this tradeoff in order to not completely mess up our media creation pipeline (a lot of Quixel).

Initial tests show that just plugging the new shader in results in a game that is slightly darker and much more contrasty (which we don't like), with much more pleasing shiny details and bigger ranges of "feel" to the materials (which we do like). Being able to properly do rough vs shiny was my big goal with this, and this has been achieved.

I expect I will write side-by side shaders that can be toggled, and from there tweak some constants in order to get the all-around brightness back to where it used to be, and after that batch-convert most of the textures. From there we can tweak things manually.

This probably won't be in the next update (focused on multiplayer community stuff), but soon after that.

Multiplayer Community Features

posted by johno on October 20, 2015, 02:04:47 in sbtf

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.

S.B.T.F. Early Access Update Fjorton (14)

posted by johno on October 08, 2015, 18:11:22 in sbtf

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

Back To Work!

posted by johno on October 05, 2015, 12:49:11 in sbtf

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.

Trying To Relax

posted by johno on September 30, 2015, 22:03:47 in sbtf

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.

That Was Not The Problem

posted by johno on September 25, 2015, 23:08:35 in sbtf

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

Almost Update

posted by johno on September 23, 2015, 20:41:43 in sbtf

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.

Drawing The Line

posted by johno on September 22, 2015, 21:10:55 in sbtf

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.

Finding Out What Is Taking All The Time...

posted by johno on September 18, 2015, 22:10:16 in sbtf

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.

Profiling

posted by johno on September 17, 2015, 13:56:59 in sbtf

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.

S.B.T.F. Early Access Update Tretton (13)

posted by johno on September 08, 2015, 23:14:56 in sbtf

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

S.B.T.F. Early Access Update 12

posted by johno on August 21, 2015, 00:22:13 in sbtf

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

S.B.T.F. Early Access Update 11

posted by johno on August 14, 2015, 16:00:43 in sbtf

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

About Rendering and Networked Multiplayer Performance

posted by johno on August 09, 2015, 15:01:59 in sbtf

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.

Space Game Junkie

posted by johno on August 08, 2015, 00:58:44 in sbtf

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

S.B.T.F Early Access Update 10

posted by mad on August 05, 2015, 21:14:44 in sbtf

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






Early Access Update 10 is imminent!

posted by johno on August 04, 2015, 20:44:40 in sbtf

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!

Update 10 Is Close

posted by johno on July 28, 2015, 21:20:17 in sbtf

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.

Ignore Everything We Say (just kidding)

posted by johno on July 24, 2015, 20:52:06 in sbtf

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.

What We're Up To

posted by johno on July 21, 2015, 18:48:55 in sbtf

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.

S.B.T.F. Early Access Update 9

posted by johno on July 09, 2015, 17:30:13 in sbtf

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

More Mission Generators + Options

posted by johno on July 08, 2015, 00:58:42 in sbtf

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.

Sneak peeks and some beers

posted by mad on July 03, 2015, 15:02:30 in sbtf

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.

S.B.T.F. Early Access Update 8

posted by johno on June 29, 2015, 13:16:24 in sbtf

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

Still Working...

posted by johno on June 25, 2015, 20:26:26 in sbtf

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...

Shotgun Parties

posted by johno on June 22, 2015, 20:17:44 in sbtf

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.

Networked Party Progression

posted by johno on June 12, 2015, 21:21:49 in sbtf

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!)

Shotgun!

posted by johno on June 10, 2015, 21:24:14 in sbtf

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!

Shotgun?

posted by johno on June 10, 2015, 09:48:11 in sbtf

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.

S.B.T.F. Early Access Update 6

posted by johno on June 05, 2015, 22:14:28 in sbtf

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

S.B.T.F. Early Access Update 5

posted by johno on June 04, 2015, 20:20:29 in sbtf

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

Internet Steam Networking Tests

posted by johno on May 29, 2015, 21:02:31 in sbtf

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.

Initial Steam Networking Tests

posted by johno on May 28, 2015, 20:10:33 in sbtf

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.

Better Image Quality

posted by johno on May 27, 2015, 19:03:12 in sbtf

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.

S.B.T.F. Early Access Update 4

posted by johno on May 26, 2015, 16:54:36 in sbtf

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

New Player / Hero Characters

posted by johno on May 22, 2015, 19:08:31 in sbtf

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




What we've done is implement the beginnings of a texture compositor, so that we can put most anyone's face on the models. Right now it's just us devs and some close friends and family, but we're thinking it would be very cool to allow players to supply their own faces, i.e. "give us your face and we will melt it".

We have genderized all the random names and implemented a user option for gender preference (none, female, male). If this is set to anything but "none" all the names that appear will be in the gender you specify, and all the player models will have gender-specific faces.

We have also implemented specific hero-gibs, so when someone gets killed you might even find their face lying around.

We are aiming for an update including all of this stuff early next week.

LAN Multiplayer Update Imminent

posted by johno on May 14, 2015, 20:45:06 in sbtf

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.

Status

posted by johno on May 13, 2015, 21:16:53 in sbtf

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.

Map seeder

posted by mad on May 13, 2015, 11:58:23 in sbtf

Looking forward to selecting a map of your choice?

Networked Multiplayer Coming Along Well!

posted by johno on May 06, 2015, 21:33:21 in sbtf

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!

Get it right now and your life will be complete!

posted by mad on May 05, 2015, 19:00:00 in ace








UfoPilot : Astro-Creeps Elite Coming Soon to Steam

posted by johno on May 04, 2015, 18:37:26 in ace

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!

Alternate Sentry Friendly Fire

posted by johno on April 28, 2015, 01:28:49 in sbtf

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.

I really am working...

posted by johno on April 22, 2015, 15:33:38 in sbtf

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.

nornware SDK yeah!

posted by johno on April 16, 2015, 20:45:58 in sbtf

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!

FBX SDK meh...

posted by johno on April 16, 2015, 17:53:19 in sbtf

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?

Early Access Update 1

posted by johno on April 15, 2015, 21:06:11 in sbtf

Today we released Steam Early Access Update 1.

Random Breaches - fun but hard:)

posted by mad on April 07, 2015, 19:24:55 in sbtf



Forums

posted by johno on April 07, 2015, 14:12:20 in sbtf

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

Full Steam Ahead!

posted by johno on April 06, 2015, 21:33:49 in sbtf

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!







Hello Teammate!

posted by johno on March 23, 2015, 19:46:40 in sbtf

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.

Co-Op Madness

posted by johno on March 10, 2015, 20:10:56 in sbtf

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.

More Co-Op Playtesting

posted by johno on March 09, 2015, 18:50:38 in sbtf

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.

Co-Op Screen Layouts

posted by johno on March 06, 2015, 23:36:11 in sbtf

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.

Modeling our Hero(s)

posted by angelison on February 27, 2015, 16:51:35 in sbtf

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.

Split Screen Solutions

posted by johno on February 25, 2015, 19:16:06 in sbtf

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.

First Co-Op Playtest

posted by johno on February 24, 2015, 16:54:10 in sbtf

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!

Working on split-screen co-op

posted by johno on February 17, 2015, 19:35:45 in sbtf

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... :)

Green Office, Green Light, Green Community

posted by johno on February 10, 2015, 15:08:28 in sbtf

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


green nornware office


Today we finally were able to sit down and talk through all the awesome design input we have received from the community. We are carefully considering all the suggestions and weighing them against our own vision for the game, and are pretty sure you will all be happy with what we come up with.

Credits will of course be included for any ideas that we use / modify / are inspired by!

Life Change-Up

posted by johno on January 28, 2015, 14:20:41 in sbtf

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.

Space Beast Terror Fright - Steam Greenlight Trailer and The Making Of

posted by johno on January 12, 2015, 23:38:49 in sbtf

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!

Space Beast Terror Fright - Demo Released

posted by johno on January 05, 2015, 05:14:21 in sbtf

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!

Space Beast Terror Fright - Screenshot

posted by johno on December 12, 2014, 16:00:01 in sbtf

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

screenshot space beast terror fright

The Chopping Block

posted by johno on December 05, 2014, 19:06:42 in sbtf

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.

Ass-Handed Coordinate System

posted by johno on November 26, 2014, 15:00:36 in sbtf

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...

Heads Up Display = Game?

posted by johno on November 20, 2014, 20:04:25 in sbtf

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.

Reactor Shields

posted by johno on November 13, 2014, 18:49:20 in sbtf

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.

Z-Buffer woes

posted by johno on November 12, 2014, 14:00:17 in sbtf

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...

Airlock and High-Level Mission Flow

posted by johno on November 12, 2014, 00:10:14 in sbtf

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.

Shader Permutation Hell

posted by johno on November 05, 2014, 17:43:44 in sbtf

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...

Oh! It's a Rogue-Like!

posted by johno on November 04, 2014, 19:55:43 in sbtf

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.

Lo-Fi Wins!

posted by johno on November 04, 2014, 15:58:06 in sbtf

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.

Usability Trumps Realism

posted by johno on November 03, 2014, 15:10:49 in sbtf

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...

It is cool, but is it useful?

posted by johno on October 30, 2014, 18:49:40 in sbtf

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.

Touchy Feely Avatar Movement Stuff

posted by johno on October 29, 2014, 17:38:54 in sbtf

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.

Proper Wall-Walking

posted by johno on October 26, 2014, 22:29:15 in sbtf

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

They're Coming Out Of The !@#$% Walls!

posted by johno on October 24, 2014, 01:26:05 in sbtf

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.

Muzzle Flare!

posted by johno on October 23, 2014, 19:21:14 in sbtf

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...

Hud Weapon = More Game!

posted by johno on October 22, 2014, 18:53:10 in sbtf

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.

Sentry Turret Heirarchy

posted by johno on October 21, 2014, 19:52:55 in sbtf

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.

Rage?

posted by johno on October 15, 2014, 15:07:22 in sbtf

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!

Melee Weapon?

posted by johno on October 15, 2014, 13:50:35 in sbtf

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...

Hud Weapon Modeling

posted by angelison on October 14, 2014, 13:55:50 in sbtf

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.

Autodesk FBX Memory Management

posted by johno on October 14, 2014, 11:49:03 in sbtf

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

Matrix Mastery

posted by johno on October 13, 2014, 12:57:46 in sbtf

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.

Unified Lighting

posted by johno on August 29, 2014, 14:19:10 in sbtf

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.

3d Texture Ambient Cube!

posted by johno on August 21, 2014, 00:02:03 in sbtf

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.

3d Texture Ambient Cube?

posted by johno on August 14, 2014, 12:35:30 in sbtf

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... ;)