Sloppy scaffolds is a way to construct in-game objects, similar to the "voxel" grid method used by Space Engineers, Minecraft, etc.
But while voxels are optimized for terrain, sloppy scaffolds are optimized for functional objects such as bases, starships, plants, and equipment.
The key to this system is mesh distortion. Using relatively simple math, you can scale and bend any mesh. This is what bone animations do, it's really straightforward.
Let's say we're building a base using sloppy scaffolds. The constraint is that we don't build using walls or floor tiles or other basic components: we build using a defined "interior space" form. It's a tube, and we paint it onto the ground with our mouse. The tube becomes a line of connected nodes which can be independently manipulated to create larger and smaller areas, bend the tube in various ways, and so on. Although it is logically a "tube", in this case it is a boxy shape, a wide one-story building.
The tube is actually a pair of meshes. One fairly narrow "rigid" mesh, which contains hardpoints. This can be scaled and rotated, but not bent. Between the rigid meshes is the "flexible" mesh. This creates a fluid curve between rigid mesh elements, and can repeat itself if the gap between the rigid meshes is quite long. Depending on the tube, it may have several sets of rigid meshes that alternate or change on demand, and it may have distinct outward-facing and inward-facing rigid meshes.
The hardpoints are where we put our doors, windows, and walls. We fill the inside of our tube with all the things that either break up the tube (interior walls) or allow access (doors/windows). The hardpoints can also have "logical sets" mounted on to them, which allows us to create internal rooms of various sizes and shapes, and those rooms have furniture mounting points on them. In this way, you can decorate your tube.
Of course, one tube is not enough to make a base with.
For example, let's say you're building a base. Your instinct might be to create a really wide spot in your tube for a complex area - like you want a dorm with bathrooms and a lounge and it's all got to fit in this spot. But there's no interior rooms that break up the space right, since they're all quite simple. What do you do?
Well, you paint another tube. But instead of painting it onto the ground, you paint it onto the exterior hardpoints of the first tube. The new tube automatically configures itself to match the first tube. The hardpoints aren't taken up, either: your doors and windows now go from one tube into the other.
The new tube might be constricted. If you have an arc on the outer tube, the inner tube will be compressed down. If there's still space between the hardpoints for the flexible mesh to connect them, it's fine. But if the hard points collide or are shifted too dramatically, you suffer a "break". A break means that a hard point is deleted, and the connective mesh fills the gap. This will fluidly reduce the number of hardpoints as you paint on more tunnels. Similarly, if you're on the outside of the curve, you'll be stretched. This will never cause a break, but you can add in a new hardpoint that isn't reflected to the other tunnels.
Basically, this is not a rigid grid. The curves do not march lockstep, since the tubes can be expanded and contracted. The curves do not necessarily have the same number of hardpoints.
Now, all of this might not matter if all you're creating is a floor plan. Why add all this complexity for a floor plan?
Let's take it into space. Your interior spaces are now pressurized spaces. You can mount engines and reactors onto those external hardpoints, and there's and "engineering" tube which can have tanks, reactors, and heavy engines mounted within it. What's good about this approach?
First off, by scaling the tunnel you can very nimbly scale the interior mounts. If you need more fuel, make the engineering shaft wider or pull the hardpoints further apart. More thrust? scale up the spot where you put the engine. Want optimal exterior mounting? Shrink the engineering space down and stick on some exterior stuff like solar panels or batteries.
Let's say your core tunnel is a spent on shared spaces and cockpits, and then the central shaft becomes engineering. You want to add in habitation space, gardens, etc, so you paint a tube onto the core shaft, and mirror it for good measure. You could just leave it aligned, but the engines produce a tremendous amount of heat and vibration. So you pull the habitation tube off of the main engineering tube at the back, and then curve it out and away into a fishbone shape. It's still connected at the front, integrated into your shared space, but then it strikes off on its own.
This is the heart of the "sloppy scaffold": the scaffolds stick together when it makes sense, but can also be pulled apart. They can be split up and rejoined and all sorts of combinations.
This is only possible because each scaffold element is "walled". You are never asked to put down A Wall Block or A Roof Block. Instead, you put down bounded areas. So attempting to figure out contiguous space, pathing, and pressurized area is really easy. Each segment is much more expensive than a voxel, but since it covers a lot more logical space than a voxel, it's fine.
Collision detection seems like an issue initially, since a grid is a lot easier to detect collisions on. But it's really not so bad, since the scaffolds break into a bunch of simple bounding boxes. And since the scaffolds only interact at merged hard points, the exact nature of nearby elements is unimportant.
The last piece of the engine is the wiring system. You have scaffolds. You have modules such as engines, solar panels, and chairs. And then you have cables.
Cables run between hardpoints much more freeform, and can spiral off into space or whatever else you need them to do. They are always 1-1, no splitting or splicing, so it's pretty easy to keep track of them. And their whole point is to connect two things in different places together. Maybe this is a pathway, like running hand rails along the outside of the ship. Maybe it's a water supply pipe, providing living spaces with liquid. Maybe it's a data line, piping data from one place to another. These are important to allow us to create connectivity, since our constraints reduce connectivity dramatically.
Now you know the basic idea, but you're probably not sold on why it's better than voxel. It's probably not worth that much effort just to get smoother lines, right?
Well, there's a big power hiding inside this concept. See, since the scaffolds can flex... the ship can flex.
Let's say we built that wishbone-shaped ship. However, that's the configuration we want it in during travel. When it's parked and the engine is off, we'd like those wishbones to come together around the engine. This protects the engine from micro-impacts and also allows us to travel easily between the two wings.
In a voxel system, you'd have to do some noxious hinge crap, break the ship into several different voxel grids, and then suffer through physics simulations. Even then, it wouldn't be very fluid: the pieces would all be broken apart logically, no connections allowed.
In our case, we can simply recalculate all the meshes. Connectivity is maintained: the whole scaffold bends organically, like an octopus limb. Rooms may distort, but assuming there is no breaking due to compression, nothing would really change. Connectivity is maintained outside of the mesh as well, with the cables remaining connected, no complaints. Connectivity on attached scaffolds works as well: attached scaffolds are also recalculated and fluidly reshaped.
Tweening between the two states is also very easy, meaning that it's not a huge problem to animate the shift.
This same operation can be applied to the girth of the scaffold, increasing or decreasing its size. For example, if you want an inflatable habitat, or perhaps you have a docking area and you want to open wide to receive a ship then close down to keep it safe.
The shape of the ship matters, and the ideal shape changes depending on exactly what phase of what mission the ship is on. We might close around engines when we aren't using them. We might extend a spiral of solar panels if we are near a sun. We might move habitable areas away from a radioactive reactor before we turn it on.
Changing the shapes of these ships is normally done on a mission basis, rather than a physics basis. This system is not optimized for physics. So the flex of the pieces as you crash into an asteroid? That'd be expensive to calculate. But switching everything over into "asteroid drilling" mode? Simple!
And why not toss in which things are turned on or off or have their settings changed in this mode? Then you can calculate all the performance of all the ship's pieces, and know exactly how much the engine vibration will affect the crew's downtime, or how slowly the ship has to travel to avoid sending a docked ship crashing through the back wall.
This combines well with overall world optimization. If you have ships where you know the configurations it can be set up into, and you know the stats associated with each configuration... then just load that. You don't need to simulate the ship, you just need to know its performance. Similarly, if you know its performance, you know how fast various resources are changing, and you can set up events to happen when certain amounts are reached. You don't need to simulate the systems every round, you just need to set an event to happen at a certain time, when a resource meets a specific threshold. Some of those can be automatic - running out of fuel, for example. Some can be player-created - customized missions that happen without the player's direct control. Some might be best-guesses based on the crew's default behavior.
Anyway, you can tell that this system is optimized for systems rather than physics. While there might be some physics simulation involved, primarily this responds to environmental threats or direct damage rather than things like flexing or detecting collisions. It's not really any worse at those things than a voxel system, but voxel systems are really bad at them, too. Instead, I'd like to focus on having dozens or hundreds of active objects running at all times with no slowdown. So it's all about the ops: bake the physical layouts into operational details, and use those to quickly block out performance on missions. Basically: turn the physical ship into a spreadsheet.
And if the player can define configurations and missions... they can define stories. They can define an explosion on deck 3 happening at a specific time. They can define a surprise message. They can define a crewmember getting sick, or how crewmembers file in and out of the crew quarters each day. Big or small, this allows players to craft and share scenarios.
...
Well, that was talking about ships. But sloppy scaffolding is useful for more than just ships.
Let's say we're defining alien life forms. It's super-easy to use sloppy scaffolds.
A tree is just a hard wood scaffold with more hard wood scaffolds springing off of it, and twigs attached to those hardpoints, and leaves attached to those. Defining how it is exactly laid out and changes over time is annoying, but it can be done: the life cycle of the average tree, defined in the same way you define a ship transforming into "idle" mode or whatever.
Things that want to animate are a bit more difficult, because computing meshes on the fly is expensive. For example, a mammal would be easy to define using sloppy scaffolds, and it'd be easy to make them vary by simply changing the exact scale of various scaffold elements. But a mammal wants to run around and stuff.
The only realistic way to approach that is to have a core skeleton and then map the scaffold elements to it. This would be similar to Spore's approach, and it'd require a lot of work. But...
What about gear?
Let's say you want to let someone design their own exosuit for missions to distant worlds. You already have a base shape that is mapped to various bones and has various animations. Now it becomes relatively easy to animate: when you paint a scaffold onto the surface of the character, it maps to the bones the nearby mesh verts map to. And if you paint a scaffold onto that scaffold, it maps to the scaffold's map. This creates a simple, fluid way to create (puffy, mechanical) gear. And, as with ships, the scaffolding comes with functionality and hardpoints - meaning you could vary its purpose wildly depending on exactly how you build it.
Now, if your gear has multiple modes, it can shift between those modes exactly like a space ship... while remaining tied to the same bone animations. This means you could shift between different preset configurations while animating the base character. Want a fold-out jet pack? Sure!
...
Anyway, I really wanted to come up with something that wasn't as rigid as voxels. Allowing things to remain connected while moving gracefully was a big concern.
I don't see any huge issues with the core idea. Some of the advanced stuff has some hurdles - especially designing clothes - but overall it seems relatively promising!
Thursday, May 21, 2015
Monday, May 18, 2015
Mission-Based Iteration vs Survival-Mode
Construction games!
I love expanding the core concerns of construction games. It gives an extended, graceful complexity curve as the player becomes more skilled. I also enjoy allowing for breadth of complexities, so different players will discover very different approaches and create very different scenarios for themselves.
But, at the end of the day, that complexity is not why players care about the game. The reason players want to play is because there are things to do.
Even when those things are largely self-directed, they are anchored in a core pressure system, a basic reality of how things work.
AKA, the "survival mode".
Personally, I think that a construction game needs to have both a survival mode and a creative mode, but I think they should interact a lot more freely and fluidly than most games allow.
Creative mode, where a player is free to create anything of any size, is important for allowing players to express themselves. Survival mode is where they learn what actually works, refine their design sense and taste.
Obviously, they are free to create whatever silly, unusable crap they want in creative mode, but the survival mode pressures give them a strong sense of whether something is designed "well" or not. Still, the freedom to create anything in creative mode is important, as experiments and art pieces are perfectly acceptable.
I think these two modes are more deeply linked than even that implies.
Right now, I think the big problem with construction games is that their creative mode and their survival modes are too chunky, too binary, too separate. If you're in survival mode, you had better eat and mine and survive monster attacks. If you're in creative mode, you can build anything with no constraints or pressures, never die, etc. This kind of thinking, this binary divide, is oldschool. It inherits from the idea of a "map editor", and that's not a concept that exists in a construction game.
Instead, we need to think of creative mode as an extension of survival mode, or visa-versa. There's a sliding scale where you shake off some of the survival-mode limits but keep others in order to refine your approach. Similarly, you'll want to have a method of porting those refined creations down into the survival world. "Iterated construction" is my goal.
As an example, in Kerbal you can build any kind of rocket you want, launch it, and pilot it for hours... and then revert it all. This "test" allows you to refine your rocket design and mission plan without pressure. You can keep trying all you want, until it goes right. Moreover, the diversity of possible missions lets you try a lot of different designs with different parameters.
Kerbal's recent updates have been focused on making survival mode more rigid and pathed, involving research, budgets, part and mass limits, and lots of ground-side complexity. When you try to build a ship, the parts you haven't unlocked are hidden, and you can't even test-fly a rocket that is too expensive, heavy, tall, wide, or complex for your facilities.
I don't believe this is a good path, although it's obviously quite subjective. This by-the-nose guidance really feels awkward: "survival mode" in Kerbal was trying to survive the mission. It's about designing good rockets and learning orbital mechanics. And that was reflected in their core constructive play: people enjoyed building larger, more intricate rockets as their skills expanded.
Now the survival mode is about making profits, taking contracts, upgrading ground facilities. Those don't help guide you towards building better rockets! At best, they might help you build cheaper rockets, but that's kind of a boring core aesthetic, don't you think?
The old idea was that you would survive a mission to distance planets. You would land on weird moons, or on worlds with dense atmosphere and lots of gravity, or a world with no ground at all. Each of these mission profiles suggested themselves quite elegantly: they exist on the map, therefore they are a place worth going. Each had different tolerances and requirements, and therefore each one tested and refined your construction skills. You could build more complex missions off of these pieces - an orbital station around Juul, a colony on the Mun, a rover that works on Eve, etc.
Those missions still exist. You can get a contract to go to Eve, a contract to put a space station around Juul. But they are hidden and metered. The new survival mode does not support the creative mode. It does not guide you towards building more elegantly and awesomely.
The original problem was simply that building things in Kerbal is a bit of a difficulty wall. Hundreds of parts and no understanding of things like aircraft parts vs rocket parts vs science parts vs crew parts vs... well, it's a bit overwhelming. The idea with the original science mode was to have those parts unlock - you start with so few parts that you can't possibly be confused for long. It's a good idea, but we need to stop confusing "tutorial" with "survival mode". They are completely unrelated.
Tutorials teach you how to make the game work. Survival mode teaches you to make the game sing. A survival mode with an integrated tutorial is dangerous: you might end up with a survival mode that just teaches you how to keep playing the survival mode. As with Kerbal. Completely sidelines your core play!
But Kerbal did do something very right with their original sandbox mode: their survival mode has distinct challenges and difficulty settings that are fluidly integrated.
You can see this with a few construction games. For example, in a diving game you quickly learn that your oxygen runs out extremely quickly as you go down deeper, and that the pressure makes it more and more difficult to keep vehicles and bases intact. Unfortunately, most of these games are not constructed to make iterative missions to those areas possible.
Once you get the radiation suit in Subnautica, radiation stops existing. Once you get the rebreather, depth penalties stop existing. This levels the playing field, which is exactly the wrong thing to do. It means that instead of trying to iterate and create better bases, you just tick off the check boxes and keep following the game's script.
Compare that to sandbox Kerbal, where once you've gone to Duna... you want to go back to Duna with a better design. This is the heart of an iterative approach: the challenges in a given mission don't exist to be flattened away, they exist to exert continual pressure.
That way you can learn to build a better design.
Subnautica - and most games like it - attempt to exert survival mode pressure by filling these areas with more dangerous creatures. However, that doesn't really get along well with the construction parts of the game. There's not really any relationship between the monsters of the deep and how you build your base. There's no pressure to build your base differently in order to make it more effective in different environments. And, of course, there's never any pressure to build a better-designed second base in the same environment.
That's the heart of the problem.
We could also talk a bit about Space Engineers. In creative mode, all the ship systems work as they do in survival. None of them really matter much - you can't die, your guns fire even if there's no ammo - but you can immediately tell how well your ship is designed without even passing it back into survival mode.
To me, this is a sign that the barrier between survival and creative is not as distinct as we like to believe. Why not let me plan out anything I want, and tell me how well it would work? Why not let me enforce specific survival limitations in creative mode? Let's mix and match.
Hm. We need to stop thinking about "survival mode" vs "creative mode", and start thinking about iterative construction.
At least, that's my plan.
I love expanding the core concerns of construction games. It gives an extended, graceful complexity curve as the player becomes more skilled. I also enjoy allowing for breadth of complexities, so different players will discover very different approaches and create very different scenarios for themselves.
But, at the end of the day, that complexity is not why players care about the game. The reason players want to play is because there are things to do.
Even when those things are largely self-directed, they are anchored in a core pressure system, a basic reality of how things work.
AKA, the "survival mode".
Personally, I think that a construction game needs to have both a survival mode and a creative mode, but I think they should interact a lot more freely and fluidly than most games allow.
Creative mode, where a player is free to create anything of any size, is important for allowing players to express themselves. Survival mode is where they learn what actually works, refine their design sense and taste.
Obviously, they are free to create whatever silly, unusable crap they want in creative mode, but the survival mode pressures give them a strong sense of whether something is designed "well" or not. Still, the freedom to create anything in creative mode is important, as experiments and art pieces are perfectly acceptable.
I think these two modes are more deeply linked than even that implies.
Right now, I think the big problem with construction games is that their creative mode and their survival modes are too chunky, too binary, too separate. If you're in survival mode, you had better eat and mine and survive monster attacks. If you're in creative mode, you can build anything with no constraints or pressures, never die, etc. This kind of thinking, this binary divide, is oldschool. It inherits from the idea of a "map editor", and that's not a concept that exists in a construction game.
Instead, we need to think of creative mode as an extension of survival mode, or visa-versa. There's a sliding scale where you shake off some of the survival-mode limits but keep others in order to refine your approach. Similarly, you'll want to have a method of porting those refined creations down into the survival world. "Iterated construction" is my goal.
As an example, in Kerbal you can build any kind of rocket you want, launch it, and pilot it for hours... and then revert it all. This "test" allows you to refine your rocket design and mission plan without pressure. You can keep trying all you want, until it goes right. Moreover, the diversity of possible missions lets you try a lot of different designs with different parameters.
Kerbal's recent updates have been focused on making survival mode more rigid and pathed, involving research, budgets, part and mass limits, and lots of ground-side complexity. When you try to build a ship, the parts you haven't unlocked are hidden, and you can't even test-fly a rocket that is too expensive, heavy, tall, wide, or complex for your facilities.
I don't believe this is a good path, although it's obviously quite subjective. This by-the-nose guidance really feels awkward: "survival mode" in Kerbal was trying to survive the mission. It's about designing good rockets and learning orbital mechanics. And that was reflected in their core constructive play: people enjoyed building larger, more intricate rockets as their skills expanded.
Now the survival mode is about making profits, taking contracts, upgrading ground facilities. Those don't help guide you towards building better rockets! At best, they might help you build cheaper rockets, but that's kind of a boring core aesthetic, don't you think?
The old idea was that you would survive a mission to distance planets. You would land on weird moons, or on worlds with dense atmosphere and lots of gravity, or a world with no ground at all. Each of these mission profiles suggested themselves quite elegantly: they exist on the map, therefore they are a place worth going. Each had different tolerances and requirements, and therefore each one tested and refined your construction skills. You could build more complex missions off of these pieces - an orbital station around Juul, a colony on the Mun, a rover that works on Eve, etc.
Those missions still exist. You can get a contract to go to Eve, a contract to put a space station around Juul. But they are hidden and metered. The new survival mode does not support the creative mode. It does not guide you towards building more elegantly and awesomely.
The original problem was simply that building things in Kerbal is a bit of a difficulty wall. Hundreds of parts and no understanding of things like aircraft parts vs rocket parts vs science parts vs crew parts vs... well, it's a bit overwhelming. The idea with the original science mode was to have those parts unlock - you start with so few parts that you can't possibly be confused for long. It's a good idea, but we need to stop confusing "tutorial" with "survival mode". They are completely unrelated.
Tutorials teach you how to make the game work. Survival mode teaches you to make the game sing. A survival mode with an integrated tutorial is dangerous: you might end up with a survival mode that just teaches you how to keep playing the survival mode. As with Kerbal. Completely sidelines your core play!
But Kerbal did do something very right with their original sandbox mode: their survival mode has distinct challenges and difficulty settings that are fluidly integrated.
You can see this with a few construction games. For example, in a diving game you quickly learn that your oxygen runs out extremely quickly as you go down deeper, and that the pressure makes it more and more difficult to keep vehicles and bases intact. Unfortunately, most of these games are not constructed to make iterative missions to those areas possible.
Once you get the radiation suit in Subnautica, radiation stops existing. Once you get the rebreather, depth penalties stop existing. This levels the playing field, which is exactly the wrong thing to do. It means that instead of trying to iterate and create better bases, you just tick off the check boxes and keep following the game's script.
Compare that to sandbox Kerbal, where once you've gone to Duna... you want to go back to Duna with a better design. This is the heart of an iterative approach: the challenges in a given mission don't exist to be flattened away, they exist to exert continual pressure.
That way you can learn to build a better design.
Subnautica - and most games like it - attempt to exert survival mode pressure by filling these areas with more dangerous creatures. However, that doesn't really get along well with the construction parts of the game. There's not really any relationship between the monsters of the deep and how you build your base. There's no pressure to build your base differently in order to make it more effective in different environments. And, of course, there's never any pressure to build a better-designed second base in the same environment.
That's the heart of the problem.
We could also talk a bit about Space Engineers. In creative mode, all the ship systems work as they do in survival. None of them really matter much - you can't die, your guns fire even if there's no ammo - but you can immediately tell how well your ship is designed without even passing it back into survival mode.
To me, this is a sign that the barrier between survival and creative is not as distinct as we like to believe. Why not let me plan out anything I want, and tell me how well it would work? Why not let me enforce specific survival limitations in creative mode? Let's mix and match.
Hm. We need to stop thinking about "survival mode" vs "creative mode", and start thinking about iterative construction.
At least, that's my plan.
Friday, May 15, 2015
Story, Storied, Have Stored
I love player-created content. I love it so much, I don't even want to call it "mods". I want it so flawlessly integrated into the core game that it's just how you play.
From a technical standpoint, this isn't as difficult as you might think. Just pipe player creations into other players' worlds. Sure, there's issues with quality or suitability, but the technical act of taking a player's constructed content and showing it to another player is pretty straightforward.
For me, the problem isn't the quality of the content or the technical aspect of sharing it. The problem is the disconnect between the players. The context of the content is lost.
Players are happy to create content, but a lot of the time, they create a context for the content that doesn't exist inside of the game world. For example, I'm playing Space Engineers. Sometimes I just want to create a functional ship - hey, look, this drills really well. But a lot of the time, I have a fiction in my head: this ship is a cryo scout ship with a crew of 10, this station is for several alien species that can't breath the same atmosphere, etc. These fictions are interesting to design for and, in theory, could give rise to a lot of interesting things happening with them.
If the ships and space stations are simply injected into another player's game, the context is lost and they are reduced to a jumble of parts ripe for the harvesting.
The context is removed, but it can be rediscovered. It can be hunted for. I see this a lot with Let's Players doing community showcases, exploring ships with only a bit of a text blurb to tell them what's up. This mystery has power - perhaps especially because there is little validation. You'll never know whether your guesses are right. Maybe you guess the station is a hospital for contagious diseases instead of a multispecies diplomatic station. In some ways, that doesn't matter: as long as your guess was interesting to you, you're having fun with the content I built, and that's the key.
In some ways, it matters a lot.
If the context is solid, it can live on and grow as the game progresses - and the new player can even be invited to participate.
If a new player understands that my station is a multispecies diplomatic base, they can quickly realize that the other ships in the area belong to these species. Suddenly, the fact that none of the nearby ships have weapons makes sense, and it's a reason for that player to design a weaponless diplomatic ship themselves. If one of the species is fronting a battleship, suddenly the player knows that there's an overly warlike species disrupting the negotiations. This steadily unfolds into a web of contexts and small scenarios.
We're talking solely through space ships existing in a specific place. All of that context can be built and explored without any combat modeling, or diplomatic modeling, or even any concept of time moving forward.
The core gameplay of most of these space ship building games is combat, or perhaps resource wrangling. What if, instead, the core gameplay was about creating and relating scenarios?
One way to do this would be to have the core gameplay be about designing ships for various groups and then watching them grow or shrink as your ship performs well or poorly. It is possible to make this complex enough to avoid dominant design strategies.
Another way to do this would be to rely entirely on player contextualization.
Players can present challenges. These might be blurbs such as "the nearby stars are highly radioactive, but colonization proceeds" or "a disease is spreading through the Traxican people, turning them into violent zombies!" Optionally, it can include worlds, stations, ships, people - as much as they want to put in.
Other players can attempt to approach these challenges by designing a ship and giving a blurb back. So players might design a colony ship to colonize those radioactive stars. They might design a medical ship to cure the disease, or an anti-personnel ship to kill the zombies.
The player that presented the challenge is required to use at least one player-submitted ship as part of their next challenge. So they find a colony ship they like and the next blurb is "in orbit around the planet, the radiation shields give out and the crew crash-land. They have to cobble together a base!" Or they use both the medical and anti-personnel ship and write a story about how the two clashed - and now the species are at war...
This freeform contextualization can also be done solo - creating ships to solve your own problems and creating new challenges based on that. While it seems masturbatory, it can be used to do worldbuilding in an organic and interesting way. The result is a pile of content ready to be repurposed for another player's experience!
This simple mechanism automatically includes quality filtering, since all the content is judged and propagated or ignored by other players. But it has several downsides.
The first downside is gameplay. You need to carefully design your gameplay so that players can get a feel for the ships and worlds that they live in. That means, at a minimum, the ability to embed commentary into designs such that as a player moves through them they hear explanations or see examples. My first impression of that would be allowing the players to record "ghost logs" like from System Shock 2 - you walk into a room, and you see someone slip across the room and lie down in a bed. Micro-machinima for context. This requires some effort - animations, recording, etc.
More gameplay would be better - the ability to use the ships. Some kind of statistical propagation as I discussed last essay. It's all quite doable, but you need to be aware that these gameplay methods serve to give the player context, not to actually be core gameplay.
Another thing that is troubling is the tense of the stories.
Since every story is narrated by a player, fundamentally everything "happened". The players don't get to unfold stories in real time unless they happen to be the one writing them. If you see a cool ship, your exploration of it is to see where it was and what it did, not where it is and what it is doing.
In order to avoid this, you have to allow players to create a "race track" of a scenario. Our scenario about settling a radioactive star would have various distances to travel with various amounts of radiation hitting you, attempts to scan planets while boiling under the sun, and then dropping the colonist base to the surface unharmed. More race track elements could be injected if the player is creative: crew members going rogue, the planet having ancient defenses, etc. Players could attempt these challenges with their own ships, or with any other ship submitted.
The problem with this approach is that the required gameplay can be quite bizarre. Moving from spot to spot, processing resources, and shooting at things are all pretty typical, but what kind of gameplay is "a crew member goes rogue"?
You can invent a gameplay for it. You can come up with something, I'm sure. Can you come up with gameplay for literally everything anyone will ever think of? "Ancients give one crew member psychic powers". "There's shapeshifters on the planet, and they pretend to be the crew". "The crew runs out of clean clothes". Each of these can be modeled, but each one is another special case, and needs to be thought up before anyone decides to use that special case!
I think the best way to do this would be to have a bunch of viable generic tasks that can be customized, but if there are new tasks, they are handled using the same context system. Your ship is intended to colonize a radioactive star, and in the end the other player decides how much he likes your ship... why not have him decide how well your ship can handle the rogue crew member? Submit a blurb describing how your ship handles it, and he'll decide how it unfolds.
This does take the event "into the past" again, but it's only for things that can't be done live.
Hm.
Anyway, thanks for listening. I have a lot more to say, but this is plenty long already.
From a technical standpoint, this isn't as difficult as you might think. Just pipe player creations into other players' worlds. Sure, there's issues with quality or suitability, but the technical act of taking a player's constructed content and showing it to another player is pretty straightforward.
For me, the problem isn't the quality of the content or the technical aspect of sharing it. The problem is the disconnect between the players. The context of the content is lost.
Players are happy to create content, but a lot of the time, they create a context for the content that doesn't exist inside of the game world. For example, I'm playing Space Engineers. Sometimes I just want to create a functional ship - hey, look, this drills really well. But a lot of the time, I have a fiction in my head: this ship is a cryo scout ship with a crew of 10, this station is for several alien species that can't breath the same atmosphere, etc. These fictions are interesting to design for and, in theory, could give rise to a lot of interesting things happening with them.
If the ships and space stations are simply injected into another player's game, the context is lost and they are reduced to a jumble of parts ripe for the harvesting.
The context is removed, but it can be rediscovered. It can be hunted for. I see this a lot with Let's Players doing community showcases, exploring ships with only a bit of a text blurb to tell them what's up. This mystery has power - perhaps especially because there is little validation. You'll never know whether your guesses are right. Maybe you guess the station is a hospital for contagious diseases instead of a multispecies diplomatic station. In some ways, that doesn't matter: as long as your guess was interesting to you, you're having fun with the content I built, and that's the key.
In some ways, it matters a lot.
If the context is solid, it can live on and grow as the game progresses - and the new player can even be invited to participate.
If a new player understands that my station is a multispecies diplomatic base, they can quickly realize that the other ships in the area belong to these species. Suddenly, the fact that none of the nearby ships have weapons makes sense, and it's a reason for that player to design a weaponless diplomatic ship themselves. If one of the species is fronting a battleship, suddenly the player knows that there's an overly warlike species disrupting the negotiations. This steadily unfolds into a web of contexts and small scenarios.
We're talking solely through space ships existing in a specific place. All of that context can be built and explored without any combat modeling, or diplomatic modeling, or even any concept of time moving forward.
The core gameplay of most of these space ship building games is combat, or perhaps resource wrangling. What if, instead, the core gameplay was about creating and relating scenarios?
One way to do this would be to have the core gameplay be about designing ships for various groups and then watching them grow or shrink as your ship performs well or poorly. It is possible to make this complex enough to avoid dominant design strategies.
Another way to do this would be to rely entirely on player contextualization.
Players can present challenges. These might be blurbs such as "the nearby stars are highly radioactive, but colonization proceeds" or "a disease is spreading through the Traxican people, turning them into violent zombies!" Optionally, it can include worlds, stations, ships, people - as much as they want to put in.
Other players can attempt to approach these challenges by designing a ship and giving a blurb back. So players might design a colony ship to colonize those radioactive stars. They might design a medical ship to cure the disease, or an anti-personnel ship to kill the zombies.
The player that presented the challenge is required to use at least one player-submitted ship as part of their next challenge. So they find a colony ship they like and the next blurb is "in orbit around the planet, the radiation shields give out and the crew crash-land. They have to cobble together a base!" Or they use both the medical and anti-personnel ship and write a story about how the two clashed - and now the species are at war...
This freeform contextualization can also be done solo - creating ships to solve your own problems and creating new challenges based on that. While it seems masturbatory, it can be used to do worldbuilding in an organic and interesting way. The result is a pile of content ready to be repurposed for another player's experience!
This simple mechanism automatically includes quality filtering, since all the content is judged and propagated or ignored by other players. But it has several downsides.
The first downside is gameplay. You need to carefully design your gameplay so that players can get a feel for the ships and worlds that they live in. That means, at a minimum, the ability to embed commentary into designs such that as a player moves through them they hear explanations or see examples. My first impression of that would be allowing the players to record "ghost logs" like from System Shock 2 - you walk into a room, and you see someone slip across the room and lie down in a bed. Micro-machinima for context. This requires some effort - animations, recording, etc.
More gameplay would be better - the ability to use the ships. Some kind of statistical propagation as I discussed last essay. It's all quite doable, but you need to be aware that these gameplay methods serve to give the player context, not to actually be core gameplay.
Another thing that is troubling is the tense of the stories.
Since every story is narrated by a player, fundamentally everything "happened". The players don't get to unfold stories in real time unless they happen to be the one writing them. If you see a cool ship, your exploration of it is to see where it was and what it did, not where it is and what it is doing.
In order to avoid this, you have to allow players to create a "race track" of a scenario. Our scenario about settling a radioactive star would have various distances to travel with various amounts of radiation hitting you, attempts to scan planets while boiling under the sun, and then dropping the colonist base to the surface unharmed. More race track elements could be injected if the player is creative: crew members going rogue, the planet having ancient defenses, etc. Players could attempt these challenges with their own ships, or with any other ship submitted.
The problem with this approach is that the required gameplay can be quite bizarre. Moving from spot to spot, processing resources, and shooting at things are all pretty typical, but what kind of gameplay is "a crew member goes rogue"?
You can invent a gameplay for it. You can come up with something, I'm sure. Can you come up with gameplay for literally everything anyone will ever think of? "Ancients give one crew member psychic powers". "There's shapeshifters on the planet, and they pretend to be the crew". "The crew runs out of clean clothes". Each of these can be modeled, but each one is another special case, and needs to be thought up before anyone decides to use that special case!
I think the best way to do this would be to have a bunch of viable generic tasks that can be customized, but if there are new tasks, they are handled using the same context system. Your ship is intended to colonize a radioactive star, and in the end the other player decides how much he likes your ship... why not have him decide how well your ship can handle the rogue crew member? Submit a blurb describing how your ship handles it, and he'll decide how it unfolds.
This does take the event "into the past" again, but it's only for things that can't be done live.
Hm.
Anyway, thanks for listening. I have a lot more to say, but this is plenty long already.
Tuesday, May 12, 2015
Topological Play: Pull, Push, Connect, and Access
I like construction games. I especially like construction games where people live in the thing you built, like bases or star ships. I've talked about this stuff a lot in the past, but today I'd like to talk about specific kinds of pressures which make construction games more interesting.
When you think of a construction game, you probably think of two common kinds of play:
1) Spreadsheet play. Having enough modules of the right type to get the performance you want. May also involve things like ship speed and weapon coverage stats.
2) Physics play. Having a structure that doesn't break when it's active, or that resists damage well.
These are certainly fine kinds of play, but I think there are some other kinds of play. Let's talk about them.
Connection play is when you have to put your modules in specific relationships to each other, either allowing no space between them or requiring that the space between them be filled with specific modules.
A module that adds on to another module physically takes up space. A cable running from one place to another physically takes up space.
How flexible this is can really change how the game feels. For example, can an attached module be in any adjacent block, or does it require a specific face? Can a cable be curved and branch? Maybe a cable doesn't actually fill the voxel, so you can lay many cables through an area and even walk through them - you just can't slap down another voxel in that spot. Tons of options.
This can also be inverted: a block might require an empty space off of a particular face to allow for heat venting, maintenance access, vehicular traffic, line-of-sight broadcast, etc. These are functionally the same constraints: whether it's a required component or a required empty space, the topological challenges are the same.
It's a fun challenge to stack these up in complex ways. For example, an engine might require an empty tile for venting: why not aim that face of four engines all into the same empty tile? Optimization!
Pull and push is when components exude a particular field effect. For example, a reactor might give off deadly radiation, a heater might give off heat, a factory might give off noise and vibration, an antenna might give off connectivity, etc. If you want to be complex, you can make each kind of field effect propagate differently through different materials: a heavy wall might block deadly radiation, but actively extend vibration due to its rigid structure.
Push and pull act to softly guide the player to leave certain spaces empty and fill other spaces, as well as gently guiding them to put specific modules near each other. For example, an engine gives off heat and vibration, but is almost immune to those things. So you can stick a bunch of engines together, and put them off away from the delicate stuff. A factory produces vibration, but is sensitive to it, so you can't cluster them up. A heater will keep components from frosting over, so put those kinds of things clustered tightly around the heater. You end up with a design that varies system density in a natural and believable way. Good way to do it.
Most of the time, these are binary fields - you're either inside our outside of them. I think that's not a very good way to do it, because it's too rigid and forced - I like a degrading field that has a lot of wiggle room for designers. This also allows you to play with extending or inhibiting a field in a very fluid, adaptable way, and that leads to interesting designs.
This also requires that you can model their effects in subtle ways. I recommend a combination of two factors: maintenance requirements and performance efficiency. A factory that is subjected to vibration might work less efficiently, since it must move much more carefully for the fine detailing. Or perhaps the vibration causes it to break down faster. Even if ongoing maintenance is not part of the game world, simply SAYING that it requires extra maintenance is enough to distinguish it from a better-designed ship. Ideally, you could scuff it up and make it look dirty.
Access is when you calculate clear propagations between a module and another module. One example of this might be wiring: if you wire up all the components on your ship to a central computer, you can access them all and they can all access each other. This is great for operations, but might be vulnerable to hackers or power surges.
Another example would be life support: an air vent provides air to all the open voxels it can reach, assuming it is a contained space. But, more than that: a couch provides a place to rest if people can reach it. A cafeteria provides food, if you can walk to it. A repair gantry provides access to the engines when you swing it out that way, or to the life support systems when you swing it this way.
These access networks can be very adaptable and provide a very nice "soft" way to push players to design more thoughtfully. A space ship where your crew have good access to the engines to maintain and repair them is great, and that can be calculated using an access network. It can also be done in very creative ways: maybe the maintenance space can be pressurized for really delicate work, but only when the engines are off (they produce too much heat). Maybe the maintenance space is actually solid space most of the time, but the engines can be pushed apart like sliding shelves for maintenance purposes.
Similarly, network-wide threats are a great way to make things more interesting. Maybe not everything should be on the same network, because if something goes wrong, everything goes wrong. Maybe there should be bulwarks in the network that can be sealed: airtight doors or circuit breakers. Also, because the network contains all the network flow for all the components, maybe you should separate the network to keep contamination down: keep a data network running light and fast, keep a life support network safe from visitor's diseases, keep a power network safe from sudden power draws from intermittent devices.
All at once
Of course, the ideal is to combine all these things at once, in different amounts and directions.
For example: one kind of starship engine produces heat and vibration, requires empty space for venting, and needs fuel and power lines. Another kind of engine produces deadly radiation, requires no venting or fuel, but requires 100x as much electricity.
Not only are the modules different, but how they interact with the space around them is different. The basic engine can have life support regions and computers relatively close-by, but the other one produces radiation that will cause computers to have glitches and crew to have cancer. So even though they have no access constraints of their own, they affect everyone else's constraints. The high power draw of the second one may require it be on its own power grid, while the fuel requirement for the first one might be harder to topologically manage because of all the physical piping it pulls to your engine area.
So your modules don't just have a statistical presence: they also interfere with other kinds of concerns because of their various constraints.
It sounds like a lot of fun!
When you think of a construction game, you probably think of two common kinds of play:
1) Spreadsheet play. Having enough modules of the right type to get the performance you want. May also involve things like ship speed and weapon coverage stats.
2) Physics play. Having a structure that doesn't break when it's active, or that resists damage well.
These are certainly fine kinds of play, but I think there are some other kinds of play. Let's talk about them.
Connection play is when you have to put your modules in specific relationships to each other, either allowing no space between them or requiring that the space between them be filled with specific modules.
A module that adds on to another module physically takes up space. A cable running from one place to another physically takes up space.
How flexible this is can really change how the game feels. For example, can an attached module be in any adjacent block, or does it require a specific face? Can a cable be curved and branch? Maybe a cable doesn't actually fill the voxel, so you can lay many cables through an area and even walk through them - you just can't slap down another voxel in that spot. Tons of options.
This can also be inverted: a block might require an empty space off of a particular face to allow for heat venting, maintenance access, vehicular traffic, line-of-sight broadcast, etc. These are functionally the same constraints: whether it's a required component or a required empty space, the topological challenges are the same.
It's a fun challenge to stack these up in complex ways. For example, an engine might require an empty tile for venting: why not aim that face of four engines all into the same empty tile? Optimization!
Pull and push is when components exude a particular field effect. For example, a reactor might give off deadly radiation, a heater might give off heat, a factory might give off noise and vibration, an antenna might give off connectivity, etc. If you want to be complex, you can make each kind of field effect propagate differently through different materials: a heavy wall might block deadly radiation, but actively extend vibration due to its rigid structure.
Push and pull act to softly guide the player to leave certain spaces empty and fill other spaces, as well as gently guiding them to put specific modules near each other. For example, an engine gives off heat and vibration, but is almost immune to those things. So you can stick a bunch of engines together, and put them off away from the delicate stuff. A factory produces vibration, but is sensitive to it, so you can't cluster them up. A heater will keep components from frosting over, so put those kinds of things clustered tightly around the heater. You end up with a design that varies system density in a natural and believable way. Good way to do it.
Most of the time, these are binary fields - you're either inside our outside of them. I think that's not a very good way to do it, because it's too rigid and forced - I like a degrading field that has a lot of wiggle room for designers. This also allows you to play with extending or inhibiting a field in a very fluid, adaptable way, and that leads to interesting designs.
This also requires that you can model their effects in subtle ways. I recommend a combination of two factors: maintenance requirements and performance efficiency. A factory that is subjected to vibration might work less efficiently, since it must move much more carefully for the fine detailing. Or perhaps the vibration causes it to break down faster. Even if ongoing maintenance is not part of the game world, simply SAYING that it requires extra maintenance is enough to distinguish it from a better-designed ship. Ideally, you could scuff it up and make it look dirty.
Access is when you calculate clear propagations between a module and another module. One example of this might be wiring: if you wire up all the components on your ship to a central computer, you can access them all and they can all access each other. This is great for operations, but might be vulnerable to hackers or power surges.
Another example would be life support: an air vent provides air to all the open voxels it can reach, assuming it is a contained space. But, more than that: a couch provides a place to rest if people can reach it. A cafeteria provides food, if you can walk to it. A repair gantry provides access to the engines when you swing it out that way, or to the life support systems when you swing it this way.
These access networks can be very adaptable and provide a very nice "soft" way to push players to design more thoughtfully. A space ship where your crew have good access to the engines to maintain and repair them is great, and that can be calculated using an access network. It can also be done in very creative ways: maybe the maintenance space can be pressurized for really delicate work, but only when the engines are off (they produce too much heat). Maybe the maintenance space is actually solid space most of the time, but the engines can be pushed apart like sliding shelves for maintenance purposes.
Similarly, network-wide threats are a great way to make things more interesting. Maybe not everything should be on the same network, because if something goes wrong, everything goes wrong. Maybe there should be bulwarks in the network that can be sealed: airtight doors or circuit breakers. Also, because the network contains all the network flow for all the components, maybe you should separate the network to keep contamination down: keep a data network running light and fast, keep a life support network safe from visitor's diseases, keep a power network safe from sudden power draws from intermittent devices.
All at once
Of course, the ideal is to combine all these things at once, in different amounts and directions.
For example: one kind of starship engine produces heat and vibration, requires empty space for venting, and needs fuel and power lines. Another kind of engine produces deadly radiation, requires no venting or fuel, but requires 100x as much electricity.
Not only are the modules different, but how they interact with the space around them is different. The basic engine can have life support regions and computers relatively close-by, but the other one produces radiation that will cause computers to have glitches and crew to have cancer. So even though they have no access constraints of their own, they affect everyone else's constraints. The high power draw of the second one may require it be on its own power grid, while the fuel requirement for the first one might be harder to topologically manage because of all the physical piping it pulls to your engine area.
So your modules don't just have a statistical presence: they also interfere with other kinds of concerns because of their various constraints.
It sounds like a lot of fun!
Subscribe to:
Posts (Atom)