Module Design in Astrophobia

My Astrophobia prototype is coming along swimmingly, one hour at a time. But one challenge that faces me is the design of the cramped space modules you inhabit.

There are two pieces to this equation. Design from a "how you move through them without getting stuck or lost" perspective, and design from a "what they do" perspective.

"What they do" is slightly easier to tackle, so let's talk about that first.

These modules are proper modules in that they connect up in rather arbitrary stacks. Sometimes you may have to use an adapter, but the power and air flows correctly. This means you can "grow" your station with whatever modules you're really interested in having. But what sort of modules is that, and how are they organized?

Well, what sort of things can you do in space?

The first and foremost challenge is, of course, to make your station habitable. The lowest level of habitability requires four things: an airlock with a suit rig, a life support system, a bed, and a bathroom. Obviously, you could have a module which does all these things in one go, but in general you would have a separate module for each. You might sometimes find a bathroom right in a life support module, since water and solids would otherwise have to be pumped from one or the other.

Even with just these four modules, you already have more complexity than you might think. For example, I'm not letting you get away with magic teleporting water.

This means you need to have a fluid pipe connected from the life support to the bathroom (and any other place you might want fluids, such as fish tanks). This is a core part of our actual gameplay: laying out our facility involves weighing a lot of resource transfer options. Fluid pipes are pretty forgiving, so they make a good intro.

Air is obviously piped through each (pressurized) hab through the docking hardpoints. But fluid? Not so much.

So you have to run the fluid pipe to your bathroom. There are two basic approaches to it.

One is to have your fluid pipe run along your modules through custom hardpoints. This is not difficult, but it adds to the weight (and price) of your modules, reduces available space, is noisy, and means you have a specific, quite limited kind of dock hardpoint. The other option is to have the fluid pipes run out of the sides or backs of the modules and run standalone fluid pipes to the areas you want fluid, completely separate from your pressurized modules. Both options have advantages and disadvantages, and you can use either one depending on the modules you decide to buy. Either way, how much space is taken up by your need to pipe water around is an important factor - it may be that space is at a premium for you, or it may be that you can run a zigzag standalone pipe all over massive areas and not care. It depends on your design philosophy. (It will also effect how it breaks and how you can repair it...)

Anyway, the simple constraints of life support are not quite that simple. While providing for one person is pretty easy given the fact that you can simply call up for more water/ox tanks whenever you need them, you may want to do far better if you have a team, or visitors, or are selling oxygen to visiting ships, or are running industrial modules that contaminate the air, or any number of complicated things. Most of these have little to do with the beginning player, but basically a life support module isn't a closed system.

It scrubs CO2 out of the air and then... dumps it out a gas pipe port. You can leave that just venting into space, or you can attach a gas pipe to it and use it for something else. Or you can use a more advanced life support system that can reclaim oxygen from it.

It scrubs contaminates out the air and then... dumps them. Along with some percentage of the nitrogen base. Same thing applies, and if you start to really foul up your air with chemicals, you may have to worry about running low on nitrogen.

It creates oxygen from electrolysis, probably, so there's a hydrogen byproduct. Which is... yup. Out a pipe.

The player is allowed to try to use these outputs or ignore them, as they feel comfortable. But the point is that things do get complex if you want them to. And, in our game, that complexity is reflected by having to move resources around, which takes up physical space.

Basic life support aside, what else can you do in space?

Well, one option is obviously science. There's a plethora of possible science modules. But, in this universe, people have been running around in deep space for quite a while, and research is probably pretty well-established. Most research that you would want to do would be about monitoring unusual local conditions, rather than fundamental research on microgravity.

So there's monitoring humans in the environment. Obviously you and your crew are viable monitoring subjects, but those same devices could be used on visitors. And then there's astrophysics, using particle detectors, gravity detectors, and telescopes. That's probably it.

Research is not really a focus in these facilities, at least not in the vanilla game. So what else can you do in space?

Supporting other spacegoers is always valuable. This might take the form of servicing ships - providing them with fuel, oxygen, water, and food. This would also push the player to develop a complex web of food production or shipping storage, to get maximum return on investment. Repairs might also be a viable source of income, requiring advanced robotic arms.

Other spacegoers include tourists (or crew on "unshore" leave). Providing them with entertainment, relaxation, and excitement could be a fun thing to have to aim for, with garden habs and malls and virtual reality games...

What else can you do in space?

Shipping is simple on the surface, but turns out to be endlessly complex and customizable underneath. Whether you're talking about shipping data or shipping fish, it's a matter of arranging transport in and out, and storage while it's local. Given the difficulty of moving resources around, good storage and dock working would be an art.

Space manufacturing is viable in our universe. Take in resources, output more refined resources or finished goods. This is where you get a lot of industrial contamination, heat, vibration, and the more awful of the noise sources. Whether this is as simple as processing waste from docking vessels or as complicated as turning asteroid ore into spare parts, this can be very profitable if you can get all the pieces working together. Start with shipping, I think.

Obviously, energy generation and storage is another biggie, right from the start. It's not too bad if you just want to run a bit of life support and a television, but if you plan to sell energy to visitors or run massive processing facilities, you may need more than just a few solar panels. You may even need special "power cables" that take up space, just like fluid or gas cables.

Of course, all these things you can do are not mission objectives. They're just random things you might like to do. There's nothing wrong with just building a giant inflatable hab and doing absolutely nothing. When you start a new game, you might choose the kind of environment you start in. This would probably alter how feasible it is to do these various things - or even how hard it is just to stay alive.

...

Now, regarding moving through spaces.

I've chosen a third-person camera for my game because it gives you a sense of awareness about where you are relative to the things in the room. This is especially important in Astrophobia, because things will frequently be in weird places due to the zero gravity. Relying on the player to remember to look up or down is a bad idea, and the third person camera minimizes that.

However, the game is also quite cramped at times - purposefully so. A third-person camera is a little bit difficult in such times, because you're either looking at the outside of a wall, or you're so close to your avatar that they fill the screen. I have some solutions for this - the camera automatically trends towards the correct zoom range for the room you're in, and the actual camera focal point is just over your right shoulder instead of directly into the back of your head, so even at maximum zoom you never fill the screen. You do, however, tend to take up a very large part of the lower-left portion of it. I may do something with that, like make you fade out or make the camera move a bit more to the side or something, I haven't decided.

In the end, living in space is about living in confinement - hence the name. I want the player to always feel like they are straddling the edge of claustrophobia, and that's not hard, because in reality the space station is very claustrophobic. Living spaces are cramped.

There is a limit on how cramped I can actually make the game spaces, though, because the player has to be able to navigate through them. So I can make things a little opener, a little cleaner than you might normally get in a realistic design. The third person camera will actually help a lot, here, because it will make spaces seem smaller than they are.

Navigation is inherently complex in zero gravity as compared to in gravity, and navigation with a third person camera is inherently more complex than navigation in first person or gods-eye.

For example, our little jet pack. Forward, backwards, left, right, up, down. And how do you reorient? Those are just cardinal movements. Keeping the camera from aggressively reorienting is critical, so while there is some gentle orientation built into the cameras to keep from falling through walls or spinning hopelessly, in the end you'll need to control your orientation more carefully.

One option is to use the mouse for orientation. However, this is not ideal for a few reasons.

Third person mouse control is usually "mouse is a cursor in the world, and your character looks at that point". This doesn't work as well in a world where up and down are as viable as left and right. Still, it holds enough promise that I should try it out. The first-person-style "move the mouse to rotate your character" has always worked poorly in third person, and works even worse in zero gravity.

Another option is to use thumbsticks to change your orientation. This would actually be a pretty good solution, except for one problem: I'm not going to require a controller. So I would have to put thumbstick analogs into keyboard controls. So... WSADSHIFTCONTROL for moving, and then... what, QERF for rotation? That's a lot of freaking buttons!

It's made a bit more complex because the astronaut needs to be able to designate what she's looking at. IE, interact with a specific item.

I also want to implement a control scheme for "sticking" to surfaces, so you can "walk" or "climb" along surfaces in a very easy way. I think it'll be a simple extension of the above methods, except that you'll move relative to the surface instead of relative to the camera, and your character rotation will be a lot more forgivingly anchored.

In the end, controls are probably a more difficult problem than actually making the rest of the gameplay. More experimentation is needed!

Too Much Doing Stuff

I just saw a bundle of indie games, all quite polished, none of which I own. I played their little demo reel videos, and initially each excited me... but then they showed the gameplay, and I kept losing interest.

I'm sure these games are quite good, but I suddenly find myself completely uninterested in games that want me to... well... to do things.

For example, there's Bollywood Wannabee, a very interesting-looking game... except it appears to be a mission-based skill game. And my thought was "hm. I really don't want to play like that." And there's an adventure game, and a shmup - "hm. I don't really want to play like that."

So I thought about the games I actually want to play. Saints Row, Gone Home, Kerbal... they're all open. You exist within a game world that has structure, yes. And there are probably some missions and some progression that you can follow. But the games are very hands-off. They're okay with me not doing anything. In fact, all three reward me just farting around doing nothing. In their own way.

I'm beginning to think that may be the "genre" I have started to like above all others. The "Hey, hi, how ya doin, take yer shoes off" genre. HHHYDTYSO.

I'm not interested in doing what the game wants me to do. At least, not at the pace it wants me to. Maybe it's because I've drifted away from the target age, but my tastes no longer line up with the game designer's intent. The designers tell me I should want to do this particular level now, and try to get a good score. Or, hey, choose any level - but they're levels we designed and the point is to get a good score. Do as we ask!

