Work continues today on the power system.
I think I've got a working set of code to emulate power needs on a ship, and I'm now in the process of filling-in some content to test it. And since seeing it makes it easier to explain, here's what I have so far:
The above room is a continuation of the air pump simulation from a few days ago. To recap: an air tank (orange cylinder) is to the right of an air pump in the wall, which gathers gas from the room to its left, and pumps it into the tank. The new part are the snaking blue conduits and the battery in the lower right (below the light).
As described yesterday, ship items are going to need power, and to get it they'll request power from points specified in their data. If the thing under that request point has power, it's delivered to the requester, and it runs for one more turn. If not, the requester shuts down until it can have its power needs fulfilled again.
In the example room above, the air pump needs some kWh per "turn," something like 1 kW/h. So when the pump is ready, it checks its nearby points for power input. Assuming one of those points is the tile to the right, we find a conduit, air tank, and floor there. Since the conduit is the right type, it tries to get power from that.
The conduit, however, has no power stored, so it requests power from its nearby points. Since this conduit is an "L" shape, it tries to get power from the tile "south" of it. That, in turn, tries to get power from the conduit to the right, and so on until we reach the battery. Since the battery actually has power stored, it deducts from its charge (if any), and sends a message back up the chain about how much it gave. Assuming we have enough to fulfill the pump's request, the pump triggers another "turn's" worth of action until it makes the next request.
So far, I think this'll work. It'll allow distant power sources to supply components around the ship. It also allows power to reroute around faults in the path, in case one of the conduits is damaged. More importantly, I'm hoping this will be one of the "fun" bits of ship building: planning system layouts, power needs, redundancies, etc. Then, setting the ship loose and watching it succeed, or more likely, fail.
One of the risks of this system is performance. Each power cycle is a series of connection requests, possibly many for complex layouts. And this could eat into performance. However, I'm hoping that by keeping the rate of requests for power limited, it won't kill performance. E.g. if each item on the ship requests power once per second, that shouldn't be too bad. And if power fails on the ship, a 1-second lag time to shut-down of connected equipment won't be unrealistic.
The other, more scary, risk is that this won't be fun. I was reading Tynan Sylvester's AMA today on reddit, and one of the things he discusses is the core of a game's design. He warned against adding complexity to compensate for lack of fun, or not identifying the fun soon enough. He explained that core game concepts should be identifiable as fun early on, and can be reached by trimming out excess fat over and over until there's one irresistible experience.
I'm not sure that I'm doing this very well. I mean, I expect to enjoy this, but it's not enjoyable right now. Heck, there's not much to do besides build. And maybe watch funny AI bugs. It's no more a game than a Lego set. An unfinished, glitchy Lego set.
Then again, I think I'm building towards an experience I already know I like. Namely, Prison Architect or Rimworld within the context of a spaceship. It'll have differences, but a lot of the fun I have in those games is coming up with a new design for a prison/colony, and testing to see how well it works in practice. That's the core experience, and it may be that it cannot exist without a certain minimum number of interacting systems.
Which I guess Tynan also admits in his StarCraft example. One can strip out a lot in SC to reach the core, but the core still has several parts. 4 unit types, AI for the units, a map with resources, and an opponent. I can probably narrow down the number of systems I have to a minimum, and add code to test it with a crew in space. Maybe that should be a "game jam" goal I set for the near future?
Worth serious thought.