I like construction games. I especially like construction games where people live in the thing you built, like bases or star ships. I've talked about this stuff a lot in the past, but today I'd like to talk about specific kinds of pressures which make construction games more interesting.
When you think of a construction game, you probably think of two common kinds of play:
1) Spreadsheet play. Having enough modules of the right type to get the performance you want. May also involve things like ship speed and weapon coverage stats.
2) Physics play. Having a structure that doesn't break when it's active, or that resists damage well.
These are certainly fine kinds of play, but I think there are some other kinds of play. Let's talk about them.
Connection play is when you have to put your modules in specific relationships to each other, either allowing no space between them or requiring that the space between them be filled with specific modules.
A module that adds on to another module physically takes up space. A cable running from one place to another physically takes up space.
How flexible this is can really change how the game feels. For example, can an attached module be in any adjacent block, or does it require a specific face? Can a cable be curved and branch? Maybe a cable doesn't actually fill the voxel, so you can lay many cables through an area and even walk through them - you just can't slap down another voxel in that spot. Tons of options.
This can also be inverted: a block might require an empty space off of a particular face to allow for heat venting, maintenance access, vehicular traffic, line-of-sight broadcast, etc. These are functionally the same constraints: whether it's a required component or a required empty space, the topological challenges are the same.
It's a fun challenge to stack these up in complex ways. For example, an engine might require an empty tile for venting: why not aim that face of four engines all into the same empty tile? Optimization!
Pull and push is when components exude a particular field effect. For example, a reactor might give off deadly radiation, a heater might give off heat, a factory might give off noise and vibration, an antenna might give off connectivity, etc. If you want to be complex, you can make each kind of field effect propagate differently through different materials: a heavy wall might block deadly radiation, but actively extend vibration due to its rigid structure.
Push and pull act to softly guide the player to leave certain spaces empty and fill other spaces, as well as gently guiding them to put specific modules near each other. For example, an engine gives off heat and vibration, but is almost immune to those things. So you can stick a bunch of engines together, and put them off away from the delicate stuff. A factory produces vibration, but is sensitive to it, so you can't cluster them up. A heater will keep components from frosting over, so put those kinds of things clustered tightly around the heater. You end up with a design that varies system density in a natural and believable way. Good way to do it.
Most of the time, these are binary fields - you're either inside our outside of them. I think that's not a very good way to do it, because it's too rigid and forced - I like a degrading field that has a lot of wiggle room for designers. This also allows you to play with extending or inhibiting a field in a very fluid, adaptable way, and that leads to interesting designs.
This also requires that you can model their effects in subtle ways. I recommend a combination of two factors: maintenance requirements and performance efficiency. A factory that is subjected to vibration might work less efficiently, since it must move much more carefully for the fine detailing. Or perhaps the vibration causes it to break down faster. Even if ongoing maintenance is not part of the game world, simply SAYING that it requires extra maintenance is enough to distinguish it from a better-designed ship. Ideally, you could scuff it up and make it look dirty.
Access is when you calculate clear propagations between a module and another module. One example of this might be wiring: if you wire up all the components on your ship to a central computer, you can access them all and they can all access each other. This is great for operations, but might be vulnerable to hackers or power surges.
Another example would be life support: an air vent provides air to all the open voxels it can reach, assuming it is a contained space. But, more than that: a couch provides a place to rest if people can reach it. A cafeteria provides food, if you can walk to it. A repair gantry provides access to the engines when you swing it out that way, or to the life support systems when you swing it this way.
These access networks can be very adaptable and provide a very nice "soft" way to push players to design more thoughtfully. A space ship where your crew have good access to the engines to maintain and repair them is great, and that can be calculated using an access network. It can also be done in very creative ways: maybe the maintenance space can be pressurized for really delicate work, but only when the engines are off (they produce too much heat). Maybe the maintenance space is actually solid space most of the time, but the engines can be pushed apart like sliding shelves for maintenance purposes.
Similarly, network-wide threats are a great way to make things more interesting. Maybe not everything should be on the same network, because if something goes wrong, everything goes wrong. Maybe there should be bulwarks in the network that can be sealed: airtight doors or circuit breakers. Also, because the network contains all the network flow for all the components, maybe you should separate the network to keep contamination down: keep a data network running light and fast, keep a life support network safe from visitor's diseases, keep a power network safe from sudden power draws from intermittent devices.
All at once
Of course, the ideal is to combine all these things at once, in different amounts and directions.
For example: one kind of starship engine produces heat and vibration, requires empty space for venting, and needs fuel and power lines. Another kind of engine produces deadly radiation, requires no venting or fuel, but requires 100x as much electricity.
Not only are the modules different, but how they interact with the space around them is different. The basic engine can have life support regions and computers relatively close-by, but the other one produces radiation that will cause computers to have glitches and crew to have cancer. So even though they have no access constraints of their own, they affect everyone else's constraints. The high power draw of the second one may require it be on its own power grid, while the fuel requirement for the first one might be harder to topologically manage because of all the physical piping it pulls to your engine area.
So your modules don't just have a statistical presence: they also interfere with other kinds of concerns because of their various constraints.
It sounds like a lot of fun!
No comments:
Post a Comment