Motherships

Let's design another space game! There's so many options. This one is about building starships for multiple phases with multiple nested vehicles - like Kerbal, but instead of discarding earlier stages, you use them as motherships.

The game's most core activity is definitely travel. Travel from star to star, planet to planet, moon to moon, continent to continent. Although there are fuel constraints, the fuel constraints are not the focus. Instead, the focus is on different types of travel and the hazards associated with them. In general, traveling doesn't require a tremendous amount of effort, and time acceleration can be used to make it pass more quickly, but the hazards involved can require some careful planning or intervention.

For example, a particular star might throw out massive amounts of radiation. In your mothership this isn't be a problem - the way the saucer hull is designed specifically protects it from all sorts of radiation. But in a landing craft, your heat will rise rapidly. There are a lot of ways you can deal with this. Design a ship with good cooling. Land on the dark side of the planet. Have a coolant system which can be discharged to cool you down but uses up some amount of coolant to do so.

Combine this with a much wider variety of planetary difficulties - active volcanoes, sand storms, liquid methane clouds, acid atmosphere, science to do on the bottom of the ocean... some are planet-wide, some are biome-wide, some are system-wide. All require you to plan your missions a bit more carefully, especially since the way the rewards are structured will push you to visit as many different planets and biomes in one trip as you can manage.

Piloting vehicles is the "core" challenge, but there are three other play elements which crop up, all of which use the same mechanic. These require me to explain the camera:

This is not a proper 3D game. It's a 2D game, with very simplified spritework. Not pixelated, but more like simple vector art. This means that the camera can be zoomed and panned, but not tilted. So your mouse cursor doesn't control the camera in any meaningful way. Instead, the mouse is used to interact with the screen. Because the ships are designed in a psuedo-2D, no element of the ship is ever completely hidden by other elements, although obviously a cross-section must sometimes be shown in order for you to see through the outer hull of something like a saucer.

So you can easily click on specific elements of the ship.

For something like our coolant system, you could click on it to discharge coolant, PSSSH. Right click for a single large coolant spray, or left click and hold to continually spray until you are cool enough by your standards.

This same method can be used for many other kinds of interaction. For example, if you click and drag on a satellite dish, you orient the dish towards your mouse. By gently tweaking the exact orientation, you can "tune" for a precise connection to other dishes you've installed in the system (or even between systems). This is shown via a static-covered icon of the target you're connecting to, so you can both choose a target and fiddle to try and clean up the static.

Something like a robot arm no longer needs to be painstakingly controlled joint-by-joint. Just click and drag to move the arm around. Want to dock? Get close, then click and drag your docking port to either extend an umbilical or allow autopilot to take over and line you up.

You can also use this method to draw resource flows and circuits, remove or attach modules, and so on. Just click and drag, or just plain click to activate. Some of these will be things the ship needs to deal with hazards or day-to-day operations, others are ways to fine tune interaction between the ship and the nearby universe.

So the three play elements that use this method are:

Ship management. This includes things like coolant, turning on or off various expensive systems such as labs, accelerators, hydrogen harvesters, etc. With these, right-clicking typically does a quick burst or toggle, while left-click-and-hold cycles it for as long as you hold the button. This is also important for deploying or drawing components, such as setting up land bases using local regolith or inflating a hab module.

Intership management. This includes docking, grabbing things, moving modules or resources from ship to ship, connecting beams or antennae - anything where a click-and-drag allows you to specify a target ship, ship component, or world.

Non-ship management. This is when things that aren't mapped to a ship module show up on the screen to be interacted with. These are usually HUD elements which are only on-screen when you activate a module that has complex interactivity. For example, a fleet command module will show pictures and status on all active vehicles in the area, and you can interact with them in basic ways by clicking on their icons. Similarly, this is how you program a flight computer or designate duty cycles with astronauts.

To facilitate the need to travel from place to place, a large part of the game features resources that can only be created or used in specific regions, and therefore have to be transported. This could easily involve all four kinds of play. Travel, obviously, to pick up a resource from a ground station and carry to the mothership. Ship management, to turn on the processor for that resource when you need it, but not leave it on eating fuel when you don't. Intership management, to reach out and grab the resource, then load it into the transport bay. And non-ship management, to receive an alert that the ground base has finished production of that material.

You could also do the whole thing while cutting those away. For example, you could use a mass cannon to fire the resource without needing a transport ship.

You could also do the whole thing by leveraging those significantly more. For example, recording the flight profile of you fetching the resource, then simply dictating that the flight computer do the flight for you the next time, playing it at 100x speed.

There's also no particular restriction on how you do it in the first place. Maybe instead of a base and a mothership, you just have a saucer that lands, processes materials from the ground, then launches into the sky and does the orbital processing, all in one ship. Of course, that means you have a very large, complex ship, since each of those steps is fairly large. The advantages you could have gained by having two stationary ships is that you could deploy very heavy or fragile extensions knowing those two ships would never need to move again. If you have to pack it into one ship that has to move, you have all that weight and required reinforcement loaded into one chassis.

This also has the added benefit of pushing the player to include several different classes of vehicle in the same mission, beyond the simpler "visit A then B" ship designs they might have defaulted to.

Combined with a tech tree to make the various components and sizes come out in a lumpy fashion, I think it sounds like a fun game.

Anyway, that's it.