Category Archives: Barotrauma

Barotrauma chat lag and other issues

Apparently the problem with the chat getting unbearably laggy after a few rounds is still there, even though I thought I managed to fix it. After the optimizations done to the networking code I haven’t been able to reproduce it when debugging the game on my machine (even with 10 clients and very high simulated lag and package loss), but it’s definitely still there even though the game may run smoothly for a few more rounds than before…

It seems that it isn’t just a problem with the chat but all the messages that are sent using a reliable delivery method (such as picking up items and damage done to the walls), the chat lag is just the most noticeable effect. I’ll be doing my best to fix it as soon as possible, but in the mean time I guess the best way to work around the bug is to restart the server whenever the lag appears.

The problem with the autoupdater should be fixed now btw, turns out it was a problem in the update servers end and not the launcher itself. Although, I did add proper exception handling to the place where the crashes happened so if there are any similar issues in the future, the launcher will show an error message instead of just crashing.



Subsurface is progressing nicely and I’ll be releasing a new version in a week or two. However, it probably won’t be called Subsurface anymore. Back in the first posts about the game I mentioned that Subsurface was working title, but it kind of stuck and I started liking it. Now I’ve noticed that the name is a bit problematic: apparently there’s an indie game studio called Subsurface Games and a dive log program called Subsurface, which makes the game somewhat hard to find by googling.

So, I guess a new name would be in order. So far I’ve come up with one potential name, which I think sounds very appropriate for the game:


Barotrauma is physical damage to body tissues caused by a difference in pressure between a gas space inside, or in contact with the body, and the surrounding fluid.

Barotrauma typically occurs when the organism is exposed to a significant change in ambient pressure, such as when a scuba diver, a free-diver or an airplane passenger ascends or descends, or during uncontrolled decompression of a pressure vessel


If any of you want to share your thoughts about the name or have any other name suggestions, I’d love to hear them!

Also, here are some of the things that will be in the next update:

– Major optimization and a ton of bugfixes/improvements in the networking code. And by major I mean MAJOR: most of the time I’ve spent on the game after the last update has gone in testing everything I can think of and making the multiplayer mode smooth and stable. The game now also generates a detailed report whenever it crashes, which will make it much easier to fix the bugs that I’ve missed.

– Several things to prevent people from sinking the sub within minutes of the round starting. There are security officers armed with stun batons now, who may attempt to immobilize and capture saboteurs. Blowing up the reactor is also much harder: it takes almost a minute for it to overheat, and when temperature starts to get critical, a warning light switches on in the command room and a button can be pressed to shut the reactor down remotely.

– A basic tutorial which walks players through the most common tasks on board the sub. In the future there will also be additional tutorials that take a more in-depth look at the various game mechanics (and why not one that explains how to use the submarine editor).

– Server admins can now play themselves without starting another instance of the game.

– A bunch of new items, graphics, sounds and a second submarine in addition to Aegir Mark I.

– An auto-updater, so you won’t need to re-download the entire game whenever there’s an update.

– Linux port of the game is almost finished and will most likely be released alongside the next update. After that, I’ll start looking in to the Mac port.

dgfjdsfgb launcher

Subsurface v0.1.1

A big thanks for all the feedback I’ve gotten on Subsurface, the amount of work people have been putting on getting the wiki up and of course everyone who’s played the game so far! The couple of multiplayer sessions I’ve taken a part of have been great fun despite all the bugs and other issues.

And speaking of bugs, Subsurface v0.1.1 is now out with a bunch of bugfixes and additions. Mostly stuff related to the multiplayer mode and some item bugfixes/improvements.

I think the next bigger thing I’ll be adding to Subsurface will be an in-game tutorial: I know the game is quite hard to figure out at the moment and I think many of the players haven’t managed to completely understand a large part of the game mechanics yet. I’ll also publish the source code on github as soon as I get around to writing some sort of EULA for it: since I’m planning on eventually putting a price tag on the finished game, I don’t think I should just “toss it out” the way I did with SCP-CB.

And no, I haven’t forgotten about the SCP-[REDACTED] update for SCP-CB. Now that the Subsurface release is out of the way, I think I’ll try to set some time aside to get the update done. The SCPs in the earlier “teaser posts” aren’t the only new thing coming up: Astray488 (the artist formerly known as Mirocaine) has been sending me some other cool stuff as well…

Subsurface v0.1

title text

The first public pre-alpha version of Subsurface is now out!


There’s also a wiki now, and separate sections for Subsurface on the SCP-CB Undertow Games forums. There isn’t much content in either of them yet, but I’ll be adding more stuff in the following days (including tutorials for modding and the game itself).

EDIT: The current wiki is temporary, it will be moved to gamepedia shortly.


“Content packages”

(Sorry, no SCP – CB updates yet, you’ll still have to wait some more time for SCP-966)


