Download Audio

A couple of weeks ago, dudecon introduced me to Kerbal Space Program, an in-development “space program” simulator. Since then, I’ve started getting up early to squeeze in an hour or so of play in the mornings, played at home, played at work, and spent no less than 20 hours developing a Python script to parse the game files to do out-of-game “rocket science” analyses on parts and spacecraft. You don’t know me very well, so in case I’ve not made it clear: I think this game is a ton of fun.

For a few basic definitions, let’s start by clarifying that at this point, Kerbal Space Program (“KSP”, from now on) is a toy, not a game. While the developer’s website and in-game UX stubs suggest a game component is in the works (for more on this, I defer to Shamus Young), KSP is currently available only in “sandbox” mode, allowing players to build, launch, fly, and fail subject to nothing but their own whims and the brutal reign of mostly-realistic physics. If “space program simulator” is ambiguous, the premise is that players build space ships using various parts, launch them (or fail to launch them), and then do mostly-realistic space ship things with them. These space ships are intended to be reminiscent of actual space craft from yesterday, today, and “tomorrow”; you don’t build faster-than-light city-ships with ultra-powerful weapons and fight wars. You build multi-stage lifters, orbital fuel depots, satellites, and rovers, and you try to put them in stable orbits around planets and moons (or not), and if you’re very daring, you might even try to land on planets or moons (again, or not).

An orbital lifter in the Vehicle Assembly Building

In-universe, the Kerbal Space Program is an effort of the Kerbals, a race of small green humanoids from the planet Kerbin, a roughly Earth-like world in the Kerbol system. The Kerbol system comprises six planets and one dwarf planet along with ten associated moons. Most of the planets are designed to be rough analogs of planets in the real-life Sol system; Mercury, Venus, Earth, Mars, Jupiter, and Pluto, specifically, though there are significant differences in every case.

This intrepid Kerbal can’t get enough of the sunrise as seen from the surface of Eve. Nevermind the wreckage of his ship in the background.

As I described it to a friend, KSP is a unique experience in that almost all of the fun (for me) comes from the metagame. The in-game play mechanics are simple and predictable. Rocket turns left, rocket turns right; rocket burns hard, rocket burns low, and so on. There is no in-game conflict that will prevent you from controlling a vehicle as you see fit… provided that you have designed a vehicle that may be controlled as you see fit. Most of the fun is had in designing a vehicle and the lifter for it, pre-planning a route, and planning specific burns to provide the motion you imagined. The game provides a handy burn-planning tool, which doubles as an instructional tool for how orbiting really works.

Planning an orbit to be captured by Ike, Duna’s moon. Duna is roughly analogous to Mars.

The only obstacle to overcome in KSP is physics. The developers use the patched conic approximation, a real-life tool used in planning space travel, to simulate orbits and facilitate burn planning with reasonable accuracy. Air drag is also simulated (though currently, the implementation is fairly rudimentary), which makes getting to space harder than it looks (or perhaps, just as hard as it looks). Where most games use realistic physics as some equivalent of eye candy, KSP exposes physics as a harsh, unyielding foe. Early attempts at rocket building will almost certainly fail spectacularly. Poorly-timed maneuvering will waste fuel, and eternally strand your immortal Kerbals in the void of space or on the surface of an alien world.

A (very) small fuel lifter docks with a space station.

One of my favorite features (indeed, one of the most crucial features) in KSP is the ability to “time warp”. Since they are accurately simulating orbits and using realistic-ish rocket power, an orbital transfer to another planet takes months to years to accomplish. Obviously, players can’t wait that long, so with the push of a button, we can accelerate time up to 100,000 times normal. Even at that speed, transit to another world can take several minutes, which helps convey the enormity of the distances being traveled. While this isn’t quite a “Win the Game” button, it is a meaningful example of a game feature intended to reduce player tedium, and therefore it’s a Good Thing.

