Tuesday, October 29, 2013

Constraint is Interesting


Last essay I talked about the idea of adding mechanical polymorphism. Things like arms that can transfer goods and whatever else I could come up with. But it didn't feel compelling. Today I'm going to restrict that mechanical polymorphism while talking about research. It's more interesting than it sounds.

Fundamentally, it is very compelling to unlock more stuff. It's interesting to go on a mission using a bunch of shitty components so that you unlock a better version of one of them so you can go on more missions. It's very compelling. But I don't like rocket launches as a primary mechanic. What can we use besides that?

How about a railgun? A hundred miles of magnetic rail that shoot you off the top of a mountain. This takes care of the first launch stages, so your designs can focus on the more interesting final stages and payload.

But if you take out the launch stage, you lose a lot of research potential. A big part of discovering more modules is discovering better launch modules. Larger tanks, larger engines, better fuel management... take that out, and what do you have?

Well, a lot, of course. You can focus complexity and growth into anything.

See, the biggest restriction is still the launch platform. But instead of being a giant cluster of rockets, it's a railgun. The railgun never changes, nor does the atmosphere. So our payload has to be a specific kind of shape to properly fire from the railgun, and has to be aerodynamic enough not to tumble, shatter, or excessively brake in the atmosphere. IE, it has to be one stack.

So our progress up the tech tree isn't about "bigger", but "smaller". For example, an early generation computer might be the same size as a cockpit - but after a few thousand science points, you can use something the size of a thumb that has hundreds of times more power. Similarly, you might start with inefficient solar panels pasted to the sides of the chassis, then figure out how to make versions that fold out a bit when you reach orbit, then figure out how to make them massively expand - the exact size and weight of the payload component will vary, but the final result will be significantly better.

There's no reason to leave the simple stuff behind, though. You can also figure out how to use solar paint - no folding out, but ultra-lightweight and quite efficient. Similarly, there are times when you'll still want a giant computer on your payload - but the new giant computers are so much better than the old ones. So there's always a lot of possibilities.

The biggest and most interesting challenge to this is the "unfolding". It's pretty easy to attach rockets and stuff, get the payload going in the right direction. But a lot of payloads will want to be in some shape besides "stack of fuel tanks". For example, you might want a space station with long struts, or a lander that has a dome shape. The launch profile has to be a stack, but you can always make some components of that stack fold out, inflate, assemble, or otherwise change shape.

For example, you might create a stack where you have a four-arm fold-out module that will create a 4-way perpendicular set of arms. But what's at the end of the arms?

Well, whatever you originally packed in line with the column, crowded into a stack segment divided four ways. And maybe one of the things crammed into that space is, in fact, another mechanical device which folds out and in turn has its own divided substack segment... You can see that we've changed the name of the game from "more fuel and rockets" to "packing shit in more efficiently". Rocket Tetris.

There's a lot of room for manual labor, here. Not everything can always be packed in line with the stack, so maybe you send it up in another payload, or maybe it's in a different part of the stack, a place where you could fit it. Then an astronaut puts the two pieces together manually.

There's a lot of fun complexity hiding in this concept, and it's a much deeper and more interesting concept than the ones I've come up with previously. I don't want to go into excessive detail about the play cases here, but if you try to imagine how you might drop a rover on the moon using this kind of system, I think you can start to see how interesting it might get.

By adding a strict constraint (everything must go in one stack, no projections) we add a lot of depth in trying to work within that constraint.

As usual, there is a good reminder in this. Games are born more out of constraint than freedom. I tend to forget that.

No comments: