Clarity in Zero Gravity

(This is a long technical post)

As you hopefully know, I'm developing a thing called Astrophobia. It's a game about living on a space station, and it has relatively real-feeling zero gravity stuff going on.

The difficulty lies in what gameplay to create. See, the feeling of being someone stuck on a space station is pretty compelling, but there's no inherent gameplay in changing how the player moves around. It feels very different, but it affords no particular skill challenges. At least, not in any way I can make feel meaty and fun. Most of the actual difficulties of navigating a space station I've abstracted out, because you can't control a digital avatar to the degree required to make it truly realistic.

My original idea was to make the gameplay about creating and managing a space station that deals with vaguely real-feeling hard-scifi challenges, such as maintaining mining vessels or entertaining space tourists or serving as a deep space radio relay.

However, the creation of a space station is actually not easy.

Oh, the mechanics are easy enough. I've already implemented them. You can place rooms, work the systems, and so on. But in terms of headspace, it feels tenuous and difficult. The system I was going to use, which involves colored cables running through the base, is very hard to grasp from inside the base.

It would be quite simple to do from outside the base. Blueprints on a table, draw some lines, check some boxes. Easy to understand. The cognitive load is lessened by the use of tools. That is, the tool of a map.

I did implement a map in the game, and you can use it to build the base. But it feels... wrong. It doesn't feel like you're living in a space station.

After having actually "lived" in a space station - that is, having built a few in the game world and floated around inside of them - I can say that construction isn't part of the feel. Sure, maintenance, attaching things, detaching things - yeah. But actually commissioning new modules and deciding how fundamental wiring is done? That's not part of the experience. I should have realized it immediately, of course: that sort of design work isn't part of any "live in a place" experience. Living in a place is about living in a place, and designing is unrelated.

So I was thinking about breaking the game in half.

Designing a facility (or a module for a facility) is a huge amount of deep fun, and living in the thing you've built is a huge source of deep fun, too. So I really think that I need to split the game in two.

I'm thinking you've got the "living in space" section, but then you've also got the "ground support designing stuff" section. I like the idea of cycles, of a team living on a base for six months, then returning home. And you get to design the add-on or the next base that will be there for the arriving fresh new team.

I like the idea of making the designing of the facility feel as organic and real as living in the facility. To that end, I'm thinking of a design system that feels like pencils on graph paper. This sounds like a detail, but it's not: I'm talking about sticking the design to a 2D, line-centric approach. It feels fitting: the personal portion of the game extends traditional 2D into 3D, so it seems suiting that the traditional 3D designing tools are brought down to 2D.

This constraint isn't really a limitation so much as an advantage born out of the game's overall constraints. Space station modules are, fundamentally, a very constrained design space. For example, they are all basically tubes running along a given axis.

Let's say you want to design an inflatable hab. You could do this by simply choosing that material and drawing a line. Our graph-paper constraint understands you've chosen a structural material and want it to be that radius at those points, and you instantly have a fundamental structure for your module. If you want a rigid cubic tube, draw a line after choosing that, and you've got it. Draw BOTH, and you'll have an inflatable outer hab around a rigid cubic box.

Line controls exist to help you if you want straights, smooth curves, or mirrored modules, obviously. And adjusting them is as easy as grabbing the line and moving it.

Once the fundamental structure is laid down, it's a matter of putting in the things you want to put in. Here a simple, Kerbal-like method of lateral/radial symmetry can be used, or you can manually work with "the far wall" or "the near wall" to place objects that aren't mirrored. So if you want your inflatable hab to have soft beds in it, you can select them, pump the radial symmetry, and then click on the hab. An array of beds will be placed in a ring around the core axis. Exterior solar panels? Same thing, except they automatically get placed on the outside of the wall.

You don't need the added complexity of seeing the hab in 3D, at least not in the basic design system. You don't need to place beds by clicking in a 3D space. The design constraints of the module allow you to place the bed in 2D knowing full well exactly where it'll actually show up. Similarly, since everything needs to be attached to a wall, there's never any confusion about where it'll end up in space. Just cycle through the walls (two for our basic modules, four for our double-layer example) and whatever you place will be placed on that wall with whatever symmetry you've selected putting it in other areas as needed.

Then put in connectors of your choice so your module can connect to other modules. Design those, too. Send it all up at once, and the end result is that these one-axis simple-to-design modules end up as a catacomb of your own design. Which you then live in.

This very easy to use system can allow players to build whatever modules they need or want, and also allows for easy modding as people add more parts, ports, and structural elements. But is is easy to transition from the lineart design to a final, functional mesh?

Well, yes.

Many of the things you added are static modeled. The beds are not dynamically built, just dynamically placed and rotated.

The only mesh that has to be generated is the fundamental structural mesh. This isn't as hard as it sounds, though: create one "slice" of the material, correctly modeled and UV-mapped. Make sure it's got symmetric verts on each side. We can simply take that mesh and duplicate it over and over, each time lining up the left edge of the next bit with the right edge of the previous bit. Scaling up and down happens over the course of the mesh - if X is our spinal axis, then we simply scale all the verts towards the preferred scale depending on their X component.

The difficult part of the fundamental structural mesh is complex structures. For example, what if you want windows? What if your inflatable hab should have big plastic windows in it, ignoring radiation concerns?

The easy way to do this is to have different materials. You'd have three: an opaque mesh slice, a window mesh slice, and a transition mesh slice. However, this can get very complex if you want something like circular windows (rather than ribs that are windows). I think that freeform window placement is probably something to hold off on, but it probably wouldn't be THAT difficult to place them like beds or solar panels, except that instead of just placing meshes, they cut holes in the wall before placing their mesh.

With the technical concerns addressed (or handwaved), I can talk about gameplay.

Right now, I like the idea of having to live in the base for a specific duty cycle - three months, six months, a year, two years - it'll depend on what the player decides and the expense of switching crews, as well as the level of medical support available to the astronauts. However, because of that long timespan, the game obviously cannot be played entirely real-time.

I'm thinking that you can play as much as you like in real time, but there are various things you can do to enter an automatic time-advance. Sometimes these would be short - going to bed would advance you eight hours, perhaps. But they could also be long: simply clicking "go" on your weekly schedule could advance a whole week if nothing breaks in the middle. I want to reward time spent actually wandering the facility and living in it, so I think that "design research" points steadily tick up as you work in real time, second-by-second. Obviously this can be gamed by just leaving the game running in the background, but I'm not to concerned about that kind of exploit. There are plenty of tasks to do in real time if you want to - repairs, maintenance, EVA, even just eating or hanging out with other astronauts. Also, you can switch between multiple teams on multiple space stations...

Design research points are obviously spent in the design phase. I'm thinking they augment the idea of cash: you earn cash by having your space facility actually do something. The cash fee for sending up new modules (whether for a new station or to attach to an existing station) is simply based on weight, nothing more. However, every component has a design difficulty attached to it as well, and if you can't meet that fee, you can't figure out how to work it into the module and it doesn't pass testing. IE, you can't launch. There are obvious opportunities for tradeoff here, with something like a lightweight inflatable wall having a high design cost, but a heavy metal tube having a low design cost.

There might also be other kinds of resources, but we're not going to worry about that yet. That's for mods.

When designing a space station, you need to take into account how it's going to work and what it needs to accomplish. In the beginning that might be mostly just figuring out how to keep astronauts alive. But you'll need to expand. Support tourists, mining fleets, deep space probes, etc. All of these bring in the cash while testing your design capabilities. The more challenging variants don't require bigger stations, but better designs. Share designs with your friends, as well - even invite them aboard.

But when it comes to actual design, an important factor is how the station actually works. In order for a design to be "better" or "worse" it needs to be better or worse at something.

Previously I had designed the systems to be about consuming vast amounts of space, so spatial optimization (especially regarding material transfers) was the primary concern. However, with this refit that doesn't really suit. What I would like to do, if possible, is make it so that the individual modules end up really tightly bound together, so that you'll never really consider a module as a completely independent entity.