And... it doesn't gel with me any more. I don't like it any more.

Make something for me. No, wait, it's okay if it's not for me. As long as it can accommodate me. Something I can live in. Something I can pick up and shape as suits my tastes.

Kerbal lets me. Saints Row lets me. Gone Home lets me. They're about as different from each other as you can imagine - tone, play, genre - but they all let me go at my own pace and do what I want.

Gone Home is obviously the most limited example, since rather than letting me do whatever I want, it simply lets me do the few things it is able to do... but whenever I want at whatever pace I want, and it includes several "depacing" elements such as songs you may want to just sit around and listen to.

Saints Row doesn't have unlimited freedom - the game is still about the stupid stuff GTAlikes are about. But I can take it at whatever pace I like, wander the city if I want, dress up funny if I want, play around with the car if I want. The missions are the dullest part of the game to me.

Kerbal has vast amounts of freedom, of course, allowing me to build practically anything, especially with mods. And I know that, if I reaaaalllly wanted to, I could make my own mods. I am free to play as I like.

Of course the line is blurry. For example, does an Elder Scrolls game offer me enough freedom?

Honestly, I don't think it does. Too much of the personalization in an elder scrolls game is tied to the core fighting loop, and the loop is boring. I like that I can wander wherever, but the core loop keeps intruding. This is sort of like how Saints Row IV keeps popping up cops whenever I land clumsily. It gets in the way of what I actually want to do and forces me to deal with whatever the game designers thought I would want to do.

Give me freedom, please. Let me play how I want to play. A well-crafted game means little if it insists I play some childish skill game instead of getting to be in that world as I prefer.

And if that seems like it would neuter your design... how neutered were Gone Home, Kerbal, and Saints Row?

These games all have something to say, something amazing to let you experience. But they invite you in and let you figure it all out at your pace.

Think of a game not as a lecture to be strictly attended, but as a clever friend you haven't seen in years.

Building a Cramped Space Station

I've started playing around with the feel of a closed-in space station, the feeling that the station was designed to be lived in with a tight space constraint rather than being there for you to fight monsters in. There are a lot of questions about what sort of play you can have.

First off, let's talk about constructive play.

While I can easily put a base together in scene edit view, it reminds me that "leaving" the game camera is the opposite of what I want for the player. I want the player to feel like they are in the facility at all times, so if I allow a player to build a base, I might want to consider what kind of construction we could do from the "inside".

First off, there's adding rooms. Right now I'm working on a 3D grid system, each room taking up a multiple of 5x5x5m chunks of space. The three-dimensionality of the grid makes it a little difficult to design in scene view, because obviously rooms get in the way of rooms, you can never quite see what's going on.

So I began to consider: what if the avatar was what could place rooms? This is in space, so if there's no room there, you can still go to the 5x5x5m grid point and float in empty space. Then you can hit "tab" and pull up a list of rooms that can be placed. Flipping through the options puts up a blue ghost of the room in this grid point - augmented reality in your avatar's helmet, displayed in the game world as a player facsimile.

Rotating and inverting scale are similarly done in-world by your avatar. The player hits "up" while in this mode, and the avatar sweeps her arms forward, spinning the room 90 degrees. Finally, click to lay it down proper. Ideally it'd be constructed somehow - flown in and attached or something - but that would be a lot of programming effort, so I'll probably just have it magically zap in after a few seconds.

This sort of construction allows the player to "burrow". You don't need to do away with the idea of a map to do this, either. You just wouldn't use scene view maps - instead you'd use some kind of simplified iconic map in-world. Zoom the camera in when your avatar displays a map, Dead-Space-style.

That option to zoom in on something your avatar is looking at is actually the backbone of more complex customizations.

You've created some kind of room, but it's stock, probably empty. You can hit tab while inside a room and it'd focus your avatar's attention on whatever hot spot she's looking at. Then, like with placing the room, you can overlay glowing blue options for things to put there. Beds, posters, desks, computers, whatever you want that fits the hot spot type. Of course, zero gravity means you get some pretty freaky orientations...

In terms of gameplay, this lends itself to grimy in-world fiddling as a gameplay mechanic. You slide through the halls of the space station and find an access panel. Pop it open and the camera zooms to let you see it clearly: inside it has a simple status indicator and a few leads that can be interconnected as you like. White, red, black - the twin row of leads can be wired to connect any color to any color, piping data, control, or power from any color to any color. A part of the challenge of the game is therefore wiring up your rooms so that you have all the functionality you need. T-junctions and other sorts of splitters make it difficult because white-red will go one way, and red-black will go the other, all clearly indicated by the wires on the wall.

By constraining the flow of power, control, and data, we can make building space stations a much more interesting situation. It's easy to build a space station which functions, in that it has rooms and people can live in it. But if you want to build a station that has a lot of functionality, you'll need to get clever with the wiring.

What sort of functionality would you need from a space station? Well, locking and unlocking doors, video feeds, PA systems - those are the typical first thoughts, and they'd be included here. But unless you're playing multiplayer, there's not a whole lot of need for that.

Another option is handling failures, shorts, and decompression events - existing rooms slowly degrade, so you need to build with that in mind, and route around rooms that give out entirely. That's not too bad, I suppose.

The option I want to focus on is resource pumping. Various rooms create various kinds of resources. Some will be physical, some will be data, some might even be emotional or cultural. As the owner of the space station, you get resources and special build options for exporting resources to the homeworld. But "raw" resources have a very low value. Instead, you want to convert them to more advanced resources. You catch sunlight, turn it into electricity. Combining electricity and water, you can create heavy-cell batteries, which produces some toxic effluent that needs to be dealt with as well...

Rather than automating the conversion of materials, I want to make it mostly a manual matter. To do this, I will make use of space constraints.

Let's say you receive vast amounts of ore from freelance miners. You need to store that raw ore somewhere, so you build a big room to stick it in. You need to get the ore to the smelter, so you create a wind tunnel that blows through the ore storage room which, with a small amount of robotic assistance, can send rocks gently along another tunnel you created to get the ore to the smelter.

The smelter turns ore into ingots, but not so cheaply. It requires a lot of power - too much power for the "white red black" lines to carry, so you must use heavy power cables running from your generator to the smelter. It also produces a lot of toxic gas and ash, which must be either vented into space or stored for reclamation - both of which add space constraints.

The ingots then get stored somewhere, and they're kind of heavy to move using air, so you use mag-loading. It works fine, and you could sell these ingots if you like. Which means you'll have to have a way to get them to a docking port, so now there's a magnetic conveyor belt running to a docking bay, maybe even the one you originally got the rock at...

Or you could make the ingots more valuable by refining them further - into useful physical forms such as bins, or into higher-grade alloys. Both require more resources, including more power. Do you run another heavy cable line to them, or do you use the same cable line and only run one of the refiners at a time?

You can start to see the spatial constraints rearing their head. At all times there is a question: can I reuse any of this infrastructure? I don't really need to smelt ALL the time - I can smelt far faster than I receive ore, so maybe I smelt, then I turn off the smelter and use that power for the alloying process. Hell, maybe I can even store the alloy bricks back into the ore containment room, since the dock only has 6 direct access room slots... otherwise I'll need to direct ships that want to give ore and ships that want to receive alloys into different docks.

The 3D map allows us to create "focal points" - zones where there is a very high density of diverse resource consumption, such as docking bays, chains of refineries - anything where there's only a few 5x5x5m tiles active, and they eat half a dozen or more different resources that have to be piped in. With vertical having the same ease as horizontal, you can bring resources in via a variety of paths, but you are still limited to orthogonal directions. So there's always an effort to build a system which allows you to reuse some of those paths so you can condense the operation. The easier and smaller the operation, the cheaper it is to set up and the less parts there are to break.

This can be made especially fun because of the white-red-black pipelines that permeate the building. You can use them to send out commands, if you wire everything right. So... can you have a button on the wall of your docking station which initializes transfer of ore, then automatically starts the smelting process while fuel lines refill your visitor from the other side?

This is what I mean by "resource pumping". Resources take up space, whether at rest or in motion. Converting them takes time, so there is an aspect of "turning things on and waiting a bit". And, of course the better the output resources, the more complex the space station you'll need to design to accomplish it.

Anyway, it's been fun to think about these kinds of things. The basic idea - obtain and refine resources - is pretty simple. But working it deeply into the "limited space" doctrine of "realistic" space stations required a bit of thought about the focus of it.

Complexity in Open Empire Construction

One of the things I've been designing my current prototypes towards is rules that provide juicy emergent complexity. Most construction games put simple caps and restraints in to keep growth from exploding, but I want to make it so that it feels organic, and players should feel like the limits they are hitting are their own constructions.

For example, in Civilization there is usually a "city penalty" - the more cities you have, the bigger of a penalty. I don't like that. Similarly, in many space expansion games like Master of Orion, there is a "fleet cap" which is very expensive to overdraw. Even just at the most basic level, there's only so many places you can build, so there's an enforced cap on your size anyway.

Instead, I've been thinking about much "softer" organic constraints.

For example, in this space game I'm building, information transmission happens via satellite dish - connecting two facilities together. However, there is a level of signal decay based on the distance between the facilities, obviously. The worse the decay, the lower the bandwidth. On the other hand, you can always just put on a bigger, stronger dish and boost that signal, right? Sure.

