Hobnob's Packet

Progress towards possible futures.

Fri, 09 May 2008 16:03:01 GMT

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.

Spacestation 13 H9.5

Fri, 21 Mar 2008 11:59:15 GMT

The confused situation involving the offical SS13 hub now seems to be resolved - the hub password has been made public for everyone. That being so, I've released the latest update to my version (download link) which uses the official hub, and has a few updates, including a new auxiliary engine, some config changes for voting options, and also implements Hikato's Sandbox mode.

I'll be releasing my source changes to the OpenSS13 SVN repository, also. It's still not absolutely clear how that will work, but if a consensus "core" version of the base source is made, I'll work to port my version so it's compatible with it.

Spacestation 13 40.93.2H9.4

Thu, 13 Mar 2008 16:56:44 GMT

Stari has recently been hosting my mod of SS13 for me, which was very kind of him, but his server seems to be dead for the moment. Rather than suffer me hosting it on my terrible DSL connection, I've uploaded the hosting files (download link) for anyone to try.

This version has a substantially reworked engine and generator. Feedback on the changes, especially bugs, is welcome.

Apart from a few minor additions and tweaks, this version is close to ready for me to release the source code to the official dev team (assuming no show-stopper bugs appear). If Open SS13 happens, then I'll release the source publicly too.

Edit: The SS13 hub password has now been set, so this version won't allow you to host public games. However, you can still run it off-line to try the new systems. The dev team has now received the source, and Hikato is hosting a public server.

Edit 2: I've re-uploaded the hosting files so they now use the custom version hub for SS13, as set up by Stephen001.

MapSub, and how it works.

Thu, 30 Aug 2007 17:23:47 GMT

MapSub is a program I wrote to allow editing of maps for Space Station 13. We're in a slightly odd situation with SS13; a perfectly good set of map maker files are available, but the author has moved on to a new project and is no longer interested in compiling maps for the game.

MapSub works by, in effect, converting a Dream Maker DMP file into the same format as a compiled map, then inserting that data into the original SS13 DMB file. It's a fairly complex task, involving rewriting a large portion of the DMB's data structures, but it seems to work OK, and now anyone, with a bit of effort, can create or modify a map for SS13. I hope to see some creative layouts soon.

One particular difficulty is instances; that's what you get when you add an atom to the map, and then change its variables. For example, SS13 has a security camera object, /obj/machinery/camera, by which players can view remote parts of the station. Adding an atom to the map is pretty easy, you just need to know its index number (atom number 32, in this case), but complications arise because each camera needs two variables set: its direction, dir, and a unique name tag for the camera, called c_tag.

If you open up a DMP file in a text editor, you'll see the values of the instance variables after each atom name in braces, for example:

/obj/machinery/camera{dir = 4; c_tag = "Northern Airlock" }

You'll see this format for any atom in the map which doesn't use the default variable values.

The difficulty arises because each of these instance initializations is turned, by the DM compiler, into a tiny, unnamed procedure in the final DMB file. The procedures are executed as the map loads, and set the atoms variables to their desired values. What this means is, if I want to be able to add new instances to a map (and MapSub would be much less useful if it couldn't), then the program must create an initialization procedure for each new instance.

In effect, that means compiling and inserting new DM bytecode into the DMB file; a fairly scary idea, particularly if you're working only with information you've reverse-engineered from the format. Fortunately, setting a variable is one of the simplest procedures: a push of the value (integer, float, or string index) on to the stack, then a pop of that value into the variable. (I'll have a lot more to say about how I think the DM bytecode works in a future post.)

So, MapSub must interpret the DMP format, convert the data into the same format used internally in the DMB file, identify each new instance and build the bytecode to initialize it, then insert that code into the DMB and make sure its referenced correctly. Not to mention decode the string table, append any new strings used, and then re-encode it. Frankly, I'm half-amazed that it works at all, but so far there seems to be no major bugs.

MapSub is written in Java, which has good and bad points. One constant problem is its lack of unsigned data types, a terrible pain when working with file formats (such as DMB) that use unsigned values. There are workarounds, but it's easy to miss a case, and I suspect MapSub will start throwing up bugs if anyone ever starts using, say, more that 32767 different objects. The other disadvantage is the need to download the Java Runtime Environment to run the program. A pity, but on the other hand, half the Windows programs nowadays seem to need some variant of the .NET framework, and it's a chore you only need to do once.

One big benefit of Java is its excellent Collections framework; things like extensible lists, associative maps, and so on. MapSub makes extensive use of these for all the data re-jigging it needs to do. C++ has the STL, which can do all the same stuff, but I find Java's versions rather easier to use.