All this talk about rocket stages! Okay, that's done. But let's continue talking about the fundamental gameplay concept behind them: the idea that different functional gameplay elements must be stacked in the same shared space.
This is a great concept, because it's basically Tetris gone off the deep end. When building something, you not only have to build something that functions like you need it to, but you also need to consider the requirements of the next functional piece, providing good anchors and spatial arrangement for that!
Let's consider a classic game idea: you are building a city (or a space base, or a secret lab, or a dungeon, whatever).
Classically, these games operate by building everything in the same basic plane (rarely, with some 3D elements). While you certainly do build the facility in stages as you progress, each of the stages is normally simply attached somewhere in the base. At advanced levels of play there will be a lot of preplanning for optimal final base arrangement, but in general these games can be played "expansively": just staple the next pieces on wherever you can. At very worst, delete a misplaced early piece and then reconfigure a bit.
I'd like to think about how to combine this with the concept of stacking in shared space.
For example, let's say there's a game about a futuristic city. As you build the city, you literally build on top of the existing layer. So your first layer gradually gets covered up as you build a second layer, and so on. However, the lower layers don't vanish: they still operate, albeit in a dark and economically depressed manner.
If you want to build a giant supermall, you'll need to build it right on top of a bunch of tram stations for deliveries (and people too poor to fly space-cars). In order to build tram stations, you need to build them on top of power stations. And so on.
You can make it much more complex. For example, tram stations might cut across several layers, rising and falling to deliver locals to various heights. Landing bays for space-cars might require two layer deep substructures for safety reasons. A giant spire of a building could easily cross a dozen layers. Airflow and weather in the lower layers could be a concern which grows and changes as you stack more layers down on top.
It's a simple enough concept, with a lot of room for whatever complexity you want to add.
We could also go a route with shifting, adaptive layers. For example, let's say this is a game about ghosts coming from dreamers, and you run a sleep clinic specifically to deal with such things.
So you're responsible for arranging all the rooms in the clinic, placing the patients, and creating their daily schedules (including where they can spend their time off and so on). In turn, the dreamscape is manufactured around their bedrooms and their moods created by their day. In the dreamscape you can build another facility to work with the dream-avatars of the patients and protect them from dream-monsters - including those that may emerge from their avatars, or the avatars themselves.
You can stack this N deep, as you like. The treatment in the dream world may involve how they migrate around the dream facility you created, and that may in turn create an "unconsciousscape" or something where you can build another facility to treat all of humankind simultaneously...
Anyway, the key complication to this approach is that the foundations are mutable. If you change where a patient sleeps, or if you introduce a particularly obnoxious thing to their daily lives, the dreamscape foundation will change, and the facility you built there will also be altered - perhaps some buildings lose power, or partially collapse.
Both of these game designs are relatively straightfoward, but they seem like they would be interesting.
Wednesday, July 31, 2013
Recovering Operational Stuff: The Game
For the past few days I've been talking about stages (rocket stages) as gameplay. Today I wanted to talk about stages that continue to operate.
A big problem with Kerbal's "rocket stage design" philosophy is that each stage tends to be kind of fire-and-forget. There is some interaction between the phases, mostly in terms of physical dependencies, but nearly all the effort is simply to get the payload to the destination. Nearly all of the stages are disposable.
But the most interesting things are done when you have stages that are complex. Launch a space station hub which drops a lander that has a skyhook... that's when things get interesting. A lot of stages that have complex, ongoing functions.
So let's forget the harsh physics sim and focus on the idea of having a system where you create stages that continue to do stuff. For example, if you want to mine the moon, you have an orbital base which drops the mining facility which has a heavy lift shuttle to bring the payload back to the base...
The key here is how to make the physicality of the stages matter to each other. If it's all just standardized docking modules and dropping stuff, then we end up with a cargo-box situation where it doesn't matter what the space station is dropping. Just use the same space station regardless of what we're dropping. No! We want it to matter. But how?
Let's make our game a sort of Battlestar Galactica thing, where you're on the run and you can only stop for a few weeks at any given resting point. When you drop a mining facility, you're going to want most of that stuff back before you leave, stowed away securely for the rigors of warp travel. You might leave some scaffolding and concrete behind, sure, but those mining lasers and solar panels are too valuable to ditch. So every stage you launch, you plan to bring the vast majority of it back and reconnect it.
Now the physicality of the design matters, because not only do you have to drop it, you also have to resecure it, and in a way that is safe for warp travel.
I'm picturing something like a giant space donut with a bunch of big "patches" on the outside. Those patches are places you can construct your ships, and the places you'll want to reattach them to. Of course, the ships you create are often very complex, multi-stage objects, since they do have to operate in complex environments at interplanetary ranges. You could launch your fuel station and your mining facility separately, but it probably makes more sense to combine them into a single ship and return the facility to the fuel station rather than trekking them both back to the hub with independent microwarp drives.
Also, you have to choose how much to leave behind. The mining facility has a few very high-value modules - laser drills, for example. Perhaps you just want to reclaim those, so you load them and the crew onto the ore shuttle and leave behind the majority of the facility framework. On the other hand, infrastructure struts aren't free either - maybe you really do want to recover the majority of the facility. Perhaps even to the point of recollapsing inflatable hab units and deconstituting concrete back into powder for reuse. It depends on gravity and time, I suppose. And how much work you feel like doing to set it all back up again at the next respite.
I also like the idea of very adaptive physical objects. The space station unfolds when it reaches orbit. The shuttle has "wings" of plasma to help lift it, but it needs to be careful not to cut the space station. The facility can "self destruct" and pack itself into a box for cargo lifting. Even habitable modules might migrate around a facility shift-by-shift to keep the workers all perfectly rested and happy...
The big thing here is the recovery of each stage. This makes it critical for stages to be able to re-dock with each other, or be dismantled into easily-carried parts. Either way, it's clear that the physics of the game will have to be a lot more forgiving than Kerbal's. In fact, the piloting and docking is probably done automatically, with you simply choosing destinations and directing crew as to what to build or change when something needs building or changing.
This automation will allow you to steadily build up your capabilities such that even on a short respite you could deploy hundreds of mining ships to strip a star system bare in just a few weeks. Of course, the final goal is to fill the donut hole with an intergalactic drive and leave to find a green planet in some other galaxy... but who will manage to gather the rare resources and manufacture the delicate components that need to be manufactured at the bottom of a planet's gravity well?
A big problem with Kerbal's "rocket stage design" philosophy is that each stage tends to be kind of fire-and-forget. There is some interaction between the phases, mostly in terms of physical dependencies, but nearly all the effort is simply to get the payload to the destination. Nearly all of the stages are disposable.
But the most interesting things are done when you have stages that are complex. Launch a space station hub which drops a lander that has a skyhook... that's when things get interesting. A lot of stages that have complex, ongoing functions.
So let's forget the harsh physics sim and focus on the idea of having a system where you create stages that continue to do stuff. For example, if you want to mine the moon, you have an orbital base which drops the mining facility which has a heavy lift shuttle to bring the payload back to the base...
The key here is how to make the physicality of the stages matter to each other. If it's all just standardized docking modules and dropping stuff, then we end up with a cargo-box situation where it doesn't matter what the space station is dropping. Just use the same space station regardless of what we're dropping. No! We want it to matter. But how?
Let's make our game a sort of Battlestar Galactica thing, where you're on the run and you can only stop for a few weeks at any given resting point. When you drop a mining facility, you're going to want most of that stuff back before you leave, stowed away securely for the rigors of warp travel. You might leave some scaffolding and concrete behind, sure, but those mining lasers and solar panels are too valuable to ditch. So every stage you launch, you plan to bring the vast majority of it back and reconnect it.
Now the physicality of the design matters, because not only do you have to drop it, you also have to resecure it, and in a way that is safe for warp travel.
I'm picturing something like a giant space donut with a bunch of big "patches" on the outside. Those patches are places you can construct your ships, and the places you'll want to reattach them to. Of course, the ships you create are often very complex, multi-stage objects, since they do have to operate in complex environments at interplanetary ranges. You could launch your fuel station and your mining facility separately, but it probably makes more sense to combine them into a single ship and return the facility to the fuel station rather than trekking them both back to the hub with independent microwarp drives.
Also, you have to choose how much to leave behind. The mining facility has a few very high-value modules - laser drills, for example. Perhaps you just want to reclaim those, so you load them and the crew onto the ore shuttle and leave behind the majority of the facility framework. On the other hand, infrastructure struts aren't free either - maybe you really do want to recover the majority of the facility. Perhaps even to the point of recollapsing inflatable hab units and deconstituting concrete back into powder for reuse. It depends on gravity and time, I suppose. And how much work you feel like doing to set it all back up again at the next respite.
I also like the idea of very adaptive physical objects. The space station unfolds when it reaches orbit. The shuttle has "wings" of plasma to help lift it, but it needs to be careful not to cut the space station. The facility can "self destruct" and pack itself into a box for cargo lifting. Even habitable modules might migrate around a facility shift-by-shift to keep the workers all perfectly rested and happy...
The big thing here is the recovery of each stage. This makes it critical for stages to be able to re-dock with each other, or be dismantled into easily-carried parts. Either way, it's clear that the physics of the game will have to be a lot more forgiving than Kerbal's. In fact, the piloting and docking is probably done automatically, with you simply choosing destinations and directing crew as to what to build or change when something needs building or changing.
This automation will allow you to steadily build up your capabilities such that even on a short respite you could deploy hundreds of mining ships to strip a star system bare in just a few weeks. Of course, the final goal is to fill the donut hole with an intergalactic drive and leave to find a green planet in some other galaxy... but who will manage to gather the rare resources and manufacture the delicate components that need to be manufactured at the bottom of a planet's gravity well?
Tuesday, July 30, 2013
Design with Stage Constraints
Yesterday I talked about stage-based design - stages as in rockets, not as in levels. Read that first, if you like, because this builds on it.
When it comes to building stages, a big part of the fun is the constraints that are put on the construction. In Kerbal, there are four major constraints.
1) Rockets fire downward. Since the primary engines fire downward, there's a very strong limit as to vertical construction. You can't put an engine above another engine and fire them both, because the top engine will destroy the bottom engine.
2) Fuel tanks are heavy and get emptied out. This means that you'll optimally want to shed those heavy fuel tanks the instant they dry up - which means many of your stages are arranged specifically to dump empty tanks safely and quickly.
3) The physics of the rocket restrict how you can build it. Wobble, shear, and strain will rip your rocket apart if you build it clumsily. Unfortunately, in Kerbal this can be fixed by just using struts to staple everything together firmly, so it's not as much of an issue.
4) The tradeoff between vertical and horizontal. You can put a lot of things in a vertical line - especially fuel tanks - but that can get difficult when you want to add more complex devices and behaviors. However, horizontal construction interferes with the line of the other vertical segments, and also creates a lot of wobble - at least until you realize the wobble is broken.
These constraints create a wonderful environment where you can build easily, but the restrictions grow organically as you get bigger. The constraints are all about tradeoffs rather than restrictions, and are therefore a lot more flexible and expressive than a game where you have five hardpoints and you slot in three weapons and a shield. Moreover, the constraints are specifically polished such that they interact with building in stages: you can drop large chunks of your creation as you go along, which means the remainder has a new profile and new performance characteristics.
In my early tests for the "sea and sky" game I talked about yesterday, one thing I ran into was the overly simplistic construction system I created. It's worth considering whether a system with some more constraints could be made more interesting.
Unlike space travel, fuel isn't the biggest concern in the sea and sky game. I think that hull is. Each kind of medium - flight, sea, subaquatic - has a different kind of hull with different characteristics. While the different kinds of hulls can survive the different kinds of mediums, they are definitely a burden, adding weight and drag.
It makes sense that, instead of jettisoning fuel tanks, you'd have to jettison hulls. When you want to go from air to submarine, you need to land the blimp on the surface and then just get rid of the blimp part, leave you with a submarine. Of course, the blimp would have to be big enough to carry the submarine, but that's the joy of the stages approach, isn't it? Each stage must be larger than the last.
However, that theory is all well and good, but how do you make it interesting physically? How do you give the player the clay and push him with tradeoffs?
Well, it's got to be in how the hulls connect up and orient, doesn't it?
It's tempting to simply make each hull contain the next hull, like Russian nesting dolls. But that runs into the same problem as the cargo boxes: there's no tight relationship between the stages. It's just cargo-carrying: they don't share the same physics space. So we want our hulls to exist in the same physics space all the time.
Which means we really don't have any option: the hulls have to all be exterior, at least partially.
The question is: do we arrange the hulls into a single hull, or do we have them separated into distinct hulls which are connected - or, perhaps, both?
Well, distinct hulls is problematic for two reasons. One is physics: both the drag and the physics simulation would be annoying to deal with. Another problem is mirroring: radial mirroring is good, but in our case we would be using x-axis mirroring, which has far more limitations. Either way, due to the way that mirroring works, unless you want multiple final stages it's the earlier stages that have to be on the outside, and that would result in extremely complicated structures. The only realistic way to do it would be to not mirror hulls at all, which would limit us more or less to vertical stacking - not how I want to do it.
Anyway, I think that distinct hulls are a possibility, but I think they should be considered advanced. I'm much more interested in having all the hulls in one line, and then blasting off the back every time you want to activate the next section.
The concern here is that every hull has to therefore be acceptable in every medium. If you have a submarine that launches a ship that launches a jet, then your submarine-ship-jet first stage needs to be able to move around underwater. As long as we understand that, we can simply make our hulls work okay like that. The concern for construction is how to protect or hide away the not-yet-required extensions that only work in a specific medium. Do your plane stage wings have sealed jets on them, or perhaps they are folded away inside and only unfold on the surface. Maybe your surface ship hull actually has turbines operating underneath during the submarine stage, since they are going to be submarine engines even while you're on the surface. How can you optimize? How much fun can you design in?
My thought is that each piece of the hull would be smaller than the next, and therefore be partly nestled within its parent. The ship hull's rear 30% is embedded in the submarine hull. The airplane hull is half embedded in the ship hull. This overlap not only keeps the structural integrity of the hull overall, but also shelters the rear area of the child hull such that delicate and medium-specific equipment can be put there.
I think this design fills a lot of my requirements, especially in terms of how each hull is always partially exposed. How well you can use that exposure, and prevent it from screwing up your other stages is the question. Can your hull fit a fold-out wing section internally? Should you expand it until it can? But then you'll need a larger parent hull... oh, and now you need a jet hull with four substages, meaning that the nose is too long and you've got a difficult time with your wings set so far back... maybe you should use an X-mirror external hull attachment for wings a bit further up as well?
Hm. I think it sounds fun.
When it comes to building stages, a big part of the fun is the constraints that are put on the construction. In Kerbal, there are four major constraints.
1) Rockets fire downward. Since the primary engines fire downward, there's a very strong limit as to vertical construction. You can't put an engine above another engine and fire them both, because the top engine will destroy the bottom engine.
2) Fuel tanks are heavy and get emptied out. This means that you'll optimally want to shed those heavy fuel tanks the instant they dry up - which means many of your stages are arranged specifically to dump empty tanks safely and quickly.
3) The physics of the rocket restrict how you can build it. Wobble, shear, and strain will rip your rocket apart if you build it clumsily. Unfortunately, in Kerbal this can be fixed by just using struts to staple everything together firmly, so it's not as much of an issue.
4) The tradeoff between vertical and horizontal. You can put a lot of things in a vertical line - especially fuel tanks - but that can get difficult when you want to add more complex devices and behaviors. However, horizontal construction interferes with the line of the other vertical segments, and also creates a lot of wobble - at least until you realize the wobble is broken.
These constraints create a wonderful environment where you can build easily, but the restrictions grow organically as you get bigger. The constraints are all about tradeoffs rather than restrictions, and are therefore a lot more flexible and expressive than a game where you have five hardpoints and you slot in three weapons and a shield. Moreover, the constraints are specifically polished such that they interact with building in stages: you can drop large chunks of your creation as you go along, which means the remainder has a new profile and new performance characteristics.
In my early tests for the "sea and sky" game I talked about yesterday, one thing I ran into was the overly simplistic construction system I created. It's worth considering whether a system with some more constraints could be made more interesting.
Unlike space travel, fuel isn't the biggest concern in the sea and sky game. I think that hull is. Each kind of medium - flight, sea, subaquatic - has a different kind of hull with different characteristics. While the different kinds of hulls can survive the different kinds of mediums, they are definitely a burden, adding weight and drag.
It makes sense that, instead of jettisoning fuel tanks, you'd have to jettison hulls. When you want to go from air to submarine, you need to land the blimp on the surface and then just get rid of the blimp part, leave you with a submarine. Of course, the blimp would have to be big enough to carry the submarine, but that's the joy of the stages approach, isn't it? Each stage must be larger than the last.
However, that theory is all well and good, but how do you make it interesting physically? How do you give the player the clay and push him with tradeoffs?
Well, it's got to be in how the hulls connect up and orient, doesn't it?
It's tempting to simply make each hull contain the next hull, like Russian nesting dolls. But that runs into the same problem as the cargo boxes: there's no tight relationship between the stages. It's just cargo-carrying: they don't share the same physics space. So we want our hulls to exist in the same physics space all the time.
Which means we really don't have any option: the hulls have to all be exterior, at least partially.
The question is: do we arrange the hulls into a single hull, or do we have them separated into distinct hulls which are connected - or, perhaps, both?
Well, distinct hulls is problematic for two reasons. One is physics: both the drag and the physics simulation would be annoying to deal with. Another problem is mirroring: radial mirroring is good, but in our case we would be using x-axis mirroring, which has far more limitations. Either way, due to the way that mirroring works, unless you want multiple final stages it's the earlier stages that have to be on the outside, and that would result in extremely complicated structures. The only realistic way to do it would be to not mirror hulls at all, which would limit us more or less to vertical stacking - not how I want to do it.
Anyway, I think that distinct hulls are a possibility, but I think they should be considered advanced. I'm much more interested in having all the hulls in one line, and then blasting off the back every time you want to activate the next section.
The concern here is that every hull has to therefore be acceptable in every medium. If you have a submarine that launches a ship that launches a jet, then your submarine-ship-jet first stage needs to be able to move around underwater. As long as we understand that, we can simply make our hulls work okay like that. The concern for construction is how to protect or hide away the not-yet-required extensions that only work in a specific medium. Do your plane stage wings have sealed jets on them, or perhaps they are folded away inside and only unfold on the surface. Maybe your surface ship hull actually has turbines operating underneath during the submarine stage, since they are going to be submarine engines even while you're on the surface. How can you optimize? How much fun can you design in?
My thought is that each piece of the hull would be smaller than the next, and therefore be partly nestled within its parent. The ship hull's rear 30% is embedded in the submarine hull. The airplane hull is half embedded in the ship hull. This overlap not only keeps the structural integrity of the hull overall, but also shelters the rear area of the child hull such that delicate and medium-specific equipment can be put there.
I think this design fills a lot of my requirements, especially in terms of how each hull is always partially exposed. How well you can use that exposure, and prevent it from screwing up your other stages is the question. Can your hull fit a fold-out wing section internally? Should you expand it until it can? But then you'll need a larger parent hull... oh, and now you need a jet hull with four substages, meaning that the nose is too long and you've got a difficult time with your wings set so far back... maybe you should use an X-mirror external hull attachment for wings a bit further up as well?
Hm. I think it sounds fun.
Monday, July 29, 2013
Staged!
So, recently my big interest has been with stages - by which I mean Kerbal-style stages, where you discard each stage in turn as the next phase of your mission progresses. So, not stages as in "levels", but stages as in "constructs which perform a task and then are discarded".
Well, I've done a lot of testing and some prototyping and I've come up with some interesting discoveries about the concept that maybe you'd like to listen to. Well, I hope so, since that's the rest of this essay.
The first thing I tried was a simple "cargo bay" system. So you could design a vehicle and land it somewhere, at which point you would simply build a base out of the components you brought with you. Concrete, inflatable habs, prefab rooms, solar panels, just stick 'em together however you want.
In terms of resource constraints, it's actually pretty interesting. But in terms of the vehicular gameplay, it's actually really dull, because there's no interaction between the later stages and the earlier stages. You're literally just shipping a box full of stuff. If you want a different kind of base, you just ship a box that has different stuff in it... but the vehicle doesn't care. It's just a box.
Moreover, if you are going for deeply nested stages (3+ stages), you end up with a string of boxes, and you use each box to build a transport section for the next box... and again, nobody cares whats in the box for the next stage. No interaction.
I was thinking about ways to make the stages more interesting. There are, as far as I can tell, two ways to make the stages more interactive. One: make the components required by the next stage affect this stage. Two: recycle components used by this stage for the next stage.
For example, let's say you're building a space station. Instead of discarding the final rocket stage, why not use it? Send some crew in to scrub it down and weld in some room partitions and, viola, you have a nice, spacious science module! Yes, unrealistic, but we're talking about how to make stages more interesting.
In the other direction: you can't simply assemble a moon base out of component buildings, because they all need to be connected to the same framework of power, life support, and walkable tunnels. So you pack in all the inflatable habs and solar panels you want to use, yeah, but you also have to take a massive "+" shaped framework along. How do you make it work out? Maybe you make it fold into a kind of stool-shaped shape and attach rockets to the "legs". When it comes time to deorbit and land on the moon, you unkink those legs and land politely in the proper formation. Then you can attach the habs and solar panels and stuff to it. Maybe some work is needed on the joints to make it all properly connect up after all that folding and unfolding.
And, hey, yeah, you ditched that deorbit rocket on the way down, but it's good metal that you could use. Go out and find where it landed, drag it back to base. You can always use another large, heavyweight building, even if it requires weeks of astronaut-labor to clean it up and put in doors and stuff.
Basically, my thought is that it's really difficult to create strong, complex structures off-planet. So while a lot of the stuff you'll want to use is basically just packed up in a box and shipped around, the big core elements that hold the stage together need to be carted around more or less intact, aside from some minimal joints and reassembly requirements.
The joy of this approach lies in the N-stage situation, rather than the 2-stage situation.
Right now, we're talking rockets. Let's switch over to a different kind of game world.
This game world is on the sea, and the primary objective is to populate the various islands and set up subaquatic bases. So our major means of transport are submarines, ships, and aircraft. To push for as many medium changes as possible, there are teleport rings hidden in various places at the bottom of the ocean. When you go through, you appear in the air very far away. Of course, you can also go into the airside teleport ring and come out at the bottom of the ocean.
As such, we'll spend a lot of the early game just using ships and populating islands, with light aircraft for scouting. But as we get further along, we start to need to transition. A ship that carries a submarine. A submarine that carries a plane. A plane that carries a ship. Well, maybe not a plane, but an air-lift vehicle of some variety.
Each stage is disposable, but there's a lot of overlap. Unlike a rocket, fuel is not an overwhelming primary resource. Certainly fuel is important, but the medium switch is the primary mechanic here, and therefore the concern is all the pieces you needed to make the old vehicle work are now working against you in the new vehicle. That big hull you used to offset water and carry a heavy load is now either annoyingly heavy (for lifting into the sky) or continues to displace water annoyingly (when attempting to sink). The jet engines you flew with are now submersed, and a massive drag...
So there would be a lot of fun details to work with. Do you discard the wings when you suddenly find yourself underwater, or do you seal off those engines and open up the sub engines next to them, or maybe there's a whole upper stage containing wings and balloons that gets discarded. So... do you separate into sections? Seal and deal? Break off flanges? How much can you reuse? Do you deal with a crappy middle stage because you need a component from the first stage for the third stage?
Of course, this is all made more interesting by the ability of the crew to modify the vehicle (and resulting facility) with whatever you have in cargo. Maybe you go through an air portal and pop in under the sea... but instead of jettisoning the jet engines, you send a crew out to detach and stow them, and then attach turbines to that spot instead. Is your cargo bay arranged to allow that? Is the undersea condition okay for that kind of activity?
These are the thoughts I've been having. Stages.
I've also been thinking of stages in other kinds of games. For example, in a Shadowrun game, maybe you have several "stages" to your op, featuring decking, rigging, magical scouting and perimeter-establishing, crashing through the front gates in giant trucks, then breaking into the perimeter using an intrusion team so you can do a bit more decking and spirit-calling.
Instead of thinking of a Shadowrun run as a combat mission where you shoot everything, you could think about it in terms of constructing the mission out of stages. And just like with Kerbal, the stages can be built by you out of the components and tasks you think will help best with your mission.
And, like I've done, you can have complex relations between stages. Maybe the initial rigging you used to spy on the enemy and transport your heavy server farm to the location isn't simply discarded! Maybe it has a server-farm retrieval stage later on, and perhaps even supports a later stage by repurposing the spy drones. Perhaps even on the fly, as things go south.
Doesn't that sound interesting?
Well, I've done a lot of testing and some prototyping and I've come up with some interesting discoveries about the concept that maybe you'd like to listen to. Well, I hope so, since that's the rest of this essay.
The first thing I tried was a simple "cargo bay" system. So you could design a vehicle and land it somewhere, at which point you would simply build a base out of the components you brought with you. Concrete, inflatable habs, prefab rooms, solar panels, just stick 'em together however you want.
In terms of resource constraints, it's actually pretty interesting. But in terms of the vehicular gameplay, it's actually really dull, because there's no interaction between the later stages and the earlier stages. You're literally just shipping a box full of stuff. If you want a different kind of base, you just ship a box that has different stuff in it... but the vehicle doesn't care. It's just a box.
Moreover, if you are going for deeply nested stages (3+ stages), you end up with a string of boxes, and you use each box to build a transport section for the next box... and again, nobody cares whats in the box for the next stage. No interaction.
I was thinking about ways to make the stages more interesting. There are, as far as I can tell, two ways to make the stages more interactive. One: make the components required by the next stage affect this stage. Two: recycle components used by this stage for the next stage.
For example, let's say you're building a space station. Instead of discarding the final rocket stage, why not use it? Send some crew in to scrub it down and weld in some room partitions and, viola, you have a nice, spacious science module! Yes, unrealistic, but we're talking about how to make stages more interesting.
In the other direction: you can't simply assemble a moon base out of component buildings, because they all need to be connected to the same framework of power, life support, and walkable tunnels. So you pack in all the inflatable habs and solar panels you want to use, yeah, but you also have to take a massive "+" shaped framework along. How do you make it work out? Maybe you make it fold into a kind of stool-shaped shape and attach rockets to the "legs". When it comes time to deorbit and land on the moon, you unkink those legs and land politely in the proper formation. Then you can attach the habs and solar panels and stuff to it. Maybe some work is needed on the joints to make it all properly connect up after all that folding and unfolding.
And, hey, yeah, you ditched that deorbit rocket on the way down, but it's good metal that you could use. Go out and find where it landed, drag it back to base. You can always use another large, heavyweight building, even if it requires weeks of astronaut-labor to clean it up and put in doors and stuff.
Basically, my thought is that it's really difficult to create strong, complex structures off-planet. So while a lot of the stuff you'll want to use is basically just packed up in a box and shipped around, the big core elements that hold the stage together need to be carted around more or less intact, aside from some minimal joints and reassembly requirements.
The joy of this approach lies in the N-stage situation, rather than the 2-stage situation.
Right now, we're talking rockets. Let's switch over to a different kind of game world.
This game world is on the sea, and the primary objective is to populate the various islands and set up subaquatic bases. So our major means of transport are submarines, ships, and aircraft. To push for as many medium changes as possible, there are teleport rings hidden in various places at the bottom of the ocean. When you go through, you appear in the air very far away. Of course, you can also go into the airside teleport ring and come out at the bottom of the ocean.
As such, we'll spend a lot of the early game just using ships and populating islands, with light aircraft for scouting. But as we get further along, we start to need to transition. A ship that carries a submarine. A submarine that carries a plane. A plane that carries a ship. Well, maybe not a plane, but an air-lift vehicle of some variety.
Each stage is disposable, but there's a lot of overlap. Unlike a rocket, fuel is not an overwhelming primary resource. Certainly fuel is important, but the medium switch is the primary mechanic here, and therefore the concern is all the pieces you needed to make the old vehicle work are now working against you in the new vehicle. That big hull you used to offset water and carry a heavy load is now either annoyingly heavy (for lifting into the sky) or continues to displace water annoyingly (when attempting to sink). The jet engines you flew with are now submersed, and a massive drag...
So there would be a lot of fun details to work with. Do you discard the wings when you suddenly find yourself underwater, or do you seal off those engines and open up the sub engines next to them, or maybe there's a whole upper stage containing wings and balloons that gets discarded. So... do you separate into sections? Seal and deal? Break off flanges? How much can you reuse? Do you deal with a crappy middle stage because you need a component from the first stage for the third stage?
Of course, this is all made more interesting by the ability of the crew to modify the vehicle (and resulting facility) with whatever you have in cargo. Maybe you go through an air portal and pop in under the sea... but instead of jettisoning the jet engines, you send a crew out to detach and stow them, and then attach turbines to that spot instead. Is your cargo bay arranged to allow that? Is the undersea condition okay for that kind of activity?
These are the thoughts I've been having. Stages.
I've also been thinking of stages in other kinds of games. For example, in a Shadowrun game, maybe you have several "stages" to your op, featuring decking, rigging, magical scouting and perimeter-establishing, crashing through the front gates in giant trucks, then breaking into the perimeter using an intrusion team so you can do a bit more decking and spirit-calling.
Instead of thinking of a Shadowrun run as a combat mission where you shoot everything, you could think about it in terms of constructing the mission out of stages. And just like with Kerbal, the stages can be built by you out of the components and tasks you think will help best with your mission.
And, like I've done, you can have complex relations between stages. Maybe the initial rigging you used to spy on the enemy and transport your heavy server farm to the location isn't simply discarded! Maybe it has a server-farm retrieval stage later on, and perhaps even supports a later stage by repurposing the spy drones. Perhaps even on the fly, as things go south.
Doesn't that sound interesting?
Saturday, July 27, 2013
Crossover RPGs
So, I was playing "Project X Zone", which is Capcom's massive crossover strategy RPG.
It's really weird to see a strategy RPG that's based around crossovers - it doesn't really work as well as a tournament fighter like Street Fighter vs Everything for two big reasons.
The first is that the plot has to be excessively contrived and convoluted to bring everyone together. It's like "oh, look, the first four hours of the game are every character just randomly happening to gather in the same places!" In a tournament fighter, there's no need for that. Not only do you not have to bother to explain, even if you choose to, you only have to explain a few people coming together, not dozens.
The other big problem is drowning. Project X Zone is a strategy RPG with dozens of units. So many units that I am literally unable to keep track of them all. The worst part is? Those units aren't characters. They're pairs or triplets of characters.
Drowning...
Of course, I recognize most of the characters. But even though I recognize the characters, there's no feeling of connection to them because they play such a teeny tiny role due to the sheer number of them, and because they all have more or less identical capabilities. Well, aside from their out-of-combat abilities, which can be used from anywhere to anywhere, so it doesn't matter where they are or who they are fighting.
That isn't to say the game is boring. Sure, the plot is stupid and the cut scenes are bogged down by the requirement to allow dozens of characters to get a line in. Sure, all the units only differ by having a small amount of range difference or getting their advanced techniques one or two levels earlier or later... but it's actually a pretty interesting game when you get past the incredibly dull, easy first four hours.
However, when it comes to crossover RPGs, I really think these sorts of things have it backwards. Why try to include every character in a balanced way? It just annoys people who want to care about specific characters only to find you keep intruding with some other ones.
For example, I can't stand the one-strap rich girl from this game. She's one of the characters I don't know, but she's the centerpiece of the game. She's got the hoopty powers and the villains are after her, specifically. Everyone else is basically just along for the ride. She's not really an interesting character, either, so I have a hard time even caring about her in the slightest. Just let me team up Chun Li with Dante and cut my way through everything with them.
Yeah. Instead of limiting me and forcing me to accept all the characters, why not do it like a fighter? Let me choose who I want my main character to be. Then take me through a bunch of stock encounters which are only different by what my character mumbles at the beginning and end. Just like a fighter.
Except, unlike a fighter, I don't fight everyone in every encounter. Instead, I gain and/or lose party members and take on a battle map.
Lower the amount of time the game takes - maybe it only takes 3 hours to get through a character's "story". So what? It's very replayable. Now that I've gone through as Megaman, I'll try again as Jill. Maybe on a harder setting.
Why poison the game by cramming everything into one session? Just let it be sleek and fast. Give it replayability so that I may revel in each character in turn.
...
This is only recommended for big crossover games, though. If your characters are all new to me, I won't have any real preferences and should probably be taken through a more rigidly defined story so I can be introduced to them and made to care.
It's really weird to see a strategy RPG that's based around crossovers - it doesn't really work as well as a tournament fighter like Street Fighter vs Everything for two big reasons.
The first is that the plot has to be excessively contrived and convoluted to bring everyone together. It's like "oh, look, the first four hours of the game are every character just randomly happening to gather in the same places!" In a tournament fighter, there's no need for that. Not only do you not have to bother to explain, even if you choose to, you only have to explain a few people coming together, not dozens.
The other big problem is drowning. Project X Zone is a strategy RPG with dozens of units. So many units that I am literally unable to keep track of them all. The worst part is? Those units aren't characters. They're pairs or triplets of characters.
Drowning...
Of course, I recognize most of the characters. But even though I recognize the characters, there's no feeling of connection to them because they play such a teeny tiny role due to the sheer number of them, and because they all have more or less identical capabilities. Well, aside from their out-of-combat abilities, which can be used from anywhere to anywhere, so it doesn't matter where they are or who they are fighting.
That isn't to say the game is boring. Sure, the plot is stupid and the cut scenes are bogged down by the requirement to allow dozens of characters to get a line in. Sure, all the units only differ by having a small amount of range difference or getting their advanced techniques one or two levels earlier or later... but it's actually a pretty interesting game when you get past the incredibly dull, easy first four hours.
However, when it comes to crossover RPGs, I really think these sorts of things have it backwards. Why try to include every character in a balanced way? It just annoys people who want to care about specific characters only to find you keep intruding with some other ones.
For example, I can't stand the one-strap rich girl from this game. She's one of the characters I don't know, but she's the centerpiece of the game. She's got the hoopty powers and the villains are after her, specifically. Everyone else is basically just along for the ride. She's not really an interesting character, either, so I have a hard time even caring about her in the slightest. Just let me team up Chun Li with Dante and cut my way through everything with them.
Yeah. Instead of limiting me and forcing me to accept all the characters, why not do it like a fighter? Let me choose who I want my main character to be. Then take me through a bunch of stock encounters which are only different by what my character mumbles at the beginning and end. Just like a fighter.
Except, unlike a fighter, I don't fight everyone in every encounter. Instead, I gain and/or lose party members and take on a battle map.
Lower the amount of time the game takes - maybe it only takes 3 hours to get through a character's "story". So what? It's very replayable. Now that I've gone through as Megaman, I'll try again as Jill. Maybe on a harder setting.
Why poison the game by cramming everything into one session? Just let it be sleek and fast. Give it replayability so that I may revel in each character in turn.
...
This is only recommended for big crossover games, though. If your characters are all new to me, I won't have any real preferences and should probably be taken through a more rigidly defined story so I can be introduced to them and made to care.
Tuesday, July 23, 2013
Economy-Based Games and Phased Constructions
A while back I bought and played Anno 2070. It's a few years old, so my little mini-review prelude might not be anything new to people, but I have to describe the game in order to set up the design questions later on.
The reason I waited a few weeks before posting this is that Anno 2070 is an Ubisoft game, with the requisite almost supernatural amount of bullshit that causes.
Anyway, as you might be able to guess, that left me mad enough that I couldn't trust myself to talk about the actual game behind the multiple layers of total corporate bullshit. Now that a few weeks have passed and I'm just annoyed by them destroying their own product instead of actually angry at being forced to try to deal with it, let's talk about the game.
The game is one of those economic base construction games that can't decide whether it wants to be SimCity or Starcraft. The end result is a game that is as slow as SimCity, but requires you to build up a military. It has a pacing similar to Master of Orion, and is more similar to those kinds of 4x games than something like Starcraft, despite ostensibly being an RTS. Of course, instead of the complexity of the tech tree and unit customization in a 4x game, Anno 2070 focuses a lot more on the topological challenges of constructing a base.
The base building features a lot of balance sheet actions. That is, there's a lot of different kinds of resources and it's quite difficult to optimize. In a normal RTS the base construction is basically a matter of choosing how you want to balance economy with various military capabilities. Because that's the core, the base itself does not require very much internal balancing. However, in Anno 2070 virtually every building requires an assortment of resources, including a continuous drain on up to five different kinds of "food" for the residential buildings. This makes production and consumption a core part of Anno 2070's gameplay, and in some cases it can be quite complex to produce the variety of goods you need to support your economy.
This is made more complex by Anno 2070's zoning system. First, most of the non-residential buildings in the game have an area of influence. So whenever you put a building down, you are trying to figure out the optimal arrangement so that the good areas of influence overlap well and the bad areas of influence don't have too much of an effect. But even above that, each island is a completely distinct colony, like a new planet in a 4x game. Since each island has specific resources (including the ability to grow specific foodstuffs) trade between the islands is critical to keeping your complex economy running. I'm sure that this is a fun part of the high-level combat play - trying to cut supply lines - but I stopped playing before I reached anything like that level of play.
There's also underwater bases: Anno 2070 splits everything into above the sea and below with a camera motion that involves a fun splash and a visual spray like water on a camera. It's very charming, and to be honest I could fall in love with this game if it were more focused on that kind of experience.
To me, the problem with Anno 2070 is simply that the primary play of the game seems to be "how many pieces can you juggle at once?"
I don't really feel anything compelling about trying to juggle what are fundamentally twelve identical farming systems just because I need twelve slightly different arbitrary foodstuffs. It is very repetitive. Each tier I advance simply unlocks another tier of identical infrastructure requirements using somewhat different buildings. "Oh, but THESE farms require GLASS to build!" Psh, who cares. In fact, why should I have to build glass? It's perfectly affordable on the market, just let me buy it. In fact, just let me buy the wheat I need the glass for. That's what humans do: one colony, just for wheat. There's no reason I can't, except that you've artificially made it difficult to buy and sell things in order to make that yet another layer of more or less identical pieces to juggle.
In terms of a skill game, I'm sure Anno 2070 actually has a high skill level you can attain. The ability to quickly and accurately build and balance the many layers of production and consumption is something you'd definitely get better at over time, but I can't say it's something I'm very interested in actually doing.
Worse, the game has combat in it.
WHY.
Why would you need combat in a game where the primary challenge is just getting your bases to function in the first place? That'd be like putting combat in Kerbal Space Program.
I guess I can see it as a requirement. RTS games - even these long-form RTS games - always feature combat. But it's boring, and it's a big drag on the economy.
Well, now that the review is out of the way, let's talk about the game I was kind of hoping it would evolve into, until it devolved into a long-form RTS.
When I learned that Anno 2070 treated individual islands and underwater plateaus as distinct colonies with their own distinct economies, I thought I was getting into an interesting "rise of civilization" game, where the challenge would be to try and get the various colonies optimized and specialized to the point where you could support the next level of civilization. Sort of like SimCity, except where you control all the cities at once. And I thought "Wow, this could be really interesting!"
You can try to play it that way, and to an extent it works out, but there's an overwhelming, looming issue: the goal of the game is to win, not to achieve. And that means that, in the end, it comes down to murdering people with a boring, expensive navy.
Now, when I jumped into Anno 2070, I'd just finished playing an obscene amount of Kerbal Space Program, so I probably came in with the wrong mindset. But my mindset, right or wrong, was "I want to build a society and watch it tick!" Just like how in Kerbal, you build a rocket and then fly it through space on whatever mission you've come up with today, I wanted to create a society to achieve whatever goal I came up with today.
But there were no goals to come up with. The goal was provided: win. If you were playing an early mission map, winning was often a delicious rush towards building a strong enough society to research or fix or produce or whatever. But if you're playing an open map or a later mission map, the objective is to just dominate the map. As if there could ever be a more boring goal.
So I was thinking: how could you build a game where it's an open-goal situation similar to Kerbal, but with the more complex build-to-build construction system of a SimCitylike?
A huge part of Kerbal's joy lies in the construction. You need to create a multi-phase solution which holds together during all phases AND transitions between phases safely. Of course, you also need to have the final phase accomplish whatever you were trying to accomplish. Fundamentally, this system is a front-loaded one, where you build everything ahead of time and then go into execution mode to see how it performs... except you also control it in execution mode. It's very addictive, and if any of the end goals in Kerbal were constructive, I'd still be playing it.
Alas, the end goals in Kerbal are all pretty shallow. There's a massive rush of interest when you first get started. Land on the Mun, build a space station, send a probe to the outer planets, build a working spaceplane... lots of really interesting goals dictated by the existence of things in the universe. You want to land on the Mun because the Mun is there and you can land on it. But once you get to the Mun, you can't build on that much. There are few if any second-tier goals. In theory, refueling from a space station might be a good second-tier goal, but that's the only one I can think of and it's annoying.
You can't scan the moon, can't build a rocket factory on Mars, can't create a functional space station that performs science experiments in real time.
In other words, the initial construction-execution system is very nice, but what is missing from Kerbal is the "rise of civilization" base building. I can't build on my successes, nor can my successes provide me with much long-term benefit.
But that's one thing that Anno 2070 does quite well, compartmentalizing pieces of the economy and allowing you to construct a fairly complicated growing civilization piece by piece.
So I started thinking: what if you combined the two concepts?
You start off by creating a universe with stuff in it. Reaching the stuff is not terribly easy, and depending on which stuff you aim for with how much payload, can have very different kinds of requirements. You make the stuff seem interesting, and allow it to be seen and prodded by the player by using the normal exploration camera - but only reachable by game objects if they go through the difficult process of reaching it.
But unlike Kerbal, you also need to make it so that facilities can be built on or around this stuff. Facilities which can A) produce goods, B) participate in trade routes of some kind with nearby facilities, and C) be expanded by sending over more stuff from a construction facility (or home). Some facilities might just take pictures and radio them home. Others might mine the core of the planet with huge drills and ship out tons of ore. And others might just do research.
Ideally, each of the "stuffs" that you might want to reach should be unique in some way, so that the facilities will have different difficulties and purposes, and so that every "stuff" creates something unique that the overall interstuff economy could benefit from (more rocket parts, to be blunt).
Now let's get to concrete concepts.
I like the idea of multiple mediums, so the facilities have radically different performance characteristics and requirements. For example, undersea bases, orbital bases, surface bases without atmosphere, surface bases with atmosphere, floating bases (in atmosphere), and so on.
A variety of mediums makes it more interesting to set up a facility, with each kind of medium requiring not just different facility components, but also a different late stage system to deposit the facility. Moreover, each kind of medium is not universal - an undersea base on one planet will have a very different "sea" than an undersea base on another planet. Similarly, an orbital facility around Mercury is going to get very different solar panel performance than one orbiting Neptune. An atmosphere raining liquid methane is going to have verrrrry different requirements than a Utah desert.
This variety should keep things interesting as players move on to try a new goal and find that the requirements are very different.
As to the launching system, one of the annoying parts of Kerbal is that there are some secrets and best practices that make the launch a bit disappointing. Any launch can be converted into a mere fuel-weight optimization using lots of structural beams and fuel lines, since fuel lines allow you to pump fuel so as to empty out specific disposable fuselages first, while structural beams allow you to make any crazy-ass labyrinth of disposable fuselages structurally sound.
I think it might be best to carefully consider how you make your stages interesting. In Kerbal you learn a lot about different kinds of stages, and about mass, and about maneuvering in atmosphere, orbit, or deep orbital exchanges. But in the end, there is generally an extremely clear optimal rocket design, and you just stick the right weight rocket on your payload and out it goes. This is actually pretty realistic, but it's only interesting for a little while, and then you figure out the secrets and it becomes just a bit of a time waste as you build nearly identical rocket after rocket and have them follow nearly identical flight plans.
Ideally, for the purposes of gameplay, we'd want the stages to be unique enough that there are tradeoffs to be considered at every step.
A big part of this is allowing for launches from facilities other than your starting base. A rocket launching from a space station has very different requirements than one launching from the moon. Not only is the amount of lift required much smaller, but also the kind off arrangements you can use is limited when launching from space, because you can't afford to push the space station around or damage it. Similarly, not everything actually requires a classic rocket. If we could arrange for other kinds of transports to be viable - balloons, planes, railguns - we could radically expand the play space.
I think the core here is the transition between stages. In Kerbal, the stage transition is rocket-centric: you blow off some fuselages. That's fine for rockets, but as you might understand that's not ideal for our purposes. Not only do we need the separation events to be more complex, we also need the stages to be polymorphic in themselves. One of the craziest parts of Kerbal is that you just literally strap your finished product to the nose of the rocket. Obviously, that's crazy!
It's far better to create something like a container that opens up.
This leads to a lot of complexity, especially if you make mechanical operations robust and cheap, and allow for expansions by way of semipermanent docking, welding, and other kinds of fusing. Imagine launching a rocket, then dropping the rocket, then unfolding the "egg" payload into a magnetic solar sail...
As you get further from buffeting forces, your structures can be made more delicate. Tweaked appropriately, you could certainly end up with a mission that actually gets larger with each consecutive stage. Larger, but far less massive. You could even design a system where most of the stages were, in fact, functional facilities launching other functional facilities...
These are the tenets I think I would love to see in a game. It doesn't have to be based around space travel, though. You could create the same kinds of concepts in any kind of scenario, although sometimes it would feel a bit odd because the idea revolves around designing stages and then executing them.
Actually, given how much I liked the above/below sea part of Anno 2070, it might be fun to create such a game entirely about building underwater, island, and floating bases.
Those are my thoughts!
...
ARGH I forgot the multiplayer part.
Well, that'd be this long again, so let's leave it like that.
The reason I waited a few weeks before posting this is that Anno 2070 is an Ubisoft game, with the requisite almost supernatural amount of bullshit that causes.
Anyway, as you might be able to guess, that left me mad enough that I couldn't trust myself to talk about the actual game behind the multiple layers of total corporate bullshit. Now that a few weeks have passed and I'm just annoyed by them destroying their own product instead of actually angry at being forced to try to deal with it, let's talk about the game.
The game is one of those economic base construction games that can't decide whether it wants to be SimCity or Starcraft. The end result is a game that is as slow as SimCity, but requires you to build up a military. It has a pacing similar to Master of Orion, and is more similar to those kinds of 4x games than something like Starcraft, despite ostensibly being an RTS. Of course, instead of the complexity of the tech tree and unit customization in a 4x game, Anno 2070 focuses a lot more on the topological challenges of constructing a base.
The base building features a lot of balance sheet actions. That is, there's a lot of different kinds of resources and it's quite difficult to optimize. In a normal RTS the base construction is basically a matter of choosing how you want to balance economy with various military capabilities. Because that's the core, the base itself does not require very much internal balancing. However, in Anno 2070 virtually every building requires an assortment of resources, including a continuous drain on up to five different kinds of "food" for the residential buildings. This makes production and consumption a core part of Anno 2070's gameplay, and in some cases it can be quite complex to produce the variety of goods you need to support your economy.
This is made more complex by Anno 2070's zoning system. First, most of the non-residential buildings in the game have an area of influence. So whenever you put a building down, you are trying to figure out the optimal arrangement so that the good areas of influence overlap well and the bad areas of influence don't have too much of an effect. But even above that, each island is a completely distinct colony, like a new planet in a 4x game. Since each island has specific resources (including the ability to grow specific foodstuffs) trade between the islands is critical to keeping your complex economy running. I'm sure that this is a fun part of the high-level combat play - trying to cut supply lines - but I stopped playing before I reached anything like that level of play.
There's also underwater bases: Anno 2070 splits everything into above the sea and below with a camera motion that involves a fun splash and a visual spray like water on a camera. It's very charming, and to be honest I could fall in love with this game if it were more focused on that kind of experience.
To me, the problem with Anno 2070 is simply that the primary play of the game seems to be "how many pieces can you juggle at once?"
I don't really feel anything compelling about trying to juggle what are fundamentally twelve identical farming systems just because I need twelve slightly different arbitrary foodstuffs. It is very repetitive. Each tier I advance simply unlocks another tier of identical infrastructure requirements using somewhat different buildings. "Oh, but THESE farms require GLASS to build!" Psh, who cares. In fact, why should I have to build glass? It's perfectly affordable on the market, just let me buy it. In fact, just let me buy the wheat I need the glass for. That's what humans do: one colony, just for wheat. There's no reason I can't, except that you've artificially made it difficult to buy and sell things in order to make that yet another layer of more or less identical pieces to juggle.
In terms of a skill game, I'm sure Anno 2070 actually has a high skill level you can attain. The ability to quickly and accurately build and balance the many layers of production and consumption is something you'd definitely get better at over time, but I can't say it's something I'm very interested in actually doing.
Worse, the game has combat in it.
WHY.
Why would you need combat in a game where the primary challenge is just getting your bases to function in the first place? That'd be like putting combat in Kerbal Space Program.
I guess I can see it as a requirement. RTS games - even these long-form RTS games - always feature combat. But it's boring, and it's a big drag on the economy.
Well, now that the review is out of the way, let's talk about the game I was kind of hoping it would evolve into, until it devolved into a long-form RTS.
When I learned that Anno 2070 treated individual islands and underwater plateaus as distinct colonies with their own distinct economies, I thought I was getting into an interesting "rise of civilization" game, where the challenge would be to try and get the various colonies optimized and specialized to the point where you could support the next level of civilization. Sort of like SimCity, except where you control all the cities at once. And I thought "Wow, this could be really interesting!"
You can try to play it that way, and to an extent it works out, but there's an overwhelming, looming issue: the goal of the game is to win, not to achieve. And that means that, in the end, it comes down to murdering people with a boring, expensive navy.
Now, when I jumped into Anno 2070, I'd just finished playing an obscene amount of Kerbal Space Program, so I probably came in with the wrong mindset. But my mindset, right or wrong, was "I want to build a society and watch it tick!" Just like how in Kerbal, you build a rocket and then fly it through space on whatever mission you've come up with today, I wanted to create a society to achieve whatever goal I came up with today.
But there were no goals to come up with. The goal was provided: win. If you were playing an early mission map, winning was often a delicious rush towards building a strong enough society to research or fix or produce or whatever. But if you're playing an open map or a later mission map, the objective is to just dominate the map. As if there could ever be a more boring goal.
So I was thinking: how could you build a game where it's an open-goal situation similar to Kerbal, but with the more complex build-to-build construction system of a SimCitylike?
A huge part of Kerbal's joy lies in the construction. You need to create a multi-phase solution which holds together during all phases AND transitions between phases safely. Of course, you also need to have the final phase accomplish whatever you were trying to accomplish. Fundamentally, this system is a front-loaded one, where you build everything ahead of time and then go into execution mode to see how it performs... except you also control it in execution mode. It's very addictive, and if any of the end goals in Kerbal were constructive, I'd still be playing it.
Alas, the end goals in Kerbal are all pretty shallow. There's a massive rush of interest when you first get started. Land on the Mun, build a space station, send a probe to the outer planets, build a working spaceplane... lots of really interesting goals dictated by the existence of things in the universe. You want to land on the Mun because the Mun is there and you can land on it. But once you get to the Mun, you can't build on that much. There are few if any second-tier goals. In theory, refueling from a space station might be a good second-tier goal, but that's the only one I can think of and it's annoying.
You can't scan the moon, can't build a rocket factory on Mars, can't create a functional space station that performs science experiments in real time.
In other words, the initial construction-execution system is very nice, but what is missing from Kerbal is the "rise of civilization" base building. I can't build on my successes, nor can my successes provide me with much long-term benefit.
But that's one thing that Anno 2070 does quite well, compartmentalizing pieces of the economy and allowing you to construct a fairly complicated growing civilization piece by piece.
So I started thinking: what if you combined the two concepts?
You start off by creating a universe with stuff in it. Reaching the stuff is not terribly easy, and depending on which stuff you aim for with how much payload, can have very different kinds of requirements. You make the stuff seem interesting, and allow it to be seen and prodded by the player by using the normal exploration camera - but only reachable by game objects if they go through the difficult process of reaching it.
But unlike Kerbal, you also need to make it so that facilities can be built on or around this stuff. Facilities which can A) produce goods, B) participate in trade routes of some kind with nearby facilities, and C) be expanded by sending over more stuff from a construction facility (or home). Some facilities might just take pictures and radio them home. Others might mine the core of the planet with huge drills and ship out tons of ore. And others might just do research.
Ideally, each of the "stuffs" that you might want to reach should be unique in some way, so that the facilities will have different difficulties and purposes, and so that every "stuff" creates something unique that the overall interstuff economy could benefit from (more rocket parts, to be blunt).
Now let's get to concrete concepts.
I like the idea of multiple mediums, so the facilities have radically different performance characteristics and requirements. For example, undersea bases, orbital bases, surface bases without atmosphere, surface bases with atmosphere, floating bases (in atmosphere), and so on.
A variety of mediums makes it more interesting to set up a facility, with each kind of medium requiring not just different facility components, but also a different late stage system to deposit the facility. Moreover, each kind of medium is not universal - an undersea base on one planet will have a very different "sea" than an undersea base on another planet. Similarly, an orbital facility around Mercury is going to get very different solar panel performance than one orbiting Neptune. An atmosphere raining liquid methane is going to have verrrrry different requirements than a Utah desert.
This variety should keep things interesting as players move on to try a new goal and find that the requirements are very different.
As to the launching system, one of the annoying parts of Kerbal is that there are some secrets and best practices that make the launch a bit disappointing. Any launch can be converted into a mere fuel-weight optimization using lots of structural beams and fuel lines, since fuel lines allow you to pump fuel so as to empty out specific disposable fuselages first, while structural beams allow you to make any crazy-ass labyrinth of disposable fuselages structurally sound.
I think it might be best to carefully consider how you make your stages interesting. In Kerbal you learn a lot about different kinds of stages, and about mass, and about maneuvering in atmosphere, orbit, or deep orbital exchanges. But in the end, there is generally an extremely clear optimal rocket design, and you just stick the right weight rocket on your payload and out it goes. This is actually pretty realistic, but it's only interesting for a little while, and then you figure out the secrets and it becomes just a bit of a time waste as you build nearly identical rocket after rocket and have them follow nearly identical flight plans.
Ideally, for the purposes of gameplay, we'd want the stages to be unique enough that there are tradeoffs to be considered at every step.
A big part of this is allowing for launches from facilities other than your starting base. A rocket launching from a space station has very different requirements than one launching from the moon. Not only is the amount of lift required much smaller, but also the kind off arrangements you can use is limited when launching from space, because you can't afford to push the space station around or damage it. Similarly, not everything actually requires a classic rocket. If we could arrange for other kinds of transports to be viable - balloons, planes, railguns - we could radically expand the play space.
I think the core here is the transition between stages. In Kerbal, the stage transition is rocket-centric: you blow off some fuselages. That's fine for rockets, but as you might understand that's not ideal for our purposes. Not only do we need the separation events to be more complex, we also need the stages to be polymorphic in themselves. One of the craziest parts of Kerbal is that you just literally strap your finished product to the nose of the rocket. Obviously, that's crazy!
It's far better to create something like a container that opens up.
This leads to a lot of complexity, especially if you make mechanical operations robust and cheap, and allow for expansions by way of semipermanent docking, welding, and other kinds of fusing. Imagine launching a rocket, then dropping the rocket, then unfolding the "egg" payload into a magnetic solar sail...
As you get further from buffeting forces, your structures can be made more delicate. Tweaked appropriately, you could certainly end up with a mission that actually gets larger with each consecutive stage. Larger, but far less massive. You could even design a system where most of the stages were, in fact, functional facilities launching other functional facilities...
These are the tenets I think I would love to see in a game. It doesn't have to be based around space travel, though. You could create the same kinds of concepts in any kind of scenario, although sometimes it would feel a bit odd because the idea revolves around designing stages and then executing them.
Actually, given how much I liked the above/below sea part of Anno 2070, it might be fun to create such a game entirely about building underwater, island, and floating bases.
Those are my thoughts!
...
ARGH I forgot the multiplayer part.
Well, that'd be this long again, so let's leave it like that.
Monday, July 22, 2013
Culture in a Cup
I've started thinking about culture - the kinds of norms and judgments and responses that a society builds. To a large extent, the culture of a society dictates a lot more or the society's behavior and growth patterns than the technological or economic state of the society. Of course, the culture is strongly influenced by technology and economy...
I was thinking about whether you could use this in a game. Instead of building your game around technological research and building new buildings and shooting at people, could you replace those systems with one where you define and alter the culture of your people? Could you make a game where the people act largely autonomously, but guided by the culture you have crafted? Furthermore, as the situation changes... would you buckle under the pressure of the culture you initially created, as you struggle to make it suitable for the new situation?
Let's say that the game is sort of a fantastical game - not a fantasy game in that there are orcs and dragons and things, but more of a dreamlike game. You create a little village full of, I dunno, elves or something. And then you guide their culture so that their growth and interactions with other tribes goes vaguely well.
I think a big part of the game would have to be in factionalizing. That is, breaking the population down into subsets.
You can make a cultural rule "do not kill", but that's a pretty strong restriction and, in most cases, you'll probably eventually want to kill some people - invaders, bandits, sheep, whatever. So the answer is to create a subset of people who are allowed to kill, and then control the culture such that the murderous subset only comes into play in specific situations, and maybe even include some "clean up" rules to prevent weakening of the overall "do not kill" norm. IE, "police can kill" with an event trigger of "if a police officer kills someone, they are no longer a police officer", which would relegate them to the general population and prevent the police subgroup from developing serial murdering as a common trait.
By creating a lot of different groups and gating which groups can funnel into which groups at what times, you can create a societal "machine" with rules that automatically regulate its behavior. The machine reacts to pressures both internal and external and the society flows along the path that carves. Of course, this machine is not made of unbending metal - particular groups will gain or lose traits, corruption, and/or authority as the machine moves along. Understanding how this tarnish builds up will allow you to build a society which lasts longer.
Because, inevitably, the society will fall apart. The core rules you build cannot be simply peeled away - it takes a huge amount of effort to change a rule, once made. All you can do is add more rules. Patches. Eventually, the society will not be capable of reacting to the stresses it was originally created to react to.
Of course, the fun lies in the route between here and there. Not only is there a lot of choice as to what sort of society you want to set up, the stresses are going to be radically different depending on the environment you live in, the number and aggressiveness of your neighbors, and so on. If you want to set up a tiny hippie community on a tropical beach that never grows one iota, there's no judgment from the game that says its a bad idea. A small, unchanging community might be a good idea, actually, because it'll have fewer internal stresses. Of course, small communities tend to get ripped apart by external stresses, so if you plan to do that, somewhere forgiving and isolated would be the best bet.
Or you can build a society where you try to conquer the world. Or create technological marvels. Or maybe you want to try for specific ethical situations - build a matriarchy, or a Logan's Run "kill the adults" situation, or explore whether a democracy can work before the invention of writing. Or build a new village with fresh cultural rules in the ruins of your old, self-destructed empire...
I think this sounds very interesting, and I'm going to think about it some more.
I was thinking about whether you could use this in a game. Instead of building your game around technological research and building new buildings and shooting at people, could you replace those systems with one where you define and alter the culture of your people? Could you make a game where the people act largely autonomously, but guided by the culture you have crafted? Furthermore, as the situation changes... would you buckle under the pressure of the culture you initially created, as you struggle to make it suitable for the new situation?
Let's say that the game is sort of a fantastical game - not a fantasy game in that there are orcs and dragons and things, but more of a dreamlike game. You create a little village full of, I dunno, elves or something. And then you guide their culture so that their growth and interactions with other tribes goes vaguely well.
I think a big part of the game would have to be in factionalizing. That is, breaking the population down into subsets.
You can make a cultural rule "do not kill", but that's a pretty strong restriction and, in most cases, you'll probably eventually want to kill some people - invaders, bandits, sheep, whatever. So the answer is to create a subset of people who are allowed to kill, and then control the culture such that the murderous subset only comes into play in specific situations, and maybe even include some "clean up" rules to prevent weakening of the overall "do not kill" norm. IE, "police can kill" with an event trigger of "if a police officer kills someone, they are no longer a police officer", which would relegate them to the general population and prevent the police subgroup from developing serial murdering as a common trait.
By creating a lot of different groups and gating which groups can funnel into which groups at what times, you can create a societal "machine" with rules that automatically regulate its behavior. The machine reacts to pressures both internal and external and the society flows along the path that carves. Of course, this machine is not made of unbending metal - particular groups will gain or lose traits, corruption, and/or authority as the machine moves along. Understanding how this tarnish builds up will allow you to build a society which lasts longer.
Because, inevitably, the society will fall apart. The core rules you build cannot be simply peeled away - it takes a huge amount of effort to change a rule, once made. All you can do is add more rules. Patches. Eventually, the society will not be capable of reacting to the stresses it was originally created to react to.
Of course, the fun lies in the route between here and there. Not only is there a lot of choice as to what sort of society you want to set up, the stresses are going to be radically different depending on the environment you live in, the number and aggressiveness of your neighbors, and so on. If you want to set up a tiny hippie community on a tropical beach that never grows one iota, there's no judgment from the game that says its a bad idea. A small, unchanging community might be a good idea, actually, because it'll have fewer internal stresses. Of course, small communities tend to get ripped apart by external stresses, so if you plan to do that, somewhere forgiving and isolated would be the best bet.
Or you can build a society where you try to conquer the world. Or create technological marvels. Or maybe you want to try for specific ethical situations - build a matriarchy, or a Logan's Run "kill the adults" situation, or explore whether a democracy can work before the invention of writing. Or build a new village with fresh cultural rules in the ruins of your old, self-destructed empire...
I think this sounds very interesting, and I'm going to think about it some more.
Thursday, July 18, 2013
Customizing Starships
As some of you might know, I'm sort of doing a space battle prototype thing. One of the keys to any space-ship-related game is allowing the player to customize their starship.
The vast majority of starship customization options are treated the same as fantasy character equipment. Slot in various pieces of gear into various positions. The only real difference is that instead of having two hands, you have a certain number of weapon hardpoints or whatever. But, fundamentally, it's a matter of slotting in equipment. Many games actually allow you to do this pretty much instantly, in deep space. Because as anyone will tell you, completely changing out your computer core while flying in deep space is a straightforward and easy process.
Putting that aside, I started to think about other pieces of this puzzle.
In my game, the ship is quite customizable in terms of how you use things in battle - throwing energy around, using NPC commander abilities, and so on. Changing out the equipment as well seems overly complex and I rather like the idea that you pretty much know what weapons and shields any given class of ship will have. It lessons the need to have players click on enemy ships and try to read their blueprints - instead, you can easily see precisely the array of enemies you're up against. Of course, most starship games do that as well - only the PC ship can be customized. Nobody else bothers to customize their ship. Another way to stretch my suspension of disbelief.
So I was thinking about other kinds of customization that don't involve completely changing the ship loadout.
One is rebalancing or modifying the ship systems. While you wouldn't switch out your phaser bank for a missile bay, you could modify your phaser bank to be more powerful at the cost of weakening your available impulse drive, or you could change the phase pattern so it's more effective against shields but has a shorter range... these tweaks can change the parameters of your vessel and make it unique even when you're still flying the same class of ship with the same weapons and shields and such. Make the ship systems a bit stretchy instead of swappable.
Obviously, another feature is visual modification. Changing the paint job and fundamental texture of the various pieces of the ship. Even though you're both the same class of ship, your ship might look like a rusted, antennae-covered heap painted in pink and white, while someone else might have a smooth, polished chrome variant. This is quite easy to do, and is basically a given. Restrictions on available colors, patterns, and textures can unify factions such that even if they use the same ship class you can tell what faction someone is because their surface texture is notably different. Of course, you could also monetize rare textures.
More than that, the lighting on the ship can be customized. When in a game environment, the light that actually falls on your ship might not reliably illuminate the whole visible side. However, all ships have lights - sensors, observation decks, running lights, spotlights on their name, and so on. Customizing the placement, color, and layout of these lights could be fun!
The ship mesh is also quite easy to modify, and you could allow the players to stretch, squash, tilt, and dent their ship in various ways. I don't know that I'd bother, though. It seems a bit wonky to treat a ship like play-dough.
But all of these things are just visuals. There is another facet of the ship which can be customized: the audio.
Unless your whole game is going to be starship combat, there's going to be a fair amount of driving around, orbiting, idling in menus, chatting, whatever else. Only a small portion of a game - especially an MMO - is spent in direct combat. Therefore, customizing the ambient sound of your ship seems like a great idea.
Let's assume you can't wander around your ship in first person mode or anything - even so, you are still the captain of your ship. You should be able to hear your ship. Too many starship games give you the audio of the outside of your ship - typically just the gentle fwooosh of the engines. I'd like to give the players the audio inside their ship. It's even possible to give them the option to hang out in various places on their ship to get various audio ambiance. Bridge, engineering, canteen, lounge, and so on.
In general, these ambient environments have two major pieces: the background hum, and the ambient noises.
The background hum, representing the workings of the power core, engines, ventilation, and so on. This is a valuable tool for making the ship feel alive. The throb of the generators can change in timbre depending on the load, so you can hear it grind while you're at FTL, then drop to a gentle buzz when you decide to go into standing orbit. The ventilation whooshes a bit more aggressively during the day shift, due to the high population, but it is gentler during the night shift. And so on.
The ambient noises are actually easier to make, because they don't have to shift in timbre or frequency. Instead, they play somewhat randomly in somewhat random order. These would be the bleeping of consoles, whooshing of doors, footsteps, gentle conversational noises, and so on. While these do give the ship a feeling of life, I also like the idea that they are altered by the modifications you make to your ship systems. If you punch up the range on your scanners, you might get more "scanner" bloops and ambient conversation about "filtering out sensor ghosts" or whatever. Similarly, if your hull texture is festooned with crappy metal plates instead of the sleek chrome armor, you might hear creaking or a echo "buzz" after each sensor bleep.
The ability to put in voice acting is a powerful one, although also an expensive one. Ideally, even though it's just ambient conversations held in the background, only vaguely audible, you would still be able to tell which crewmember was talking and their personality.
Anyway, if you make the ship ambient noise vary widely depending on player customizations, I think it'd make the game a lot more interesting, especially when the players change ships or go onto a friend's ship.
The vast majority of starship customization options are treated the same as fantasy character equipment. Slot in various pieces of gear into various positions. The only real difference is that instead of having two hands, you have a certain number of weapon hardpoints or whatever. But, fundamentally, it's a matter of slotting in equipment. Many games actually allow you to do this pretty much instantly, in deep space. Because as anyone will tell you, completely changing out your computer core while flying in deep space is a straightforward and easy process.
Putting that aside, I started to think about other pieces of this puzzle.
In my game, the ship is quite customizable in terms of how you use things in battle - throwing energy around, using NPC commander abilities, and so on. Changing out the equipment as well seems overly complex and I rather like the idea that you pretty much know what weapons and shields any given class of ship will have. It lessons the need to have players click on enemy ships and try to read their blueprints - instead, you can easily see precisely the array of enemies you're up against. Of course, most starship games do that as well - only the PC ship can be customized. Nobody else bothers to customize their ship. Another way to stretch my suspension of disbelief.
So I was thinking about other kinds of customization that don't involve completely changing the ship loadout.
One is rebalancing or modifying the ship systems. While you wouldn't switch out your phaser bank for a missile bay, you could modify your phaser bank to be more powerful at the cost of weakening your available impulse drive, or you could change the phase pattern so it's more effective against shields but has a shorter range... these tweaks can change the parameters of your vessel and make it unique even when you're still flying the same class of ship with the same weapons and shields and such. Make the ship systems a bit stretchy instead of swappable.
Obviously, another feature is visual modification. Changing the paint job and fundamental texture of the various pieces of the ship. Even though you're both the same class of ship, your ship might look like a rusted, antennae-covered heap painted in pink and white, while someone else might have a smooth, polished chrome variant. This is quite easy to do, and is basically a given. Restrictions on available colors, patterns, and textures can unify factions such that even if they use the same ship class you can tell what faction someone is because their surface texture is notably different. Of course, you could also monetize rare textures.
More than that, the lighting on the ship can be customized. When in a game environment, the light that actually falls on your ship might not reliably illuminate the whole visible side. However, all ships have lights - sensors, observation decks, running lights, spotlights on their name, and so on. Customizing the placement, color, and layout of these lights could be fun!
The ship mesh is also quite easy to modify, and you could allow the players to stretch, squash, tilt, and dent their ship in various ways. I don't know that I'd bother, though. It seems a bit wonky to treat a ship like play-dough.
But all of these things are just visuals. There is another facet of the ship which can be customized: the audio.
Unless your whole game is going to be starship combat, there's going to be a fair amount of driving around, orbiting, idling in menus, chatting, whatever else. Only a small portion of a game - especially an MMO - is spent in direct combat. Therefore, customizing the ambient sound of your ship seems like a great idea.
Let's assume you can't wander around your ship in first person mode or anything - even so, you are still the captain of your ship. You should be able to hear your ship. Too many starship games give you the audio of the outside of your ship - typically just the gentle fwooosh of the engines. I'd like to give the players the audio inside their ship. It's even possible to give them the option to hang out in various places on their ship to get various audio ambiance. Bridge, engineering, canteen, lounge, and so on.
In general, these ambient environments have two major pieces: the background hum, and the ambient noises.
The background hum, representing the workings of the power core, engines, ventilation, and so on. This is a valuable tool for making the ship feel alive. The throb of the generators can change in timbre depending on the load, so you can hear it grind while you're at FTL, then drop to a gentle buzz when you decide to go into standing orbit. The ventilation whooshes a bit more aggressively during the day shift, due to the high population, but it is gentler during the night shift. And so on.
The ambient noises are actually easier to make, because they don't have to shift in timbre or frequency. Instead, they play somewhat randomly in somewhat random order. These would be the bleeping of consoles, whooshing of doors, footsteps, gentle conversational noises, and so on. While these do give the ship a feeling of life, I also like the idea that they are altered by the modifications you make to your ship systems. If you punch up the range on your scanners, you might get more "scanner" bloops and ambient conversation about "filtering out sensor ghosts" or whatever. Similarly, if your hull texture is festooned with crappy metal plates instead of the sleek chrome armor, you might hear creaking or a echo "buzz" after each sensor bleep.
The ability to put in voice acting is a powerful one, although also an expensive one. Ideally, even though it's just ambient conversations held in the background, only vaguely audible, you would still be able to tell which crewmember was talking and their personality.
Anyway, if you make the ship ambient noise vary widely depending on player customizations, I think it'd make the game a lot more interesting, especially when the players change ships or go onto a friend's ship.
Wednesday, July 17, 2013
Taiga Repair, Construction, and Terraforming
I was thinking about how to create a less-violent RPG. The heart of the RPG setting - the violent murder of as many locals as possible - has always been both nonsensical and lazy. So I'm always thinking about ways to make RPGs that are not about murdering locals.
The core problem is that the combat engine in an RPG is basically the "wheels" of the "car". All the exploration, leveling, gaining and losing party members, looting, attrition, buying and selling, all that stuff is all oriented around the battle system. The battle system is, in turn, built with enough statistical dependencies to allow for those other play systems to link in and affect them.
So you can replace the combat engine of an RPG, sure. But the initial impulse is to replace it with a minigame.
Minigames serve a different purpose. They are generally more skill-based than statistical, and their outcome is generally binary. Minigames are essentially gating systems, while RPG battles are essentially grinding systems. They're very different, even if at first glance they seem to have the same basic role.
The good news is that if you realize the difference, you should be able to build a replacement. So now that we've established that, let's talk about Taiga Repair, Construction, and Terraforming.
Taiga RCT is an interstellar contracting company that goes from planet to planet building and repairing things. This is a very similar theme to the idea of an adventuring party that travels from town to town. Except, instead of murdering wildlife, these adventurers repair, construct, and terraform. Imagine it's just like a classic RPG - lots of exploration, side quests, talking to people, buying and selling weapons... except that the theme is high-tech construction.
So as you wander around a subterranean base, you'd have a "random encounter" with, say, a malfunctioning door, or perhaps a clogged ventilation duct, or maybe both. Sound lame? More lame than bats and rats and slimes? Those are the equivalent enemies. Later on you'll be trying to construct giant bridges, desperately trying to get the pumping system on-line so you can prevent the undersea city from flooding before lowering the bulkheads, fighting back a crop blight while trying to increase the amount of oxygen in the air, and so on.
The combat in the game is fundamentally similar to the combat in any RPG - except that you're fixing malfunctions or constructing systems rather than killing monsters.
Every character has health, except that in this case it's self-confidence. Systems which continue to malfunction even when you're trying to fix them cause you to lose self-confidence, while repairing or constructing functional systems gives you some back. The party as a whole also has a level of confidence - the confidence the locals have that they'll be able to fix things. This allows you to gate things like advanced equipment, tiered quests, and so on based on what the locals think the party can handle.
Resolving these challenges is similar to a combat RPG as well, in that you have a "basic attack" which attempts to repair or construct, as well as more constrained techniques to buff, debuff, heal, multi-attack, and so on. However, there are a few key differences.
The first is that the enemies you face are not enemies, they are systems. But the malfunctions and missing pieces are not necessarily standalone, and they are frequently related to other malfunctions or missing pieces. You encounter a broken automatic door. It's possible for you to fix it by just brute-force attacking it, but you'll probably lose a lot of confidence, because you're essentially rebuilding the whole door from the ground up.
On the other hand, you can dig deeper and reveal that the broken automatic door is because of the broken sensor system above the door - you've added another enemy to the fray, but it's a much weaker target that will fix or severely weaken the door glitch once repaired. You can dig deeper yet, if you like, revealing that the broken sensor is because the ventilation system has bad filters, and spews dust everywhere - including on to sensors.
These can be quite complex, with several challenges linking to the same base error, or with several errors fueling a single fault, or even with circular fault chains... that can make encountering the same "enemies" still quite unique-feeling as their interconnections are always different.
This brings us to the next point. The challenges can be random, but they are constructive rather than fire-and-forget. Because of this, there is interconnectivity between the battles in the form of fundamental systems. In the case of a subterranean base, the fundamental systems might include the life support system and the power supply. In the case of a crop disease terraforming situation, the fundamental systems might include the crops and the atmosphere. If you're building a bridge, the fundamental system is the bridge you haven't finished building. In all cases, the defects and deficits in the fundamental systems can be steadily addressed by solving individual battles.
While you don't have to use every battle as an opportunity to gnaw away at these fundamental systems, if you feel up to it you can do so by simply digging until you encounter a cause that is part of the fundamental system. These are much more difficult enemies than the surface-layer stuff, so you want to be careful. For example, it may be significantly better to simply repair the door sensor than to try to fix the busted filters, because the busted filters are very difficult in comparison. But if you fix the busted filters, you'll get a boost to what the people on the planet think of you, and the fundamental system will be slightly closer to being completed/repaired.
This approach allows us to create random "dungeons" and turn the game into a randomized adventure. Every "dungeon" is a facility that has a few fundamental systems that are deficient, and then there's a bevy of surface malfunctions that can be traced back to that. Often you'll need the locals' help - after gnawing on the fundamental system for a while, it'll level up and things will become more difficult, so you'll need to find the designer or the implementer or someone with lots of experience to help you lower the difficulty back down to manageable levels.
This also allows us to have a lot of different kinds of societies with a lot of different preferences, something that is sorely lacking in today's RPGs. Because every society of every kind has facilities, you can represent a specific society's culture and needs and preferences by what kinds of facilities they have with what kinds of subsystems. Similarly, the equipment you buy locally will always be the strongest because it's the equipment designed specifically to work with the local systems. Equipment from somewhere else isn't as perfectly tuned to this tech.
There can be a class-based party system just like any other RPG. Except that instead of warriors and mages and rogues, you'd have engineers and mechanics and researchers.
The core problem is that the combat engine in an RPG is basically the "wheels" of the "car". All the exploration, leveling, gaining and losing party members, looting, attrition, buying and selling, all that stuff is all oriented around the battle system. The battle system is, in turn, built with enough statistical dependencies to allow for those other play systems to link in and affect them.
So you can replace the combat engine of an RPG, sure. But the initial impulse is to replace it with a minigame.
Minigames serve a different purpose. They are generally more skill-based than statistical, and their outcome is generally binary. Minigames are essentially gating systems, while RPG battles are essentially grinding systems. They're very different, even if at first glance they seem to have the same basic role.
The good news is that if you realize the difference, you should be able to build a replacement. So now that we've established that, let's talk about Taiga Repair, Construction, and Terraforming.
Taiga RCT is an interstellar contracting company that goes from planet to planet building and repairing things. This is a very similar theme to the idea of an adventuring party that travels from town to town. Except, instead of murdering wildlife, these adventurers repair, construct, and terraform. Imagine it's just like a classic RPG - lots of exploration, side quests, talking to people, buying and selling weapons... except that the theme is high-tech construction.
So as you wander around a subterranean base, you'd have a "random encounter" with, say, a malfunctioning door, or perhaps a clogged ventilation duct, or maybe both. Sound lame? More lame than bats and rats and slimes? Those are the equivalent enemies. Later on you'll be trying to construct giant bridges, desperately trying to get the pumping system on-line so you can prevent the undersea city from flooding before lowering the bulkheads, fighting back a crop blight while trying to increase the amount of oxygen in the air, and so on.
The combat in the game is fundamentally similar to the combat in any RPG - except that you're fixing malfunctions or constructing systems rather than killing monsters.
Every character has health, except that in this case it's self-confidence. Systems which continue to malfunction even when you're trying to fix them cause you to lose self-confidence, while repairing or constructing functional systems gives you some back. The party as a whole also has a level of confidence - the confidence the locals have that they'll be able to fix things. This allows you to gate things like advanced equipment, tiered quests, and so on based on what the locals think the party can handle.
Resolving these challenges is similar to a combat RPG as well, in that you have a "basic attack" which attempts to repair or construct, as well as more constrained techniques to buff, debuff, heal, multi-attack, and so on. However, there are a few key differences.
The first is that the enemies you face are not enemies, they are systems. But the malfunctions and missing pieces are not necessarily standalone, and they are frequently related to other malfunctions or missing pieces. You encounter a broken automatic door. It's possible for you to fix it by just brute-force attacking it, but you'll probably lose a lot of confidence, because you're essentially rebuilding the whole door from the ground up.
On the other hand, you can dig deeper and reveal that the broken automatic door is because of the broken sensor system above the door - you've added another enemy to the fray, but it's a much weaker target that will fix or severely weaken the door glitch once repaired. You can dig deeper yet, if you like, revealing that the broken sensor is because the ventilation system has bad filters, and spews dust everywhere - including on to sensors.
These can be quite complex, with several challenges linking to the same base error, or with several errors fueling a single fault, or even with circular fault chains... that can make encountering the same "enemies" still quite unique-feeling as their interconnections are always different.
This brings us to the next point. The challenges can be random, but they are constructive rather than fire-and-forget. Because of this, there is interconnectivity between the battles in the form of fundamental systems. In the case of a subterranean base, the fundamental systems might include the life support system and the power supply. In the case of a crop disease terraforming situation, the fundamental systems might include the crops and the atmosphere. If you're building a bridge, the fundamental system is the bridge you haven't finished building. In all cases, the defects and deficits in the fundamental systems can be steadily addressed by solving individual battles.
While you don't have to use every battle as an opportunity to gnaw away at these fundamental systems, if you feel up to it you can do so by simply digging until you encounter a cause that is part of the fundamental system. These are much more difficult enemies than the surface-layer stuff, so you want to be careful. For example, it may be significantly better to simply repair the door sensor than to try to fix the busted filters, because the busted filters are very difficult in comparison. But if you fix the busted filters, you'll get a boost to what the people on the planet think of you, and the fundamental system will be slightly closer to being completed/repaired.
This approach allows us to create random "dungeons" and turn the game into a randomized adventure. Every "dungeon" is a facility that has a few fundamental systems that are deficient, and then there's a bevy of surface malfunctions that can be traced back to that. Often you'll need the locals' help - after gnawing on the fundamental system for a while, it'll level up and things will become more difficult, so you'll need to find the designer or the implementer or someone with lots of experience to help you lower the difficulty back down to manageable levels.
This also allows us to have a lot of different kinds of societies with a lot of different preferences, something that is sorely lacking in today's RPGs. Because every society of every kind has facilities, you can represent a specific society's culture and needs and preferences by what kinds of facilities they have with what kinds of subsystems. Similarly, the equipment you buy locally will always be the strongest because it's the equipment designed specifically to work with the local systems. Equipment from somewhere else isn't as perfectly tuned to this tech.
There can be a class-based party system just like any other RPG. Except that instead of warriors and mages and rogues, you'd have engineers and mechanics and researchers.
Monday, July 15, 2013
The Digital Fire Sale
So, right now we're in the midst of a month-long blitz by... AmazonAppleGOGGamersGateSteamUbiSoftFuckingEveryone as they desperately cut prices on digital games in a "summer sale". If you haven't been exposed or if you're reading this after the fact, this is a sale where literally 20-50% of the games on the site are discounted by 30% or more - often things like 75%.
This simultaneous fire sale is bad. Or, rather, it's a sign that everything about the game retail market is shit. This sale indicates that all of the major digital retailers are fine taking a 50% hit to their prices and, in most cases, the game devs are similarly okay.
One of the reasons for this is that we're in the summer doldrums. Classically, studios don't like publishing in the summer, preferring to publish in the October-September sweet spot. So it is a time when there aren't very many new releases.
Another factor is the "long tail" idea. The overhead in distributing a digital game is very low, so nearly everything is revenue. After the first few months a game has been out, you've already gotten over your initial sale bump and now you're into vestigial sales. So your marketing preference should change from selling at what the market will bear to selling at what the market will be interested by. Hence many titles going for 75% off - if they can get people to buy their game this far past the initial hump, it's all just a final profit. It's a radical version of GameStop steadily marking down their new copies of games that never sold, except that in this case it works ten times faster and, due to a lack of inventory, it applies equally well to good and bad games.
This is especially true of the many games embracing pay DLC, or even as simple marketing for a game that you're about to put out. In those cases, even giving the game away for free would probably be a profit - but, of course, giving it away for free would be a bit weird-feeling. It's much easier to pretend it's a "sale".
And that's the issue.
We're not seeing something that is driven by the classic brick and mortar algorithms. There is no stock. There is no supply-side cost. The price of a digital game has nothing to do with anything store-related. It is 100% created out of whole cloth - every sale is revenue. So you try to find a line, a sweet spot where lowering the price doesn't increase the number of purchasers enough to be worth it, but raising the price would result in enough fewer that you'd lose out.
We like to pretend this price exists as some plausible ideal, but it doesn't. Not only is it largely defined by the whims and norms of the market, it also diminishes over time. Although in practical terms a game from 5 years ago is probably still just as fun as it was when released (aside from the very tippy-top of the graphics ladder), in reality the game is worth less, because fewer people are buying it. Decreasing the price over time will maximize your return, even if your game still looks fantastic and plays sharply.
These sales aren't sales. They are the prices these games should be, given those facts. Combined with pay DLC, the prices may still be too high.
So, this "fire sale", this clumsy mass-markdown which requires the community to do all the sorting and advertising, this is the way the market is. This is how prices will decay.
We just haven't normalized to it, yet, so we get there in these clumsy jumps.
Addendum: the worst part about these fire sales is that the games are often already pretty cheap. Lowering the prices doesn't actually make the games much more interesting, past a certain (already reached) point.
The thing older games really need is marketing, to remind people of how awesome they are. By simply lumping everything together under one discount banner, these fire sales do the exact opposite. Fortunately, the obsessive gamer geeks that watch the market are already around to repair the damage by marketing their favorite games via word of mouth. But that's a pretty clumsy way to do it.
This simultaneous fire sale is bad. Or, rather, it's a sign that everything about the game retail market is shit. This sale indicates that all of the major digital retailers are fine taking a 50% hit to their prices and, in most cases, the game devs are similarly okay.
One of the reasons for this is that we're in the summer doldrums. Classically, studios don't like publishing in the summer, preferring to publish in the October-September sweet spot. So it is a time when there aren't very many new releases.
Another factor is the "long tail" idea. The overhead in distributing a digital game is very low, so nearly everything is revenue. After the first few months a game has been out, you've already gotten over your initial sale bump and now you're into vestigial sales. So your marketing preference should change from selling at what the market will bear to selling at what the market will be interested by. Hence many titles going for 75% off - if they can get people to buy their game this far past the initial hump, it's all just a final profit. It's a radical version of GameStop steadily marking down their new copies of games that never sold, except that in this case it works ten times faster and, due to a lack of inventory, it applies equally well to good and bad games.
This is especially true of the many games embracing pay DLC, or even as simple marketing for a game that you're about to put out. In those cases, even giving the game away for free would probably be a profit - but, of course, giving it away for free would be a bit weird-feeling. It's much easier to pretend it's a "sale".
And that's the issue.
We're not seeing something that is driven by the classic brick and mortar algorithms. There is no stock. There is no supply-side cost. The price of a digital game has nothing to do with anything store-related. It is 100% created out of whole cloth - every sale is revenue. So you try to find a line, a sweet spot where lowering the price doesn't increase the number of purchasers enough to be worth it, but raising the price would result in enough fewer that you'd lose out.
We like to pretend this price exists as some plausible ideal, but it doesn't. Not only is it largely defined by the whims and norms of the market, it also diminishes over time. Although in practical terms a game from 5 years ago is probably still just as fun as it was when released (aside from the very tippy-top of the graphics ladder), in reality the game is worth less, because fewer people are buying it. Decreasing the price over time will maximize your return, even if your game still looks fantastic and plays sharply.
These sales aren't sales. They are the prices these games should be, given those facts. Combined with pay DLC, the prices may still be too high.
So, this "fire sale", this clumsy mass-markdown which requires the community to do all the sorting and advertising, this is the way the market is. This is how prices will decay.
We just haven't normalized to it, yet, so we get there in these clumsy jumps.
Addendum: the worst part about these fire sales is that the games are often already pretty cheap. Lowering the prices doesn't actually make the games much more interesting, past a certain (already reached) point.
The thing older games really need is marketing, to remind people of how awesome they are. By simply lumping everything together under one discount banner, these fire sales do the exact opposite. Fortunately, the obsessive gamer geeks that watch the market are already around to repair the damage by marketing their favorite games via word of mouth. But that's a pretty clumsy way to do it.
Thursday, July 11, 2013
Simple City-Building
I've been thinking about city-building games, especially after the catastrophe that the newest Sim City visited upon us.
But here's the secret about me and the Sim City franchise: I don't like it.
I mean, it's enjoyable enough, but when I think of cities, I think of cities. Huge things with global influence. The new Sim City, with its four square blocks of space, really hammered this home. I didn't start feeling like Sim City 2000 was talking my language until the city hit the max size cap... and then that was pretty much endgame. Endgame where I was just starting to feel it was interesting.
I thought about it some. How do you design a city game where your city really feels like a huge city with global influence?
Well, obviously, you make it a huge city with global influence.
The global influence part means making the city part of a larger world or universe. New York City isn't simply New York City: it is influenced by and strongly influences world events. It receives its fair share of immigrants from whatever culture is currently going through an immigration wave, it influences global banking but feels the bite when global banking fails, it has crime but the crime sometimes involves multinational cartels...
New York City isn't about plumbing and roadwork, to me. It's about creating a beating heart to pump the blood of human society through the world. That's the sort of game I want to play.
The question is: how do you do it?
One way to do it is, of course, via simple spreadsheet. You can make a game where all the decisions are laid out in bare sentences, and you simply allocate funds and votes. But that's a bit too dry. Cities do exist in physical space. I want my city to exist as solid city - buildings, streets, and so on. They don't have to be all simulated in detail, but I want a south side and a Devil's Kitchen and a market district and all that.
So I've put together a simple framework. I'll describe it here, maybe create a prototype (although I'm already doing a different prototype, so maybe not).
The grid for the city is a grid, with each tile being about the size of a new Sim City city - IE, a smallish district. The grid is warped for an organic feel, but the fundamental structure is unbroken except when it's impossible to build somewhere because of water or broken land.
Each district (grid tile) has ratings. Some are things like beauty, terrain roughness, or altitude. Some are based around the population: residents, commuters, pollution, crime, culture. And, obviously, each district has four neighbors (or less, if they're on a coast or at the edge of a major highway).
When you define a zone, you don't define it in terms of residential or industrial or whatever. Instead, you point it at something.
For example, if you want an airport district, you point it at the sky. If you want a shipping district, you point it at the neighboring sea, or the neighboring highway.
You can also point it at specific areas of concern. Point it at banking, at movies, at medicine or physics. Whatever other global economic concepts arise. In a game with technologies and economies, this will also generate resources, which is useful.
You can point them at specific physical areas far away. Point them at a space station, at another city on the other side of the planet, at the north pole. Now they are connected to whatever you pointed them at, both in terms of physical travel and in terms of economic relationships. The reverse is also true: if you point a district at a faraway city, immigrants from that city will tend to live in that district, and that district's culture will be strongly influenced by them.
Lastly, you can point them at other districts in your city, but only at neighbors. For example, you might point a district at your airport district, and it will grow to support the airport, with hotels and warehouses and upscale commercial stuff.
Some of this is automatic, though. For example, if you have a district pointed at heavy industry and a district pointed at shipping, they'll automatically add to the city's totals of shipping and industry, and therefore support each other even without being pointed at each other. Similarly, a district can be pointed at another continent without actually having a transcontinental airport in it, as long as you have a transcontinental airport in the city somewhere. It's only when you want a district to be completely shaped by the need to support another district you use the pointing thing.
As the world situation changes, the pressures from various elements change, and therefore the pressures on the districts change. If a horrible earthquake hits a city one of your districts is pointed to, the refugees pouring into that district will radically amp up the population and destroy the economy. You need to revamp your city to this changing situation. You could adapt the neighboring districts to support this district, but the neighbors may be on important tasks of their own. You could point new districts at that damaged city, and un-point this district. That wouldn't reduce the economic damage already done to the district, but it would take the pressure off and allow it to begin healing. But the new districts don't have any economy already in existence, which means refugees into those districts will turn it into a permanent slum, since there's no jobs or ready culture to absorb them... you could also just un-point the existing district and say "screw off" to the remaining refugees, which would be pretty vile but perhaps economically viable.
You can also go on the offensive. Your district pointed at physics research? Pump cash into it and push for a physics breakthrough!
One of the keys to this game is that it is multiplayer. Not necessarily strictly on-line, but there are other cities in the world. The ways they all interact is a big part of the game. There's a lot of potential to make this a fun semi-casual asynchronous game.
I think this is a pretty easy design. I like it.
But here's the secret about me and the Sim City franchise: I don't like it.
I mean, it's enjoyable enough, but when I think of cities, I think of cities. Huge things with global influence. The new Sim City, with its four square blocks of space, really hammered this home. I didn't start feeling like Sim City 2000 was talking my language until the city hit the max size cap... and then that was pretty much endgame. Endgame where I was just starting to feel it was interesting.
I thought about it some. How do you design a city game where your city really feels like a huge city with global influence?
Well, obviously, you make it a huge city with global influence.
The global influence part means making the city part of a larger world or universe. New York City isn't simply New York City: it is influenced by and strongly influences world events. It receives its fair share of immigrants from whatever culture is currently going through an immigration wave, it influences global banking but feels the bite when global banking fails, it has crime but the crime sometimes involves multinational cartels...
New York City isn't about plumbing and roadwork, to me. It's about creating a beating heart to pump the blood of human society through the world. That's the sort of game I want to play.
The question is: how do you do it?
One way to do it is, of course, via simple spreadsheet. You can make a game where all the decisions are laid out in bare sentences, and you simply allocate funds and votes. But that's a bit too dry. Cities do exist in physical space. I want my city to exist as solid city - buildings, streets, and so on. They don't have to be all simulated in detail, but I want a south side and a Devil's Kitchen and a market district and all that.
So I've put together a simple framework. I'll describe it here, maybe create a prototype (although I'm already doing a different prototype, so maybe not).
The grid for the city is a grid, with each tile being about the size of a new Sim City city - IE, a smallish district. The grid is warped for an organic feel, but the fundamental structure is unbroken except when it's impossible to build somewhere because of water or broken land.
Each district (grid tile) has ratings. Some are things like beauty, terrain roughness, or altitude. Some are based around the population: residents, commuters, pollution, crime, culture. And, obviously, each district has four neighbors (or less, if they're on a coast or at the edge of a major highway).
When you define a zone, you don't define it in terms of residential or industrial or whatever. Instead, you point it at something.
For example, if you want an airport district, you point it at the sky. If you want a shipping district, you point it at the neighboring sea, or the neighboring highway.
You can also point it at specific areas of concern. Point it at banking, at movies, at medicine or physics. Whatever other global economic concepts arise. In a game with technologies and economies, this will also generate resources, which is useful.
You can point them at specific physical areas far away. Point them at a space station, at another city on the other side of the planet, at the north pole. Now they are connected to whatever you pointed them at, both in terms of physical travel and in terms of economic relationships. The reverse is also true: if you point a district at a faraway city, immigrants from that city will tend to live in that district, and that district's culture will be strongly influenced by them.
Lastly, you can point them at other districts in your city, but only at neighbors. For example, you might point a district at your airport district, and it will grow to support the airport, with hotels and warehouses and upscale commercial stuff.
Some of this is automatic, though. For example, if you have a district pointed at heavy industry and a district pointed at shipping, they'll automatically add to the city's totals of shipping and industry, and therefore support each other even without being pointed at each other. Similarly, a district can be pointed at another continent without actually having a transcontinental airport in it, as long as you have a transcontinental airport in the city somewhere. It's only when you want a district to be completely shaped by the need to support another district you use the pointing thing.
As the world situation changes, the pressures from various elements change, and therefore the pressures on the districts change. If a horrible earthquake hits a city one of your districts is pointed to, the refugees pouring into that district will radically amp up the population and destroy the economy. You need to revamp your city to this changing situation. You could adapt the neighboring districts to support this district, but the neighbors may be on important tasks of their own. You could point new districts at that damaged city, and un-point this district. That wouldn't reduce the economic damage already done to the district, but it would take the pressure off and allow it to begin healing. But the new districts don't have any economy already in existence, which means refugees into those districts will turn it into a permanent slum, since there's no jobs or ready culture to absorb them... you could also just un-point the existing district and say "screw off" to the remaining refugees, which would be pretty vile but perhaps economically viable.
You can also go on the offensive. Your district pointed at physics research? Pump cash into it and push for a physics breakthrough!
One of the keys to this game is that it is multiplayer. Not necessarily strictly on-line, but there are other cities in the world. The ways they all interact is a big part of the game. There's a lot of potential to make this a fun semi-casual asynchronous game.
I think this is a pretty easy design. I like it.
Wednesday, July 10, 2013
Games as Striking Moments
A lot of little theories run around about the fundamental nature of game design. Games as sequences of meaningful choices, or as skill training, or whatever your favorite is. I don't like these, because to me game design is artistic, and therefore any rigid mold you try to put it in is something that should be broken as a matter of artistic expression. When you say "game design is about presenting meaningful choices", someone will counter with a game like Bioshock Infinite, which basically had no meaningful choices but was still highly regarded.
With that in mind, let's talk about other theories of game design that might shake the status quo a little bit. Here's one:
Game design is about giving the players striking moments.
When you think about your favorite games, in general the things you remember are the most striking moments in the game. Sometimes these scenes are parts of the story - for example, the early Final Fantasies were built around having half a dozen fundamental striking scenes and then just sticking game between them. Final Fantasy VI is the best example of this. The story itself was not terribly well executed, the graphics were primitive, the gameplay was so flawed that nobody noticed they'd turned off several stats and left them turned off... but there were foundational scenes which punched you in the face. The epic opening, the choice of which chapter to play next, the burning of Figaro followed by the sinking and rising of Figaro, the quiet and inexplicable western music when you walk into a bar and suddenly see Shadow, the beserk espers, the rending of the earth, Celes' grinding, hopeless island quest, and so on.
These don't really craft a meaningful "story" as such. Even if you removed half of the pieces, you could still have exactly the same story. Figaro's ability to submerge and tunnel through the sand adds nothing significant to the plot... but it does add an amazing, striking set of scenes and some conceits for some minor missions.
Later Final Fantasies remembered this basic idea, but have put the player on rails. We'll talk a bit later about how pacing is dreadfully important, and how they drop the ball.
The same can be said of basically every game you remember loving that had a significant story... but lots of games we loved had little to no story. For example, XCom, Street Fighter, Mario, and so on. So many of these games did not have many (or any) plot-related striking moments.
But they still have striking moments.
Programmed right into the game progression.
The first terror mission you face. The first time you encounter M. Bison as he floats down. The time you manage to stay alive despite getting 6 Z-shaped bricks in a row at the highest Tetris difficulty. The time when you managed to jump across eight flying turtles, or found the warp gates. The first time you send a star fleet of your own construction into enemy territory.
Some games also have multiplayer moments. The time you managed to get all those headshots. The time you and your friend held out against twelve enemies. The time you wouldn't stop hitting each other in the back of the head at the worst possible moments. The time when you dressed up as ridiculously as possible in a contest to see whose avatar could be made more outrageous. And, of course, the time you managed to jump a Ferrari over the river while your buddy did handstands on the roof.
I've been thinking a lot about these striking moments, and the nature of games as a vessel for striking moments. I've been thinking about them in part because - and this is something I can't stress enough - I think we're not using them well enough. There are a lot of kinds of moments we're not using because we're not thinking of them in this way. Not all striking moments have to be about murder or subverting the game's implicit seriousness.
So, if games are simply a delivery vehicle for striking moments, why aren't they just sequences of striking moments?
Well, for the same reason movies aren't. The gameplay and pacing of a game allows us to establish the striking moment as striking. Taking on a single demon in God Hand is an impressive moment, but in most other games it's barely even notable. Similarly, a woman being killed by an evil villain happens in virtually every M-rated game - but it's only when that woman is established as a major character that you get something with the emotional punch of Aerith's death.
This is something that modern spectacle fighters are skirting the edge of. Every time you press X to rip a gorgon's head off, you're supposed to feel it is a striking moment. But it isn't very striking to most people because the game hasn't set it up with any weight. Some people will still find it striking, but only those whose heads are in the exact right spot at that moment. Most players aren't going to feel exactly like you want them to feel, or expect the things you think they are expecting.
This is where games really shine, because you can really guide the player into the exact spot you want them. By crafting the characters, plot, and gameplay, you can teach the players exactly what to expect... and, therefore, you can strike them perfectly with your striking moments. A good example of this is the poisoning of Doma in FFVI - that's the scene where Kefka poisons a whole city. Not only is poisoning of that sort something that is obviously villainous, but when Kefka originally orders it, he is countermanded by someone who is (at the time) in the running for main villain. That's right - one of the major villains thinks it's beyond the pale. So when Kefka does it anyway, it's not just a villain event horizon moment. It's so beyond what is acceptable that the villains turn against him, throw him in prison, and make peace with you because they are so horrified by what he did. That context really sets Kefka up as a massive, once-in-a-game-generation memorable villain.
Of course, you can also do it with gameplay. The 20-kill streak you're so proud of in Team Fortress 2 is a good example: the rules are set up such that it is difficult to pull off, and everyone knows it is difficult to pull off. So pulling it off is a hell of an accomplishment, even though in many shooters a 20-kill streak is something you achieve five minutes into the first stage.
The key to setting these striking events up is to shepherd the player so that their expectations are aligned in just the right way for the moment to hit hard. Self-directed pacing helps a lot, here. For example, that gameplay moment where you get a super kill streak isn't one where the designers tell you "okay, now aim for a 20-kill streak". No, they simply allow it to be possible, and then, when you are ready, you will move into it on your own and quickly realize that a hell of a moment is developing. Similarly, the developers don't say "dress as silly as possible and show your friends!" They simply make it possible to dress silly, and possible to show your friends, and you quickly realize that there is potential to be had.
This is a little more difficult with story elements, but the same philosophy applies. The gameplay between scripted moments should be crafted such that playing the gameplay sort of tugs the player into alignment. Players that are out of alignment will generally continue to play the gameplay instead of progress through a story beat, and therefore be brought into alignment steadily.
The RPG is the great example in this. An RPG's play serves two purposes. It is an outlet so that a player can let off statistical steam... but, simultaneously, it takes place in a place and for a reason which aligns the player with the next story beat. When the player is eager to level and tweak stats, they can put off the story and do so... simultaneously, they are primed for the next story beat, because every moment they spend wandering the town or screwing around in the forest is another jot of investment into the town and the forest and the people within it. At least, when well-designed.
More recent Final Fantasies show that you can fail to do this. These Final Fantasies should, by all rights, be full of striking moments. But I literally can't remember any of them. None of them were primed properly, because the gameplay was too static and linear. I wasn't allowed the time to be brought into alignment - the gameplay either had too little vectoring, or was too rigid to allow me to let off my statistical steam.
Now, with all that said, I mentioned that I think we're not using moments to their fullest.
By that I simply mean that our emergent events are limited to violence, skill challenge, and subversion. I think we can allow for more kinds of moments than that. Think about the plot moments that strike you. These often involved impressive places or things. Sometimes it involved people dying, but usually not because you were killing them. These moments are scripted... but couldn't we create similar moments through gameplay?
The basic concept is that the gameplay establishes a vector, and allows the player to get invested in the fundamental concept... and then we throw in a twist or a challenge option which makes their head tilt. As a basic example: teach the player how to fight, then offer a pacifist route reward. However, in our case, we want to talk about concepts rather than skill challenges.
We could talk about places. Teach the player to cut trees and make houses... then show him houses built right into the trees, made without harming them.
We could also talk about people. Teach the player to treat NPCs as people... then let them actually act like people, and confound him.
The first is easier, because we can rely on multiplayer for fuel. By allowing players to build things and then share them, you can introduce players to massively impressive works of art built with the same resources they themselves have. However, you do need to take care with pacing. Striking moments are things which require you to be on the right vector - vectors established through gameplay. Simply throwing content at players will drown them in content, not create striking moments. The ultimate example of this is Spore, which drowned in its own content overdelivery. Recalibrated so that the gameplay could pull the players into the proper vector over time, introducing new alien species could have made each species intensely interesting and feel unique. But delivered willy-nilly, they all blend together into mush.
The second option - people - is harder. There are several reasons. 1) We don't have any established frameworks for allowing emotional interactions. 2) People are going to want to turn it into porn faster than they'll want to turn it into meaningful relationships. 3) Creating unique content may require a lot of effort.
One option is to simulate it using multiplayer, just as before. You can create a framework where NPCs are controlled asynchronously by polling several players for responses with mirror techniques. For example, the NPCs they interact with are built out of the massed actions of other player characters, while their own responses to that NPC will form the NPC responses to those other players. This could theoretically have a lot of potential, but you'd need to do a lot of innovation because there's no standard practice.
Another option is to embrace the porn in the same way an RPG embraces level grinding, and assume that when the player is getting tired of porn they'll move into the next personal arc moment. I dunno whether or not this would work, but it'd be difficult to convince anyone to take it seriously.
Another option is to have an algorithm which controls the NPC responses. This doesn't require a very smart algorithm, any more than the algorithm for putting bounties on kill streaks does. All it requires is carefully planned out algorithms that pull players into the vector properly. However, because the uniqueness of the algorithmic responses is low, you need to make the gameplay highly variable, again like TF2. No two games are the same, so your 20-kill streak might be extremely impressive and striking... or a bland reminder that there are a lot of newbies floating around. By making the gameplay vary wildly, you can make the context vary, and therefore make the moment vary as to how striking it is. Good gameplay will constantly tug the player into alignment with at least one of the possible striking moments, so if you embrace the chaos you can create a sort of "radial" moment system where the players might aim for different kinds of moments depending on the situation they find themselves in.
In the same way as someone in a fighting game might aim for a kill-streak... or they might aim for a perfect, or a handicapped run, or a carebear tutorial run, or a hat-achievement run, or...
These are still fundamentally skill-type challenges, but I think a little baby step could be taken with this concept. See where it goes before running off at full steam.
Anyway, those are my thoughts on the matter. Sorry it ended up so long.
With that in mind, let's talk about other theories of game design that might shake the status quo a little bit. Here's one:
Game design is about giving the players striking moments.
When you think about your favorite games, in general the things you remember are the most striking moments in the game. Sometimes these scenes are parts of the story - for example, the early Final Fantasies were built around having half a dozen fundamental striking scenes and then just sticking game between them. Final Fantasy VI is the best example of this. The story itself was not terribly well executed, the graphics were primitive, the gameplay was so flawed that nobody noticed they'd turned off several stats and left them turned off... but there were foundational scenes which punched you in the face. The epic opening, the choice of which chapter to play next, the burning of Figaro followed by the sinking and rising of Figaro, the quiet and inexplicable western music when you walk into a bar and suddenly see Shadow, the beserk espers, the rending of the earth, Celes' grinding, hopeless island quest, and so on.
These don't really craft a meaningful "story" as such. Even if you removed half of the pieces, you could still have exactly the same story. Figaro's ability to submerge and tunnel through the sand adds nothing significant to the plot... but it does add an amazing, striking set of scenes and some conceits for some minor missions.
Later Final Fantasies remembered this basic idea, but have put the player on rails. We'll talk a bit later about how pacing is dreadfully important, and how they drop the ball.
The same can be said of basically every game you remember loving that had a significant story... but lots of games we loved had little to no story. For example, XCom, Street Fighter, Mario, and so on. So many of these games did not have many (or any) plot-related striking moments.
But they still have striking moments.
Programmed right into the game progression.
The first terror mission you face. The first time you encounter M. Bison as he floats down. The time you manage to stay alive despite getting 6 Z-shaped bricks in a row at the highest Tetris difficulty. The time when you managed to jump across eight flying turtles, or found the warp gates. The first time you send a star fleet of your own construction into enemy territory.
Some games also have multiplayer moments. The time you managed to get all those headshots. The time you and your friend held out against twelve enemies. The time you wouldn't stop hitting each other in the back of the head at the worst possible moments. The time when you dressed up as ridiculously as possible in a contest to see whose avatar could be made more outrageous. And, of course, the time you managed to jump a Ferrari over the river while your buddy did handstands on the roof.
I've been thinking a lot about these striking moments, and the nature of games as a vessel for striking moments. I've been thinking about them in part because - and this is something I can't stress enough - I think we're not using them well enough. There are a lot of kinds of moments we're not using because we're not thinking of them in this way. Not all striking moments have to be about murder or subverting the game's implicit seriousness.
So, if games are simply a delivery vehicle for striking moments, why aren't they just sequences of striking moments?
Well, for the same reason movies aren't. The gameplay and pacing of a game allows us to establish the striking moment as striking. Taking on a single demon in God Hand is an impressive moment, but in most other games it's barely even notable. Similarly, a woman being killed by an evil villain happens in virtually every M-rated game - but it's only when that woman is established as a major character that you get something with the emotional punch of Aerith's death.
This is something that modern spectacle fighters are skirting the edge of. Every time you press X to rip a gorgon's head off, you're supposed to feel it is a striking moment. But it isn't very striking to most people because the game hasn't set it up with any weight. Some people will still find it striking, but only those whose heads are in the exact right spot at that moment. Most players aren't going to feel exactly like you want them to feel, or expect the things you think they are expecting.
This is where games really shine, because you can really guide the player into the exact spot you want them. By crafting the characters, plot, and gameplay, you can teach the players exactly what to expect... and, therefore, you can strike them perfectly with your striking moments. A good example of this is the poisoning of Doma in FFVI - that's the scene where Kefka poisons a whole city. Not only is poisoning of that sort something that is obviously villainous, but when Kefka originally orders it, he is countermanded by someone who is (at the time) in the running for main villain. That's right - one of the major villains thinks it's beyond the pale. So when Kefka does it anyway, it's not just a villain event horizon moment. It's so beyond what is acceptable that the villains turn against him, throw him in prison, and make peace with you because they are so horrified by what he did. That context really sets Kefka up as a massive, once-in-a-game-generation memorable villain.
Of course, you can also do it with gameplay. The 20-kill streak you're so proud of in Team Fortress 2 is a good example: the rules are set up such that it is difficult to pull off, and everyone knows it is difficult to pull off. So pulling it off is a hell of an accomplishment, even though in many shooters a 20-kill streak is something you achieve five minutes into the first stage.
The key to setting these striking events up is to shepherd the player so that their expectations are aligned in just the right way for the moment to hit hard. Self-directed pacing helps a lot, here. For example, that gameplay moment where you get a super kill streak isn't one where the designers tell you "okay, now aim for a 20-kill streak". No, they simply allow it to be possible, and then, when you are ready, you will move into it on your own and quickly realize that a hell of a moment is developing. Similarly, the developers don't say "dress as silly as possible and show your friends!" They simply make it possible to dress silly, and possible to show your friends, and you quickly realize that there is potential to be had.
This is a little more difficult with story elements, but the same philosophy applies. The gameplay between scripted moments should be crafted such that playing the gameplay sort of tugs the player into alignment. Players that are out of alignment will generally continue to play the gameplay instead of progress through a story beat, and therefore be brought into alignment steadily.
The RPG is the great example in this. An RPG's play serves two purposes. It is an outlet so that a player can let off statistical steam... but, simultaneously, it takes place in a place and for a reason which aligns the player with the next story beat. When the player is eager to level and tweak stats, they can put off the story and do so... simultaneously, they are primed for the next story beat, because every moment they spend wandering the town or screwing around in the forest is another jot of investment into the town and the forest and the people within it. At least, when well-designed.
More recent Final Fantasies show that you can fail to do this. These Final Fantasies should, by all rights, be full of striking moments. But I literally can't remember any of them. None of them were primed properly, because the gameplay was too static and linear. I wasn't allowed the time to be brought into alignment - the gameplay either had too little vectoring, or was too rigid to allow me to let off my statistical steam.
Now, with all that said, I mentioned that I think we're not using moments to their fullest.
By that I simply mean that our emergent events are limited to violence, skill challenge, and subversion. I think we can allow for more kinds of moments than that. Think about the plot moments that strike you. These often involved impressive places or things. Sometimes it involved people dying, but usually not because you were killing them. These moments are scripted... but couldn't we create similar moments through gameplay?
The basic concept is that the gameplay establishes a vector, and allows the player to get invested in the fundamental concept... and then we throw in a twist or a challenge option which makes their head tilt. As a basic example: teach the player how to fight, then offer a pacifist route reward. However, in our case, we want to talk about concepts rather than skill challenges.
We could talk about places. Teach the player to cut trees and make houses... then show him houses built right into the trees, made without harming them.
We could also talk about people. Teach the player to treat NPCs as people... then let them actually act like people, and confound him.
The first is easier, because we can rely on multiplayer for fuel. By allowing players to build things and then share them, you can introduce players to massively impressive works of art built with the same resources they themselves have. However, you do need to take care with pacing. Striking moments are things which require you to be on the right vector - vectors established through gameplay. Simply throwing content at players will drown them in content, not create striking moments. The ultimate example of this is Spore, which drowned in its own content overdelivery. Recalibrated so that the gameplay could pull the players into the proper vector over time, introducing new alien species could have made each species intensely interesting and feel unique. But delivered willy-nilly, they all blend together into mush.
The second option - people - is harder. There are several reasons. 1) We don't have any established frameworks for allowing emotional interactions. 2) People are going to want to turn it into porn faster than they'll want to turn it into meaningful relationships. 3) Creating unique content may require a lot of effort.
One option is to simulate it using multiplayer, just as before. You can create a framework where NPCs are controlled asynchronously by polling several players for responses with mirror techniques. For example, the NPCs they interact with are built out of the massed actions of other player characters, while their own responses to that NPC will form the NPC responses to those other players. This could theoretically have a lot of potential, but you'd need to do a lot of innovation because there's no standard practice.
Another option is to embrace the porn in the same way an RPG embraces level grinding, and assume that when the player is getting tired of porn they'll move into the next personal arc moment. I dunno whether or not this would work, but it'd be difficult to convince anyone to take it seriously.
Another option is to have an algorithm which controls the NPC responses. This doesn't require a very smart algorithm, any more than the algorithm for putting bounties on kill streaks does. All it requires is carefully planned out algorithms that pull players into the vector properly. However, because the uniqueness of the algorithmic responses is low, you need to make the gameplay highly variable, again like TF2. No two games are the same, so your 20-kill streak might be extremely impressive and striking... or a bland reminder that there are a lot of newbies floating around. By making the gameplay vary wildly, you can make the context vary, and therefore make the moment vary as to how striking it is. Good gameplay will constantly tug the player into alignment with at least one of the possible striking moments, so if you embrace the chaos you can create a sort of "radial" moment system where the players might aim for different kinds of moments depending on the situation they find themselves in.
In the same way as someone in a fighting game might aim for a kill-streak... or they might aim for a perfect, or a handicapped run, or a carebear tutorial run, or a hat-achievement run, or...
These are still fundamentally skill-type challenges, but I think a little baby step could be taken with this concept. See where it goes before running off at full steam.
Anyway, those are my thoughts on the matter. Sorry it ended up so long.
Monday, July 08, 2013
Hide and Seek
Nick Lalone tossed out a simple tweet, also found here: a simple game where you (and all other players) hide, and then there's an AI seeker that tries to find you. Players who hide successfully win the round and get some kind of reward.
As far as meaty casual games go, this has all the hallmarks of being a good idea. A simple player action that can be done largely asynchronously, but an action that has some tactical depth to it. Fundamentally, it bears a lot of similarity to Parking Wars: you're choosing a "parking spot" (hiding spot) and hoping nobody calls you on it.
The key to making this sort of game interesting is how well the player can read the seeker's intention. In a game like Parking Wars, you got to know your friends and what times of day they were likely to pop by to play the game - and also whether they would let things ride a bit, or instantly hit you. It was a game about understanding who you are up against.
In this hide-and-seek game, you have to build the seeker such that the players can weigh their options. They have to understand the tendencies of the seeker.
Here's my take on this design:
You can place your character anywhere on the map - well, anywhere with a place to stand that isn't occupied by another player. The map automatically expands as more players log in, and shrinks with fewer players, so there's a constant acreage-to-player ratio. Creating 2D tile maps on the fly is pretty easy, so that's not a technical barrier. You can choose to place yourself somewhere else, but that will set you back some points. Ideally you want to choose a location where you'll be safe for a while, because you're awarded points by not being found.
The player can always see all other players, and the position of the seekers. There's a ratio of acre-to-seeker that is also preserved.
Seekers move according to some general rules. They come in a few simple varieties - the AI doesn't need to evolve, you just need to have which seekers are in the area change, and since they search in different ways, different places will be safe.
For example, you might have an eagle seeker. The eagle moves in a straight line until it hits a barrier, at which point it turns right. It moves at one space per minute, and has extremely long range of vision. If it sees someone, though, it moves rapidly to them - they can't relocate once spotted. Using these rules, you can easily predict the path of an eagle... unless some other player hides badly, and now the eagle is suddenly over there, moving in some other direction!
Or you might have hound seekers, which carefully canvas the local chunk, then roam across several chunks along the roads that are generated in the world - before choosing another chunk to canvas. If you're in a chunk that's being canvassed, you'll want to move, because the hound will eventually look in every spot. But if it's just wandering on the road, you're relatively safe.
Or you might have something scary, like a childcatcher. They always go for places where other seekers have found players in the past. If a place looks like a good hiding spot... it probably is, except against someone who knows that players generally hide there!
Anyway, the simple AI lets the player predict the sort of danger they are in, but it's made more complex by whether there are other players in the area that could get spotted and lure the seeker over. The terrain generation in question needs to be the sort of terrain you can hide in, so nice and rough - probably with some basic biome work. This place is a forest, that one's a jungle, that one's a city, etc.
Also, the AI is self-balancing. If one of the AI seekers is more dangerous than the others, then players will generally try to avoid it and go into the chunks where there are no powerful seekers. However, that raises the population density in those "safe" areas, making them less safe. And lowers the population density in the dangerous areas, making them more safe.
Add in an evolving map and some social features for completeness. If you hide within eyeshot of a friend, you get extra points. Of course, that means anyone who catches your friend will be able to see you. Maybe allow people to have multiple hiders as long as they are on different game worlds, so you don't feel like you only play the game by not playing it.
For monetization, you could go with customizable avatars and buying the points that you normally earn by hiding, or even buying tiles to place on the world map. Traps to snare the seeker, barricades that count as walls for a few hours, hosting a new game world, accessing more game worlds simultaneously.
This'd be easy to program and, I think, fun to play.
As far as meaty casual games go, this has all the hallmarks of being a good idea. A simple player action that can be done largely asynchronously, but an action that has some tactical depth to it. Fundamentally, it bears a lot of similarity to Parking Wars: you're choosing a "parking spot" (hiding spot) and hoping nobody calls you on it.
The key to making this sort of game interesting is how well the player can read the seeker's intention. In a game like Parking Wars, you got to know your friends and what times of day they were likely to pop by to play the game - and also whether they would let things ride a bit, or instantly hit you. It was a game about understanding who you are up against.
In this hide-and-seek game, you have to build the seeker such that the players can weigh their options. They have to understand the tendencies of the seeker.
Here's my take on this design:
You can place your character anywhere on the map - well, anywhere with a place to stand that isn't occupied by another player. The map automatically expands as more players log in, and shrinks with fewer players, so there's a constant acreage-to-player ratio. Creating 2D tile maps on the fly is pretty easy, so that's not a technical barrier. You can choose to place yourself somewhere else, but that will set you back some points. Ideally you want to choose a location where you'll be safe for a while, because you're awarded points by not being found.
The player can always see all other players, and the position of the seekers. There's a ratio of acre-to-seeker that is also preserved.
Seekers move according to some general rules. They come in a few simple varieties - the AI doesn't need to evolve, you just need to have which seekers are in the area change, and since they search in different ways, different places will be safe.
For example, you might have an eagle seeker. The eagle moves in a straight line until it hits a barrier, at which point it turns right. It moves at one space per minute, and has extremely long range of vision. If it sees someone, though, it moves rapidly to them - they can't relocate once spotted. Using these rules, you can easily predict the path of an eagle... unless some other player hides badly, and now the eagle is suddenly over there, moving in some other direction!
Or you might have hound seekers, which carefully canvas the local chunk, then roam across several chunks along the roads that are generated in the world - before choosing another chunk to canvas. If you're in a chunk that's being canvassed, you'll want to move, because the hound will eventually look in every spot. But if it's just wandering on the road, you're relatively safe.
Or you might have something scary, like a childcatcher. They always go for places where other seekers have found players in the past. If a place looks like a good hiding spot... it probably is, except against someone who knows that players generally hide there!
Anyway, the simple AI lets the player predict the sort of danger they are in, but it's made more complex by whether there are other players in the area that could get spotted and lure the seeker over. The terrain generation in question needs to be the sort of terrain you can hide in, so nice and rough - probably with some basic biome work. This place is a forest, that one's a jungle, that one's a city, etc.
Also, the AI is self-balancing. If one of the AI seekers is more dangerous than the others, then players will generally try to avoid it and go into the chunks where there are no powerful seekers. However, that raises the population density in those "safe" areas, making them less safe. And lowers the population density in the dangerous areas, making them more safe.
Add in an evolving map and some social features for completeness. If you hide within eyeshot of a friend, you get extra points. Of course, that means anyone who catches your friend will be able to see you. Maybe allow people to have multiple hiders as long as they are on different game worlds, so you don't feel like you only play the game by not playing it.
For monetization, you could go with customizable avatars and buying the points that you normally earn by hiding, or even buying tiles to place on the world map. Traps to snare the seeker, barricades that count as walls for a few hours, hosting a new game world, accessing more game worlds simultaneously.
This'd be easy to program and, I think, fun to play.
Subscribe to:
Posts (Atom)