So to prevent saturation at the highest level of gameplay, I implement saturation as a limit. Comm arrays produce radio noise - it's how they communicate. So I implement radio noise as another source of signal degradation. Those strong, high-quality communications between homeworld and Neptune work fine, but they fill the area between with noise, degrading other communications - even other communications from the same facilities. Obviously, some disruptions are more focused and disrupt less actual space - directed broadcast is your savior here. But as the number of facilities climb, figuring out how to aim and schedule direct broadcasts so disruption remains small will be a fun challenge. Do you use relay stations to keep the signal saturation manageable, or do you schedule a rotating series of broadcasts, each in its own short, clear window of time?

This has the added, built-in bit of juice that the player can hear the radio broadcasts for wherever they happen to be looking at on the galaxy map. So if two stations are voice communicating, they'll hear "blah blah blah blah" simlish, as clear or fuzzily as the noise indicates. If it's a control system demanding a state change, they'll hear BREEP-dooooooop-BREEP or something. If it's a data transfer, the ever-popular modem sound.

I really enjoy coming up with these soft-but-juicy kinds of mechanics. Mechanics that add to the player's experience based on what the player is doing, rather than forcefully putting up walls or highways. Here are some more that I have planned:

Staying on the topic of information transfer, there are several kinds of information. I plan to start with three, but obviously more could be added. The three I want to start with are interpersonal, control, and science.

Control is a resource a lot of devices use either intermittently or continuously. A button might take a small amount of control to push, and turn on the air filters. On the other hand, an atmospheric scanner might produce science based on the amount of control it can eat up. There are automatic buttons that can be programmed and don't require control, and there are automatic scanners... but in both cases, they are either less efficient or less robust.

The key to control is that it's only produced by humans. You can transmit control via a comm station, typically from ground control (which has a lot of humans on staff). However, the bandwidth required can be prohibitive if you're trying to do something like scan a planet - it's more useful for just pushing buttons remotely. Even more than the simple signal bandwidth, the light seconds delay between controller and controlled will degrade the control pipe specifically, basically counting as extra signal degradation. Of course, if there are humans on the station, then the humans can be the source of the control and that has no delay.

Humans both generate and store a certain amount of control, depending on their condition. A single human certainly produces enough control to push buttons and levers all day, but something like a scientific scanner might require several humans, or humans working at peak efficiency. Improving human condition requires not just life support, but also entertainment and places to live a life. Similar to the control transmissions, humans can transfer control resources to each other via a comm relay. Human to human interaction transfers control much more effectively than transferring control via control comms. So it's common to have ground control communicate with science teams to organize them, radically increasing their control resources.

The max storage available to each human still depends on their condition, so that is a limiting factor. Again, the restrictions on the nature of comm stations can matter: do you maintain a constant stream of chatter to constantly charge the humans with control, or do you go with short bursts a few times a day to charge them up without constantly causing signal degradation?

Of course, science is also a data resource and can be transferred in much the same way. When you scan a planet's atmosphere to produce science, that science is stored in a local database. In order to be useful, it needs to be transferred to a construction station, since the point of science is to allow or disallow construction of specific kinds of more advanced devices. So you need to get your science from your research facility to your construction facilities.

One problem is signal degradation, of course. Especially since most serious science outposts will also have a high level of control requirements, which means that either control or interpersonal communication will often be degrading the signal. So maybe you schedule data uploads to happen at a specific time, and you cut off voice communication during that time.

However, because it's fun to make things more complicated, the nature of science data is not the same as the nature of control data. With control data, one control transferred is one more control on the other side. It may take some time to do that transfer if the bandwidth is bad, but it's a zero-sum situation.

With science data, the situation is more complex. First, it really does transfer. For the sake of playability, when you broadcast science data you remove it from the broadcaster. This is okay, because science is generated pretty rapidly, so you're not in danger of "running out".

However, there is loss. When a database receives science data, it doesn't just add it in. Instead, a database has a certain amount of resistance based on the amount of data in it, to the tune of 1% per hour. So if you have 6000 science data, then you have a resistance of 60 data per hour. This is then applied against incoming communications.

So if your science facility sends over 60 data in a 1-hour broadcast (quite slow), none of it would get through. But if you send 60 data in 1 minute, then 59 of that would get added in. Of course, then it would have 6059 science data in it, and will resist 60.59 data per hour.

This rewards clever comms usage, and offers some fun optimization challenges.

For example, you might broadcast in rapid, high-volume bursts. This would fillllll the sky with noise (and the player would hear a loud modem sound), but it'd be short-lived. That's a fun possibility. Another option is to have multiple databases. There's the "core" database, but then there's specifically the input database. The input database is very nearly empty, so even slow data trickles will fill it with little loss. Then, every day or so, the input database is pumped into the main database using a super-fast server at the rate of 1000 science per second, or something similarly absurd.

Because science is never "spent" on building modules, the challenge is not to continuously generate science to replace lost science, but to reach new heights of science. So as you strive for more science so you can build better toys, you need to create better science pipelines. Fun!

Anyway, these are the sorts of play ideas I've been thinking about for this prototype. And that's just the communication between bases...

Starship Game Design Discussion

I've been really thinking a lot about the kinds of gameplay you can get out of different kinds of design/construction games. So I've come up with a new idea for a game, which I'm codenaming "Rocketload". I'm going to discuss the design here, and although it's in public, it's mostly to cement it in my head. Feel free to comment if you somehow find it interesting.

The game has two fundamental pieces that work in tandem. There's a payload design/delivery system, and research system. They support each other and both operate in the same timescales in universe time. IE, if you launch a new payload, you could fast forward until it arrives... but all the other facilities and research projects and rockets will progress apace.

The rocket part of the game is component construction followed by staged launching, but not like Kerbal. Rather than constructing a physical rocket, you would construct a logical rocket. We're going to abstract out the physics because otherwise we wouldn't be able to simulate a hundred payloads simultaneously, which we're going to need to be able to do. Your highly trained rocket engineers will turn the logical design into a concrete design and send it into space for you, as you watch.

That's because the focus of our game is not on rocket physics, but on creating a massive network of spaceborn facilities. The focus is on facilities, not on rockets. The rockets just act as a constraint on your ability to put facilities in places.

Designing a rocket is a simple matter: the design section is a bunch of horizontal bars. Let's say we want to design something like Sputnik: it goes "beep beep" as it orbits the earth.

We grab the "beeper" object and put it on one of those bars. Next to it shows up the warning "Requires 1 mAh/day, no power source" or something similar. So we drag our smallest battery (1 Ah) and put it on the bar below the beeper. The simplistic logic of the bars instantly understands that the battery is available to power the beeper. So the beeper's warning would change to "42 day limit". That's how long it'd be until the battery runs out of juice.

We need to put it in orbit. For that we'll need a rocket engine, so we choose a launch-grade engine and put it below the battery. We could add as many launch-grade engines as we want, but one will do. We also have to add some fuel, so we'll put it on the same row to link it to that engine. To help us with this, at any point we can designate a target for our launch by clicking in the solar system map - a low orbit over our home planet.

A burn pattern would appear - a line of varying color to denote burn points, and whether there is enough fuel for them as loaded. When the target is assigned, the engine bar has a note attached with a fuel cost vs how much fuel you've got loaded up. You can launch without enough fuel, if you like - the assumption is that you'd pick it up somewhere out in deep space before you needed it.

So it's a much simpler setup than Kerbal, all about simple logical connectivity.

But there is some complexity hidden in the wings. For example, let's say we want to put it in orbit around the moon instead of ourselves. One option would be to simply click on a lunar orbit instead of a homeworld orbit. However, the engine costs for this would be annoying. So let's change out the launch-grade engine for the smallest engine we have, and much less fuel. The burn pattern blinks error - you can't reach escape velocity with this. But we can package the whole thing up as a stage by simply clicking on the little "-{" button that encompasses those three bars. Then we add a launch-grade engine and some fuel to a fourth bar, and the system understands it is responsible for launching the other payload, including the small rocket and its fuel. So we click on earth orbit for this one.

This stage's burn pattern is from the surface to orbit. The inner stage's burn pattern is now from orbit to orbit - something the small engine can handle.

Of course, you can continue to edit the stages. Add fuel to the inner stage. Remove fuel. Add a new rocket. Layer on as many stages as you want and put the satellite around Pluto - although it'll run out of juice at 42 days, so you're not likely to still be able to hear it.

Now this was a simple beeping satellite that creates only a very modest number of science points, and it'll run out of battery before anything goes wrong. But the primary concern with facilities is maintenance. Stuff breaking. Everything has a degradation rate, with degradation being that rate added over time. It will break when it hits 100 degradation, so something with 1 degradation/day will break in 100 days without maintenance. Our beeper and tiny battery probably have 0.01/day degradation rate...

This degradation rate really changes how you try to build facilities, because you have to take into account their failure rate and pattern. Humans can maintain (reduce degradation rate 90%) and repair (reduce degradation total from 90 to 50 at the cost of spare parts), so having a manned mission can radically extend the longevity, although all that life support is heavy. Also, humans act as a science lab or construction center, so if you want to do offworld research/construction, you'll need folks in orbit.

However, the degradation rate is not 100% static. Rocket engines produce a specific amount of vibration, and that's doubled or so when traveling through an atmosphere. Vibration causes degradation to the rest of the system, but not equally: each layer absorbs some of the vibration, reducing the effect on the next layer. So, in our "beepy satellite around the moon" example, once we got to earth orbit and our launch stage detached, we would see that our small engine for reaching lunar orbit would have quite a lot of degradation, our battery less, and our beepy thing least. Our small engine produces only a small amount of vibration, so it's unlikely to cause our battery to fail.

This should give facility/starship design some fun complexity, especially when you start to consider docking, replacing parts with other parts, strapping on add-ons in deep space, and so on. It can rival Kerbal in terms of complexity, but the complexity is all on the space side rather than the liftoff side. Scattering facilities and probes all over the star system for science, materials-gathering, construction, culture, staging... yeah!

Of course, the other side of the game is the science half. It makes the facilities matter.

While it's always a fun impulse to build a space station for the sake of building a space station, it's important to the longevity of the game to have that space station matter in the game world. And this is where science comes into play.

Let's say that your scanny probe picked up a new kind of resource while orbiting earth: a resource called "paired ions" or somesuch. The scientific explanation doesn't matter, all that matters is that it's something new and you want to bring it home. So you need a collector for it.

So we go home and build a new kind of rocket part - a deep space "paired ion" collector and storage tank.

We do this by using the device creation system, which looks just like the standard payload system, except you're using logical components rather than rocket components. Our device would be a tank (defaulting to standard alloys and intended to contain paired ions) with a deep space intake pointed into it (defaulting to standard electronics, and intended to ingest paired ions).

Just like that, we have the plans for a device. Except that device is going to be really, really slow or awkwardly huge, because it's a passive collector, and passive collectors are rough. So let's put in some electricity. We could add a battery (a tank containing electricity), but it'd make more sense to just specify an electrical intake, allowing us to power the collector from any kind of electrical source we want to design into our rocket. There. Our efficiency skyrocketed.

Of course, this is just an idea for a device. It's not finished. In order to actually create the device, we need to add in some research elements. The basic idea of any R&D project is that you start off by researching (using science inputs), and then you transition to engineering and final design (using material inputs). Science inputs basically build up "momentum", and then you bleed off momentum with the material inputs until you reach 0 and stop. The more science input, the better the engineering of the final result. The more material input, the larger/more materials. In both cases, momentum is based more on time running rather than actual amount of science/material, so juggle things to be more effective.

This is reflected by simply dragging science and/or material inputs onto whatever components you want them to be attached to.

One science input is the facility that detects the paired ions in the first place. Let's attach that to our ion collector part. This is a good match, because our detection facility is detecting the same resource. The two are well-matched, and therefore the research will be more effective than the momentum would imply. This should give us a really high-quality collector!

We also have a satellite orbiting the earth going "beep beep beep". We could add that to another component, such as the electrical input or the tank itself. But there's not any particularly good reason to do that - it'd add momentum for minimal benefit. We also can't add it to the collector: only one science input per device. We go ahead and add it to the electrical input just in case we want to use it, even though it's unlikely. Still, that means we can't use it in another project. One science project at a time.

To decelerate we need to add materials. We'll add a stock alloy material to all three elements, since we can throttle them as we please and don't have to use them if we don't want to.

Our project is then a matter of throttling up on the ion detection research input and leaving it throttled up as long as we want. We can go do other things, leave it "baking".

After a while, when we feel we've done enough research, we can throttle up on the storage tank's materials. This will cut research - you can only do research or development at any given time, not both. This will steadily decelerate us, and in the end we'll have spent all our acceleration on our collector, making a very high-quality collector, and all our deceleration on our tank, which will give us a very large tank.

The final stats also have to include degradation and price as well, and it's all worked out with simple algorithms. This system would have a noticeable degradation, because it has a high-tech part that isn't very big. If we had decelerated on the collector instead of the tank, our collector would be much bigger (and even more effective), and have a lower degradation rate due to the extra space and material used. Of course, our tank would be tiny.

And then the part gets added to our manifest and we can put it on a rocket, fly it out there, do our collecting, and then bring it back to our orbital base or land it back at home using parachutes.

Of course, it can get quite interesting. For example, what if that detecting station crapped out partway into our research cycle? Would we continue to accelerate using just the "beep beep" satellite so we could have a larger final product, or would we settle for a runty final device?

Also, paired ions are a material. When we get back a tankload, we might build an engine that uses paired ions as fuel. We might then use paired ions as a development material to decelerate the research. But this uses up our limited supply. What if we run out before we finish decelerating? Do we let the project idle along while we go fetch more?

All told, I think this combination of systems allows us to take our own approach to developing our space network. It also allows us to occupy the same space as other players (if we want) while still having distinct technologies. The combination of device function, research sources, and materials should make developing new devices fun, and keeping your space facilities operational in the face of degradation should keep things spicy.

The key to all of this, the hidden purpose behind this design, is mods.

See, using this system, mods are very easy to make.

If you want to add a laserbeam comm array mod, then you would add the laser beam pieces into the base device options. Then, not only can you distribute your default laser comm devices, but other people can use them in other kinds of devices. For example, powering their laser with jet fuel, or having a laser input control their light show. This should allow people to combine mods very easily as well, since the various mods will have device options that can be combined into one final device rather than being distinct objects that must always remain separate. The key lies in the simple but robust method of connecting elements to each other.

That's the hope, anyway.

Dynasty Warriors 8: The Unpolished

So, I played about ten hours of Dynasty Warriors 8.

I like the combat in the Dynasty Warriors games - it varies between "vaguely enjoyable" and "fun", which is better than most other games. It's particularly good in 8.

And, while the battle system is always fun and polished, the rest of the game tends to be painfully unpolished and awkward.

For example, the battle event system. In any given battle, a dozen or so events will happen that evolve the battle. Reinforcements will arrive, people will attack, somebody will betray somebody. Sounds cool, right?

But these battle events are really awkward and difficult to read. Just as an example, I was told to "take the south base as a decoy", but the battle then said "objective failed" less than thirty seconds later. Exactly how was I supposed to even reach the base in that period of time? Am I supposed to memorize every battle event and keep trying over and over?

Or "intercept person A before he reaches point B" - but he's on the other side of the map. I literally cannot reach him because my last objective was on this side of the map. I understand - it's an advanced objective for a later replay. So I'm supposed to keep trying over and over.

To tell you the truth, I wouldn't mind doing that. In the other games in the series, that's exactly what I do. But in Dynasty Warriors 8, you can't restart a battle in single-player campaign mode. Why not?

Whatever the reason, it makes the already opaque and annoying events even more annoying.

What's worse is that both the map and the announcements are really unreliable. A gate in red should be impassable, and a gate in green should be passable. But that's only the case about half the time. Moreover, if you kill a gate captain or guardian officer, the gate should open. But it only opens when the announcement "you killed person B!" gets put on the screen. And that can take literally thirty seconds as other announcements such as "You got 5 XP!" play out instead. Moreover, you can't even tell whether the gate is going to open at all. So you hang around and wait, while your objectives timeout and you lose every secondary objective in the mission because you were under the impression that this green gate was going to fucking open when you killed the guardian.

The last straw was this map where you need to keep people from defecting by aiding them. It highlights three primary objective points in green - one to the west, two to the south. So I immediately go south. Strangely, the gates close on my tail and lock me in. I go to aid the two blobs to the south... but everyone still switches sides. Worse, there's nothing at these two southern blobs and its impossible to get back out to the north.

Evidently, I glitched the game, went through a gate I wasn't supposed to be able to get through.

So of course I quit out to the menu, select "campaign", select the right house, select "continue", wait through the two minutes of loading, select my officer, hit start... and FUCK me, it didn't save any of my officer's equipment or skills and his default is two level 1 bullshit weapons, one of which he isn't even compatible with.

So I stopped playing.

See, this rant has a point.

Dynasty Warriors 8's core play mechanic is actually pretty fun. But it's still got all this baggage from a decade ago - it's got this really wonky event system, this awful menu system, this incoherent level design... all the baggage is making it come apart at the seams.

They did discard a lot of other baggage. The timer is gone, for example.

But the complete lack of polish makes all this other baggage just feel awful. I could forgive the archaic baggage if the punishment for not perfectly handling the baggage was very small. But the punishment is a minimum of two minutes of loading, usually followed by forgetting all my settings, and then having to start what is frequently a one-hour battle over from scratch.

Of course, ideally you'd replace that baggage with some newer systems that didn't suck, but I can't expect too much from a franchise so set in its ways. The least I can expect, though, is for the game not to actually get worse.

And it did.

The combat is good. Much better than any previous installment. But the punishment for not reading the developer's minds is staggeringly, annoyingly high.

Gone Home

So, I'm going to talk about Gone Home.

If you haven't played it, go play it. The game is much like a box full of friendly butterflies: it's best to open it without knowing that it's full of friendly butterflies. And if someone asks "is it really worth $20 to just open a box? It seems like a lot for so little..." you just have to nod and hope they trust your opinion.

So, um, stop reading this and go play it. You wouldn't want to ruin the surprise of friendly butterflies.

That said, my spoilers are going to be pretty modest. We're going to be talking about some of the design pieces of the game that I happened to notice most.

.
.
.
.
.
.
.
.

Most people will have noticed the music. A lot of people have commented on how much they liked it, but I didn't particularly like it as music. But I did like it as an expression of the world those characters inhabit.

The music was a reflection of Sam and Lonnie, and their growing relationship. Even though it's not something I would put on my playlist, I really enjoyed hearing it because it was used for the purposes music is supposed to be used for: it was expressive.

Shock! Music is supposed to express things! Wow!

It doesn't sound like much of an innovative statement to anyone who really likes music, but when you think about games and music, you find that video game music is almost universally used to express the game world and the pacing within it. Not the characters. Characters have themes, but the themes reflect the character's position in the world and story, not the character themself.

