I've been really thinking about the concept of travel, control, and time. I've been trying to think of "slow control" methods of travel. That is, methods that are more introspective than the standard rapid running & platforming segments.
Things like sailing, orbital transfer, gliders, leaping long distances, swinging, and "quick climbing" (dashing up the side of things) are all good examples of what I'm talking about. These methods of travel rarely challenge your reaction speed or require you to dodge obstacles. Instead, they're about looking ahead and tweaking a bit so that you end up where you want to be in the future.
I wracked my brain trying to think of a method of travel that really seemed interesting and tangible. Something that would involve a few different modes, an organic feel, and that "slow control" method.
And I came up with the Sun Wing.
This takes place in a slightly fantastical future where there's not really any rocket fuel left. Reaching space is only possible via Sun Wing.
The Sun Wing is a very adaptive, technologically advanced not-quite-glider. Near the ground, it operates like a glider.
However, it has several engines in it.
One is the electrical jet turbine. This can't keep the vehicle aloft forever, because it eats through electricity faster than the solar paint can replenish it. It mostly serves to increase speed in the upper atmosphere, helping take you into suborbital arcs. It can be used low and close to the ground, if you like, but it's less effective there.
Another is the afterburner. The vehicle wicks water out of the air and converts it into hydrogen and oxygen. This happens really slow, so the vast majority of this happens on the ground in time acceleration. You can use that and the jet turbine to create a powerful "afterburner" effect, normally used to launch off the surface and into the air. Used effectively, this will last long enough to get you high enough for your jet turbine to take over. Used ineffectively, it's a fun way to give you a little added duration to your flights. It can also be used to help land by firing retrojets just above the ground.
At lower altitudes, you'll use a hydrogen-heavy mix, preserving oxygen for breathing purposes. You can use it in the upper atmosphere or even in deep space, but you'll burn your oxygen very quick.
The third and final engine is the ion drive, which is used for non-atmospheric maneuvering. IE, going from sub-orbital to orbital and back. The ion drive can be as powerful in space as the jet turbine is in the atmosphere, but you aren't going to have the electricity to run it at that level: it's even more energy-hogging than the jet turbine.
These three engines combine to give the player a lot of control over how they get around. They can glide around near the surface, fly in the middle altitudes, or even enter space. In theory, you could even reach the moon on a Sun Wing... except, of course, for the pesky need to breath. Even with scrubbers, the oxygen you take with you is pretty limited. You have to watch your weight, after all.
There is another facet of the Sun Wing: it has a very adaptive surface. The higher in the atmosphere it goes, the wider its wingspan becomes. This keeps your lift pretty constant even as your air pressure decreases. It also radically increases the solar paint's surface area, so you get a whole lot more electricity, making your jet turbine and ion engines feasible to run continuously.
When you leave the atmosphere, your flying rig stops looking like a sleeping bag with arms and inflates into a small but comfortable little tent. You can do this when parked, too, but like the extended wings, you can't really do this in dense atmosphere because it'll tear apart. Anyway, you can go from "rigged for flying" to "in the tent" whenever you like once it's open, and when you're in the tent you can see orbital paths, science experiments, emails from the surface, and so on.
...
The actual GAME part of this thing involves interacting with people on the surface. There are still plenty of people in this fantastical future, although there are very few compared to the 8 billion we have. More like a million, living relatively easy lives with an incredibly high level of technology. Most of them are interested in trading, or in giving you scientific missions.
There are five categories of task, although they certainly aren't exclusive and you can often do several at once if you figure out how.
Salvage/survey is the most basic mission. Because the population is so low, most of the world is empty of humans. While the maps of these areas are generally accurate in a topological sense, you can often find things that aren't topological. An old computer that still works, a junkyard nobody's raided, a cache of DVDs... some you can actually load into your cargo pocket and fly away with, while others you'll need to tag for pickup by whoever is closest. The advantage of loading it into your cargo pocket is that you can deliver it to wherever you like, while tagging always benefits the person closest to you rather than whoever you like. Either way, you get credit.
Cargo missions are pretty straightforward. Everyone is willing to trade, whether in credits or barter. Sometimes you'll run with whatever cargo you happen to want to, other times you might get a specific cargo with a specific delivery requirement. Because every pound added to the Sun Wing makes it harder to travel, you'll usually carry very low-weight goods such as data chips, computer components, spices, genetic samples, DVDs, and so on. You can carry heavier goods, but to do that you'll generally want to take off from a zeppelin or carrier, which limits where you can start from. Of course, not all places are easy to land in, either...
Data missions are a staple. Because of the heavy debris fields in orbit, there are few satellites. Therefore, you'll often find it useful to stand in as a temporary satellite, relaying transmissions, taking pictures, and so on. You may even be asked to deploy a temporary satellite as cargo. There are a few similar missions that happen in the atmosphere, normally wind-mapping, but this is primarily an orbital/suborbital thing.
Manufacturing missions might be possible when you've upgraded your wing, or launched from a zeppelin. The rig for manufacturing things is sometimes a bit heavy, but the point is that certain things can only be manufactured in orbit, whether because of the zero gravity, the magnetic fields, or the radiation. Manufacturing normally has strict requirements about the conditions - for example "only in the shadow of the planet" or "only when passing over the poles". Because of this, an understanding of basic orbital mechanics and a steady hand on the time accelerator is required or you'll end up corrupting the batch.
Lastly, there's space ops. This generally involves refueling and maintaining the few satellites there are, although you can also salvage from debris fields, perform debris cleanup, and even launch new permanent satellites if your wing has been upgraded to the point where it can carry that kind of payload.
It needs to be stressed that these missions aren't for the sake of doing these missions. Every mission you do, whether it was a request or just something you wanted to do, improves the life of a local. The more resources and connections a local has, the happier and healthier they are, and the more friendly they are to you. Obviously, with a million random people, it's not like every one of them then turns around and gives you an upgraded Sun Wing module, but everyone at least contributes what they can. Whether it's a paint job, a pretty picture, some clothes, or just agreeing to store your stuff for you. And, of course, they help each other out - someone who can't give you anything will still help all their neighbors, which effectively means you went on a bit of mission for them, too.
The world is large, so part of the fun is exploring the surface bit by bit, and finding some places to call "home" with people you like to help and hang out with between missions. Of course, you can use time acceleration to blitz through every landing and spend almost all your player time in the sky, it's up to you.
...
All combined, the idea is to have a kind of movement that is a lot of fun, transitioning organically between glider, jet, and spacecraft. The somewhat complex array of resources to manage during flight gives you a level of fine control over things like how long you can stay in space, and there's enough skill involved that you can polish your skills for a while.
The setting gives you a bunch of resources in a lot of places - some reliably in a given place, some that need to be stumbled across, and some that are midway between. The steady improvements to yourself and the human inhabitants gives the world some constructive longevity.
There is also a lot of opportunity for multiplayer, whether with NPC Sun Wings or other players. Docking up in space, landing together, trading tech modules, transferring cargo or fuel in midair, creating transmission networks out of spaced-out Sun Wings so that people even further apart can communicate...
In the end, the point is to have a design that can be easily implemented at the most basic level (the mechanics of the glider) and then easily expanded to include the rest of the stuff. Hopefully, that will allow me to release iterative demos, each of which is fun to play in its own right.
Wednesday, November 06, 2013
Monday, November 04, 2013
Doing Animation Wright
I like the new Phoenix Wright game. It translated everything into 3D, so all the characters are 3D models (or very convincing pseudo-3D models). The art style survived almost entirely intact, aside from some damage to the way that hair looks.
But there is one big change that I think I finally figured out.
The motions inherited from the old games (TAKE THAT! WHHAAAAT!) look robotic and excessive. But not all the animations look robotic: a lot of animations originating in this game seem very natural and powerful. It's not universal. Some old motions translate very well, and some new motions are awkward.
It took me a while to figure out why that is.
It's the framerate.
The old games literally used animated GIFs. The frame rate was very low. Because of this, you couldn't really create secondary nuances very easily. Instead, you usually take advantage of the low framerate to put serious "pop" into your animations, the same way you might cut a frame out of a cartoon to give it some extra pop. So the classic style was to cut to just before the primary stance and use a simple "pop" animation to bring the stance to the fore. You put in plenty of exaggeration to make it pop properly.
The classic example is the "TAKE THAT" finger point, along with most of the other lawyer animations such as lashing a whip, pounding on the table, having toupees blown off, and so on. The panicked animations for various witnesses are also done like this. These are perfectly suited for the low frame rate - they take a simple stance and use a POP animation to transition into the final stance.
There are a lot of examples of nuanced animations in the old games, too, usually on the part of people who don't get excited. The most iconic is probably Trucy's bounce. Put her in her primary stance and then just create a subtle bounce. The secondary animation of her hair and cape follow in turn, and make it a very engaging animation. There are other examples, such as Gumshoe's head-scratch, but in all cases these subtler animations were fighting against the GIF format, squeezed into a low framerate and with a significant file size cost.
But in the new game, those are the animations that shine. With 4x the old frame rate and no significant file size problems, the animations can be as subtle as you like. Moreover, nuances and secondary events can easily be put in.
You can easily see this with Trucy's new bounce, which is identical to the old bounce except that the secondary animation is a really intricate ripple. Another clear example is the first witness' hair-pull action, where she tugs on her long braids and causes them to stretch. The new heroine's BLEAH face also has some really great nuanced animations that shine in this new format.
But the old animation style looks awkward and stilted. Just compare the hair pull animation from our first witness to two of her other animations: letting the hair bounce into her eyes, and pulling down a flower inhaler off her hat. Both of these are obviously done in the old style, with a simple starting pose followed by a straight-through exaggerated motion into the final pose. At eight frames a second, they would look great. At ~32, they look clumsy.
It's clear to me that the animation team was working through this same thought process and will probably continue to polish their presentation in later games.
I don't think that big gestures are coming to an end in Phoenix Wright. It's not the big gestures that are bad, it's the oldschool "pop" animation style. There are big gestures which work, such as Trucy's magic trick. But these gestures don't pop into exaggerated existence. Instead they follow a more refined style with standard pre-motion countermotion and a feeling of weight and substance. It is a better animation style, and it's the one they'll use now that they're no longer trapped by GIF.
Of course, the "POP" of the old animations will be missed... they'll have to find some way to make the new animations as explosive and iconic.
But there is one big change that I think I finally figured out.
The motions inherited from the old games (TAKE THAT! WHHAAAAT!) look robotic and excessive. But not all the animations look robotic: a lot of animations originating in this game seem very natural and powerful. It's not universal. Some old motions translate very well, and some new motions are awkward.
It took me a while to figure out why that is.
It's the framerate.
The old games literally used animated GIFs. The frame rate was very low. Because of this, you couldn't really create secondary nuances very easily. Instead, you usually take advantage of the low framerate to put serious "pop" into your animations, the same way you might cut a frame out of a cartoon to give it some extra pop. So the classic style was to cut to just before the primary stance and use a simple "pop" animation to bring the stance to the fore. You put in plenty of exaggeration to make it pop properly.
The classic example is the "TAKE THAT" finger point, along with most of the other lawyer animations such as lashing a whip, pounding on the table, having toupees blown off, and so on. The panicked animations for various witnesses are also done like this. These are perfectly suited for the low frame rate - they take a simple stance and use a POP animation to transition into the final stance.
There are a lot of examples of nuanced animations in the old games, too, usually on the part of people who don't get excited. The most iconic is probably Trucy's bounce. Put her in her primary stance and then just create a subtle bounce. The secondary animation of her hair and cape follow in turn, and make it a very engaging animation. There are other examples, such as Gumshoe's head-scratch, but in all cases these subtler animations were fighting against the GIF format, squeezed into a low framerate and with a significant file size cost.
But in the new game, those are the animations that shine. With 4x the old frame rate and no significant file size problems, the animations can be as subtle as you like. Moreover, nuances and secondary events can easily be put in.
You can easily see this with Trucy's new bounce, which is identical to the old bounce except that the secondary animation is a really intricate ripple. Another clear example is the first witness' hair-pull action, where she tugs on her long braids and causes them to stretch. The new heroine's BLEAH face also has some really great nuanced animations that shine in this new format.
But the old animation style looks awkward and stilted. Just compare the hair pull animation from our first witness to two of her other animations: letting the hair bounce into her eyes, and pulling down a flower inhaler off her hat. Both of these are obviously done in the old style, with a simple starting pose followed by a straight-through exaggerated motion into the final pose. At eight frames a second, they would look great. At ~32, they look clumsy.
It's clear to me that the animation team was working through this same thought process and will probably continue to polish their presentation in later games.
I don't think that big gestures are coming to an end in Phoenix Wright. It's not the big gestures that are bad, it's the oldschool "pop" animation style. There are big gestures which work, such as Trucy's magic trick. But these gestures don't pop into exaggerated existence. Instead they follow a more refined style with standard pre-motion countermotion and a feeling of weight and substance. It is a better animation style, and it's the one they'll use now that they're no longer trapped by GIF.
Of course, the "POP" of the old animations will be missed... they'll have to find some way to make the new animations as explosive and iconic.
Thursday, October 31, 2013
Refine the Constraint
Last essay, I talked about a space game where you use a railgun to shoot a payload into the upper atmosphere, radically reducing the need for a complex launch stage. The downside of this would be that you would have to shape the payload to fit into the railgun's track, meaning a single stack, say 3m wide. The restriction allows for the player to carefully try to cram more functionality into that constraint, which provides a lot of the challenge and also a lot of the progression (smaller, more powerful parts).
The problem with this approach in my original vision was that the cramming only started when you started to think of complex payloads. I was still thinking of a lot of the basics as simply being stack components. Like Kerbal: you have a full-width fuel tank, a full-width engine. There's no cramming involved - you just stack them. But it didn't feel right. Engines are still a major part of the game, and to have them be supremely oversimplified seemed like it was undercutting my mechanic.
A real rocket engine isn't simply "fuel flows into the nozzle and explodes". Or, rather, it is at the most basic level, but we can allow it to be a lot more interesting. This can be part of the career mode, just like discovering mechanical struts or SAS or whatever. Just like you aren't required to actually understand the math behind things like SAS modules, you don't have to understand the math behind a rocket engine.
You might start off by choosing a nozzle and, for your first rocket, just mounting a mixing valve on top of it, and then run some pipes from the fuel tanks to the mixing valve. There you go. Rocket engine. (We'll ignore the igniter.)
Of course, this is quite a simple rocket engine that requires the fuel to be kept under pressure. The burn rate is restricted by how fast the fuel tanks push fuel into the valve. The valve can certainly reduce that from max - you can throttle down easily enough. But increasing it above that maximum is impossible, so the resulting rocket has a very low maximum burn rate.
So you research a pump that sucks fuel in. It goes between the valve and the nozzle, and is visually just a bulgy chamber with a pipe in and pipe out connection. This allows you to pull in a lot more fuel, giving you a much higher max burn rate regardless of tank pressure. It does only work so well, but you can always stack them together if you can fit them into the 3m restricted space the launch method allows. (In reality, you'd only ever use one, and you'd just make it bigger and more powerful. However, that doesn't fit as well into our game mechanic.)
This pump works great, but you find that you frequently overheat. So you research a nozzle with a heat exchanger built into it. That's the loop and bulge that's attached between the nozzle and the combustion chamber. The heat exchanger hooks into the pump, so you can run ice-cold fresh fuel around the chamber, heating the fuel and cooling the chamber - both good. If you want to you can run other, dedicated coolants through instead - that's up to you. The more effective the cooling of the chamber and the heating of the fuel, the better the efficiency.
And there's no reason you can't have four nozzles bunched up, fed from a single valve... you have tons of options. You can even use mechanical winches to separate the nozzles to wider than the 3m limit once you've launched... Then you invent the gimbal, and so on. The complexity is introduced piece by piece, and you never feel lost. You are the source of most of the complexity.
The key here is that we're integrating the design of the rocket engine into the core play mechanic. Even our fuel tanks: we don't have a big orange "LOX" tank. The player would create each of the two (or more) internal tanks separately, and run pipes. Externally you could paint it orange and nobody would be able to tell, but by making the player build them separate internally you make the player choose what kind of configuration they want, whether they need to add coolant systems or pressurization modules, whether they want to cram the fuel canisters tightly together or leave plenty of room... options.
Since our core play is all about arranging components within the constraint, the rockets and fuel offer a very good early guide to the concept, as well as allowing us to gently explain that empty space is not the enemy. Gaps between the two LOX fuel tanks are not evil, nor is the empty space around the rocket valve. The constraint isn't "fill all empty space", but "get everything into something less than 3m diameter".
Anyway, the other half of this lesson is designing your first command module, cramming in seats and computers and shit.
The problem with this approach in my original vision was that the cramming only started when you started to think of complex payloads. I was still thinking of a lot of the basics as simply being stack components. Like Kerbal: you have a full-width fuel tank, a full-width engine. There's no cramming involved - you just stack them. But it didn't feel right. Engines are still a major part of the game, and to have them be supremely oversimplified seemed like it was undercutting my mechanic.
A real rocket engine isn't simply "fuel flows into the nozzle and explodes". Or, rather, it is at the most basic level, but we can allow it to be a lot more interesting. This can be part of the career mode, just like discovering mechanical struts or SAS or whatever. Just like you aren't required to actually understand the math behind things like SAS modules, you don't have to understand the math behind a rocket engine.
You might start off by choosing a nozzle and, for your first rocket, just mounting a mixing valve on top of it, and then run some pipes from the fuel tanks to the mixing valve. There you go. Rocket engine. (We'll ignore the igniter.)
Of course, this is quite a simple rocket engine that requires the fuel to be kept under pressure. The burn rate is restricted by how fast the fuel tanks push fuel into the valve. The valve can certainly reduce that from max - you can throttle down easily enough. But increasing it above that maximum is impossible, so the resulting rocket has a very low maximum burn rate.
So you research a pump that sucks fuel in. It goes between the valve and the nozzle, and is visually just a bulgy chamber with a pipe in and pipe out connection. This allows you to pull in a lot more fuel, giving you a much higher max burn rate regardless of tank pressure. It does only work so well, but you can always stack them together if you can fit them into the 3m restricted space the launch method allows. (In reality, you'd only ever use one, and you'd just make it bigger and more powerful. However, that doesn't fit as well into our game mechanic.)
This pump works great, but you find that you frequently overheat. So you research a nozzle with a heat exchanger built into it. That's the loop and bulge that's attached between the nozzle and the combustion chamber. The heat exchanger hooks into the pump, so you can run ice-cold fresh fuel around the chamber, heating the fuel and cooling the chamber - both good. If you want to you can run other, dedicated coolants through instead - that's up to you. The more effective the cooling of the chamber and the heating of the fuel, the better the efficiency.
And there's no reason you can't have four nozzles bunched up, fed from a single valve... you have tons of options. You can even use mechanical winches to separate the nozzles to wider than the 3m limit once you've launched... Then you invent the gimbal, and so on. The complexity is introduced piece by piece, and you never feel lost. You are the source of most of the complexity.
The key here is that we're integrating the design of the rocket engine into the core play mechanic. Even our fuel tanks: we don't have a big orange "LOX" tank. The player would create each of the two (or more) internal tanks separately, and run pipes. Externally you could paint it orange and nobody would be able to tell, but by making the player build them separate internally you make the player choose what kind of configuration they want, whether they need to add coolant systems or pressurization modules, whether they want to cram the fuel canisters tightly together or leave plenty of room... options.
Since our core play is all about arranging components within the constraint, the rockets and fuel offer a very good early guide to the concept, as well as allowing us to gently explain that empty space is not the enemy. Gaps between the two LOX fuel tanks are not evil, nor is the empty space around the rocket valve. The constraint isn't "fill all empty space", but "get everything into something less than 3m diameter".
Anyway, the other half of this lesson is designing your first command module, cramming in seats and computers and shit.
Tuesday, October 29, 2013
Constraint is Interesting
STILL THINKING ABOUT SPACE GAMES.
Last essay I talked about the idea of adding mechanical polymorphism. Things like arms that can transfer goods and whatever else I could come up with. But it didn't feel compelling. Today I'm going to restrict that mechanical polymorphism while talking about research. It's more interesting than it sounds.
Fundamentally, it is very compelling to unlock more stuff. It's interesting to go on a mission using a bunch of shitty components so that you unlock a better version of one of them so you can go on more missions. It's very compelling. But I don't like rocket launches as a primary mechanic. What can we use besides that?
How about a railgun? A hundred miles of magnetic rail that shoot you off the top of a mountain. This takes care of the first launch stages, so your designs can focus on the more interesting final stages and payload.
But if you take out the launch stage, you lose a lot of research potential. A big part of discovering more modules is discovering better launch modules. Larger tanks, larger engines, better fuel management... take that out, and what do you have?
Well, a lot, of course. You can focus complexity and growth into anything.
See, the biggest restriction is still the launch platform. But instead of being a giant cluster of rockets, it's a railgun. The railgun never changes, nor does the atmosphere. So our payload has to be a specific kind of shape to properly fire from the railgun, and has to be aerodynamic enough not to tumble, shatter, or excessively brake in the atmosphere. IE, it has to be one stack.
So our progress up the tech tree isn't about "bigger", but "smaller". For example, an early generation computer might be the same size as a cockpit - but after a few thousand science points, you can use something the size of a thumb that has hundreds of times more power. Similarly, you might start with inefficient solar panels pasted to the sides of the chassis, then figure out how to make versions that fold out a bit when you reach orbit, then figure out how to make them massively expand - the exact size and weight of the payload component will vary, but the final result will be significantly better.
There's no reason to leave the simple stuff behind, though. You can also figure out how to use solar paint - no folding out, but ultra-lightweight and quite efficient. Similarly, there are times when you'll still want a giant computer on your payload - but the new giant computers are so much better than the old ones. So there's always a lot of possibilities.
The biggest and most interesting challenge to this is the "unfolding". It's pretty easy to attach rockets and stuff, get the payload going in the right direction. But a lot of payloads will want to be in some shape besides "stack of fuel tanks". For example, you might want a space station with long struts, or a lander that has a dome shape. The launch profile has to be a stack, but you can always make some components of that stack fold out, inflate, assemble, or otherwise change shape.
For example, you might create a stack where you have a four-arm fold-out module that will create a 4-way perpendicular set of arms. But what's at the end of the arms?
Well, whatever you originally packed in line with the column, crowded into a stack segment divided four ways. And maybe one of the things crammed into that space is, in fact, another mechanical device which folds out and in turn has its own divided substack segment... You can see that we've changed the name of the game from "more fuel and rockets" to "packing shit in more efficiently". Rocket Tetris.
There's a lot of room for manual labor, here. Not everything can always be packed in line with the stack, so maybe you send it up in another payload, or maybe it's in a different part of the stack, a place where you could fit it. Then an astronaut puts the two pieces together manually.
There's a lot of fun complexity hiding in this concept, and it's a much deeper and more interesting concept than the ones I've come up with previously. I don't want to go into excessive detail about the play cases here, but if you try to imagine how you might drop a rover on the moon using this kind of system, I think you can start to see how interesting it might get.
By adding a strict constraint (everything must go in one stack, no projections) we add a lot of depth in trying to work within that constraint.
As usual, there is a good reminder in this. Games are born more out of constraint than freedom. I tend to forget that.
Last essay I talked about the idea of adding mechanical polymorphism. Things like arms that can transfer goods and whatever else I could come up with. But it didn't feel compelling. Today I'm going to restrict that mechanical polymorphism while talking about research. It's more interesting than it sounds.
Fundamentally, it is very compelling to unlock more stuff. It's interesting to go on a mission using a bunch of shitty components so that you unlock a better version of one of them so you can go on more missions. It's very compelling. But I don't like rocket launches as a primary mechanic. What can we use besides that?
How about a railgun? A hundred miles of magnetic rail that shoot you off the top of a mountain. This takes care of the first launch stages, so your designs can focus on the more interesting final stages and payload.
But if you take out the launch stage, you lose a lot of research potential. A big part of discovering more modules is discovering better launch modules. Larger tanks, larger engines, better fuel management... take that out, and what do you have?
Well, a lot, of course. You can focus complexity and growth into anything.
See, the biggest restriction is still the launch platform. But instead of being a giant cluster of rockets, it's a railgun. The railgun never changes, nor does the atmosphere. So our payload has to be a specific kind of shape to properly fire from the railgun, and has to be aerodynamic enough not to tumble, shatter, or excessively brake in the atmosphere. IE, it has to be one stack.
So our progress up the tech tree isn't about "bigger", but "smaller". For example, an early generation computer might be the same size as a cockpit - but after a few thousand science points, you can use something the size of a thumb that has hundreds of times more power. Similarly, you might start with inefficient solar panels pasted to the sides of the chassis, then figure out how to make versions that fold out a bit when you reach orbit, then figure out how to make them massively expand - the exact size and weight of the payload component will vary, but the final result will be significantly better.
There's no reason to leave the simple stuff behind, though. You can also figure out how to use solar paint - no folding out, but ultra-lightweight and quite efficient. Similarly, there are times when you'll still want a giant computer on your payload - but the new giant computers are so much better than the old ones. So there's always a lot of possibilities.
The biggest and most interesting challenge to this is the "unfolding". It's pretty easy to attach rockets and stuff, get the payload going in the right direction. But a lot of payloads will want to be in some shape besides "stack of fuel tanks". For example, you might want a space station with long struts, or a lander that has a dome shape. The launch profile has to be a stack, but you can always make some components of that stack fold out, inflate, assemble, or otherwise change shape.
For example, you might create a stack where you have a four-arm fold-out module that will create a 4-way perpendicular set of arms. But what's at the end of the arms?
Well, whatever you originally packed in line with the column, crowded into a stack segment divided four ways. And maybe one of the things crammed into that space is, in fact, another mechanical device which folds out and in turn has its own divided substack segment... You can see that we've changed the name of the game from "more fuel and rockets" to "packing shit in more efficiently". Rocket Tetris.
There's a lot of room for manual labor, here. Not everything can always be packed in line with the stack, so maybe you send it up in another payload, or maybe it's in a different part of the stack, a place where you could fit it. Then an astronaut puts the two pieces together manually.
There's a lot of fun complexity hiding in this concept, and it's a much deeper and more interesting concept than the ones I've come up with previously. I don't want to go into excessive detail about the play cases here, but if you try to imagine how you might drop a rover on the moon using this kind of system, I think you can start to see how interesting it might get.
By adding a strict constraint (everything must go in one stack, no projections) we add a lot of depth in trying to work within that constraint.
As usual, there is a good reminder in this. Games are born more out of constraint than freedom. I tend to forget that.
Friday, October 25, 2013
Machine Dance
Several people have suggested that I basically remake Kerbal, since I love it so much. Well, there's not much point in that: Kerbal has some flaws and some design choices I wouldn't have made, but fundamentally it's very well done. If I want more Kerbal, I'll just play Kerbal.
But it is true that I want to build something that draws on Kerbal's inspiration. The reason I keep going back to Kerbal and talking about it ad nauseam is because it's really pretty unique. Even though the concept has been done before, it's never been executed like this.
At the end of the day, there are a lot of things I want to learn from Kerbal... but it's not a game I'm interested in making. The focus is all wrong. Kerbal is focused too much on physics and launching, which are not what I want to talk about. I'm happy to play a game about them, but in order for me to be interested in making a game, I have to have something I want to talk about... and the physics of rockets aren't really high on my list.
Instead, I'd prefer to talk about the other parts the space age. Science, inhabiting inhospitable worlds, getting along in zero gravity, the long isolation of a space station, the scare of relying on machines... to me, these are all more interesting things to talk about. They don't have a damn thing to do with launch or landing physics.
It might be a mistake to keep chanting "KERRRBBALLL" while thinking about gameplay that's so far removed from the core idea of Kerbal. It's a preoccupation I need to shake.
Instead, I'd like to talk about the idea of the machine dance. First, however, I need to talk about player generated content.
In brief, there are a few different types of gameplay rolled into a content creation tool.
One is the "model kit" style. This is when the player wants to create something they invented or imported, with only weak ties to in-game functionality. This is building a mansion or a sky castle in Minecraft, or trying to make a perfect moon lander replica in Kerbal.
Another is the "extended function" style. This is when you try to absolutely maximize the statistics of the product. This is asparagus staging in Kerbal, or growing wheat in Minecraft. Without much concern towards aesthetics, you try to crush the constraints that normally slow you down.
The last I can see is the "alternate function" style. This is when you try to do something different with the tools, but rather than having a specific model in mind, you are aiming for new functionality. This is creating songs and computers in Minecraft, or a self-assembling robot base in Kerbal. These are not things that the game preassembles for you, nor are they constraints that you normally deal with. The weakness of alternate function is mostly in whether or not the end product is useful or entertaining.
In many (most?) cases, some combination of the three is what you end up using at any given time. For example, a beautiful "flower" that unfolds in space, perfect for creating a massive comm system that can handle dozens of satellites.
With that in mind, I'd like to talk about the idea of the machine dance.
This concept is about making the system interact with itself much more aggressively. Rather than focusing mostly on how you interact with the outside world, we need to focus on the system interacting with itself. This is important because most of the space topics I find interesting are about how the systems work in and of themselves, not how they confront the world around them. The whole point is that there is very rarely any world around!
One way to do this is to create systems that work over time, changing slightly along the long mission hours. Fuel is burned as you accelerate, so if you want a truly long-term space ship, you'll need some way to generate fuel. So you include a component that generates fuel.
However, this doesn't add gameplay! It actually removes gameplay - the difficulty in loading up enough fuel is gone. So in order to make this worthwhile, you have to recalibrate your difficulty to make the generating fuel thing interesting.
One way to do it is to make it extremely chunky. For example, generated fuel isn't piped into the engine's fuel tank, but into a capsule. Then you have to exchange the empty canister in the engine for the full canister in the generator, either manually or using an automated robot arm. This activity strongly constrains the patterns in which you can use your engines.
Another option is to make the generation itself constrained. For example, requiring you to be facing the sun, or generating a massive amount of heat, or any number of other constraints that actively interfere with the performance of other components.
Both of these options inter-relate the various components and activities of the system. When you build an engine, you have to consider how your replacement canisters are going to move into place. You have to consider whether it'll work in deep space, or whether the waste heat from the engines will overheat the generator and visa-versa, and whether that interferes with the science module. The system has become much more tightly inter-related because each of the components has a set of constraints and effects that are turned on and off as you like.
I think this is the secret to making base building interesting: mode-changing topological challenges. It's not simply a matter of whether you have a bio lab or not. It's whether your bio lab is placed in a way where it can be used reliably, where there's no interference from the radiation lab, or from the vibrating engines. It's the pattern in which you can use the bio lab, and whether you have to wait six months without turning on any other systems in order to complete the bio experiments. And it's all organic: the player is allowed to design a ship where the lab is located whever she likes, and it matters.
But the mechanic runs deeper. I mentioned that you could either run the fresh canister over to the engine with a person... or with an automated mechanical arm. And here is the "dance" part of the machine dance.
The idea isn't to simply design a bunch of things that turn on and off optimally. There's a lot of fun to be had in designing it to reconfigure itself in certain ways, allowing you to have a lot of freedom as to what things are doing what.
Mechanical arms are one of the things. There's a lot of potential play hidden there: mechanical arms that swing through a shared space and have to be careful not to strike each other. Gantries that arms can slide along, so they can carry inventory long distances and stow it in cargo stacks.
But there's a lot of stuff besides mechanical arms. For example, you might mechanically rearrange your modules so that they are more optimally arrayed. You might print out a new module using a 3D printer, then reabsorb it. You might have a module which inflates/unfolds, giving you a lot more interior room but cramping the exterior and becoming fragile. You might even have sliding gantries for entire hubs, allowing you to dock hubs with the hubs above or below them... or put a space gap between them when your modules need to be separated due to heat generation or whatever.
Mechanical reconfiguration is fun ish, but it's limited to the clear and uninspiring rules of mechanical devices. You move devices because you need them to have less noise, or a direct connection to another node - these are simple restrictions that are difficult to build arbitrary complexity into. In the end, the complexity probably hits a pretty basic wall where you figure out how to move things in an optimal way and that's that. There's nothing fundamentally different about scaling it up or aiming for something more complex.
To make that matter, we have two options. One is to add in additional complexity when you rescale or add functionality. For example, we might have a "heavy core" system where modules in the stack don't stack along the center, but instead stud the sides. This would offer a more complex way to inter-relate modules as there's now two dimensions of contact rather than one. Similarly, the mechanics of moving them around would be a bit different. We might add in some kind of "laser bond" where modules can be connected over a distance by a high-powered laser to provide information or particles or whatever, which in turn means neither of those modules can be moved while the laser is active. This would also allow us to have mirrors, which could be used to redirect the flow in real-time so that you COULD move laser-bonded modules as long as there was a tracking mirror installed... and, of course, you could just build laser light shows for fun.
Tossing things around could also be fun, allowing you to have very long or large stations. Instead of using an arm to drag something from point A to point B, arm A tosses it through space to arm B. Works fine... as long as your engines are off. Wires could also be used to slide along or reel things in... so there are options as to how to add complexity, and you could make it very interesting by adding in different kinds of complexity for different sizes and functionalities.
But the other option is that we can add in a human element. Right now the space station is just a mechanical device. There's certainly something compelling about a big aluminum tin can, but most construction games include people for a reason. People are compelling. Even if it's something as basic as Kerbal's nearly useless astronauts.
I think we could easily integrate astronauts into this machine dance game by simply making them move around inside the modules. So the 'outside' of the modules is where all the mechanical stuff happens, but managing the 'inside' is a separate challenge.
Some parts of it would be pretty basic. Everyone needs a place to sleep and so much air and so on. But you don't have to manually dictate that stuff. Astronauts is smrt. They can figure out how to get from work to their bed without your help, even if it does require them to go on a space walk. Instead, you handle their work assignments.
Astronauts can be assigned to specific modules for work. This allows modules to be vastly more productive depending on whether astronauts have been assigned. It also allows us to give each module three states instead of two. Instead of just "on" or "off", we have "off", "holding", and "active". The bio lab can be put in "holding", where the projects are put into a slow-moving crawl but not canceled. It is less sensitive to interference and has fewer requirements/interference of its own.
The thing I like about astronauts is that you can introduce them as a helpful way to make your modules more productive... then steadily introduce their personalities as the mission continues. Anyone capable of going into space is going to be able to work for a week without letting their idiosyncrasies interfere with their jobs. A month, maybe. Depends on the person.
But at some point, the astronauts are going to begin forming lives in space. They'll start to have relationships, good and bad. They'll get lonely, or want to work on their hobbies. The more time passes, the more the astronauts resemble humans instead of cogs.
This doesn't degrade their work. On the contrary, properly managed it will actually enhance their work, because they're getting used to how things work and are healthy and happy. But you have to manage them. This isn't simply having the right modules installed: you need to massage their personal lives by changing where they tend to go and who else tends to go to those places.
Which is a topological challenge that can be worked through by mechanically rearranging modules and changing their primary assignment.
To make matters more interesting, you can have certain things generate only when astronauts have acclimatized to space: producing cultural goods such as movies, songs, babies, etc. These can have value if you can wrangle them properly, and exactly what kind of life you give your astronauts will change what kinds of cultural goods they create.
Anyway, just thinking aloud. Brewing ideas, as usual.
But it is true that I want to build something that draws on Kerbal's inspiration. The reason I keep going back to Kerbal and talking about it ad nauseam is because it's really pretty unique. Even though the concept has been done before, it's never been executed like this.
At the end of the day, there are a lot of things I want to learn from Kerbal... but it's not a game I'm interested in making. The focus is all wrong. Kerbal is focused too much on physics and launching, which are not what I want to talk about. I'm happy to play a game about them, but in order for me to be interested in making a game, I have to have something I want to talk about... and the physics of rockets aren't really high on my list.
Instead, I'd prefer to talk about the other parts the space age. Science, inhabiting inhospitable worlds, getting along in zero gravity, the long isolation of a space station, the scare of relying on machines... to me, these are all more interesting things to talk about. They don't have a damn thing to do with launch or landing physics.
It might be a mistake to keep chanting "KERRRBBALLL" while thinking about gameplay that's so far removed from the core idea of Kerbal. It's a preoccupation I need to shake.
Instead, I'd like to talk about the idea of the machine dance. First, however, I need to talk about player generated content.
In brief, there are a few different types of gameplay rolled into a content creation tool.
One is the "model kit" style. This is when the player wants to create something they invented or imported, with only weak ties to in-game functionality. This is building a mansion or a sky castle in Minecraft, or trying to make a perfect moon lander replica in Kerbal.
Another is the "extended function" style. This is when you try to absolutely maximize the statistics of the product. This is asparagus staging in Kerbal, or growing wheat in Minecraft. Without much concern towards aesthetics, you try to crush the constraints that normally slow you down.
The last I can see is the "alternate function" style. This is when you try to do something different with the tools, but rather than having a specific model in mind, you are aiming for new functionality. This is creating songs and computers in Minecraft, or a self-assembling robot base in Kerbal. These are not things that the game preassembles for you, nor are they constraints that you normally deal with. The weakness of alternate function is mostly in whether or not the end product is useful or entertaining.
In many (most?) cases, some combination of the three is what you end up using at any given time. For example, a beautiful "flower" that unfolds in space, perfect for creating a massive comm system that can handle dozens of satellites.
With that in mind, I'd like to talk about the idea of the machine dance.
This concept is about making the system interact with itself much more aggressively. Rather than focusing mostly on how you interact with the outside world, we need to focus on the system interacting with itself. This is important because most of the space topics I find interesting are about how the systems work in and of themselves, not how they confront the world around them. The whole point is that there is very rarely any world around!
One way to do this is to create systems that work over time, changing slightly along the long mission hours. Fuel is burned as you accelerate, so if you want a truly long-term space ship, you'll need some way to generate fuel. So you include a component that generates fuel.
However, this doesn't add gameplay! It actually removes gameplay - the difficulty in loading up enough fuel is gone. So in order to make this worthwhile, you have to recalibrate your difficulty to make the generating fuel thing interesting.
One way to do it is to make it extremely chunky. For example, generated fuel isn't piped into the engine's fuel tank, but into a capsule. Then you have to exchange the empty canister in the engine for the full canister in the generator, either manually or using an automated robot arm. This activity strongly constrains the patterns in which you can use your engines.
Another option is to make the generation itself constrained. For example, requiring you to be facing the sun, or generating a massive amount of heat, or any number of other constraints that actively interfere with the performance of other components.
Both of these options inter-relate the various components and activities of the system. When you build an engine, you have to consider how your replacement canisters are going to move into place. You have to consider whether it'll work in deep space, or whether the waste heat from the engines will overheat the generator and visa-versa, and whether that interferes with the science module. The system has become much more tightly inter-related because each of the components has a set of constraints and effects that are turned on and off as you like.
I think this is the secret to making base building interesting: mode-changing topological challenges. It's not simply a matter of whether you have a bio lab or not. It's whether your bio lab is placed in a way where it can be used reliably, where there's no interference from the radiation lab, or from the vibrating engines. It's the pattern in which you can use the bio lab, and whether you have to wait six months without turning on any other systems in order to complete the bio experiments. And it's all organic: the player is allowed to design a ship where the lab is located whever she likes, and it matters.
But the mechanic runs deeper. I mentioned that you could either run the fresh canister over to the engine with a person... or with an automated mechanical arm. And here is the "dance" part of the machine dance.
The idea isn't to simply design a bunch of things that turn on and off optimally. There's a lot of fun to be had in designing it to reconfigure itself in certain ways, allowing you to have a lot of freedom as to what things are doing what.
Mechanical arms are one of the things. There's a lot of potential play hidden there: mechanical arms that swing through a shared space and have to be careful not to strike each other. Gantries that arms can slide along, so they can carry inventory long distances and stow it in cargo stacks.
But there's a lot of stuff besides mechanical arms. For example, you might mechanically rearrange your modules so that they are more optimally arrayed. You might print out a new module using a 3D printer, then reabsorb it. You might have a module which inflates/unfolds, giving you a lot more interior room but cramping the exterior and becoming fragile. You might even have sliding gantries for entire hubs, allowing you to dock hubs with the hubs above or below them... or put a space gap between them when your modules need to be separated due to heat generation or whatever.
Mechanical reconfiguration is fun ish, but it's limited to the clear and uninspiring rules of mechanical devices. You move devices because you need them to have less noise, or a direct connection to another node - these are simple restrictions that are difficult to build arbitrary complexity into. In the end, the complexity probably hits a pretty basic wall where you figure out how to move things in an optimal way and that's that. There's nothing fundamentally different about scaling it up or aiming for something more complex.
To make that matter, we have two options. One is to add in additional complexity when you rescale or add functionality. For example, we might have a "heavy core" system where modules in the stack don't stack along the center, but instead stud the sides. This would offer a more complex way to inter-relate modules as there's now two dimensions of contact rather than one. Similarly, the mechanics of moving them around would be a bit different. We might add in some kind of "laser bond" where modules can be connected over a distance by a high-powered laser to provide information or particles or whatever, which in turn means neither of those modules can be moved while the laser is active. This would also allow us to have mirrors, which could be used to redirect the flow in real-time so that you COULD move laser-bonded modules as long as there was a tracking mirror installed... and, of course, you could just build laser light shows for fun.
Tossing things around could also be fun, allowing you to have very long or large stations. Instead of using an arm to drag something from point A to point B, arm A tosses it through space to arm B. Works fine... as long as your engines are off. Wires could also be used to slide along or reel things in... so there are options as to how to add complexity, and you could make it very interesting by adding in different kinds of complexity for different sizes and functionalities.
But the other option is that we can add in a human element. Right now the space station is just a mechanical device. There's certainly something compelling about a big aluminum tin can, but most construction games include people for a reason. People are compelling. Even if it's something as basic as Kerbal's nearly useless astronauts.
I think we could easily integrate astronauts into this machine dance game by simply making them move around inside the modules. So the 'outside' of the modules is where all the mechanical stuff happens, but managing the 'inside' is a separate challenge.
Some parts of it would be pretty basic. Everyone needs a place to sleep and so much air and so on. But you don't have to manually dictate that stuff. Astronauts is smrt. They can figure out how to get from work to their bed without your help, even if it does require them to go on a space walk. Instead, you handle their work assignments.
Astronauts can be assigned to specific modules for work. This allows modules to be vastly more productive depending on whether astronauts have been assigned. It also allows us to give each module three states instead of two. Instead of just "on" or "off", we have "off", "holding", and "active". The bio lab can be put in "holding", where the projects are put into a slow-moving crawl but not canceled. It is less sensitive to interference and has fewer requirements/interference of its own.
The thing I like about astronauts is that you can introduce them as a helpful way to make your modules more productive... then steadily introduce their personalities as the mission continues. Anyone capable of going into space is going to be able to work for a week without letting their idiosyncrasies interfere with their jobs. A month, maybe. Depends on the person.
But at some point, the astronauts are going to begin forming lives in space. They'll start to have relationships, good and bad. They'll get lonely, or want to work on their hobbies. The more time passes, the more the astronauts resemble humans instead of cogs.
This doesn't degrade their work. On the contrary, properly managed it will actually enhance their work, because they're getting used to how things work and are healthy and happy. But you have to manage them. This isn't simply having the right modules installed: you need to massage their personal lives by changing where they tend to go and who else tends to go to those places.
Which is a topological challenge that can be worked through by mechanically rearranging modules and changing their primary assignment.
To make matters more interesting, you can have certain things generate only when astronauts have acclimatized to space: producing cultural goods such as movies, songs, babies, etc. These can have value if you can wrangle them properly, and exactly what kind of life you give your astronauts will change what kinds of cultural goods they create.
Anyway, just thinking aloud. Brewing ideas, as usual.
Thursday, October 24, 2013
Mission Pacing
I'm in love with pacing. For example, I think the most important part of a survival horror game is not the enemies, graphics, or gameplay... it's the pacing!
Pacing does interact with those things, though. It can't really exist on its own. So I'm always keeping my eyes open for games with pacing I haven't really seen before.
Like KSP. Yeah, another Kerbal essay.
KSP's pacing is extremely unusual because it is completely player-driven... but still very compelling. I can't think of many games where the player is allowed to fine-tune the pace to this degree, and none where the pacing is still compelling.
The core of the pacing is KSP's mission flight gameplay - launching, coasting, adjusting, coasting, adjusting, coasting... it's a simple but compelling loop that keeps its vigor because every mission and every ship has its own parameters, and you can never see 100% of the mission. It's always a bit of a mystery exactly how much adjustment you'll need, exactly how long you should coast, exactly where you should land... and that's compelling. A simple, continually changing loop.
I was thinking about other kinds of gameplay that might have the same feel, produce the same pacing.
For a long time, I was stuck on the idea of physics. But KSP's physics are actually just constraints, not really ongoing challenges. I don't think I've had to deal with in-flight physics issues on rockets, landers, or space stations for at least 40 hours. It's just not a piece of the gameplay at this level. I generally don't even have launch physics issues, unless I'm trying a completely new configuration. It's all pretty pat.
No, it's not about physics. It's about traveling.
Could you make a game about swimming? Flying? Driving? Boating? These are all systems of travel... but none of them have the right coast-adjust loop. They're "always on", at least as they are normally implemented.
Well, we might be able to do something with a sailing ship. The wind in your sails, coast along. Adjusting needs to be more complex than merely turning, though, so you'd have to do something interesting to make adjusting interesting. Perhaps it involves accurately reading the wind, or dealing with sea currents, or perfecting the angle of the sail and the angle of the hull... well, it has promise, but it might be difficult to make it feel juicy. It's also problematic because the ship doesn't change much as play progresses, which means the loop will feel a lot more repetitive as compared to something like a space ship changing mass and dropping tanks.
But this is an interesting point: it doesn't have to be about travel. It just has to be something where you coast and adjust.
For example, maybe you can turn a 90s hacking movie into a game. Coasting involves letting your BBS, wardialer, and botnet operate as configured. Adjusting means changing their parameters, hacking new machines, and so on. You keep an eye on your BBS, your email, your scripts, and in doing so you identify possible opportunities and dangers before they happen. Adjust your setup to avoid them or tangle with them at an advantage.
It's rather singular, though. Unlike KSP's missions, there's no real payload/launch variation. You'll always just use your best stuff, and the configuration of your systems doesn't have the breadth of expression that KSP's payloads tend to have.
So I'm just trying to think of some other methods.
Science projects: let your research teams continue on their current trajectory with their current subexperiments, but adjust their allocation and direction when it becomes clear that certain directions are dead ends and others are more promising. The development you're aiming for would need to be very freely definable, though, to give it the same variation and complexity as a KSP payload.
Country/city building: let your city continue to develop with current policies and zoning, change them when you want to redirect. To make the looping work correctly, the price for adjusting policies and zones would be a lump sum for any amount of adjusting, so there's impetus to adjust it all at once. Each city (or country, or space base) would need to have a specific construction/topology that is interesting and some kind of target endgame, to make them as varied as KSP payloads.
Terraforming. Same as city building, but across the whole planet.
Raising fighters. Whether mons or football players, let their training regimen develop them in "coast" mode. Alter their regimen just before game to bring them into proper fighting trim. Tweak it again afterwards to not interfere with their recovery, then bring it back to the "long haul" regimen to raise stats again...
Hm.
I wonder if anyone else gets what I'm aiming for, here.
Pacing does interact with those things, though. It can't really exist on its own. So I'm always keeping my eyes open for games with pacing I haven't really seen before.
Like KSP. Yeah, another Kerbal essay.
KSP's pacing is extremely unusual because it is completely player-driven... but still very compelling. I can't think of many games where the player is allowed to fine-tune the pace to this degree, and none where the pacing is still compelling.
The core of the pacing is KSP's mission flight gameplay - launching, coasting, adjusting, coasting, adjusting, coasting... it's a simple but compelling loop that keeps its vigor because every mission and every ship has its own parameters, and you can never see 100% of the mission. It's always a bit of a mystery exactly how much adjustment you'll need, exactly how long you should coast, exactly where you should land... and that's compelling. A simple, continually changing loop.
I was thinking about other kinds of gameplay that might have the same feel, produce the same pacing.
For a long time, I was stuck on the idea of physics. But KSP's physics are actually just constraints, not really ongoing challenges. I don't think I've had to deal with in-flight physics issues on rockets, landers, or space stations for at least 40 hours. It's just not a piece of the gameplay at this level. I generally don't even have launch physics issues, unless I'm trying a completely new configuration. It's all pretty pat.
No, it's not about physics. It's about traveling.
Could you make a game about swimming? Flying? Driving? Boating? These are all systems of travel... but none of them have the right coast-adjust loop. They're "always on", at least as they are normally implemented.
Well, we might be able to do something with a sailing ship. The wind in your sails, coast along. Adjusting needs to be more complex than merely turning, though, so you'd have to do something interesting to make adjusting interesting. Perhaps it involves accurately reading the wind, or dealing with sea currents, or perfecting the angle of the sail and the angle of the hull... well, it has promise, but it might be difficult to make it feel juicy. It's also problematic because the ship doesn't change much as play progresses, which means the loop will feel a lot more repetitive as compared to something like a space ship changing mass and dropping tanks.
But this is an interesting point: it doesn't have to be about travel. It just has to be something where you coast and adjust.
For example, maybe you can turn a 90s hacking movie into a game. Coasting involves letting your BBS, wardialer, and botnet operate as configured. Adjusting means changing their parameters, hacking new machines, and so on. You keep an eye on your BBS, your email, your scripts, and in doing so you identify possible opportunities and dangers before they happen. Adjust your setup to avoid them or tangle with them at an advantage.
It's rather singular, though. Unlike KSP's missions, there's no real payload/launch variation. You'll always just use your best stuff, and the configuration of your systems doesn't have the breadth of expression that KSP's payloads tend to have.
So I'm just trying to think of some other methods.
Science projects: let your research teams continue on their current trajectory with their current subexperiments, but adjust their allocation and direction when it becomes clear that certain directions are dead ends and others are more promising. The development you're aiming for would need to be very freely definable, though, to give it the same variation and complexity as a KSP payload.
Country/city building: let your city continue to develop with current policies and zoning, change them when you want to redirect. To make the looping work correctly, the price for adjusting policies and zones would be a lump sum for any amount of adjusting, so there's impetus to adjust it all at once. Each city (or country, or space base) would need to have a specific construction/topology that is interesting and some kind of target endgame, to make them as varied as KSP payloads.
Terraforming. Same as city building, but across the whole planet.
Raising fighters. Whether mons or football players, let their training regimen develop them in "coast" mode. Alter their regimen just before game to bring them into proper fighting trim. Tweak it again afterwards to not interfere with their recovery, then bring it back to the "long haul" regimen to raise stats again...
Hm.
I wonder if anyone else gets what I'm aiming for, here.
Monday, October 21, 2013
The Wait And Click
There's a kind of mechanic that gets a bad rap: the "wait to click" mechanic. Largely considered to be a cheap and nasty mechanic for Facebook games, I'd like to consider it fresh. I think no mechanic is inherently bad, and there is some potential here.
The thing that made me reconsider this mechanic is KSP's new career mode, where you build science vessels. See, pacing is a huge part of Kerbal's appeal. You build for a while, then you launch, wait a bit, adjust, wait a bit, adjust, wait a bit, adjust... sometimes, the waiting can be quite long, such as if you're trying to reach Jool using a xenon engine and you just have to sit there and fire engines for fifteen minutes straight.
The waiting never feels too onerous because it's MY waiting. I designed the rocket. I picked the mission. And, sure, I'll pop off to program or sketch or browse the web during that time - but, again, the game isn't a Facebooky-abusive-scheduler game.
It's very possible to make a game that feels almost the same, but makes you angry about the wait. This is because player agency is, for once, actually important and delicate. People have talked about player agency so much that there's annoyed backlash, but put that aside for a moment: this is about allowing players to choose their wait, and adjust it.
There are a lot of games where you "choose your wait", but the wait always increases as you tackle higher-level play. That's not "choosing" your wait... that's railroading with a candy coating.
Even in KSP, it can feel that way sometimes when you're trying to do a solar orbital maneuver (say, to Juul), and even the highest time acceleration is just a crawwwwwl. I generally don't like going on missions to Juul because of that long wait, a wait that is forced on me. Of course, there are mods that could help - for starters, I could use an alarm clock mod. Let KSP run in the background while I go to work or whatever, it'll pause when it reaches the specified point. In this manner I could change the weight of time without changing the actual wait required. The less attention I have to pay, the less the wait weighs.
The reason I started to think about this so carefully is because of KSP's new career mode, as I mentioned. This has dramatically changed the pacing of KSP's missions. Now the mission's "active" points aren't the minor adjustments required to change orbit or land. Those still exist, but they're pretty mild compared to the catharsis of clicking science modules and uploading data, five times each module - click click click click, wait for the big broadcast to finish, click click click, adjust the timescale a bit so I get more sun juice...
People often dismiss that kind of gameplay - there's not any particular punishment for doing it poorly, and there's no particular expressiveness... in the end, every player will end up in exactly the same situation, performing more or less the exact same process. It doesn't even have any strong interlinking within itself - unlike a level of Super Mario Brothers, it doesn't matter if you do A then B, or B then A. There's no skill, no meaningful choice, no agency.
But there is agency in getting there in the first place. I designed the ship. I chose the mission. I placed the science components. I landed the ship.
That's meaningful. That's interesting. And the catharsis of the payoff is much stronger because I'm actually performing the payoff mechanics. The ship doesn't just automatically upload all the science: I have to do it. Even though there's no skill or meaningful choice involved, I have to take action in collecting the results of my labor.
This is similar to the old conceit of open-world games. The world missions are all static and railroady, but because you have to walk into the glowing circle and click, it is your choice to commit to the railroady mission. You don't feel railroaded because you chose to take on this situation at this time and in this manner. It's the same thing backwards: the reward is already decided by the time I reach the end of a KSP mission phase, but having to manually collect it makes it feel more real and rewarding.
I guess it might feel cheap to talk about this kind of gameplay as "gameplay", because it really isn't very good at being game or play. But it is very good at pacing the player, punching up their experience. It's a mistake to dismiss that kind of effect out of some kind of false pride. Sure, the mechanic is often used in trashy freemium games to abuse the player, but that's because it's effective. You can use that effectiveness in a decent game, too.
It's an interesting dynamic, and worth pursuing.
The thing that made me reconsider this mechanic is KSP's new career mode, where you build science vessels. See, pacing is a huge part of Kerbal's appeal. You build for a while, then you launch, wait a bit, adjust, wait a bit, adjust, wait a bit, adjust... sometimes, the waiting can be quite long, such as if you're trying to reach Jool using a xenon engine and you just have to sit there and fire engines for fifteen minutes straight.
The waiting never feels too onerous because it's MY waiting. I designed the rocket. I picked the mission. And, sure, I'll pop off to program or sketch or browse the web during that time - but, again, the game isn't a Facebooky-abusive-scheduler game.
It's very possible to make a game that feels almost the same, but makes you angry about the wait. This is because player agency is, for once, actually important and delicate. People have talked about player agency so much that there's annoyed backlash, but put that aside for a moment: this is about allowing players to choose their wait, and adjust it.
There are a lot of games where you "choose your wait", but the wait always increases as you tackle higher-level play. That's not "choosing" your wait... that's railroading with a candy coating.
Even in KSP, it can feel that way sometimes when you're trying to do a solar orbital maneuver (say, to Juul), and even the highest time acceleration is just a crawwwwwl. I generally don't like going on missions to Juul because of that long wait, a wait that is forced on me. Of course, there are mods that could help - for starters, I could use an alarm clock mod. Let KSP run in the background while I go to work or whatever, it'll pause when it reaches the specified point. In this manner I could change the weight of time without changing the actual wait required. The less attention I have to pay, the less the wait weighs.
The reason I started to think about this so carefully is because of KSP's new career mode, as I mentioned. This has dramatically changed the pacing of KSP's missions. Now the mission's "active" points aren't the minor adjustments required to change orbit or land. Those still exist, but they're pretty mild compared to the catharsis of clicking science modules and uploading data, five times each module - click click click click, wait for the big broadcast to finish, click click click, adjust the timescale a bit so I get more sun juice...
People often dismiss that kind of gameplay - there's not any particular punishment for doing it poorly, and there's no particular expressiveness... in the end, every player will end up in exactly the same situation, performing more or less the exact same process. It doesn't even have any strong interlinking within itself - unlike a level of Super Mario Brothers, it doesn't matter if you do A then B, or B then A. There's no skill, no meaningful choice, no agency.
But there is agency in getting there in the first place. I designed the ship. I chose the mission. I placed the science components. I landed the ship.
That's meaningful. That's interesting. And the catharsis of the payoff is much stronger because I'm actually performing the payoff mechanics. The ship doesn't just automatically upload all the science: I have to do it. Even though there's no skill or meaningful choice involved, I have to take action in collecting the results of my labor.
This is similar to the old conceit of open-world games. The world missions are all static and railroady, but because you have to walk into the glowing circle and click, it is your choice to commit to the railroady mission. You don't feel railroaded because you chose to take on this situation at this time and in this manner. It's the same thing backwards: the reward is already decided by the time I reach the end of a KSP mission phase, but having to manually collect it makes it feel more real and rewarding.
I guess it might feel cheap to talk about this kind of gameplay as "gameplay", because it really isn't very good at being game or play. But it is very good at pacing the player, punching up their experience. It's a mistake to dismiss that kind of effect out of some kind of false pride. Sure, the mechanic is often used in trashy freemium games to abuse the player, but that's because it's effective. You can use that effectiveness in a decent game, too.
It's an interesting dynamic, and worth pursuing.
Subscribe to:
Posts (Atom)