Let's talk about unscripted, intense moments in a game.
Something that happens organically, as you play.
A lot of games are good at this, and it's the reason why roguelikes are still so popular. It's why Kerbal and Space Engineers have such a long-lasting following as well.
There's an adage: "failing is fun". These games rely on trying, failing, and trying again as a tight iteration loop.
I think this mixes two things. There's the tight iteration loop you get from failing and trying again, but there's also the fascinating and fun loop where you struggle to work through the realities of a situation not going quite according to plan. AKA, "plans-awry" play.
I don't think plans-awry play needs to fail in order to be fun. Struggling and succeeding is often more powerful, because it means your efforts were good enough.
For example, these days I build my Kerbal Space Program landers to survive hard landings. Those would have been failures when I was starting out, but now my landers survive because my planning has improved. That's a potent feeling: "uh oh oh noooo- whew, good thing I planned for that possibility."
I turned a failure into a success.
Fundamentally, this is about a learning curve. A player steadily plans better, sets things up better.
The "failing is fun" theory arises from a learning cliff that the devs sprinkle with glitter. It seems to me that self-directed missions can offer lower bars for success and turn this cliff into a slope. Allowing for smaller final goals, and allowing them to degrade gracefully can make failures into at least partial successes.
Thinking a while, I came up with seven factors I think turn learning cliffs into learning curves. Seven factors that make plans-awry play work.
1) Design refinement/mission arrangement. You need to be able to choose a mission and prepare for any mission you feel like doing in enough detail that you'd prepare differently for the same mission once you know more. For example, choosing different loadouts in Kerbal depending on your comfort in getting to orbit and landing on the moon efficiently.
2) Skill play. As the game unfolds, use your steadily improving skills to navigate challenges to your plan. This might be better ship handling in Kerbal, or knowing how to identify potions in Rogue, etc.
3) World state recognition. As your vision expands, you learn to plan further ahead and understand the world state at greater ranges. For example, orbital exchange windows in Kerbal, or understanding how long you have until a boss fight in the Binding of Isaac.
4) Composite/recursive planning. Allow the player to challenge themselves by trying several missions at once, or help themselves by planning a support mission ahead of time. This allows a player to adjust their plans to serve their skills: if they feel like visiting every Juul moon in one go, they can do that. If they aren't that good at fuel planning, let them send a tanker to Juul first to make it easier. Their choice.
5) Exploits/cheats. In single-player games (or friendly multiplayer), exploits and cheats are a core part of the fun. Exploits and cheats frequently turn into fun high-level challenges and opportunities. For example, the understanding that a torch holds up sand in Minecraft: torches can be washed away by water. Water can be blocked with sand. This is a basic setup which allows people to build a switch! Before redstone, it was the only way to build mechanisms, and even now, it's still used.
6) Cool factor. Allow players to do things that are cool because they are cool. Not everything has to be driven by mechanics. To this end, make missions much more open-ended than you ever expected, especially the low-level missions. For example, in Kerbal the lowest-level mission is theoretically "reach space", but it's so unenforced that people happily build slingshots and see how far they can fling Kerbals. Having a soft, unenforced fail state is a powerful tool.
7) Share-ability. Make it easy for players to share with each other. This partly includes things like screenshots and video: make it easy for players to take good-looking footage. But it also includes things like resharing blueprints, packaging up mod lists so everyone can import things without struggle, and very easy imports of levels, challenges, etc. Perhaps even automatic content sharing within some parameters.
These seven things seem to be really good at giving the player something easy to nibble on at the beginning, when they barely understand anything... and then letting the player just stretch their legs forever as they get more and more skilled. 7) is questionable, I suppose, but I definitely argue that it's part of the same concern.
Now, this isn't just theory for theory's sake.
I'm making a game. How does The Galactic Line do these things?
1) Design refinement. This is probably the most challenging for any game, because you have to come up with gameplay that makes refining your designs deep enough to carry the whole game, but easy enough that a newbie can approach it.
For TGL, I plan to do this by focusing mostly on the crew. A newbie understands the idea of putting people on a ship, they can focus on who they want to put on. They'll just choose whichever stock ship they like best.
This will naturally lead to them understanding how the crews and ships work, as they watch their story unfold. Critically, complete failure is unlikely. While chunks of ship get shut down and people start tearing their hair out, the stock ships will be well-designed enough to limp home even after a disastrous starting mission.
They'll hopefully feel the natural impulse to make their own ships, try longer missions, larger crews, etc.
2) Skill play. In TGL, the skill is mostly about optimizing for longevity by arranging the crew and ship modules. For example, when someone stresses out and something on the ship breaks, you have three options: leave it busted, repair it by salvaging another ship module, or dedicate crewmembers to massaging it into function 24/7. These options are about resource management and planning ahead.
If you do them well, you'll have "slack". You can use this to optimize hobby rooms and relationships, arrange for experience gains or career advancement, or optimizing ship modules for better performance in the next zone. This combined with the use of "redshirt" crew members gives players a lot of ways to manage things live in a skilled or unskilled way.
3&4) World state recognition/composite missions. The player will be faced with a lot of options as to what they want to do, but the most obvious pressure will be from "bounty" missions where people request specific resources from specific places. For example, "get me 30 points of astrophysics data from Beta Sirius". Those will be calibrated for the capabilities of the ship, but there's nothing stopping you from randomly gathering as much data as you want. It has some value.
Understanding how long those missions will take and what resources they'll require can allow you to do several missions at once, either in serial or parallel. If someone wants data from Beta Sirius and another person needs you to pick up five passengers from Gamma Draconis, maybe you can do them both in one run. If things go well.
4) Recursive missions. The game encourages the player to meddle with the affairs of non-space-ship folk using a simple colonization system. Hopefully this will not only allow the players to push through map choke points/extend missions, but also feel invested in the universe they're building.
5) Exploits and cheats. Not sure about this quite yet, but the plan is to make the game moddable and I'm not aiming to prevent them.
6) Cool factor. In addition to trying to let space ships look cool, a lot of the fun stuff is going to come from the way you can make custom crewmembers. As The Sims has shown, there is an impressive appetite for putting all sorts of random people in the stew-pot in different combinations. Want a ship crewed by your favorite band? Your friends? Vampires?
From the other side, colonies can also be made cool. Want to terraform a planet? Want to cover a moon in a huge city? Want to start from just one starving industrial colony on a barren world?
7) Share-ability. This one't a bit tough because it doesn't actually exist yet. The big challenge is that I'd need some kind of central database. Once I have that, automatically downloading ships, mods, stars, and world states is fairly straightforward. It's intended to be a "massively single-player" game.
In terms of making it fun to record/screenshot... I have to think about that some more.
At the end of the day, the plan for The Galactic Line is to focus on plans-awry play with a minimum of actual failing. We'll see how that theory works out in practice.
Anyway, those are my thoughts.
Showing posts with label kerbal. Show all posts
Showing posts with label kerbal. Show all posts
Tuesday, April 04, 2017
Thursday, January 16, 2014
Games as Waffles
Waffles. Syrup delivery platforms. Tasteless but readily supports a whole stick of butter.
Okay, I'm being silly, but I thought I'd talk a little bit about games as content delivery platforms rather than as games.
Many games - including some really good ones - have basically no gameplay. Instead, the game simply offers context and pacing for the content of the game. For example, Gone Home has no gameplay in it worth mentioning. Most AAA games these days don't have open gameplay, but a very closed, gated, linear gameplay that offers the player no real freedom and requires no real skill. These games instead focus on giving you art, sound, music, dialog, mood...
And I think that's okay.
Even in games where the gameplay reigns supreme, there's a lot to be said for giving context and form to the art half of the experience.
For example, in Kerbal the game is definitely about building rockets. The physics limitations are the most interesting part of the game. But even then, the artistic side of the experience is enabled and highlighted by the gameplay. The epic scene of a sun setting behind a distant planet, the heavy feeling of separating stages, the raw fire of re-entry, the delicate bounce of a ship landing, and of course the visual appearance of the ship. It's difficult to separate it into "this is gameplay, that is aesthetics" because the two end up bound so tightly.
It's easy to look at a first person shooter and talk about what is aesthetics. Music, textures, level models, lighting... most of the things we would talk about have little direct connection to gameplay. There are things like shot sounds that are linked to gameplay, but they are still distinct from gameplay. This makes it easy to separate the two elements, and that makes it easy to use the gameplay to gate the art and visa-versa.
But in a constructive game, the aesthetics are much more tightly bound because the player is the one building the things they see. Moreover, the weight of context is very heavy. The more someone plays, the more refined their aesthetic sense becomes in regards to the aesthetics of the game.
For example, I built a very cool-looking rocket in Kerbal yesterday. To people who have not played much Kerbal, it would look amazing. But to anyone who's played a lot of Kerbal, they would sigh about how overbuilt it was. The day before that, I built the opposite kind of rocket: it looks dull to the average person, but to someone who's played a lot of Kerbal it looks very elegant and interesting because of its ground-docking function.
Of course, not all of Kerbal's aesthetics are rocket-based. No matter how long you've been playing Kerbal, shots of the natural beauty of Kerbin's star system are equally appealing. It's only the aesthetics related to the mechanic that are complex and generative.
Moreover, the aesthetics of Kerbal's rockets are fundamental to the mechanics of Kerbal. Even if you download a lot of other part packs, the fundamental visual pattern remains more or less the same. The only time the rockets begin to really feel different is when you download elements that change the fundamental layout of the rocket, such as downloading cargo bays.
I began to think: what if you make a construction game like Kerbal, where you construct a physics-limited device of some kind... but the construction engine was calibrated and engineered to give a specific kind of beautiful aesthetic? What if I took inspiration from the coolest looks Kerbal could give, and used that to create a new construction game?
The challenge here is that the construction would have to naturally give rise to this kind of beauty. Unlike many of the most modern games with starship creation, we're not choosing elements that look cool because we think they look cool. Instead, the fundamental gameplay will naturally give rise to something that looks cool.
What looks cool? Well, here's some samples. There's a lot of variation to show the kinds of things I'm talking about.
Sample
Sample
Sample
Sample
Sample
Sample
Sample
Sample
The first thing to notice is that STUFF is important. The only thing all of those devices have in common is that their surfaces are broken up by things, rather than simply being a centralized chain of major shapes. In some cases the stuff is quite minor, just the remnants of a separation stage or the texture built into the core shape. However, sometimes the stuff is extravagant. Either way, "stuff" is worth considering in detail. For example, can you put surface junk on top of other surface junk, or can you only put surface junk on top of core shapes? Kerbal only does the latter, but there's nothing stopping us from doing the former in a new game.
The second thing I notice is that the core shape is always interestingly lumpy, and usually in a fairly graceful manner. So I'm thinking a graceful, lumpy core shape covered in stuff.
The third thing I notice is contrast. This isn't a pile of gray on gray. The patterns of light and dark are pretty punchy, and I think that's important. Far more important than the colors involved. Not only does the stuff contrast with the surface tone, but the surfaces are frequently striped. In fact, whenever I identify something I think is ugly, it's almost always because the shade is too uniform!
This really shines when using concave shapes such as landing bays, where the interior of the ship is shown (see the LLL Sundiver image). I think this is because I always light concave areas, so the shading of the interior devices naturally forms stripes, pools, and bars.
In addition to simple light-dark contrast, there's also contrast between "empty" and "crowded" space. Nearly all of the ships have simple areas and complex areas, spindly areas and heavy areas. We don't want the ship entirely covered in high-density cruft, but instead we would prefer to have high and low density regions. Interiors can really shine here, because at range they can be closed and therefore be low-density, but as you zoom in they can open and reveal a new high-density region even as the zooming itself turns the previous high-density regions into low-density regions.
Lastly, almost without needing mention, symmetry.
So, when we build something, we want:
A graceful but lumpy "core body", with tapering or rounded size transitions and nacelles. These elements should have some low-grade stripes to give them a bit of texture. The stripes should be horizontal (that is, around the 'waist' of the body) since most attachments will run vertically.
A set of "extension wings" that can gracefully extend a considerable distance, for mounting solar panels or landing legs or whatever. Not intended to connect two core body elements. Some might be static, some might have joints, and some might extend or untwist.
Attachments, many of which should run a considerable distance along the body, or connect two body elements. Attachments can have different modes that change how they look, such as radio dishes unfolding. Rather than sticking solely to Kerbal functions, attachments should be a more core part of the experience - for example, running pipes along the body should be very common, along with things like processing nodes stapled to the outside. Much of the functionality of the ship should pass through attachments.
Interior spaces that can be filled with a lot of small tubes or the like. This can be as simple as interior space variants of exterior piping and modules, but it would make sense for many modules to be "summaries" of interiors. For example, a "battery" core body element is full of individual battery modules, and the player would stuff as many in as they wanted, trading off for things like safety, weight, backups, repair access, and so on.
Because of the nature of interior spaces, while exterior spaces are radial it makes more sense for interior spaces to be symmetric across only one axis. The reason for this is that bay doors make radial symmetry extremely annoying. Let me explain.
If you want a bay full of sleeper pods, if the bay is flat you can store the sleeper pods by butting the foot of them against the wall and pointing the heads towards the center. You end up with a striped "ribcage" of pods. It looks great and it's easy to understand. You can also store them running along the axis, creating a sort of "pinstripes" situation, which also looks great and is easy to understand. The bay door opens, you see the pods. This works because you have a static set of walls that you can work against.
But if you have a radial setup, there's no "base" to attach to. The walls are the parts that open. If you attach the pods to the walls, then when you open a bay door you either see the backs of the pods, or you actually yank the pods out of the bay and leave them attached to the doors. In order to get a radial bay to work, you need a central column of stuff that doesn't attach to the walls, and that wastes a lot of space and makes no structural sense. It also lights badly and doesn't look as sharp.
Well, there is one more option - force the player to attach to the parts of the bay that aren't doors. However, this is very difficult to manage both in terms of the player sticking things in and making it turn out beautiful when she's done.
The best option for interior spaces is linear symmetry, which does mean some wasted space. However, this can be okay because space doesn't have to be a critical factor. If the real constraints are weight and complexity rather than space, it's okay if interior spaces waste some space. Also, it could lead to interesting setups like a cargo bay actually being three linear-symmetry cargo bays arranged in radial symmetry, which would look neat!
Anyway, that's my thinking on the matter.
Okay, I'm being silly, but I thought I'd talk a little bit about games as content delivery platforms rather than as games.
Many games - including some really good ones - have basically no gameplay. Instead, the game simply offers context and pacing for the content of the game. For example, Gone Home has no gameplay in it worth mentioning. Most AAA games these days don't have open gameplay, but a very closed, gated, linear gameplay that offers the player no real freedom and requires no real skill. These games instead focus on giving you art, sound, music, dialog, mood...
And I think that's okay.
Even in games where the gameplay reigns supreme, there's a lot to be said for giving context and form to the art half of the experience.
For example, in Kerbal the game is definitely about building rockets. The physics limitations are the most interesting part of the game. But even then, the artistic side of the experience is enabled and highlighted by the gameplay. The epic scene of a sun setting behind a distant planet, the heavy feeling of separating stages, the raw fire of re-entry, the delicate bounce of a ship landing, and of course the visual appearance of the ship. It's difficult to separate it into "this is gameplay, that is aesthetics" because the two end up bound so tightly.
It's easy to look at a first person shooter and talk about what is aesthetics. Music, textures, level models, lighting... most of the things we would talk about have little direct connection to gameplay. There are things like shot sounds that are linked to gameplay, but they are still distinct from gameplay. This makes it easy to separate the two elements, and that makes it easy to use the gameplay to gate the art and visa-versa.
But in a constructive game, the aesthetics are much more tightly bound because the player is the one building the things they see. Moreover, the weight of context is very heavy. The more someone plays, the more refined their aesthetic sense becomes in regards to the aesthetics of the game.
For example, I built a very cool-looking rocket in Kerbal yesterday. To people who have not played much Kerbal, it would look amazing. But to anyone who's played a lot of Kerbal, they would sigh about how overbuilt it was. The day before that, I built the opposite kind of rocket: it looks dull to the average person, but to someone who's played a lot of Kerbal it looks very elegant and interesting because of its ground-docking function.
Of course, not all of Kerbal's aesthetics are rocket-based. No matter how long you've been playing Kerbal, shots of the natural beauty of Kerbin's star system are equally appealing. It's only the aesthetics related to the mechanic that are complex and generative.
Moreover, the aesthetics of Kerbal's rockets are fundamental to the mechanics of Kerbal. Even if you download a lot of other part packs, the fundamental visual pattern remains more or less the same. The only time the rockets begin to really feel different is when you download elements that change the fundamental layout of the rocket, such as downloading cargo bays.
I began to think: what if you make a construction game like Kerbal, where you construct a physics-limited device of some kind... but the construction engine was calibrated and engineered to give a specific kind of beautiful aesthetic? What if I took inspiration from the coolest looks Kerbal could give, and used that to create a new construction game?
The challenge here is that the construction would have to naturally give rise to this kind of beauty. Unlike many of the most modern games with starship creation, we're not choosing elements that look cool because we think they look cool. Instead, the fundamental gameplay will naturally give rise to something that looks cool.
What looks cool? Well, here's some samples. There's a lot of variation to show the kinds of things I'm talking about.
Sample
Sample
Sample
Sample
Sample
Sample
Sample
Sample
The first thing to notice is that STUFF is important. The only thing all of those devices have in common is that their surfaces are broken up by things, rather than simply being a centralized chain of major shapes. In some cases the stuff is quite minor, just the remnants of a separation stage or the texture built into the core shape. However, sometimes the stuff is extravagant. Either way, "stuff" is worth considering in detail. For example, can you put surface junk on top of other surface junk, or can you only put surface junk on top of core shapes? Kerbal only does the latter, but there's nothing stopping us from doing the former in a new game.
The second thing I notice is that the core shape is always interestingly lumpy, and usually in a fairly graceful manner. So I'm thinking a graceful, lumpy core shape covered in stuff.
The third thing I notice is contrast. This isn't a pile of gray on gray. The patterns of light and dark are pretty punchy, and I think that's important. Far more important than the colors involved. Not only does the stuff contrast with the surface tone, but the surfaces are frequently striped. In fact, whenever I identify something I think is ugly, it's almost always because the shade is too uniform!
This really shines when using concave shapes such as landing bays, where the interior of the ship is shown (see the LLL Sundiver image). I think this is because I always light concave areas, so the shading of the interior devices naturally forms stripes, pools, and bars.
In addition to simple light-dark contrast, there's also contrast between "empty" and "crowded" space. Nearly all of the ships have simple areas and complex areas, spindly areas and heavy areas. We don't want the ship entirely covered in high-density cruft, but instead we would prefer to have high and low density regions. Interiors can really shine here, because at range they can be closed and therefore be low-density, but as you zoom in they can open and reveal a new high-density region even as the zooming itself turns the previous high-density regions into low-density regions.
Lastly, almost without needing mention, symmetry.
So, when we build something, we want:
A graceful but lumpy "core body", with tapering or rounded size transitions and nacelles. These elements should have some low-grade stripes to give them a bit of texture. The stripes should be horizontal (that is, around the 'waist' of the body) since most attachments will run vertically.
A set of "extension wings" that can gracefully extend a considerable distance, for mounting solar panels or landing legs or whatever. Not intended to connect two core body elements. Some might be static, some might have joints, and some might extend or untwist.
Attachments, many of which should run a considerable distance along the body, or connect two body elements. Attachments can have different modes that change how they look, such as radio dishes unfolding. Rather than sticking solely to Kerbal functions, attachments should be a more core part of the experience - for example, running pipes along the body should be very common, along with things like processing nodes stapled to the outside. Much of the functionality of the ship should pass through attachments.
Interior spaces that can be filled with a lot of small tubes or the like. This can be as simple as interior space variants of exterior piping and modules, but it would make sense for many modules to be "summaries" of interiors. For example, a "battery" core body element is full of individual battery modules, and the player would stuff as many in as they wanted, trading off for things like safety, weight, backups, repair access, and so on.
Because of the nature of interior spaces, while exterior spaces are radial it makes more sense for interior spaces to be symmetric across only one axis. The reason for this is that bay doors make radial symmetry extremely annoying. Let me explain.
If you want a bay full of sleeper pods, if the bay is flat you can store the sleeper pods by butting the foot of them against the wall and pointing the heads towards the center. You end up with a striped "ribcage" of pods. It looks great and it's easy to understand. You can also store them running along the axis, creating a sort of "pinstripes" situation, which also looks great and is easy to understand. The bay door opens, you see the pods. This works because you have a static set of walls that you can work against.
But if you have a radial setup, there's no "base" to attach to. The walls are the parts that open. If you attach the pods to the walls, then when you open a bay door you either see the backs of the pods, or you actually yank the pods out of the bay and leave them attached to the doors. In order to get a radial bay to work, you need a central column of stuff that doesn't attach to the walls, and that wastes a lot of space and makes no structural sense. It also lights badly and doesn't look as sharp.
Well, there is one more option - force the player to attach to the parts of the bay that aren't doors. However, this is very difficult to manage both in terms of the player sticking things in and making it turn out beautiful when she's done.
The best option for interior spaces is linear symmetry, which does mean some wasted space. However, this can be okay because space doesn't have to be a critical factor. If the real constraints are weight and complexity rather than space, it's okay if interior spaces waste some space. Also, it could lead to interesting setups like a cargo bay actually being three linear-symmetry cargo bays arranged in radial symmetry, which would look neat!
Anyway, that's my thinking on the matter.
Subscribe to:
Posts (Atom)