Let me start with the concept of a control panel. I like the idea of a clunky control panel for this system, rather than the adaptive intelligent computer system I developed. I like the idea that when you launch a module, you have buttons and levers and lights which represent different functions included in the structure of the module. You can transfer between modules, too - the hardpoints will have a dozen or so "wire" points which will count as contiguous when modules are connected.

In previous gameplay prototypes, it was about optimizing space with time, such that various operations might share the same space as long as they didn't share the same time. I think that's still valid, but it can't have the "pumping" feel because that relied on designing the spaces to interleave physically, which is not part of the new design system. Instead, I think the new system is going to be about managing degradation.

That is, you could run the smelter and the die-caster at the same time, but their combined smoke will choke your filters and their failure chance will spike. The vibration and heat will tax both your astronauts and the hab itself, causing slow leaks, cracked electronics, and so on.

I like this idea, because it highlights the joins between modules, giving you freedom to express yourself within a module, and then attempt to optimize how you put modules together and try to maintain them. Obviously, basic supply management is also going to be an issue... but within any one hab, the player should feel free to go with the specific design they feel happy with, rather than worrying that a cabinet is half an inch off of optimal. The pressures are on inter-module and supplies, not intra-module.

That said, controlling operations is going to be important, but it needs to be something which can be scheduled and worked through with an accelerated simulation, rather than painstakingly performed in real time each time. So my thought is that each piece of an operation is very well understood and you can literally schedule them by just dropping basic functionality ("turn on smelter") into a timetable. The controls which can perform that task are automatically detected, and the actual NPC activity which does those operations can be computed. "How long does it take Ralph to get from the smelting panel to the casting panel? There's an airlock in the way? Shit, I have to design this better, there's a wasted hour there..."

Of course, it can also be done manually.

One key left unmentioned so far is the idea of things breaking down. In my previous gameplay, that really wasn't part of the equation. But in this system, it's critically important, because breaking down is one of the major things that happens if you don't optimize well. Part of your design needs to take into account what happens when something breaks down - for example, is there a backup system? In addition, how easy is it to get to that system and repair it? Do you have replacement parts? These are questions that a beginner probably won't care about, but when you start to design large systems for smelting or whatever, it starts to be a concern.

Anyway, those are my thoughts on Astrophobia today. This weekend, I'll put together the module construction system.

On PAX

So, I have a bit of a long view on the whole "PAX is run by over-entitled whiny man-children" debacle.

Me deciding whether or not to personally ban PAX means absolutely nothing, because it's not the sort of thing I like to attend. Crowds give me headaches.

But I did watch all the various people weigh in. Lot of people have decided to not have anything to do with PAX. Lot of people see nothing wrong with being an exclusionary, whiny man-child. And a lot more people saying that they didn't like the whiny man-children in charge, but the whiny man-child conference was bigger than just one or two individual whiny man-children.

Let me explain my view. Because I know everyone is dying for one more whiny man-child to weigh in.

For everyone who wants to change the industry, the problem isn't specific instances of specific people doing specific things. It is a general culture of exclusion, oppression, and arrogance. The core gamer culture is made of whiny man-children, and they've built a very whiny, childish culture.

For people who want to change that, PAX is an excellent, easily-gripped example. It is saturated in that culture, even if it occasionally struggles not to be. Regardless of what PAX planners intend for their con to represent, it is mobbed by - yup - whiny man-children. So that is what it represents.

Someone who wants to change the game industry can hold up PAX and say "this is the problem, and as you can see, it goes to the top."

Then you can watch the rationalizations come in. "He's not actually siding with rapists", "PAX is bigger than him", "you're over-reacting"...

...

Look, I'm not asking you to avoid PAX. That's not my decision to make. But I am asking you not to play down how awful gamer culture is, and that definitely includes - perhaps is exemplified by - PAX and its primary audience.

Cars are bad. Meat is bad. We understand these things, and we choose how much car and how much meat we are willing to accept. Personally, I don't accept car, but I do accept meat. Despite knowing full well that meat is bad - much, much worse than most people realize. Everything about meat and its related industries is just a nightmare.