I’ve been trying to make Subsurface as easy to mod as possible. Just like in SCP-CB, all the assets are uncompressed and can be easily edited by anyone. All the characters, sprites, items and things like that are configured in .XML files that can likewise be edited.

The config file of a welding tool

But what happens if you join some server with your modified files, or if the server is running a modified version of the game? I solved this by using a system that I call “content packages” (subject to change if anyone comes up with a better name).

The content packages are basically just lists of files the player wants to use. The game calculates an MD5 hash for each content package based on the selected files, and this hash can be compared between the servers and clients to figure out whether the files match.


Extremely unfinished launcher and a “package manager” used for configuring the content packages

Making sure the files match could’ve been done without this kind of system, just by comparing some specific files and the contents of some specific folders, but that would’ve made switching between different mods and versions a huge pain. Changed a couple of values in reactor.xml while playing the single player mode? Downloaded some mod which replaced some files in the game folder? Ok, you won’t be joining any multiplayer game before all the files are back the way they were.

Keeping the original files in tact is much easier with the content packages: if you want to do changes to a couple of files, you can make copies of them, leave the old ones alone and make a content package that’s using your new files instead of the old ones. Downloading and switching between mods should also be much easier: the maker of the mod can put all the necessary files in some separate folder without the need to overwrite any of the original game files, and create a content package that determines which files should be replaced with the modded ones.

Also, the first pre-alpha version of Subsurface will be out in ~2 weeks!

It’s a submarine now

A major change to Subsurface: now it takes place in a submarine instead of an underwater station!

I’ve been turning over this idea in my head for a while and thought it would make the game a lot more interesting, but I wasn’t sure whether it would be feasible to do using Farseer physics. The physics engine can’t handle collisions properly if one object is a lot larger than the other, and moving an object with smaller objects inside it is also somewhat problematic. But I managed to make it work pretty well by cheating a bit (for example, the submarine doesn’t actually move, only the map), and I think it was definitely worth the effort.

Now, instead of sitting in the same spot at the bottom of of the ocean, you’ll be guiding a submarine through procedurally generated caverns and trenches, trying to reach the next outpost/city/station to replenish your supplies and hire some new crew members to replace the ones who got eaten by some eldritch horror.

I think this change will improve some aspects of the game a lot. One thing is that it creates a much stronger sense of progression. Earlier, I would start the game, go about my daily routine for a while (fixing anything that needs fixing, making sure everything is running smoothly), waiting for the inevitable disaster to strike. After the situation had been resolved, I’d repair any damage and basically start from over again. I’d also gain better equipment and gather a more competent crew as the game progressed and the difficulty level of the random disasters went higher, but it still felt like I was going nowhere. Okay, I survived through that shift, lets start another one and have another monster wreck everything again.

How the game works now is somewhat similar to FTL. You have this large map with dozens of different beacons outposts, and you travel from one location to another through the aforementioned procedurally generated levels. I think it immediately gave the game some of that much needed sense of progression: you aren’t starting another round just to get through another round, but to make your way to the next location while exploring a completely new area with who knows what between you and the destination.

The “overworld map” – extremely bare bones at the moment but it shows the basic idea

At the moment the outposts are nothing more than points on the map with some creative name (such as “Location 985″), but obviously there will be more to them in the future. Some could be cities where you can hire new crew members or sign up for some kind of quests (“kill the enormous squid thing that’s stopping our ships from using some passageway”, “go to Place X and salvage something from a sub that sank there last month”). Some could be military outposts where you can buy weapons, ammo and explosives, or research facilities where you can buy cool new tech. Or remote underwater facilities that had gone completely silent some time ago after broadcasting a distress signal.


Random level (voronoi graphs ftw)


Having the game take place in a submarine also allows a wider array of things that can go wrong. Breaking the reactor and running out of power doesn’t just mean that the lights go off and oxygen generators shut down, it means you’re stuck at the bottom of some uncharted cavern until you fix the reactor or come up with some other way to power up the engines.

Navigation and steering the ship are also a new cause for potential disasters (as seen in the Youtube clip).


Internship & new Subsurface footage

A small update on what I’ve been up to lately in addition to SCP-CB v1.1:

The Computer Sciences degree I’m currently doing involves three 10-week internship periods and last week I started doing this years internship at a cool little game startup called FakeFish. They’re working on a game called Northbound, a really interesting story-driven RPG game based on the Finnish national epic Kalevala. Expect adventures in the northern wilderness, puzzles, tactical combat and exploring the Finnish folklore that ranges from comfy to horrifying and from odd to batshit insane.

Subsurface is also progressing nicely: it’s gradually starting feel more like an actual game and the multiplayer is now working well enough that I’ve managed to run a couple of online multiplayer sessions with a handful of players. Anyway, here’s a clip of what the game looks like at the moment:

As for when you’ll get to play it: I’m hoping on releasing the first public alpha version of Subsurface in one or two months from now.

Wiring and signal processing