So the screaming punk songs in Gone Home were fantastic because they were the expression of a character in the world, rather than being an expression of the world.

I'd like to highlight this particular uniqueness to Gone Home. It's really obvious: the characters are what make Gone Home. This is a game about discovering characters, not a game about using characters. And that's a big difference.

I was thinking about how to make characters more central to any given game. For example, in Bioshock Infinite and The Last of Us, there were characters and they were a big part of the story. You could say that the characters drove the game - their impulses, needs, and desires.

Despite that, the characters in those games exist to serve the game. In Gone Home, the game exists to serve the characters.

I'd like to think a little bit about whether or not this principle could be used in other kinds of games.

Let's talk about some of the basic game mechanics used to make the game serve the characters. I'd like to wave my hands and go "woooooo, aaaaaaaart", but art is built on fundamentals, and this game uses some pretty concrete methods that could bear discussing.

The music is one example - it exists for the characters, not for the world or for the player.

Similarly, all the notes and clues you find are about the internal workings of someone's life rather than about forwarding the plot or the gameplay. There is no "gate" or "gameplay hook".

For example, if this were a typical RPG, then discovering that your mom is going to conduct a forest burn would have been a "gate" for you to step in and participate, or a "gate" for the plot to advance and, I dunno, burn the city down by accident. There is a chain of events in the game world, yes - learning more about the burning does lead you further into your mother's life. But it's not a life you are part of, and it doesn't try to involve you. At no point does it result in you having to step in and act.

That's the key to this affair. The player is never called on to act.

Like a detective, the player exists to try and piece together the pieces. But unlike a detective game, there's no real blockades. Detective games are all about solving complicated clues and puzzles... but this is not like that. Even if you miss some stuff, you don't suffer. You aren't held back. There are some gates and keys, but they are all pretty basic, there to control your pacing rather than challenge your skill. They exist to say "this area is 'before' that area", not to say "solve this to win!"

And their lives are the same way. Their lives come together in your mind - their personalities, their joys and fears and problems and successes... but at no point do you have to solve those lives. You never step in. The game is entirely built around the player trying to solve a series of mysteries for the player's own sake. You feel success when you figure out what happened to Sam, where your parents went, and so on. It is success. But it's entirely internal: you never changed their lives and, if/when people get home, the only indication that you were fussing around is all the lights you left on.

It's easy to dismiss that kind of design with "it's not a game!"

But it is a game. It's a fantastic game.

There is a lot of interaction. You can pick up a vast array of (mostly useless) crap, there's even some basic physics. There are moments of complexity and denial, such as areas that go dark when the lights go out, and passages of text you can never read again. It is gorgeous both visually and aurally, and in both cases you are at the helm when exploring those facets. There are secrets to be solved, clues to be patched together, safes to be cracked...

It's just that all that stuff is separate from the lives of the characters.

So, I was thinking about how you might be able to apply this basic technique to other kinds of games and genres and so on. Obviously, in all cases you'd need to have a strong focus on characters, but I think almost every genre can do that.

The key, I think, is that you need to completely wall off the lives of the characters from the gameplay used to mine for that information. The characters never ask for or give gameplay help, aside from some very basic gating used to establish "before" and "after" for the sake of the player's experience.

Wouldn't that be boring, though?

No, I don't really think so. To a large extent, plot exists to give games an excuse to vary their setpieces and play. It's quite possible to use characters for this purpose in this scenario.

Say you're playing a brawler. You are the stone monkey of Chinese legend, and you fight through dozens of enemies in a painfully standard combat game.

Normally the plot would be "Son Wukong goes to place A, fights a boss, the boss reveals he needs to go to place B, where he is dumped to place C so he can fight another boss..." The player is very reactive. Even if the hero is quite aggressive and is the reason why most of these levels happen, the player generally has no control.

So, instead imagine that Son Wukong is learning about the lives of the individual gods and immortals which rule over the world. He is struggling to become one, but they don't even know he exists. Even if they meet him, he's just some random monkey, who cares? So instead we learn about them in indirect ways. We hear them. Find missives. See psychic leftovers. Hear it second-hand from someone who remembers. Find their favorite music, art, and so on.

We get to know the gods in question. And our progression through the levels is much the same, but each level is driven by a god's personal life, not our own activities. We aren't really interacting with the god's personal life - it's just that their personal life caused the situation we find ourselves fighting through. We're not helping the god or fighting against them or whatever - we're just drowning in the fallout of their bullshit personal life.

Now it sounds a little interesting, to me. And at the end, you confront them and they say "who the hell are you?"

And there's a big fight because it's a fighting video game.

I can design a similar approach for my space ship game. The personal lives of the crew can be discovered if you search carefully, but the actual function of the ship only has the vaguest relationship to their personal lives. When you reach the destination, you may have to choose who gets promoted, who gets punished... or even who lives and dies. So learning all about them would be a way to get emotionally invested in that.

Anyway, it's a basic approach that could probably be used a lot more often. I think it probably requires really good immersion and needs to be carefully crafted to fit into the pacing of the game you've designed, though. It's not something you can just copy half-heartedly.

Still, I'd like to try!

I Don't Like SMT4 or DLC

Let me talk about why I hate DLC.

I hate DLC because I could see Shin Megami Tensei 4 coming from five years ago.

SMT games have always been grindfests. I bought the others - I didn't beat any of them because they are a gajillion hours long, but I enjoyed them.

SMT4 has extremely limited money and experience. Enemies don't drop money, and you can only get it in tiny drips and drabs. You can regenerate MP faster than you can get XP. It's a starved game.

That's been true forever - SMT has always been on the "hard" side, which is one reason I always liked it. The other reason I liked it is that you're free to experiment by building custom demons and playing around with different builds, just like in Persona.

But SMT4 takes that scarcity up a few notches, and I was confused as to why. At first I thought it was just during the tutorial section, but it turns out that the tutorial is when money and XP comes easiest. After that, the pacing turns into something a high-level grinding MMO would be ashamed of.

This makes it almost impossible to customize demons. A level 3 demon costs about 1500 macca to re-summon. 1500 macca is fifteen fetch quests, or five of the fetch quests you get at level 10. Each fetch quest requires a not insignificant number of monster bits. This makes the fun part of the SMT series - remixing demons - a serious chore. A huge burden. I have demons in my inventory that cost ten times more money than I have ever had to resummon. So I can't mix them, because I'll never get them back.

They also raised the random brutality of the game, turning into less a game of skill and more a game of avoiding ever taking any chances or you'll have to pay the reaper. Literally.

Why did they make these mysterious changes? Well, let's see.

Real money DLC is aimed at giving you scads of money, XP, and broken weapons. And resurrection? You can use real money for that, too.

So $2 in real money will net me a basically unlimited amount of cash. 1500 macca in one drop, minimum.

Oh? Is it clear why they poisoned their own game?

I paid these guys full game price and they gave me a broken game, expecting I'd get so annoyed that I'd pay them more money to break it in the opposite direction.

Let's be clear. I am not "choosing not to buy" DLC. Nor am I "resisting their attempts to sell me" DLC. No, I would never buy DLC for this game. Ever. It was never even on the table. Never.

But in their desperation, they tried to push me for more money. In the process, they broke their game. They don't even pitch the DLC until pretty late in the game, but the broken-ness is there from the start.

They also broke their franchise: I bought every SMT game. I'm not going to buy SMT5, if there is one. I've also bought every Persona game. I'm going to have to think reeeeeal hard about the next one, though, because this is bullshit.

Can DLC be done right?

Sure. Kerbal does DLC right. There's a huge amount of Kerbal DLC. Much of it is higher quality than the original stuff. Because the Kerbal developers don't make any money off of it, they didn't break their game to try and sell it.

Can DLC be sold without breaking the game?

Sure. Batman: Arkham City has that awful Catwoman campaign, along with scads of other content. None of it is very interesting to me, but I paid full price for Arkham City and the reason I eventually got tired of it had nothing to do with it being broken for DLC sale purposes.

But you have to be careful. When there's money to be made, it's easy to get into the mindset of "this is how to monetize well, so just do more like that".

And then you break your game and your franchise and alienate gamers that have plenty of money they would be happy to give you if you would give them the game they paid for and not some bullshit money siphon.

Detailed Gameplay Discussion (Anti-Sims)

A few days back I posted about how I wanted to make a base-building game where time weighed heavily on your characters. Sort of the opposite of the Sims in terms of constraints - the Sims gives characters not enough time, and I wanted a game where they have far, far too much.

The responses I got were good in that people were paying attention and thinking about what I was saying, which is always a big win for anyone who writes random crap on the internet. But their recommendations were for mechanics I'd already tried, so I thought I'd explain why I'm not a fan of those mechanics.

First let's cover "spreadsheet gameplay".

Spreadsheet gameplay is when the primary mechanic of the game is you changing a number or a percentage to try and tweak the final outcome. This isn't necessarily a bad kind of gameplay, but it is suited mostly to slow turn-based iterative games. A spreadsheet's fundamental strength is the ability to display a large number of entries and connect them in a transparent way, which means that "more advanced" spreadsheet gameplay usually means "more stuff to tweak".

There are plenty of spreadsheet games out there - most of them are kingdom management games or dating games, for some reason. But let's talk about one for the anti-Sims game concept. You could have each character's daily time as a tweakable system. 8 hours sleeping, 5 hours working on maintenance, 3 hours working on scanning, 3 hours off time, and so on. It's a simple enough concept, and it could be linked into a starship's or base's capacities pretty easily. The gameplay concept is relatively easy to expand, too, as if you have a hundred crew you simply have a hundred of those simple entries, and can maybe manage them in clusters for ease of use. You could also make it seem less spreadsheety by making the management interface more about sliders than numbers, although that's just visual glitter.