I don't rationalize my meat-eating away by trying to trick myself into thinking it's okay to eat meat, that meat isn't bad. Instead I accept that I'm participating in something immoral. And, more and more, I limit the amount of participation as my conscious burns a little hotter.

If you want to or need to participate in core gamer culture, that's your baileywick. It has a lot money, power, and camaraderie to offer. Some people want some of that. Some people need some of that.

But it is pretty noxious.

Extended Manly Punching

I was watching a pitch for a tactical board game full of mecha, and a standard thought occurred to me: why the fighting? Giant machines are more suitable for industrial work, rescue, construction. For fighting, all you really need is an orbital cannon or a drone with a long-range missile. The fantasy of long, manly punching bouts is stupid.

So I originally wrote up a piece about a noncombat mech game (where you are a catastrophe response team), but there was so much analysis of the fundamental play of the Extended Manly Punching genre of games that it seemed wise to put it in its own post.

First off, we're going to dismiss the excessive variety of unit types. While some variety is necessary, the massive amount of variety found in things like Battletech and Warhammer is more about color, noncombat play, and longevity. And we're just discussing the core play right now. So some variety, yes. Massive variety? Outside our scope.

The "skeleton" of the gameplay is about the interplay of two basic concepts: range and cover. Every combatant has a weapons range and a movement range, which gives them a "kill zone" - they can attack an enemy within that zone on their next turn. Obviously, faster mechs and longer-ranged weapons have an advantage. However, the interplay is confused by cover.

While "range" is largely an abstract mathematical concept, cover is not. Cover is securely grounded in the map the game is played on, and ties the rather nebulous concept of range to a concrete set of constraints. Cover is directional, reducing an enemy's ability to attack you on their turn and usually reducing your ability to attack them. This is a powerful tool against mecha with long range, and is most easily exploited by mecha with fast movement. However, its ability to apply differently in different directions is what makes emergent play.

A team of mecha has a complex team kill zone and cover... cover represented by their overlapping personal kill zones and cover-taking. Flanking damage is also often popular to push this nexus of kill zones apart into a wide-reaching web. By using cover, individuals and teams can selectively protect themselves from certain avenues of attack while opening fire on others. The map may also have built-in terrain features that change range/speed/cover calculations, such as roads that give wheeled vehicles a speed boost, or hills that give mecha a weapon range boost.

This is the heart of the game. The web of kill zones you use, and predicting how your enemy's web will evolve. There's enough known information (current deployment, ideal ranges, movement speeds, and terrain) to predict several turns in advance, but there's enough variables (and sometimes hidden information) that predicting is difficult and risky. So you get a very engrossing system where it's always a challenge to read ahead. Unlike simple "rock paper scissors" fights, this emerging web of kill zones is deeply tied to the terrain of the map, and therefore it is not simply a matter of predicting what your enemy will do... but where and when they will do it.

Basically, the whole system relies on

1) A pair of basic numeric constrains which are largely interchangeable but can be combined and have unique applicability (weapon range and speed)

2) Something that deeply ties those constraints to a complex, unique environment (cover)

3) Multiplying that together several times (teams of mecha)

4) Adding meat with secondary constraints such as armor and ammo, and creating variations to mix it all up

That is my analysis, at least.

Network Control as Gameplay

One of the things I'm doing in my Astrophobia space station game is that I'm making networking into an element of gameplay. In addition to physical space constraints, I'm also adding networking constraints.

There's a lot of reasons for this. It's not complexity for complexity's sake: the constraint adds a tier of automation that would be difficult or impossible to pull off if we "flatten" the network out so that everything is connected to everything.

In the game, there are three colored cables running through every room: white, red, black. In rooms that split up, these cables would split up - some going one way, some another. These cables are the heart of the networking system. They run power and data. Simultaneously, when possible.

The basic rule is that one line can only provide enough power for one heavyweight facility. Things like lights and doors and computer consoles are connected to the power system by the low-grade wiring of the hab modules themselves, so that's not a problem. But you can't plug something that needs industrial levels of power into a standard wall socket. Your life support system, for example, would suck down one line of power. If you had a smelter and a planet-scanner as well, those would each require one line of power. That's all three lines of power - white, red, black.

