Repeating-Design Space Ships

Recently I've been thinking about space ships. AH HA that was a joke. I've been thinking about them since I was three.

One of the things I've done in the past is focus on the concept of systems in a space ship. You need life support, engines, fuel, solar panels, batteries - by breaking down the ship into a pile of parts, you can create a lot of complexity. It's also useful because you can add in additional complexity easily - just create or mod in new parts with new functions.

But there is another approach to ship design: having many of the same modules.

You can see this most commonly in space ships from movies or concept art: the artist doesn't need a space ship that statistically "works". They need one that looks and feels "right". So it has dozens of repeating modules - hundreds of engines, dozens of rows of unnamed windows, glittering lights aplenty. You can also see this in parts of Space Engineers, due to the fact that modules cannot be scaled, so larger ships need more repeating modules rather than larger versions of the modules.

There is something to this design sense, both mechanically and visually. Space Engineers doesn't really take advantage of it - I can't blame them, because nobody has.

Space Engineers (and most other non-physics ship games) use non-topological modules. That is, aside from some minor restrictions, it doesn't matter where in the ship the modules are put. If you need 50 engines, you can arrange them however you want, as long as nothing is directly behind them. This is good in that it gives you a lot of freedom as to how your ship looks, but it's bad in that it's not very compelling gameplay.

One easy way to make it more compelling is to make topological relationships matter. For example, imagine that an engine module has an efficiency rating based on the modules around it. Maybe the engine module generates heat, and if that heat is allowed to build up efficiency falls off... but if it is kept too cold, it also falls off. Maybe having high-pressure fuel raises efficiency, but every engine on the "fuel chain" diminishes the pressure for the rest. Maybe the engine module vibrates, reducing the efficiency of neighbors. There's a lot of options.

Addressing these options is a fun part of building a ship. Not only will you want to place your engine modules carefully, but you'll want to use support modules such as heavy-duty pumps, heaters, heat vents, dampeners - and those support modules may also have a variety of requirements.

Topological constraints can really make building ships interesting, but there are some constraints on the constraints. Lemme 'splain.

In order for topology to be fun, it has to be bumpy, have texture - the player needs to be able to properly grip it. Every piece the player adds has to make the player think "oh, this is going to be fun to put together!"

If every module is a 1x1x1 brick in 3D space, the player will never think that. Every piece will just be a bundle of basic stats.

One way to give the pieces "texture" is to change how they are shaped. Giving them various sizes and shapes will make it fun to figure out how they can be interlocked in interesting ways. If certain points on each one are hardpoints or resource intakes/outputs, fitting them together becomes even more complex - but don't accidentally make it so restrictive that there's only one way to fit things together!

There is another way to give the pieces texture: restrict where they can be placed.

An endless 3D grid doesn't give the player anything to grip onto. But if you make assumptions about how your ship "needs" to be laid out, you can really change the end result. for example, we can assume a standard "spinal" ship design. Then we can allow the player to choose how long or broad to make their ship, and split the spine into sections - crew section, support section, engineering section, engine section. Each module can only be attached to one section, or to a part that is ultimately anchored to that section.

However, modules near each other are "smoothed" together with the ship skin, linking them physically in the final form even if the modules are actually anchored to completely different parts of the ship. In this way modules from different segments can interact with each other and be linked together, allowing them to affect and support each other, and forming the basis for topology more complex than a simple branching tree. Basically, branching tree construction, but realspace interactivity.

Another option is to create a spaceframe of some simple shape (like a 'U'), then allowing you to put modules anywhere... but never attach modules to modules. All modules must be attached to the spaceframe. This "surface area" approach allows you to relate whatever mods you like, but space constraints become absolutely critical. Obviously, larger spaceframes have major drawbacks.

There are a lot of other methods, but the basic idea is simple.

I've been thinking about this a bit recently, partly because it produces much more refined ships. Rather than being a simple string of every required module, the space ships have repeating motifs. If you wander around inside of them, you'll walk through a ship that seems to be engineered to fight against space: halls of pulsating engines, rows of churning computers, life support pumps hammering away. It's not just a checklist - "life support, check!" - it exists properly. It's been designed, carefully balanced and placed by a rocket scientist (or, at least, someone pretending to be one).

It also looks better from outside. Regardless of the constraints used, the repeating module motif produces much more interesting ships than the "one of everything" motif.

Anyway, those are my thoughts.