Subsurface now has wiring and signal processing mechanics similar to the ones in Space Station 13. For those of you who aren’t familiar with SS13, think redstone in Minecraft. Basically different constructions/items can send various signals through wires to other constructions, and with some logic gates and other components you can built pretty complicated contraptions.

Here’s a clip of connecting a button to a door – I think I’ve managed to make the system a little more intuitive than in SS13:


You just have to equip a screwdriver to open the “connection panel” of the item, and then equip a wire and drag it to the connection of your choosing. In this case “signal_out”-connection of the button, which just sends out “1” when someone pushes the button, and “toggle”-connection of the door which toggles the state of the door whenever it receives a signal.

At the moment there aren’t that many components to use in the contraptions, just basic logic gates (and, or, not), but at least the following are to be added soon:

  • “signal comparer”: sends out “1” if it receives a signal matching to some user-determined string
  • “voice processor”: whenever someone says something in the vicinity of the component, it sends out what the person said as a string
  • “speaker”: reads the input it receives out loud (not using a speech synthesizer though, the message just appears in the chat box at the lower right corner of the screen)
  • “wifi component”: sends out the signal it receives through an user-determined a wifi channel – can be used to send data remotely
  • probably something similar to the RegEx components in SS13 in case you need to analyze an incoming signal in a more complicated way
  • obviously something that can be used to do some damage – maybe a detonator which can be connected to whatever explosives you have available

So, what can you do with these? Here’s some ideas:

  • a system which only allows a door between an airlock and the facility to be opened if the airlock is free of water, and prevents either of the doors to be opened if the other door is open
  • a voice prosessor in a command room, which shuts down every door in the facility if it hears someone saying “SHUT DOWN EVERYTHING”, or some secret phrase set by the captain
  • a system which analyzes air quality through the facility and isolates sections that are running low on oxygen
  • shutting down non-vital devices/systems if running low on power
  • functional computers (I’ll be disappointed if we won’t see anyone build a tic-tac-toe game inside Subsurface)
  • a number of detonators and explosives hidden throughout the facility, connected to wifi components and signal comparers allowing the detonators to be activated remotely using some secret phrase – or the moment any of the players says “lol” in the vicinity of a voice processor

Some men women just want to watch the world burn drown


Two clips of a little addition to Subsurface:

As you can probably see, it’s still a work in progress, but already pretty fun to play around with.

Also, if any of you are wondering about the release date SCP – Containment Breach v1.1; the release of Containment Breach – Run has unfortunately been pushed back a little and as the plan is to release v1.1 along with it, it will still be a while before it’s out.

Networked physics with Farseer & Lidgren

In addition to SCP-CB v.1.1, for the past few weeks I’ve been working on the networking part of Subsurface (physics in particular). It turned out that the way I’d implemented framerate-independent physics made it almost impossible to keep the networked clients in sync, but after some modifications everything seems to be running smoothly even with high latency.

Previously I was using a variable timestep, which basically means that if the game is running at 50% of the preferred framerate for example, we’ll just move everything twice as fast each frame. This worked somewhat acceptably in single player mode, but the problem was that the behavior of the physics simulation wasn’t 100% consistent on every framerate. As the framerate dropped and the timestep increased, the physics and the animations of the characters started to get a little “off”, and with a large enough timestep, the physics joints would just go crazy and the characters would basically explode. The physics seemed to work fine on framerates above ~25 though, so I just limited the timestep so that the game doesn’t try to compensate the dropping FPS too much and break the physics.

When I started testing on syncing the physics between a server and client, it turned out the variable timestep just doesn’t work. Even though the physics looked consistent on framerates above ~25 FPS in the single player mode, the slightest differences between the two simulations would cause them to get out of sync. An item hits the ground in a slightly different angle in one of the simulations, bounces off to a different direction and ends up in a different place than in the other simulation.

After some googling I found this fantastic article about fixed timesteps. The technique described in the article wasn’t hard to implement, and now I have a physics simulation that behaves the same no matter what the framerate is.

I took some shortcuts and simplified the way the physics are synced between the clients. The characters or any other physics objects that can be manipulated by the players don’t collide with each other, and this isn’t an FPS game where it can be crucial if a character is “actually” in a slightly different position than it appears to be on your screen, so I decided to skip latency compensation altogether. This means that the server and other clients are always a little behind a client controlling a character (you can see it in the second half of the youtube clip below). As there is essentially no way for a client to collide with or otherwise manipulate any of the other clients, at the moment it doesn’t make much difference. The only case were it could be noticeable, would be if two players were trying to pick up an item at the same time: it might look like you picked it up first, but actually the other player was closer to it and his key press arrived to the server before you, in which case the item would be pulled from your character to the other one as soon as the “player 2 just picked up that item (not you)”-message from the server arrives.

There will be various weapons (or tools that can be used as weapons) in the game though, so this kind of simple system might turn out to be insufficient in the future in which case I’ll have to implement some kind of latency compensation, but atm it works great!