However, a spreadsheet has three weaknesses that are aligned squarely on the path I want to take.

The first weakness is that spreadsheets are given to careful minmaxing. The whole point of a spreadsheet is that it gives you all the knobs and you can aim for the best outcome you can get. The way you express yourself is in which outcomes you pursue, not in how you achieve them. It is easy to become enamored with the depth of a spreadsheet, but I want this to feel like The Sims in many ways. Imagine creating a crew based on yourself and your friends, or copied from your favorite television show. The joy lies in their interactions and vagaries. I want the focus to be on the humans, not the values. I want to focus on this human feeling, and although you could inject it into a spreadsheet game (like a dating sim might), I don't really feel it's the best mechanic for the job.

The second weakness is that spreadsheets are not actually very good at handling drifting values. While simple spreadsheet games can handle drifting values, rather than being expressive gameplay, they are more just about forcing you to check in and tweak things. Worse, as the spreadsheet game gets more complex, the drifting values become harder and harder to react to. In fact, this seems to be the primary limit on complexity for spreadsheet games: at a certain point, your own personal stockpiles of stuff become the most important resources available to you, and managing them takes more and more effort the more complex and ongoing the world becomes.

Instead, I'd like the drift to feel much more organic. Rather than adding complexity, I want the drift to feel like strafing in a first person shooter, or bouncing when you try to land in a plane simulator. I want the drift to be something the player grips and feels under her fingers as she plays, rather than being an element of complexity she has to carefully budget for. The drift - personalities steadily changing, supplies slowly running out... it needs to be like a heartbeat. And I can't make a spreadsheet do that very well.

The third weakness is topological flattening. Many spreadsheet games do have a base-building mechanic - some even are full-fledged city-building games. But the topology of the city is usually strongly 'flattened'. That is, any given building is reduced to inputs and outputs, regardless of its position on the map. This makes it easy for the city to pipe into the spreadsheet, and it makes it easy for a player to build the city to accommodate her spreadsheet needs. Games where the base-building is left topologically significant - that is, where the exact placement of buildings matters a lot - are more about base-building than the spreadsheet part, and the spreadsheet part is just a supportive mechanic. Like in Sim City.

I don't like topological flattening because it fundamentally turns something that was 2 or 3 dimensions (a map) into something that is 1 dimension (a list). This loss of complexity goes against my grain.

Those are the reasons I didn't ever make a spreadsheet prototype for this concept that I ended up liking.

But there is the opposite. If a spreadsheet mechanic tends to flatten topology, there's the opposite mechanic: centralized map gameplay. IE, "like the Sims".

This is also a fine mechanic, but it also has some weaknesses squarely on the paths I want to take.

In this mechanic, you build a base, and the focus of the game is on your characters navigating the base you created - moving from room to room, using the rooms.

My problem with this mechanic is that it makes moving from room to room a character limitation, and therefore a limited resource. Basically, it makes it expensive for a character to move through your base, and therefore optimizing your base is all about reducing the amount of walking your characters do. The only way around this is to have zoning, and then have characters assigned to various zones while ignoring their size... but then you've flattened your terrain again, and that's what we're trying to avoid.

Don't misunderstand. A huuuge part of base building is connecting things to things. But rather than make it about the characters, I prefer to make it about stuff. I'll happily put in power and data and water lines, manage airflow, and whatever else I can think of. Making bases where stuff is shuttled around from room to room is great, because it makes the topology really matter. It also can allow you to do some very cool Turing-machine stuff, so I'm all for it.

But I don't want it to be the people. I don't want a situation where a person's activities are limited by time constraints, because the whole conceit of the game is that a person has way, way too much time on their hands. How long it takes to walk from A to B should never even be a concern.

But... this means flattening the base out, doesn't it? And that sort of defeats the purpose!

Well, there's a few ways to use the base topology without making room-to-room movement the primary method.

One is using nodes with radius. So you might assign someone a room to sleep in, and they would automatically "appropriate" all rooms within 2 doorways as space they commonly hang out. Then you could assign them a workstation, and the same appropriation would happen. And a place to eat, and a place to hang out - whatever you like. Assign them however many nodes you like. Maybe they're not even named - they're just "nodes".

This gets around the restrictions on travel by making travel free (at least to places designated by you), but still keeping topology important, since connected rooms are adopted along with the primary rooms you assign.

I made a few prototypes like that, but the problem always ended up being scalability. It's easy to do this with one, two, even five characters. But as the number of characters grows, it becomes more and more difficult to keep track of who is assigned where and feeling what kind of stresses. There's not any fundamental connection between a person and a place - it's arbitrarily assigned. So it's really hard to grasp quickly. It ends up bogging down, which in turn makes it more and more difficult to handle changing values.

This is primarily why I came up with the "beams" method of linking characters to the base. If you missed it: each character is "placed" at a spot, but only in a logical sense, not in a physical sense. They then automatically inhabit/maintain/work in every room with the same X coordinate or the same Y coordinate as them, creating a "+" of interaction. They also interact with people who inhabit the same rooms as them in that room. Also, you can rotate a character to use an "X" instead of a "+", which changes the constraints interestingly.

By having a character occupy a specific place, and then having all the character's interactions with the base oriented around that location, it is easy to grasp exactly who is being affected by what. By making it about a simple axis system rather than about room connectivity, I negate the "price" of traveling between rooms while still maintaining rooms as an important topological resource. Moreover, by continuing to insist on "stuff shuttling", I put opposing topological constraints into play and make base building a matter of weighing multiple kinds of topological concerns.

There are concerns about how this would scale, and I think those concerns are valid... but scaling is the critical problem with all the methods, and they all do it poorly. To some extent, I actually like that. These are people, and there should be a little weight to their behavior.

Another concern is how unbelievably abstract and unrealistic it is. I think that's a good concern, too, but I can't think of a way to concretely represent the complexity of someone's day-to-day habits on a large, complicated deep-space starship. The concern for me was not realism, but clarity and depth. This system works well because you can clearly see everything you need all on one screen, even if you have a hundred crew - and it's easy to tweak, just drag someone around on that one screen. To get that, I'm happy to abstract it out.

As to the directions I needed to go that aligned with the faults in the other methods, let's quickly mention them.

Having that personal feeling rather than a minmax feeling: check. While there is some depth to arranging rooms and crew efficiently, there is a lot of character color waiting in the wings since interpersonal interactions happen on the rooms they are marked as happening on. This means a predictable, modifiable framework for interpersonal color and forming relationships.

Handling drifting values is handled well because the single-screen display allows us to display all the drifting values at the same time as we display what everyone is doing. This makes it easy to tweak either personal behavior by dragging a character, or make it easy to mandate a usage change by clicking on a room and tweaking its output/accessibility. As time flows by, you can watch the steadily decreasing stocks in your supply room in real time, and watch people squabble or get along by watching the highlighting of individuals.

And, of course, there's definitely no topological flattening.

Okay, that's why I designed it the way I did. I don't really expect anyone to care, I just wanted to write up the explanation.

The Nature of Fans

It's been a while since I felt anything future-shocky. Culture is complicated, and even as science marches forward, culture hangs back and just kind of faffs around. But I did see something future-shocky this week. In a very early stage. Darius built a meme machine.

Meme machines have been around for a while, of course. Most of them are pretty basic, and their output is not what you'd consider "usable". If you use them or iterate them long enough you can get something useful out of it, but the percentage is low and the longevity is poor. A good example of this would be the objection engine, which produces the same kinds of output as Darius' bot, but with a different focus.

Both are "fan meme" engines. But Darius' engine operates 100% automatically. Just plug in a video with some subtitle tracks, and out pops animated gifs tagged properly. The sort of things fans make on their own, all the time. While the individual gifs aren't always good, they are tagged and ready to roll. In fact, you could even largely automate the distribution of them!

People are always considering the line between humans and "robots" - more accurately, humans and automation. They are always worried that robots are going to steal their jobs - or Mexicans are going to steal their jobs, or Polish people are going to steal their jobs, or women are going to steal their jobs, or gay people are going to... well, they worry about their jobs a lot. Out of all of those options, machines are the only one that actually steals jobs - as in, reduces the number of jobs required to perform a task.

That's because, put simply, automation makes it easier for a human to complete a task. Automation very rarely if ever reduces the number of humans involved to zero... but it does steadily divide the number of humans required for any given task.

As to the political/economic side of that argument... well, this isn't the essay for that argument, but let's just make it clear that I'm a bit of a technophile and there are an infinite variety of tasks to be done.

Most people think of physical labor when they think of robots replacing them. But the truth is more interesting: automation is predominately nonphysical. There's more software automation than physical human labor automation. I mean, every single computer on the face of the planet is literally automation. It is automation from the ground up.

We already use that automation for virtually every aspect of our personal lives. Our bus fares are automated. Our mail is automated. Our research is automated. Our entertainment is automated.

We have this weird line drawn in our head where our opinions are not automated. We hold that beliefs are somehow 100% human and cannot be automated.

Well, that's wrong.

As Darius shows, it's actually not that hard to stick an automatic thumb into the human mind.

Like any kind of automation, it's not that the human is written out. It's that the task of believing, of being a fanboy... is being augmented. Fewer humans can accomplish more of the "fanboy" task. The fanboy robot does not replace humans, but it augments them such that vastly more task can be done. Not every gif is worthy of use, but a human can easily go through 100 gifs and choose the best few. It takes no expertise. And, in fact, it actually makes that person MORE of a fan than they probably were before, because they are partaking in an act of creation, no matter how indirect.

