Open SS13

Work is continuing on the Open SS13 code; not lots of progress, but steady. Mostly at the moment I'm converting badly formatted, uncommented, decompiled code into something more modular, easier to read, and understand. The idea being to make things easy to extend, for adding new objects, game modes, and other systems. It's slow going, but we'll eventually get there. One nice thing about going through the code is finding a long-elusive bugs.

The other thing I've been working on is the pipe system. The current revision allows you to build and lay new pipelines, but doesn't yet allow cutting (or properly handle destruction) of current pipes. Part and parcel of that system is damage to pipes - from excess heat or pressure, for example. Eventually I want to make it so that, sure, you can run the engine at extreme temperatures by chucking a whole load of plasma canisters into it, but after a while that'll start damaging the pipework and you'll have to send someone inside to repair it. That'll also make engineering a slightly more interesting job, which is always a worthwhile goal in SS13.

A slightly more elaborate pipe system also allows something I've been wanting to try: a more centralized air system. Currently, magic air regulators in each room work autonomously, but I've been trying a few experiments with linking them to underfloor pipelines that scrub and supply the air at a central machine (or rather, a few machines for the whole station). I need to experiment to see if it's viable to do things this way, otherwise everyone will suffocate. The trick seems to be pre-filling the pipes with air at spawn; otherwise, the air in the rooms rushes in to fill the vacuum in the pipes, leaving none to breathe.

One big issue with a centralized air system (which has been noted every time it's mentioned) is that it's too powerful: the system would allow you to poison the whole station from a single location, just by feeding plasma into the lines. There are ways around that, though - for instance, making the only direct way of adding gas to go through the filtration unit, so you'd need to supply a lot of plasma before you'd deplete the filters and they'd start letting toxins through. The other way would be to cut into a line and build a new canister connector - something that takes time, and could be easily noticed. The idea being to provide opportunities for mayhem without making it too easy.

After that (or maybe before it), the lighting system. Currently, the OpenSS13 lighting is pretty simplistic. A better scheme (seen in Trafalgar's B12 version) also mixes in BYOND's standard lighting system, given a good reason to use flashlights, etc. However, what I'd really like to do is integrate a multi-brightness lighting system like Shadowdarke's Dynamic Area Lighting (updated slightly to use alpha blending rather than dithering). This needs quite a bit of work, since it's would be incompatible with the way SS13 uses areas for the power system. It'd also need testing of CPU loading - the game currently is a CPU hog thanks to the air system, and adding sd_DAL might tip it over the edge. But we'll see.

There are plenty more things I want to do (module system for object repair/construction, secondary wiring for object power, computer networks, etc.), had I but world enough and time. Eventually, I want to get the enough systems in place to support a persistent-state SS13 with station(s) build from the ground up, but I'll talk about that another time.

SS13, in 3D

I recently saw the subject of rebuilding SS13 in another engine come up once again. As usual, a mod of the Source Engine (as powers Half-Life 2, etc.) was mentioned as a prospect. And as usual, I think that's a terrible idea.

For me, the two major reasons SS13 is worth playing are (1) the air system, and (2) the destructable/rebuildable nature of the environment. In the Source Engine, you could probably hack together an air system (it wouldn't be pretty, but it'd work). But part 2 is right out. Source is optimized to work with a static, low/medium detailed world mesh populated by a high number of more detailed static models, and a lesser number of dynamic models. Everything, from the BSP tree up, is designed around that. It is not designed to work well with large-scale changes to the environment, and I don't think you could do so without re-writing many of the core systems, at which stage you've really not got the Source Engine any more.

Another reason to avoid Source is that, ironically, it's too good. You expect a certain level of quality from a Source Engine game (textures, models, etc.) that I think is a hard load on an unpaid dev team - perhaps it'd be better to shoot for something like a Half-Life 1 level of competence. Forget the fancy shaders and so on.

So could you make SS13 in 3D? Probably, but not easily. There are no suitable engines that I know of, so you'd have to make your own. The graphics part is actually pretty easy in concept - if you limited your station building to identically-sized cubical cells (like tiles in BYOND, but in 3D), you'd could use a portal engine to display it, which is an absolute perfect fit to the problem. Other objects would be simple meshes, located inside a particular cell and only drawn when visible.

The cellular nature of structures also make the air system simple - you could carry on pretty much exactly as SS13 works now - simulation at the level of each cell, with the outside being always a vacuum.

You could even make each connected group of cells a free-floating physics-simulated object, allowing them to spin and accelerate w.r.t. the environment. Then you could have multiple groups (multiple stations), and give them thrusters, etc., and pretty soon you've got something like Evre's Starship Server Combat idea, in 3D. Make it a persistent-state world - get out there with some starting equipment, team up, mine asteroids (or something) to build a station/ship, and go blow the hell out of your rivals.

(This in fact would be a hell of a game - imagine a good warhead hit on a station or ship that would literally blow it into two, still partially functioning sections - but it's a pipe dream for now.)

So what are the hard parts? Graphics are fairly easy, as I said - a portal engine for interiors, with scene management for exteriors being something like a dynamic AABB tree, or a uniform grid (or perhaps both). Physics wouldn't need to be too fancy - simple bounding boxes inside, and outside limit collisions to whole cells, and it's all rigid body dynamics. The problem comes with doing that in a multiplayer environment, and networking is where it gets hard. Something like RakNet will do a lot of the work, but you'd need good prediction on that physics to make it work smoothly. That's a hard problem, that even commercial games struggle to do well.

Maybe someone will someday do something like it, but the only thing I sure about is they won't do it in the Source Engine.