Of course, nothing’s perfect. Some of the user controls are cumbersome or non-obvious. Stages are easily controlled only by a single button: if you need something more complicated than a spacebar press, you’re probably going to need to zoom in, right-click on the part, and do it yourself. Resource transfer between parts is possible, but requires one to think of alt-right-clicking on the relevant parts, which didn’t come up in the tutorials I’ve played through. The game also doesn’t make use of any tooltips to communicate available control inputs; it would be handy if one could tell (at least in the assembly building) how to operate the controls being installed.

While some things might be non-obvious, though, there are a lot of ways to control the movement of a vehicle; not only are there distinct controls for engine burn, rotation, and translation, you can change the way in which those controls are interpreted by pressing Caps Lock to toggle between integrative control mode and normal control mode. There is also a docking mode, which puts translation controls on WASDQE (usually rotation controls); in general I’ve found that to be more confusing than helpful, but hey: options are nice.

The simulation also isn’t perfect. Aerodynamics are currently based entirely on surface area, so formations like nose cones that reduce drag in real life actually increase it in KSP. The patched conic lines in the orbital map also aren’t perfect; in a screenshot above, you can see my probe lined up for a beautiful capture by Duna’s moon, but once the probe got inside Ike’s SOI, the actual trajectory was revealed to be a hyperbolic plunge into the surface (but don’t worry, I pulled out of it). Life support isn’t simulated at all.

Ike, Duna, and Kerbol, seen from low-Ike orbit.

In an age of interplanetary travel, you might expect sophisticated computer systems with advanced automation, but KSP offers none of that. The closest to any automation is provided by the stationkeeping (“SAS”) modules, which can help to dampen your control input or hold a specific heading, so you don’t need to futz around with the rotation controls trying to keep a heading through a 20-minute ion engine burn to send your probe to Eeloo. Automatically timed burns, autopilot heading correction, and so on, though, don’t make an appearance in the stock game.

On the bright side, the game is eminently mod-able. Almost everything in the game is described by plain text files: if you want to change the amount of thrust output by an engine, just open up the part.cfg file and tweak the “maxThrust” line. If you want to make fuel massless, open up ResourcesGeneric.cfg and change the density. It also supports plugins, and has a healthy community of mod authors offering everything from new parts to advanced automation to orbital surface mapping. There are a few apparently-confusing aspects to this configurability. While most properties are defined in the text files, and most of the geometry is defined in open-format “COLLADA” models, certain elements like thrust vectors and gimbal joints require a “middleman” file made by the Unity tools. Planets and moons can’t be added to or subtracted from the solar system (though some of their properties can be changed). There are also a handful of parts with mystery properties: where most parts explicitly define their resource intake, scientific sensors have no such definition, but magically draw ElectricCharge anyway. These odd deviations from the generic “everything is plain text and mod-able by the user” motif seem somewhat jarring against the otherwise dramatically-open configuration, but despite that appearance, KSP presents more end-user mod-ability than just about any other game I know.

I would be remiss if I didn’t point out that KSP is cross-platform compatible and completely DRM-free. The demo and paid versions are available for PC, Mac, and Linux, and are portably packaged so you can run the game off a thumb drive or other portable storage method, so you can literally sit down anywhere and pick up your saved game. I’ve even managed to cross-link a Windows and Linux install to avoid duplicating data. While in some respects this might seem a little backwards in today’s cloud-connected gaming world, in other respects it is a refreshing change of pace. If cross platform and DRM-free development are things you care about, you might consider supporting KSP even if you don’t plan to play it.

All in all, I think Kerbal Space Program is a great toy, and a welcome addition to the repertoire of anyone who ever thought it would be cool to go to space as a kid. While the lack of any in-game progression or reward system can leave you with a “now what?” feeling, the design and planning challenges it allows can keep one interested for a long time. But, because it’s a toy, and because it relies on intellectual curiousity and imagination for player motivation, you might not think so. Want to find out? Go download the demo. You might even learn something about rocket science while you’re at it!