So this is a pretty limited resource, but not as limited as it sounds. The lines don't run uninterrupted throughout the station. Red isn't the same circuit everywhere. Instead, this particular segment of red might only run through four modules, with another segment of red running through eight others. Obviously, you could power those two segments separately.

So one method to using a lot of heavyweight devices is to split up the network, and have power sources providing to each different area. This requires a fair number of power sources - you might prefer to skimp and use something like a battery bank, which sucks down power and puts power out opportunistically on all three lines, but can run out of juice.

Another option is to hook a bunch of industrial devices to the same power line, but only turn one of them on at a time.

This brings us to the other half of the deal: data.

The lines do not simply bring in power. They transfer data. Even an unpowered line transfers data. This allows, just for starters, remotely controlling the systems.

Put a screen up in a room, plug it into the red power line. Now you have direct access to the status of all devices on the red line - both heavyweight devices and lesser devices such as the screen you're working on. You can see the devices on the screen as you walk by, in real time, a little label highlighted with their basic state. Click on the screen to interact with it properly, bringing up the detailed status reports and options for each connected object. Turn off the planetary scanner by simply clicking on it, then clicking the power toggle. Turn on the ship repair system the same way. Manually guide the repair arms right there - no need to float over to the repair arm bank to do it, so that bank can be left in vacuum and far away.

So there's a balance. The fewer lines you keep to, the more things you can control from anywhere on the line. The more line breaks you have, the easier it is to power every machine simultaneously... but you'll have a harder time controlling them remotely.

That's the tip of the iceberg. Like states in a Turing machine, it isn't really how many or few states you have so much as how they work together.

Let's start with the concept of a router. Plug a router into a room, and it hooks up to any two lines rather than any one line. The router will either keep the lines as they are (red to red, black to black) or swap them (red to black, black to red) depending on its state.

This alone opens up a vast array of control possibilities, giving you the option to not only reroute power, but also reroute control. Switch between the atmospheric scanner and the gravitic scanner as you like, while both machines continue running in the background. Switch between dozens of different security cameras. Completely shut down or bring on-line vast areas of station for maintenance purposes.

But where this entire thing begins to shine is that all of this combines to allow for automation - including NPC work behavior.

Let's say you have a life support system. It runs on tanks of oxygen and nitrogen. Over time, it will use these resources up, and you'll need to swap out the tanks.

The status of the tanks can be read from any connected console. Sure, you can visually read them. But that's just a visual representation of an underlying data stream, and that stream can easily be parsed and reacted to by automatons such as Jed, the only astronaut crazy enough to cohabitate with you.

So Jed "sees" that a life support tank is running low, probably reflected by an in-game visual of him working with the screen.

A basic rule programmed into his little astronaut brain is that he should keep the life support tanks in good condition, so he will now automatically look for a full tank to put there. As long as you put a cargo bay on the same line, he'll see the cargo bay's stocks. The data stream includes the specific in-game objects referred to, so now he can actually go and grab the full tank, cart it to the life support system, swap the two out, and cart the empty tank back to the cargo bay. Similarly, if you drop below a few full tanks in the cargo bay, he can automatically order more and/or call for refilling the empties.

And if there's a router on the line, then after he looks for a cargo bay and doesn't find one, he'll toggle the switch and look again.

This is also valuable for mods. For example, the science scanners create images of what they are scanning. If you see an anomaly, it's usually worth taking manual control and aiming the scanner for an in-depth look at that region. However, the image is transmitted over the network. There's no reason a mod couldn't do image processing and automatically detect and pursue anomalies.

You can also do automation, in theory. Tell a computer (or astronaut) to look for specific outputs from specific devices, and then give specific devices specific inputs. This can easily create chains of events - when a ship loads ore into your ore storage, it reacts when you hit 80% full, pipes the ore into the smelter, deactivates the smelter while piping the basic metal into the refinery, turn on the refinery, etc, etc, eventually pipe it all back to the ship automatically.

I look forward to implementing it.

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.