So... what I'm trying to say is:

Everyone who creates a TV show should probably pay Darius to do this for them. It won't create fans out of thin air, but it does allow the fans to produce vastly more "fan culture". It allows your fans to be more effective.

We're not at the stage where the "fan culture" task is maxed out. I think we'll see it evolve a few more times before we get to the point where humans are "fired" from being fans because there's too much fan labor and not enough fan tasks that need doing.

But, hey, I look forward to that future. It sounds amazing.

DarkStarlike

One of the kinds of gameplay I like is base-building - or, more accurately, house-building.

I really liked The Sims, but the focus on it being a time management game always wore on me. I didn't like that mechanic, especially since it punished building large, beautiful houses and rewarded building cramped little zig-zag houses. What's the point of building a house if you're going to be punished for building a nice one?

I've always wanted to do the opposite: a game where time isn't short, but long. I became interested in facilities that are inhabited. Really lived in. The exact opposite of The Sims, it's a game where you build your base specifically to keep your inhabitants happy in the long term, as they live in it for days, weeks, years. Not "how efficient can you make it", but "how long-lasting can you make it", both in terms of mechanical components lasting for a long time and in terms of keeping the inhabitants happy with their daily lives and interactions as time wears on and on.

That's why my most recent prototype is codenamed 'Dark Star'. If you haven't seen it, Dark Star was made before Alien, and then the script was reworked and refilmed and called "Alien". It's about a crew of a deep-space mining vessel, as time wears on them and they are harassed by an unimaginably stupid "terror". Unsurprisingly, since John Carpenter directed both, it also has a lot in common with The Thing. But the focus is less on the alien terror and more on the steadily unraveling humans stuck in isolation for years at a time. And it's also a comedy, rather than a horror movie.

Any way you cut it, the difficulty of this concept as a game is how you model the inhabitants. Their behavior has to be simple enough to be meaty, but also support the steady unraveling and social pressures teams suffer when isolated for long periods of time. This is doubly important for my needs, because the game is intended to allow you to leave ships in various places and use them to either gather scientific data, materials, or hook up with other ships later and serve as supply points. There's going to be multiple ships out in the universe, so the modeling has to be something that the player can grasp relatively quickly. They'll have forgotten the precise details of what's going in ship 1 when they're flying ship 9.

I thought about it a lot, but I couldn't come up with a very good mechanic. They were all really "The Sims"y, based on needs and proximity and so on. It got complicated, because you had to do things like assign rooms and jobs and manage shifts so that people would encounter each other - just a huge headache. I needed something that would run in an obvious manner at high timescales, as well as be easily and deeply modified whenever you wanted.

So, here's the simple idea:

The ship is a grid. Each inhabitant can be "posted" at one particular grid node. However, that's not their physical position: we don't actually care about their physical position for our simulation (although we do care about it for visuals). From their post, they project a "+" pattern - a beam in each orthogonal direction. All the tiles their beam hits are tiles which concern them. Those are the tiles they use or maintain day-to-day. So it should obviously include a place to sleep and a place to eat and a place to relax, whatever you can manage... and it should also hit the facilities they are responsible for repairing or using. The "+" pattern has no end - if your ship is 500 tiles wide, they will be concerned with 500 tiles horizontally (and howevermany a vertical slice is, as well). So larger ships allow characters a wider variety of facilities... and a much heavier maintenance duty, if you aren't careful.

In terms of maintenance, it's best to have enough sailors to cover every single tile. Tiles that aren't covered aren't maintained. For some tiles, that's okay. But most facilities need maintenance. Similarly, a work station means nothing if nobody works at it.

In terms of socializing, when two beams overlap that's a social encounter that the characters will have regularly - maybe not every day, but fairly regularly. The kind of social interaction depends on the kind of facility at the overlap. So if they overlap at a mess hall, they tend to eat lunch together. Characters aligned diagonally will always interact at precisely two points, so you can control what sort of interaction they have and what kind of social sustenance they provide by carefully choosing which points you interact on - if both points are the same kind of interaction, it's much more powerful but also much more limited.

