Monday, July 14, 2014

Driving Complex Arrangements

Games where you build things rely heavily on the complexity of building things. Constructed objects are placed relative to each other and serve various roles.

Adding depth to the game usually features either adding physics or adding a chain of resources. Physics is much more interesting because it allows for the player to really come up with unusual solutions and makes even small changes to the construction matter a lot. Chains of resources are useful mostly because they are a very easy way to add complexity - it requires very little balancing or assets, and can also easily be added by mods.

I've been thinking of another method, though.

What I really like is machinery that moves and does stuff.

It's a bit difficult to make physics about moving pieces, because fundamentally the most useful machines to deal with physics challenges are stiff things with a few wheels or jets or whatever, not something that changes. Similarly, a tiered system doesn't normally require any movement, just more things placed cleverly.

You can force them to require machinery by changing how things interact and proceed. For example, if you have to change from plane to boat to space ship, you can create a game where that's best done by mechanically moving things around. However, that's simple "hiding and exposing" - the mechanical version of turning things on and off.

You can make a tiered system require mechanics by having to move either the resource in question or the processing units manually. For example, if you're creating a robot, but you have to dunk the chassis in coolant every few steps to keep it from melting, you have a lot of freedom as to how to do that. You could create a long track with all the construction arms and occasional pools of coolant, or you could just have a single pool of coolant that the chassis gets dunked in over and over, while the construction arms revolve in to do their work.

This gets especially interesting if the player can choose the robot's specs and they make the construction method vary, because then there is no "best".

This seems like an interesting way to do it, but the idea of "heat" that needs to be "dumped" made me start thinking about the idea of side effects creating mechanical play.

For example, let's say you're putting crew in a space ship. Your first order of business is making sure to assign crew to each station, so the space ship runs. The crew gets tired, though, so you build bunks and set the crew up on a schedule to sleep and work. The crew gets lonely, so you set up a schedule where they hang out in the canteen together.

The point isn't to play The Sims in space. These things - loneliness, exhaustion, hunger, and whatever else you put in the game - they aren't simply negatives to be deleted. They are a resource.

Removing loneliness generates camaraderie, which can be used to trigger crew events. Removing hunger generates waste, which can be used to grow plants or processed into biofuel. And so on.

Introducing different species into your ship can add a lot of complexity to this if we would like to. For example, camaraderie might come in a number of flavors, which can be mixed in specific amounts to produce diplomacy points, which can be used to trigger international events.

Allowing for flavors and advanced mixing allows for players to set up an almost unlimited variety of setups, with no obvious "optimal". Maybe someone creates a crew and ship that are engineered for optimally triggering international events as fast as possible. Another might be focusing mostly on science production, but carefully save up the rare flavors to trigger an international event now and then.

This sort of game would allow for a very "Star Trek" feel, but with a mechanistic backend. The ship components don't move, but the crew are constantly in motion. Building your crew (at least, your command crew) would be interesting. Their skill sets obviously matter, but so do their fundamental ways of life.

Anyway, that's it. A tired Monday essay.

No comments: