Starship Game Design Discussion

I've been really thinking a lot about the kinds of gameplay you can get out of different kinds of design/construction games. So I've come up with a new idea for a game, which I'm codenaming "Rocketload". I'm going to discuss the design here, and although it's in public, it's mostly to cement it in my head. Feel free to comment if you somehow find it interesting.

The game has two fundamental pieces that work in tandem. There's a payload design/delivery system, and research system. They support each other and both operate in the same timescales in universe time. IE, if you launch a new payload, you could fast forward until it arrives... but all the other facilities and research projects and rockets will progress apace.

The rocket part of the game is component construction followed by staged launching, but not like Kerbal. Rather than constructing a physical rocket, you would construct a logical rocket. We're going to abstract out the physics because otherwise we wouldn't be able to simulate a hundred payloads simultaneously, which we're going to need to be able to do. Your highly trained rocket engineers will turn the logical design into a concrete design and send it into space for you, as you watch.

That's because the focus of our game is not on rocket physics, but on creating a massive network of spaceborn facilities. The focus is on facilities, not on rockets. The rockets just act as a constraint on your ability to put facilities in places.

Designing a rocket is a simple matter: the design section is a bunch of horizontal bars. Let's say we want to design something like Sputnik: it goes "beep beep" as it orbits the earth.

We grab the "beeper" object and put it on one of those bars. Next to it shows up the warning "Requires 1 mAh/day, no power source" or something similar. So we drag our smallest battery (1 Ah) and put it on the bar below the beeper. The simplistic logic of the bars instantly understands that the battery is available to power the beeper. So the beeper's warning would change to "42 day limit". That's how long it'd be until the battery runs out of juice.

We need to put it in orbit. For that we'll need a rocket engine, so we choose a launch-grade engine and put it below the battery. We could add as many launch-grade engines as we want, but one will do. We also have to add some fuel, so we'll put it on the same row to link it to that engine. To help us with this, at any point we can designate a target for our launch by clicking in the solar system map - a low orbit over our home planet.

A burn pattern would appear - a line of varying color to denote burn points, and whether there is enough fuel for them as loaded. When the target is assigned, the engine bar has a note attached with a fuel cost vs how much fuel you've got loaded up. You can launch without enough fuel, if you like - the assumption is that you'd pick it up somewhere out in deep space before you needed it.

So it's a much simpler setup than Kerbal, all about simple logical connectivity.

But there is some complexity hidden in the wings. For example, let's say we want to put it in orbit around the moon instead of ourselves. One option would be to simply click on a lunar orbit instead of a homeworld orbit. However, the engine costs for this would be annoying. So let's change out the launch-grade engine for the smallest engine we have, and much less fuel. The burn pattern blinks error - you can't reach escape velocity with this. But we can package the whole thing up as a stage by simply clicking on the little "-{" button that encompasses those three bars. Then we add a launch-grade engine and some fuel to a fourth bar, and the system understands it is responsible for launching the other payload, including the small rocket and its fuel. So we click on earth orbit for this one.

This stage's burn pattern is from the surface to orbit. The inner stage's burn pattern is now from orbit to orbit - something the small engine can handle.

Of course, you can continue to edit the stages. Add fuel to the inner stage. Remove fuel. Add a new rocket. Layer on as many stages as you want and put the satellite around Pluto - although it'll run out of juice at 42 days, so you're not likely to still be able to hear it.

Now this was a simple beeping satellite that creates only a very modest number of science points, and it'll run out of battery before anything goes wrong. But the primary concern with facilities is maintenance. Stuff breaking. Everything has a degradation rate, with degradation being that rate added over time. It will break when it hits 100 degradation, so something with 1 degradation/day will break in 100 days without maintenance. Our beeper and tiny battery probably have 0.01/day degradation rate...

This degradation rate really changes how you try to build facilities, because you have to take into account their failure rate and pattern. Humans can maintain (reduce degradation rate 90%) and repair (reduce degradation total from 90 to 50 at the cost of spare parts), so having a manned mission can radically extend the longevity, although all that life support is heavy. Also, humans act as a science lab or construction center, so if you want to do offworld research/construction, you'll need folks in orbit.

However, the degradation rate is not 100% static. Rocket engines produce a specific amount of vibration, and that's doubled or so when traveling through an atmosphere. Vibration causes degradation to the rest of the system, but not equally: each layer absorbs some of the vibration, reducing the effect on the next layer. So, in our "beepy satellite around the moon" example, once we got to earth orbit and our launch stage detached, we would see that our small engine for reaching lunar orbit would have quite a lot of degradation, our battery less, and our beepy thing least. Our small engine produces only a small amount of vibration, so it's unlikely to cause our battery to fail.