On the other hand, inhabitants can also be aligned on the same beam - either horizontally or vertically. (They can't be on precisely the same space, though.) In this case, there are a massive number of overlaps: every single tile along that axis. This can be a very powerful way to create plenty of social interactions... but overloading is often worse than going without, so care needs to be taken.

The core idea is that the characters have particular social characteristics and needs. Each character is probably marked by obvious appearance characteristics as to what sort of needs they have - otherwise it would be a bit difficult to tell quickly enough for my taste. You could replace that with a series of floating icons or something if you really want to avoid stereotypes, but I was planning on using floating icons for what their actual state is. Requirements/tendencies are different from actual state.

Then it's a simple matter of calculating from their various activities, and moving from your current state towards the calculated state by some amount per day (10%?).

The most basic element is your personal needs. You need a bedroom, a washroom, and a place to eat on your beams. If you don't have them, you'll quickly get annoyed. If you have extra good ones, that might help to blunt your mood swings! However, this is just a very basic baseline. Things get more complex from then:

You can calculate interpersonal interactions by simply looking at all the places your beams collide with other crewfolk's beams. This is a social interaction, and of the type the room specifies. The bad news is that this isn't scaled. On a ship with, say, 100 crew, you'd probably have 198 interactions, assuming none of the other crewmembers have the same X or Y coordinate as you. (There are ways to build a ship where the intersections happen in empty space or on incorrect job rooms, which can lessen that, but in general it stands.)

This is made much worse when someone shares a coordinate with you, because they'll overlap on around half of your rooms in most cases, meaning you can easily rack up the width or height of the ship with interactions with that one person.

Individuals can blunt this automatically, however. Any room they touch with a beam that nobody else touches with a beam is considered personal space, and they can use it to avoid 1 interpersonal interaction. So if I have 8 interpersonal interactions and 4 personal spaces, I can negate 4 of those interactions - and I'll automatically negate the ones that are the most problematic for me. If I'm not overdosing, I don't need to negate any of them. This doesn't mean you don't meet up with the other person, it just means that you also spend some time alone.

Obviously, if someone shares a coordinate with you, then all the rooms on that axis are going to be shared rooms because they have the same beams as you. This means that it's going to really limit your personal space.

The other kind of social input is the rooms you touch - shared or otherwise. This really only matters in small ships, because it's capped. If you touch three rooms, they'll each give you 33% of the social input you would have gotten if someone interacted with you there. But if you touch 100 rooms, you only get 1% each. So, as the ship gets larger, the contributions trend towards a very low baseline.

Some rooms count differently depending on your skills/job/tendencies. For example, a medical doctor isn't going to get any benefit from a deep space scanning room, and a astrophysicist won't get any benefit from a med bay... even if the two overlap on it and theoretically have a social encounter. It just does nothing. So it's critical to have a very quick and easy "read" of the situation, which is simple enough. Just color and mark the beams, and estimate the social situation for the crewmember a few weeks into the journey.

As the journey wears on, that might change. People's fundamental tendencies slowly drift out of kilter based on their long-term actual states. But it's a good enough estimation to keep a newbie in the game and not terribly confused. We can also implement some kind of actual relationship growth as well, if we like, which would further drive them off kilter - probably mostly driven by someone having lots of the same kind of social interaction with you.

All told, this system should make it very easy to estimate how people will interact socially, while also linking everything to a fun and complex space station/ship game which lets you build, leverage, launch, and reuse ships. It seems like a fun combination of managing social topology, work, and ship maintenance. Rather than being about dealing and repairing damage from space battles, it's all about trying to create a ship that operates well for extremely long periods of time, including when damaged or on the fritz or a crewmember is sick.

Anyway, I'll go ahead and program it some more.

Constructive Implicit Goals

I've been thinking about intrinsic goals, and how to create them.

Most games have goals that are stated. Kill the monster, shoot the alien, save the princess. But these games also have goals that aren't stated.

For example: you have some time, gold, and XP before you get to the monster's castle - how will you spend them? The fundamental rules about how your character interacts with the world determine the kinds of things you'll consider doing.

Grinding a bit to get the super-sword. Learning to use the fire-ice combo to kill hordes. Searching for the hidden nook that might have a treasure in it...

These are unstated goals. The game doesn't simply say "you should grind!" Instead, it simply allows you to fight while traveling from one place to another. The player quickly realizes that he can travel as much as he likes in order to get into those fights. The fundamental construction of the world allows the player to figure this out and do as much or as little as she likes.

However, that's a baby's toy - the tiniest of potentials, just enough to let the player feel like they aren't bored. An example of taking this to an extreme would be - obviously - Kerbal. Yes, I'm still talking about Kerbal.

Kerbal has no stated goals, and you really don't gain anything like experience points or such. However, there are a lot of goals built right into the world. Or, rather, the world exists to allow the player to create their own goals.

The most obvious things are the planets and moons. Each of them is a target you may want to reach. None of them have any particular reward for reaching them - they're just various sizes and atmospheres of rock. However, they have very unique physical characteristics, so reaching each is a distinct challenge.

The planets and moons are just the quick in, though - the obvious foothold. It takes almost no time to discover that the real power behind Kerbal's longevity is the physics of the universe. The planets do follow those physics, so you could say that the planets are simply specific instances, almost simply samples of how the physics can work. The core draw is the physics.

More specifically, movement.

The movement rules in Kerbal, along with the several kinds of visualizations used to help you plan your movement out, make moving an interesting challenge.

You can talk about splitting it up - launching, achieving orbit, transferring orbit, landing, docking, flying in atmosphere, supersonic flying, and so on. But they all use the same few core mechanics: position, velocity, gravity, drag. The existence of planets, especially your starting planet, provide a fun set of bumps and gradients to use, mixing the mechanics up and also prodding you into filling in your own instances. While you can't launch objects that create gravitic or atmospheric bumps, you can launch objects that have cyclic position and velocity, meaning you can use them as waypoints. Dock with them.

Anyway, this gives a very powerful set of implicit goals. Not simply because there are obvious implicit goals like in an RPG, but because the act of aiming for the obvious implicit goals makes you realize that your actions can create more implicit goals in a constructive manner. It's less like an RPG, and more like if every RPG party you sent out into the world remained there, ready and waiting for you to team up with them using another party you create later, or can be slotted into towns to make the town reshape the landscape...

Thinking about this kind of constructive implicit goals, I've created a variety of theoretical options. One such example is the RPG system briefly mentioned above, but nearly any kind of genre or theme could work. The key is that you need to give up on imposing a structured progression. Instead, you need to provide hooks to get them started, and the ability to work off of the things they build while chasing the hooks.

So if you want to make a fantasy RPG where that's the case, you would create a vast and inhospitable series of planes, each more dangerous than the last and filled with a spotty spattering of cities, ruins, and monster-gods.

Your actions would be to create adventuring parties, then guide them around - fighting monsters or avoiding them or whatever. Moving uses up some adventurer spirit - the more adventurers in your party, the less you move per point of adventurer spirit. You can stop wherever you like, whether you're out of spirit or not... but once you run out of spirit, you can't move any more. There's various kinds of long-term things you can do while stopped, depending on what adventurers are in your party. These generally change the map slightly in your favor in some manner.

Similarly, certain kinds of adventurers are vastly less mobile on certain kinds of terrain. If you're okay with sticking to roads, then horse-mounted knights will be ideal. If you want to move through the jungle, you'd be better off with rangerly elves.

If another party reaches you, then the two parties can exchange whatever members they want, and transfer whatever adventure spirit quantities remain between the two parties as they like. Some adventurers can generate spirit once they settle down permanently, so this is a valuable contribution: stop by and get your spirit recharged.

Anyway, the game would need to be somewhat carefully crafted such that your party mechanics are a bit more complex than "N members walking along". You'd probably construct a party out of social links - this guy is the leader, those three are sworn companions, etc. These links would provide a structure to help respond to challenges in a manner well-suited to your needs. A lot more work needs to be done on the design of it before you can say "okay! That's it!"

Anyway, there's lots of other genres you could start to think about, but since it involves iterative building, every genre would have to be re-cast such that there was some kind of iteration. So a first person shooter - you'd probably have to play a series of different marines or something.

It's a fun thought experiment.

Alternate Mod Multiplayer

I said this in passing on Twitter, but the more I think about it, the better an idea it seems to be.

Part one: multiplayer Kerbal. A shared universe where you can dock at each other's space stations and so on. I think it'd be a lot more fun to build things if other people could see what you built. The complexity here is in the inherent asynchronous nature of the game, but I think you could use a combination of check-ins and flight reviews to handle that. So if I launch a rocket, then the other players can watch how it is going/how it went at whatever speeds they like, including allowing me to make notes (audio or text) explaining things.

Live multiplayer might also be possible and fun, with each player controlling a piece of the mission. For example, one player launching a rocket and the other player tracking it and beaming power to it.

Part two: multiplayer Kerbal with mods.

Here's the key: each player can have different mods installed. Think of it as each player being a different nationality, and each nation having slightly different technologies. If you want to change out your mods, just switch nationalities - or create a new nationality that has the mods you want.

Part mods tend to work very well with each other - there's not going to be a crash because you installed three different kinds of fuselage parts. But operational mods do tend to conflict and crash, at least in the older versions. I say - okay! Let's make that a part of the gameplay! If you have operational mods installed and they conflict then, guess what? The the technologies aren't compatible. One nation should have one, another nation the other! You can download "nation packs" of parts and mods as well as downloading those separately, allowing for a wider variety of customization. Nation packs could also alter things like texture packs, flags, Kerbin colors...

Multiplayer games could therefore be with each player playing a given nation, giving them unique capabilities. I might have those giant 5-meter launch arrays, but I don't have the enregy-beaming capabilities that my friend does. Maybe I launch one of his payloads on one of my rockets! I can't use his ship - that mod isn't active for me, so I can't take control - but, conversely, he can't take control of the launch stage. Cooperation!

Also, very relaxed asynchronicity as we need it. I could simply hit "pause" on the mission when I separate from his payload, then check in the universe. He would then be able to play that mission out visually, see my commentary, and immediately take control over his payload when he hits the end of the recorded mission.

Of course, you could do all the same things single player, but it wouldn't be as interesting...

Anyway, I like the idea. It's sort of like allowing players to have different tech trees, but with player-constructed mods as the "levels" of the "tree" instead of pre-planning it!

Gleeful Gaming

So, I've been thinking about games that make me feel glee.

"Fun" is such an awful term, because it's so vague and wishy-washy. Every game feels different, and most of them are at least somewhat fun. Let's talk about one kind of fun in particular: glee.

Glee is a pretty rare thing to find in games. It's easy to find games that make you smile, or laugh, or shout in triumph... but it's really uncommon to find a game that gives you the kind of lighthearted joy I'm talking about.

Katamari Damacy did it. Playing Katamari Damacy was always such a gleeful experience. At least until they started adding in missions like "pick up all the hot things but not the cold things". At that point, the game lost that gleeful feeling for me, although it continued to be fun in other ways.

On the other hand, Saints Row III started off fun in other ways, but became more and more gleeful as the game went on. I had problems with that game - especially the pacing - but it was one of the rare, treasured gleeful experiences.

Kerbal Space Program is gleeful, too. Building a ridiculous rocket and trying to get to the outer planets with a heavy space station is the same kind of gleeful experience as trying to fly between two bridges in a VTOL while dressed in a pink tuxedo. To me, they feel the same.

But lots of games you might expect to be gleeful, aren't. Angry Birds is fun, but never gleeful. Mass Effect: fun, not gleeful. Racing games: fun, not gleeful.

I think for me to feel glee, there has to be an open constructive element to the game. There can be missions and objectives, there can be constraints, but they have to accept the constructions and choices I've made.

In Katamari's standard missions, exploring the levels is fun because the context is always changing. Even if I come back in a later play-through and explore it again, being bigger or smaller or coming in from a different direction can change the experience so much! By accepting my construction - size, direction - it makes me feel like it's playing with me, rather than against me. On the other hand, in Katamari's challenge missions, it's usually a matter of trying to find the one best path within the time limit. Fun, but highly restrictive and not interested in what I have to say for myself.

SR3 was also gleeful. There were plenty of missions and constraints, but in most cases it let me roll into the mission with whatever character I had built. That includes body, clothes, personality... but also upgrades and weapons. In fact, the irritating missions in SR3 are universally the ones where you have to use the provided weapons to protect the provided NPC health level. These were not simply hard: they were annoying, because they rejected my character choices in favor of providing their own.

Kerbal, of course, almost goes without saying. The whole game is built around letting you provide the construction for the gameplay part.

The three examples I gave are very goofy, but I don't think goofyness is actually a core part of feeling glee. I have felt glee at non-goofy games.

For example, Dragon's Dogma. Not a goofy game, but I felt a lot of glee running around that world. Again, that's probably because the gameplay accepted my constructions, accepted my choices.

As a counter-example to show the fine detail of how this works and fails to work: Sim City games do not make me feel glee. Their simulations are too aggressive, and rather than accept my choices, they punish me for choosing things they don't like. So it's not gleeful at all, although it is fun.

"But Kerbal has that kind of system, too!" you say. Well, that's true: in Kerbal, it is very easy to build a rocket "the way you want" only to have it explode violently. But in Kerbal, the iteration is very short and the punishment is hilariously fun. If you do something Sim City doesn't like, you spend ten hours getting slowly punished for it. If you do something Kerbal doesn't like, you explode five feet off the launch pad and watch all your rockets go spinning off every which way. Moreover, you can then go right back to your rocket design and tweak it, while in Sim City that's not as easy to do due to the difficulty of editing a city and the very long delays before you get a good grasp on whether something is working out.

In all of these games, the times when I lose that gleeful feeling are the times when the game steals my time away because of something I didn't realize would happen. The big annoyance in Dragon's Dogma? Falling off a cliff and having to revert to a save from fifteen minutes ago. In Kerbal? Landing on the Mun only to find that the hatch "is obstructed" by something and won't open. In Saints Row 3? Hm... I don't think I ever felt irritated at that game, except at the low number of clothing options.

As far as I can tell, here are the tenets for making me feel glee:

1) I must be able to construct my avatar. Not necessarily entirely freely, but with very little effort. Whether this is in customizing clothes, building my rocket, gaining skills, or just changing my size and position in a lasting, meaningful way.

2) Challenges, whether implicit or explicit, must accept my constructions.

3) Failure should be fun, and not set me back more than 5 minutes unless I've personally chosen to make the situation last more than that long.

4) Let me choose what I want to try to accomplish, when.

5) Don't distract me.

As a side note, all the games I've spent 80+ hours on have made me feel glee, and nearly all the games that make me feel glee I spent 80+ hours on.