This should give facility/starship design some fun complexity, especially when you start to consider docking, replacing parts with other parts, strapping on add-ons in deep space, and so on. It can rival Kerbal in terms of complexity, but the complexity is all on the space side rather than the liftoff side. Scattering facilities and probes all over the star system for science, materials-gathering, construction, culture, staging... yeah!

Of course, the other side of the game is the science half. It makes the facilities matter.

While it's always a fun impulse to build a space station for the sake of building a space station, it's important to the longevity of the game to have that space station matter in the game world. And this is where science comes into play.

Let's say that your scanny probe picked up a new kind of resource while orbiting earth: a resource called "paired ions" or somesuch. The scientific explanation doesn't matter, all that matters is that it's something new and you want to bring it home. So you need a collector for it.

So we go home and build a new kind of rocket part - a deep space "paired ion" collector and storage tank.

We do this by using the device creation system, which looks just like the standard payload system, except you're using logical components rather than rocket components. Our device would be a tank (defaulting to standard alloys and intended to contain paired ions) with a deep space intake pointed into it (defaulting to standard electronics, and intended to ingest paired ions).

Just like that, we have the plans for a device. Except that device is going to be really, really slow or awkwardly huge, because it's a passive collector, and passive collectors are rough. So let's put in some electricity. We could add a battery (a tank containing electricity), but it'd make more sense to just specify an electrical intake, allowing us to power the collector from any kind of electrical source we want to design into our rocket. There. Our efficiency skyrocketed.

Of course, this is just an idea for a device. It's not finished. In order to actually create the device, we need to add in some research elements. The basic idea of any R&D project is that you start off by researching (using science inputs), and then you transition to engineering and final design (using material inputs). Science inputs basically build up "momentum", and then you bleed off momentum with the material inputs until you reach 0 and stop. The more science input, the better the engineering of the final result. The more material input, the larger/more materials. In both cases, momentum is based more on time running rather than actual amount of science/material, so juggle things to be more effective.

This is reflected by simply dragging science and/or material inputs onto whatever components you want them to be attached to.

One science input is the facility that detects the paired ions in the first place. Let's attach that to our ion collector part. This is a good match, because our detection facility is detecting the same resource. The two are well-matched, and therefore the research will be more effective than the momentum would imply. This should give us a really high-quality collector!

We also have a satellite orbiting the earth going "beep beep beep". We could add that to another component, such as the electrical input or the tank itself. But there's not any particularly good reason to do that - it'd add momentum for minimal benefit. We also can't add it to the collector: only one science input per device. We go ahead and add it to the electrical input just in case we want to use it, even though it's unlikely. Still, that means we can't use it in another project. One science project at a time.

To decelerate we need to add materials. We'll add a stock alloy material to all three elements, since we can throttle them as we please and don't have to use them if we don't want to.

Our project is then a matter of throttling up on the ion detection research input and leaving it throttled up as long as we want. We can go do other things, leave it "baking".

After a while, when we feel we've done enough research, we can throttle up on the storage tank's materials. This will cut research - you can only do research or development at any given time, not both. This will steadily decelerate us, and in the end we'll have spent all our acceleration on our collector, making a very high-quality collector, and all our deceleration on our tank, which will give us a very large tank.

The final stats also have to include degradation and price as well, and it's all worked out with simple algorithms. This system would have a noticeable degradation, because it has a high-tech part that isn't very big. If we had decelerated on the collector instead of the tank, our collector would be much bigger (and even more effective), and have a lower degradation rate due to the extra space and material used. Of course, our tank would be tiny.

And then the part gets added to our manifest and we can put it on a rocket, fly it out there, do our collecting, and then bring it back to our orbital base or land it back at home using parachutes.

Of course, it can get quite interesting. For example, what if that detecting station crapped out partway into our research cycle? Would we continue to accelerate using just the "beep beep" satellite so we could have a larger final product, or would we settle for a runty final device?

Also, paired ions are a material. When we get back a tankload, we might build an engine that uses paired ions as fuel. We might then use paired ions as a development material to decelerate the research. But this uses up our limited supply. What if we run out before we finish decelerating? Do we let the project idle along while we go fetch more?

All told, I think this combination of systems allows us to take our own approach to developing our space network. It also allows us to occupy the same space as other players (if we want) while still having distinct technologies. The combination of device function, research sources, and materials should make developing new devices fun, and keeping your space facilities operational in the face of degradation should keep things spicy.

The key to all of this, the hidden purpose behind this design, is mods.

See, using this system, mods are very easy to make.

If you want to add a laserbeam comm array mod, then you would add the laser beam pieces into the base device options. Then, not only can you distribute your default laser comm devices, but other people can use them in other kinds of devices. For example, powering their laser with jet fuel, or having a laser input control their light show. This should allow people to combine mods very easily as well, since the various mods will have device options that can be combined into one final device rather than being distinct objects that must always remain separate. The key lies in the simple but robust method of connecting elements to each other.

That's the hope, anyway.