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 gameplay. Show all posts
Showing posts with label gameplay. Show all posts
Tuesday, April 04, 2017
Wednesday, August 31, 2016
Compound Grinding Engines
I've been thinking about how some games are compelling even when in barely alpha states, and others don't become compelling until nearly the whole game is complete. And I think I know the answer: compound grinding engines.
Most games burn content for play. An RPG, for example, requires the devs to create characters, monsters, maps, equipment, stats, skills, scenes, all this content. This is essentially a steam boiler: throw content in the hopper and the player bubbles.
In order to keep the engine going, you have to keep burning content.
But in the beginning, the devs don't have much fuel. They haven't created much content, and most of their content is placeholder assets. There's not really any point to bringing players in right now, so the devs usually show off their art instead of releasing demos.
There's nothing wrong with this, but clearly the game isn't playable out of the gate. Players would just be disappointed.
On the other hand, some games are substantially more playable even in primitive states. Simulation games, mostly. Physics sims, life sims, empire sims, any kind of sim game seems to have some kind of pull that makes it fun even when it's very primitive. What is it?
Well, "simulation" is the key word. The player sets something up and then watches it unfold. The player is creating content out of the initial content. We can extract a lot more heat out of this content because it forms secondary content, maybe even tertiary content.
Rather than just a single steam boiler, we're building a compound steam engine.
This isn't quite as straightforward as putting together an RPG. It requires less content, but the content needs to be carefully fitted together because a leak in the first "chamber" will make the other chambers break. Right now, it feels like most games that get it right are either accidents or instinct, so let's take a closer look.
Games like Besiege are basically double chamber engines. The devs provide some physics content, the players arrange it and have fun going to town with it.
It requires some care. For starters, allowing the players to build whatever they want with no guidance is not going to work, at least not as an initial play style. You need to give the players something to strive for. Something that a beginner can figure out how to do and an expert can hook additional constraints to. IE, "knock over the tower" can turn into "with a giant mech" or "using only sheep" when the expert players decide to try.
There's the core fitness test - the fundamental constraints. These should vary so that the players can explore different variations. In Besiege, that's the various levels. This has the advantage of being something that can be churned out in huge quantities later on. In Space Engineers, the constraints can be fine-tuned during world creation. In Kerbal, the constraints vary across a huge map and you can choose different destinations to engage different constraints.
There's also the self-challenge constraints. These typically arise from the components you allow players to build with.
Usually, physics simulations have a variety of parts that have different physical characteristics. By playing this up both statistically and visually, you can easily create self-challenge constraints. These typically arise from either holding back (banning specific systems such as liquid fuel rockets, explosives, pilots) or hilarious overstretching (mecha out of a joint block, using extendable landing gear to flap wings, using stacked explosives to drill out a five hundred meter shaft, making an 8-bit processor out of redstone). Both of these approaches can be predicted based on the components, the way they interact, the way they interact with constraints, and how clearly they are demarcated visually and systemically.
That's worth talking about, but we're going to instead move on to a much more straightforward example of multi-chamber systems: NON-physics simulations. For example, life sims, empire sims, farm sims, etc.
That is... grinding.
Today we'll defining grinding as designing a system that takes some player time in order to change a parameter in some way.
The first half of the equation is taking player time. Typically this is done via a static constraint: the game simply takes some time to interact with. Making selections, moving from place to place, etc. However, in some games specific tasks have an additional time cost, typically paired up with stat costs. IE, watering each plant takes a small amount of energy and plays a two second animation, or boxing someone requires you to play a minigame for thirty seconds.
Anyway, to me the second half is important: parameter change.
This is the "content". This is what the player pays attention to. However, without context, it's useless.
These stats often carry some context over from their real-world implication to start. For example, in Cookie Clicker, there's the initial context of "hah hah cookies how funny". Then additional context is overlaid based on the way systems interact with that 'stat'.
Similarly, in a life sim you might grind your sports stat or your intelligence or something. The initial context of "I'm sporty" or "I'm brainy" is decent, but you absolutely must layer systems on top of it in order for it to pull the player in.
It's tempting to just add "things that happen when you reach N points of stat". This is popular in dating games: to date the jock you need N sports points, to date the nerd you need N intelligence. But this is "single boiler" content, the same way marching through a dungeon or buying a new sword is content in an RPG.
To get a "multiple boiler" setup, we need to have compression and decompression cycles. I know, I know, stretching the damn metaphor.
Most of the compelling prototypes I've played feature only a small amount of "real content". Whether it's a composite VN with only one character or whether it's a space empire game with undifferentiated planets, the key is that our grinding gets "spent".
IE, we don't just get research points and have ever more of them: we gain research points in order to spend them on a technology.
The technology is the content, but the whole point is that you're going to have to go back to the previous chamber and grind there again in order to get the next technology. This means that each research grinding is done with a purpose: you're grinding specifically
to get tech A or B, not to just get a higher research rating. Mid-term goals built right in.
MMORPGs use a grinding system based around "fonts" and "sinks": kill monsters for cash, that cash drains away to upgrades, shops, etc. But that's not what we're talking about.
Ours is more of a piston-based approach. The player focuses on injecting high-pressure gas into the chamber expecting a single "pump" of the cylinder. It's true, you are gaining research points, but the intent is for that single sweep of the piston: BAM, you have a new tech and that chamber is now spent.
Whew, that metaphor is stretching pretty thin. Let's leave it behind.
The point is to create a series of asynchronous, parallel, interlocking grinding systems that the player will use to obtain specific results which will then reset that system.
The player isn't just grinding to improve tech points or gain intellect, they're grinding to spend those points on something.
This can easily be interwoven and daisy-chained. The player grinds industry to build a bigger city that they can use to grind tech more efficiently so they can unlock a new mining rig to let them grind industry more efficiently...
You're going to have long-term state. That's how the player knows they're making progress. But the point is that the long-term state feeds back into the grinding most of the time, rather than simply being a content reward. Content rewards are expensive and don't chain well, so I think of them as the final link in the chain.
A fun thing to do is to make the long-term state conflict, so you can only optimize in one direction and then need to un-optimize to go another route. Alternately, you can add in states that cause unusual mutations in the flow of grinding. For example, if the player builds a police state, then half of all research points become spy points. Yeah, the citizen unhappiness that results is not great, but if you are pumping out a lot of research, you can power through to the spy expenditures you want to achieve and then dismantle the state...
Another fun thing to do is "soft limiting". For example, you have a max research cap of 50 points of research, regardless of how you grind. But unlike a hard limit, this is a soft limit. Even without upgrading your facilities to get a higher cap, you can exceed that limit in a specific, limited way. Maybe the cap is applied at the end of each month, or you lose 50% of that overage each day, or you pay $10/day upkeep for each additional point, or each point requires an additional scientist. Each soft constraint will inspire the player to create a plan to exceed it in a different way, so think it through.
These kinds of capabilities are what separate a powerful compound grinding engine from just another newbie sim game. A relatively small amount of content can have vast effects and keep a player coming back hour after hour before you've even added art.
In theory.
I have a lot of thoughts on this, especially in regards to setting up and maintaining flow at the same time, but this is more than long enough. What do you all think?
Most games burn content for play. An RPG, for example, requires the devs to create characters, monsters, maps, equipment, stats, skills, scenes, all this content. This is essentially a steam boiler: throw content in the hopper and the player bubbles.
In order to keep the engine going, you have to keep burning content.
But in the beginning, the devs don't have much fuel. They haven't created much content, and most of their content is placeholder assets. There's not really any point to bringing players in right now, so the devs usually show off their art instead of releasing demos.
There's nothing wrong with this, but clearly the game isn't playable out of the gate. Players would just be disappointed.
On the other hand, some games are substantially more playable even in primitive states. Simulation games, mostly. Physics sims, life sims, empire sims, any kind of sim game seems to have some kind of pull that makes it fun even when it's very primitive. What is it?
Well, "simulation" is the key word. The player sets something up and then watches it unfold. The player is creating content out of the initial content. We can extract a lot more heat out of this content because it forms secondary content, maybe even tertiary content.
Rather than just a single steam boiler, we're building a compound steam engine.
This isn't quite as straightforward as putting together an RPG. It requires less content, but the content needs to be carefully fitted together because a leak in the first "chamber" will make the other chambers break. Right now, it feels like most games that get it right are either accidents or instinct, so let's take a closer look.
Games like Besiege are basically double chamber engines. The devs provide some physics content, the players arrange it and have fun going to town with it.
It requires some care. For starters, allowing the players to build whatever they want with no guidance is not going to work, at least not as an initial play style. You need to give the players something to strive for. Something that a beginner can figure out how to do and an expert can hook additional constraints to. IE, "knock over the tower" can turn into "with a giant mech" or "using only sheep" when the expert players decide to try.
There's the core fitness test - the fundamental constraints. These should vary so that the players can explore different variations. In Besiege, that's the various levels. This has the advantage of being something that can be churned out in huge quantities later on. In Space Engineers, the constraints can be fine-tuned during world creation. In Kerbal, the constraints vary across a huge map and you can choose different destinations to engage different constraints.
There's also the self-challenge constraints. These typically arise from the components you allow players to build with.
Usually, physics simulations have a variety of parts that have different physical characteristics. By playing this up both statistically and visually, you can easily create self-challenge constraints. These typically arise from either holding back (banning specific systems such as liquid fuel rockets, explosives, pilots) or hilarious overstretching (mecha out of a joint block, using extendable landing gear to flap wings, using stacked explosives to drill out a five hundred meter shaft, making an 8-bit processor out of redstone). Both of these approaches can be predicted based on the components, the way they interact, the way they interact with constraints, and how clearly they are demarcated visually and systemically.
That's worth talking about, but we're going to instead move on to a much more straightforward example of multi-chamber systems: NON-physics simulations. For example, life sims, empire sims, farm sims, etc.
That is... grinding.
Today we'll defining grinding as designing a system that takes some player time in order to change a parameter in some way.
The first half of the equation is taking player time. Typically this is done via a static constraint: the game simply takes some time to interact with. Making selections, moving from place to place, etc. However, in some games specific tasks have an additional time cost, typically paired up with stat costs. IE, watering each plant takes a small amount of energy and plays a two second animation, or boxing someone requires you to play a minigame for thirty seconds.
Anyway, to me the second half is important: parameter change.
This is the "content". This is what the player pays attention to. However, without context, it's useless.
These stats often carry some context over from their real-world implication to start. For example, in Cookie Clicker, there's the initial context of "hah hah cookies how funny". Then additional context is overlaid based on the way systems interact with that 'stat'.
Similarly, in a life sim you might grind your sports stat or your intelligence or something. The initial context of "I'm sporty" or "I'm brainy" is decent, but you absolutely must layer systems on top of it in order for it to pull the player in.
It's tempting to just add "things that happen when you reach N points of stat". This is popular in dating games: to date the jock you need N sports points, to date the nerd you need N intelligence. But this is "single boiler" content, the same way marching through a dungeon or buying a new sword is content in an RPG.
To get a "multiple boiler" setup, we need to have compression and decompression cycles. I know, I know, stretching the damn metaphor.
Most of the compelling prototypes I've played feature only a small amount of "real content". Whether it's a composite VN with only one character or whether it's a space empire game with undifferentiated planets, the key is that our grinding gets "spent".
IE, we don't just get research points and have ever more of them: we gain research points in order to spend them on a technology.
The technology is the content, but the whole point is that you're going to have to go back to the previous chamber and grind there again in order to get the next technology. This means that each research grinding is done with a purpose: you're grinding specifically
to get tech A or B, not to just get a higher research rating. Mid-term goals built right in.
MMORPGs use a grinding system based around "fonts" and "sinks": kill monsters for cash, that cash drains away to upgrades, shops, etc. But that's not what we're talking about.
Ours is more of a piston-based approach. The player focuses on injecting high-pressure gas into the chamber expecting a single "pump" of the cylinder. It's true, you are gaining research points, but the intent is for that single sweep of the piston: BAM, you have a new tech and that chamber is now spent.
Whew, that metaphor is stretching pretty thin. Let's leave it behind.
The point is to create a series of asynchronous, parallel, interlocking grinding systems that the player will use to obtain specific results which will then reset that system.
The player isn't just grinding to improve tech points or gain intellect, they're grinding to spend those points on something.
This can easily be interwoven and daisy-chained. The player grinds industry to build a bigger city that they can use to grind tech more efficiently so they can unlock a new mining rig to let them grind industry more efficiently...
You're going to have long-term state. That's how the player knows they're making progress. But the point is that the long-term state feeds back into the grinding most of the time, rather than simply being a content reward. Content rewards are expensive and don't chain well, so I think of them as the final link in the chain.
A fun thing to do is to make the long-term state conflict, so you can only optimize in one direction and then need to un-optimize to go another route. Alternately, you can add in states that cause unusual mutations in the flow of grinding. For example, if the player builds a police state, then half of all research points become spy points. Yeah, the citizen unhappiness that results is not great, but if you are pumping out a lot of research, you can power through to the spy expenditures you want to achieve and then dismantle the state...
Another fun thing to do is "soft limiting". For example, you have a max research cap of 50 points of research, regardless of how you grind. But unlike a hard limit, this is a soft limit. Even without upgrading your facilities to get a higher cap, you can exceed that limit in a specific, limited way. Maybe the cap is applied at the end of each month, or you lose 50% of that overage each day, or you pay $10/day upkeep for each additional point, or each point requires an additional scientist. Each soft constraint will inspire the player to create a plan to exceed it in a different way, so think it through.
These kinds of capabilities are what separate a powerful compound grinding engine from just another newbie sim game. A relatively small amount of content can have vast effects and keep a player coming back hour after hour before you've even added art.
In theory.
I have a lot of thoughts on this, especially in regards to setting up and maintaining flow at the same time, but this is more than long enough. What do you all think?
Wednesday, September 02, 2015
What Makes Games Different
Recently I've been pretty sour about games. None of them seem even vaguely interesting to me, even games that everyone is raving about. Metal Gear 5 lets you kidnap soldiers! Mario Maker let's you create fascinating Marioish levels!
Zzzzzzzz
I'm burned out on "gameplay". Nothing with "gameplay" is even vaguely interesting. But if a game doesn't have gameplay, sign me up! I love games with no gameplay!
This has really got me thinking about what makes games different from, say, comics.
Obviously, one thing is gameplay. But since gameplay seems really uninteresting to me, what else have you got?
Self-Expression
One thing I like is self-expression. Allowing a player to put a piece of themselves into the story is valuable, even if that piece is not very important. It also makes the world larger, at least in the player's head, if they think things could have gone differently.
Sometimes self-expression has no statistical, in-game meaning. For example, Saints Row lets you dress up however, and nobody ever treats you differently no matter what you wear. Even if you run around naked, the only comments you get are from nameless pedestrians. No actual gameplay effect.
Although that kind of "shallow" expression is valuable, there's also self-expression which has meaning in the game world. For example, an RPG lets you choose how to approach situations, who to be friends with, and how to spend your time. The final outcome in the very end is probably unchanged, but your choices affect your experience in getting there. They let you spend time differently, with different people or different challenges.
Sometimes this can be much more delicate. For example, in Space Engineers your self expression is mostly based around how your ships are shaped. This is not something most people think about - I mean, who cares how your ship is shaped? But when you play Space Engineers, it says a lot, because it's deeply linked to what your ship does, who it appeals to, and what sort of thing you are aesthetically trying to say. It also says a lot about your level of skill, since if you are a clumsy designer your designs will have noticeable aesthetics descending from that.
There's also self-expression as a shared endeavor. Group appreciation is a powerful tool, whether it's you getting to see what someone else has made, or someone else commenting on what you made. Fundamentally, this kind of shared experience is only available if your game allows for enough self-expression to make every player's experience quite different.
Pacing
I think the core strength of games is pacing, in the same way that the core strength of movies is editing, and the core strength of comics is the panels.
Games are adept at both giving the player more control over pacing, and also forcing the player to spend specific amounts of time.
Forcing the player to spend time and effort is a valuable tool for making the rewards seem valuable. In most games, "spend time" is the actual gameplay: you move through Metal Gear doing Metal Gear things, and then sometimes you get a plot reward. But we've turned it on its head for this discussion: the plot reward is only valuable because the player has spent so much time in pursuit of it.
While some games allow you to directly pursue the plot, many games are not so linear. Open-world games and RPGs have a medium of exchange. You spend your time accruing a fungible resource - money, XP, power - and then you use it to achieve the next unlock. Whether that unlock is a plot element, a new costume, or a better sword almost doesn't matter. Your time has been turned into literal money, and spending that money makes whatever you spent it on seem that much more valuable.
I remember playing the oldschool games - Final Fantasy 1, for example. I still remember saving up for "sleep" so that I could blast through the nine-pirate fight near the beginning of the game. It all meshed together - the time spent getting the money, the perceived value of the spell I bought, the actual in-combat value of the spell, and the result of overcoming a difficult combat. This chain of value started with the game's pacing: I couldn't overcome the pirates until I spent some effort at it.
The other half of the affair is how much control the player has over the pacing of the game. This is complicated, because technically I chose what to do and how to do it as I saved up for that spell, but it was obviously the game's core pacing structure that forced me to make those choices.
Player-controlled pacing is important, because every player plays differently both from other players and from themselves at other times. Today I might want to grind for XP in a dungeon, but tomorrow I might want to explore a new town. I may want to switch rapidly from exploring a new dungeon to overworld grinding to town sidequests to chatting with my buddies at base camp.
Moreover, this gives the designer a lot of slack. Since I control my pacing, if I run into three difficult combats in a row, I can decide to head back early. If I run into a string of easy combats, I can choose to press on.
All of this has walls around it. If everything is too easy or hard, the player is just going to be annoyed. And sometimes the game might benefit from getting a bit pushy - the Zozo arc in FFVI was really aggressive, but it's one of the things I remember most clearly.
The New
I think I've come to dislike games with gameplay because the gameplay is never new to me. I've played literally thousands of games over my lifetime, and nobody is really coming up with new gameplay. However, people are coming up with new self-expression and pacing elements!
So those are what I'm interested in. Your rebalanced rehash of first-person-shooting or RPG dungeon crawls is painfully familiar to me. But... letting me trade RPG party members over the internet with other people? That's new! Giving me a home base where I can talk to my party? That's new! These are things which can grow into whole new genres!
So, yeah, hook me up with "walking simulators" and pointless construction games. They're new! That's new territory!
... for a little while longer, anyway.
Zzzzzzzz
I'm burned out on "gameplay". Nothing with "gameplay" is even vaguely interesting. But if a game doesn't have gameplay, sign me up! I love games with no gameplay!
This has really got me thinking about what makes games different from, say, comics.
Obviously, one thing is gameplay. But since gameplay seems really uninteresting to me, what else have you got?
Self-Expression
One thing I like is self-expression. Allowing a player to put a piece of themselves into the story is valuable, even if that piece is not very important. It also makes the world larger, at least in the player's head, if they think things could have gone differently.
Sometimes self-expression has no statistical, in-game meaning. For example, Saints Row lets you dress up however, and nobody ever treats you differently no matter what you wear. Even if you run around naked, the only comments you get are from nameless pedestrians. No actual gameplay effect.
Although that kind of "shallow" expression is valuable, there's also self-expression which has meaning in the game world. For example, an RPG lets you choose how to approach situations, who to be friends with, and how to spend your time. The final outcome in the very end is probably unchanged, but your choices affect your experience in getting there. They let you spend time differently, with different people or different challenges.
Sometimes this can be much more delicate. For example, in Space Engineers your self expression is mostly based around how your ships are shaped. This is not something most people think about - I mean, who cares how your ship is shaped? But when you play Space Engineers, it says a lot, because it's deeply linked to what your ship does, who it appeals to, and what sort of thing you are aesthetically trying to say. It also says a lot about your level of skill, since if you are a clumsy designer your designs will have noticeable aesthetics descending from that.
There's also self-expression as a shared endeavor. Group appreciation is a powerful tool, whether it's you getting to see what someone else has made, or someone else commenting on what you made. Fundamentally, this kind of shared experience is only available if your game allows for enough self-expression to make every player's experience quite different.
Pacing
I think the core strength of games is pacing, in the same way that the core strength of movies is editing, and the core strength of comics is the panels.
Games are adept at both giving the player more control over pacing, and also forcing the player to spend specific amounts of time.
Forcing the player to spend time and effort is a valuable tool for making the rewards seem valuable. In most games, "spend time" is the actual gameplay: you move through Metal Gear doing Metal Gear things, and then sometimes you get a plot reward. But we've turned it on its head for this discussion: the plot reward is only valuable because the player has spent so much time in pursuit of it.
While some games allow you to directly pursue the plot, many games are not so linear. Open-world games and RPGs have a medium of exchange. You spend your time accruing a fungible resource - money, XP, power - and then you use it to achieve the next unlock. Whether that unlock is a plot element, a new costume, or a better sword almost doesn't matter. Your time has been turned into literal money, and spending that money makes whatever you spent it on seem that much more valuable.
I remember playing the oldschool games - Final Fantasy 1, for example. I still remember saving up for "sleep" so that I could blast through the nine-pirate fight near the beginning of the game. It all meshed together - the time spent getting the money, the perceived value of the spell I bought, the actual in-combat value of the spell, and the result of overcoming a difficult combat. This chain of value started with the game's pacing: I couldn't overcome the pirates until I spent some effort at it.
The other half of the affair is how much control the player has over the pacing of the game. This is complicated, because technically I chose what to do and how to do it as I saved up for that spell, but it was obviously the game's core pacing structure that forced me to make those choices.
Player-controlled pacing is important, because every player plays differently both from other players and from themselves at other times. Today I might want to grind for XP in a dungeon, but tomorrow I might want to explore a new town. I may want to switch rapidly from exploring a new dungeon to overworld grinding to town sidequests to chatting with my buddies at base camp.
Moreover, this gives the designer a lot of slack. Since I control my pacing, if I run into three difficult combats in a row, I can decide to head back early. If I run into a string of easy combats, I can choose to press on.
All of this has walls around it. If everything is too easy or hard, the player is just going to be annoyed. And sometimes the game might benefit from getting a bit pushy - the Zozo arc in FFVI was really aggressive, but it's one of the things I remember most clearly.
The New
I think I've come to dislike games with gameplay because the gameplay is never new to me. I've played literally thousands of games over my lifetime, and nobody is really coming up with new gameplay. However, people are coming up with new self-expression and pacing elements!
So those are what I'm interested in. Your rebalanced rehash of first-person-shooting or RPG dungeon crawls is painfully familiar to me. But... letting me trade RPG party members over the internet with other people? That's new! Giving me a home base where I can talk to my party? That's new! These are things which can grow into whole new genres!
So, yeah, hook me up with "walking simulators" and pointless construction games. They're new! That's new territory!
... for a little while longer, anyway.
Tuesday, June 16, 2015
Machinima as Gameplay
I've been thinking about how to let players create context-conveying content. Obviously, players should build physical content - space ships, maps, etc. But it's hard to explain what is cool about a space ship or a map if that's all that gets shared. Players need another option, another kind of content: procedural.
Procedural is a bad word, because it normally means "algorithmic content" such as roguelike dungeons. In this case, however, I am talking about purposeful changes over time. Processes. Maybe I should call it routine..ual... routinual? Ritual content? Probably best to call it "behavioral content" or "operational content".
Machinima is already a big thing, but it's normally outside of the game. Even if you record it while playing the game, such as a Let's Play with a story, the content itself is outside of the game and cannot really be distributed inside the game. The closest we've gotten in the past is with The Sims, where you could share photo albums.
If we bring it into the game, we can allow players to record something, and then we can chop it up and play it back as content allows. Duplicate it, move it, alter it to fit a scenario.
As an example, let's say you're playing something like Space Engineers or Kerbal. You create a ship with dozens of docking bays, all identical. You can get in a fighter, hit "record", and then record yourself approaching and landing on a docking bay. Now, whenever you or the game wants, a similar fighter (same basic bounding box, same basic thrust capacities) can come in on the same vector and land in precisely the same way.
But because the game understands the context of the objects, the game can easily flag specific locations and relationships. The point where the ship touches the bay is automatically considered the critical element. Other bays with the same layout and flagged as being the same thing can therefore automatically adjust the flight profile to perfectly match their position and orientation. This means, with no extra work, any bay can have a fighter come in and land automatically. And, if you cut and paste the bays, however many more bays, all of them can have fighters come in for a landing.
I want you to really imagine how powerful this is. Imagine you're just playing Space Engineers for the first time. You build a space station with some landing bays, and then you shakily pilot your starter ship over to a bay and park it. Now the game will instantly be able to have any ship of roughly that size warp in and shakily pilot over to your other bays. Noticing this, you cut and paste your bays, creating a massive wall of bays.
And now, there are fleets of small ships scuttling in, eager to stop in. They all line up and slide into place, many so distant they're like a swarm of butterflies.
Moreover, this behavior automatically links into other behavior. You notice that sometimes huge motherships will warp in and disgorge shuttles of the proper size. That's because when you build a carrier, you record the behavior of the shuttles leaving. They then become their own entity and can therefore pick up behaviors related to shuttles. It's a simple logical chain: your station allows for shuttles to land, these motherships have shuttles, therefore these motherships can use your station.
On the other side, things keep chaining. Once they've landed, the ships can chain into new behaviors such as trading, repairing, refueling, passenger exchange. Each of these is fueled by whether you've recorded the process in the machinima engine. And if you haven't, you can always turn it to "request mode", where they will request you to do something, and you can record machinima of it right on the spot with them.
Suddenly, the universe is alive. You've tapped into the shared behavioral engine.
We're using machinima as gameplay.
It's not just floating in the ether, either. Exactly how you land will depend on the layout of your ship, the size of the docking bays, and other gameplay considerations. When you record the machinima, your max acceleration and bounding boxes will determine the kinds of ships that are considered fit for the same behavior. And you'll also want to rig the behavior into a smart system - for example, point small ships towards small bays, but allow them to fill larger bays if your small bays are full. Set trading prices so that you can adjust the price without rerecording the behavior, or even adjust prices automatically based on supply and demand.
Basically, we've gone from just creating a ship to also creating the space and time around the ship, and the operations of the ship. These allow us to tie everything together - everything from a lot of different players. We can even embed mods into this, if we frame mods in the right way.
Normally, machinima is used for narrative content. You tell the story of two dudes on a road trip using the Space Engineers engine. By adding context that doesn't exist within the framework of the game, you make the game seem larger.
By allowing machinima sharing and reproduction within the game engine, we also allow for that. Not all behavioral recordings result in a significant in-game statistical change.
Sure, landing a ship and trading are valuable in-game functions and the behavioral recordings for those are likely to be spartan and utilitarian. But you can do so much more: record crew wandering around your ship, going to bed, changing shifts, eating in the canteen, bullshitting in the halls. Record conversations and missions that have nothing to do with any statistical in-game thing, but give your crew and ship uniqueness: when someone contacts your ship, the captain will pop up and be a specific person asking about specific things and telling a specific story about a specific ambush in a specific place.
Moreover, behavioral recording can be modded just like normal content. If we forget to make medical treatment a thing, people can mod in some new animations and record themselves interacting with various medical blocks in various ways and - poof - we have a new block with new functions that NPCs can automatically interact with. Tie the statistical operations of the block into the machinima, and you can actually have real function. The medical bay has a function for treating illness, and you can trigger that function during your machinima, meaning that playing that behavioral tidbit will actually treat illness. Conversely, anyone with an illness can automatically search for behaviors to play and for blocks in the area that will allow them to perform the behavior.
I think this is an interesting idea.
Procedural is a bad word, because it normally means "algorithmic content" such as roguelike dungeons. In this case, however, I am talking about purposeful changes over time. Processes. Maybe I should call it routine..ual... routinual? Ritual content? Probably best to call it "behavioral content" or "operational content".
Machinima is already a big thing, but it's normally outside of the game. Even if you record it while playing the game, such as a Let's Play with a story, the content itself is outside of the game and cannot really be distributed inside the game. The closest we've gotten in the past is with The Sims, where you could share photo albums.
If we bring it into the game, we can allow players to record something, and then we can chop it up and play it back as content allows. Duplicate it, move it, alter it to fit a scenario.
As an example, let's say you're playing something like Space Engineers or Kerbal. You create a ship with dozens of docking bays, all identical. You can get in a fighter, hit "record", and then record yourself approaching and landing on a docking bay. Now, whenever you or the game wants, a similar fighter (same basic bounding box, same basic thrust capacities) can come in on the same vector and land in precisely the same way.
But because the game understands the context of the objects, the game can easily flag specific locations and relationships. The point where the ship touches the bay is automatically considered the critical element. Other bays with the same layout and flagged as being the same thing can therefore automatically adjust the flight profile to perfectly match their position and orientation. This means, with no extra work, any bay can have a fighter come in and land automatically. And, if you cut and paste the bays, however many more bays, all of them can have fighters come in for a landing.
I want you to really imagine how powerful this is. Imagine you're just playing Space Engineers for the first time. You build a space station with some landing bays, and then you shakily pilot your starter ship over to a bay and park it. Now the game will instantly be able to have any ship of roughly that size warp in and shakily pilot over to your other bays. Noticing this, you cut and paste your bays, creating a massive wall of bays.
And now, there are fleets of small ships scuttling in, eager to stop in. They all line up and slide into place, many so distant they're like a swarm of butterflies.
Moreover, this behavior automatically links into other behavior. You notice that sometimes huge motherships will warp in and disgorge shuttles of the proper size. That's because when you build a carrier, you record the behavior of the shuttles leaving. They then become their own entity and can therefore pick up behaviors related to shuttles. It's a simple logical chain: your station allows for shuttles to land, these motherships have shuttles, therefore these motherships can use your station.
On the other side, things keep chaining. Once they've landed, the ships can chain into new behaviors such as trading, repairing, refueling, passenger exchange. Each of these is fueled by whether you've recorded the process in the machinima engine. And if you haven't, you can always turn it to "request mode", where they will request you to do something, and you can record machinima of it right on the spot with them.
Suddenly, the universe is alive. You've tapped into the shared behavioral engine.
We're using machinima as gameplay.
It's not just floating in the ether, either. Exactly how you land will depend on the layout of your ship, the size of the docking bays, and other gameplay considerations. When you record the machinima, your max acceleration and bounding boxes will determine the kinds of ships that are considered fit for the same behavior. And you'll also want to rig the behavior into a smart system - for example, point small ships towards small bays, but allow them to fill larger bays if your small bays are full. Set trading prices so that you can adjust the price without rerecording the behavior, or even adjust prices automatically based on supply and demand.
Basically, we've gone from just creating a ship to also creating the space and time around the ship, and the operations of the ship. These allow us to tie everything together - everything from a lot of different players. We can even embed mods into this, if we frame mods in the right way.
Normally, machinima is used for narrative content. You tell the story of two dudes on a road trip using the Space Engineers engine. By adding context that doesn't exist within the framework of the game, you make the game seem larger.
By allowing machinima sharing and reproduction within the game engine, we also allow for that. Not all behavioral recordings result in a significant in-game statistical change.
Sure, landing a ship and trading are valuable in-game functions and the behavioral recordings for those are likely to be spartan and utilitarian. But you can do so much more: record crew wandering around your ship, going to bed, changing shifts, eating in the canteen, bullshitting in the halls. Record conversations and missions that have nothing to do with any statistical in-game thing, but give your crew and ship uniqueness: when someone contacts your ship, the captain will pop up and be a specific person asking about specific things and telling a specific story about a specific ambush in a specific place.
Moreover, behavioral recording can be modded just like normal content. If we forget to make medical treatment a thing, people can mod in some new animations and record themselves interacting with various medical blocks in various ways and - poof - we have a new block with new functions that NPCs can automatically interact with. Tie the statistical operations of the block into the machinima, and you can actually have real function. The medical bay has a function for treating illness, and you can trigger that function during your machinima, meaning that playing that behavioral tidbit will actually treat illness. Conversely, anyone with an illness can automatically search for behaviors to play and for blocks in the area that will allow them to perform the behavior.
I think this is an interesting idea.
Tuesday, October 14, 2014
Boring Play
Recently I've been in a bit of a war with myself about game design.
I create a lot of prototypes - typically at least one a week. For a long time, they were mostly about exploring some gameplay idea - a particular tweak on poker rules, or a feel for the timing in a brawler.
As time passed, I became steadily more interested in themes. Pick a theme, then craft the rules out of the giant backlog of gameplay I explored. Fit them together.
In the end, there are only a few kinds of play that are considered "valid". If I come up with a theme such as "fluffy bunnies in the woods", it'll have to rely on the same challenges that every other game relies on.
Movement and timing. Pattern recognition/optimization. Choosing the right option out of an ever-changing crowd of options. Luck.
There are some games that people barely consider games. For example, Gone Home.
But Gone Home still uses these mechanics. You move around the house looking for things to click on. You put together the pattern of the story in your head. The least gamey game is still reliant on the same challenges as the most gamey game, just with very different pacing.
What about Animal Crossing and similar games?
Well, there's a lot of pattern recognition and optimization in Animal Crossing - gathering valuable things, hitting the parts of the town you need to hit, tending your crops, finding jobs and sidequests. Those are all pattern recognition and optimization.
There are some things peeking from the shadows, though. Creating your character involves picking from a list of options, but unlike an RPG battle or math-teaching game, none of the choices is right or wrong. Similarly, in Gone Home the challenges are all about movement and clicking just like in a shooty game, but none of the movement or clicks could really be considered "bad". You can't lose at Gone Home - the challenges just serve to to indicate which way is forward so you can control your own experience a bit more clearly.
In both cases, the "challenge" (picking an option, moving and looking) is there to allow the player to control their own experience. In both cases, the game tells you how to move forward specifically so you can linger or move on as your preferences and mood dictate.
OK, with that in mind, let's back up a little bit.
---
Gameplay is really boring.
Oh, it can keep your mind entrained. I play Kerbal and Skyrim and so on. The mechanics keep me thinking, keep me looking towards the next step.
But when I look at it, there's nothing to the mechanics at all. My outlook on life wouldn't be any different if I couldn't choose the right amount of fuel and thrust to land on a fake moon, or level up my sneak enough to stab a fake skeleton with a fake knife.
There is some value in these games, though.
Through Kerbal I learned a lot about the mechanics of space flight. While the lessons are stilted and simplified, they further my interest in and my understanding of real science, real space flight. By giving me a cartoonish version of something real, the game lets me hold it in my hands, twist it, hold it up to the light, and start to understand.
Skyrim is not so positive. The cartoonish thing Skyrim lets me hold is the culture that formed it. It's a very manly-man Tolkien fantasy with a lot of serious issues. But it serves: when I hold Skyrim in my hand and start gluing other people's pieces onto it, I can see all the weaknesses in that culture, and explore my steadily-increasing distance from it.
Even if you don't read into it as much as I do, Skyrim's strength is the setting, not the mechanics. High-fidelity fantasy world you can wander around in? That's what you'll remember about Skyrim. You won't fondly remember the lockpicking puzzle.
So, why do we do it?
Why do we slap useless gameplay into these things?
1) Pacing. By keeping the mind engaged, players can remain interested in the world even when their preferences aren't lining up and they aren't interested in the bit of setting they're currently looking at.
2) Engagement. By allowing players to choose how they approach the game, we also change how they approach the setpieces. This helps players grip the concepts in the world and hold them up to the light.
3) Synchronization. By giving all players the same emergent tools, we allow every player to have their own unique experiences with the same foundation. Sharing those experiences with other players (or themselves in the past), we allow players to have conversations about the concepts in the game. Even if it's just bragging about headshot counts.
Thinking about gameplay from this perspective is very freeing.
Instead of thinking "what kind of gameplay do I want in this game?" maybe we should think -
1) How do I pace the game so that the player remains interested even when their mood drifts out of synch with the setting?
2) How do I let the player explore the ramifications of change in this world?
3) What commonalities do I rely on to help players understand each other's experiences and choices?
...
I haven't gotten any further than that, yet.
I create a lot of prototypes - typically at least one a week. For a long time, they were mostly about exploring some gameplay idea - a particular tweak on poker rules, or a feel for the timing in a brawler.
As time passed, I became steadily more interested in themes. Pick a theme, then craft the rules out of the giant backlog of gameplay I explored. Fit them together.
In the end, there are only a few kinds of play that are considered "valid". If I come up with a theme such as "fluffy bunnies in the woods", it'll have to rely on the same challenges that every other game relies on.
Movement and timing. Pattern recognition/optimization. Choosing the right option out of an ever-changing crowd of options. Luck.
There are some games that people barely consider games. For example, Gone Home.
But Gone Home still uses these mechanics. You move around the house looking for things to click on. You put together the pattern of the story in your head. The least gamey game is still reliant on the same challenges as the most gamey game, just with very different pacing.
What about Animal Crossing and similar games?
Well, there's a lot of pattern recognition and optimization in Animal Crossing - gathering valuable things, hitting the parts of the town you need to hit, tending your crops, finding jobs and sidequests. Those are all pattern recognition and optimization.
There are some things peeking from the shadows, though. Creating your character involves picking from a list of options, but unlike an RPG battle or math-teaching game, none of the choices is right or wrong. Similarly, in Gone Home the challenges are all about movement and clicking just like in a shooty game, but none of the movement or clicks could really be considered "bad". You can't lose at Gone Home - the challenges just serve to to indicate which way is forward so you can control your own experience a bit more clearly.
In both cases, the "challenge" (picking an option, moving and looking) is there to allow the player to control their own experience. In both cases, the game tells you how to move forward specifically so you can linger or move on as your preferences and mood dictate.
OK, with that in mind, let's back up a little bit.
---
Gameplay is really boring.
Oh, it can keep your mind entrained. I play Kerbal and Skyrim and so on. The mechanics keep me thinking, keep me looking towards the next step.
But when I look at it, there's nothing to the mechanics at all. My outlook on life wouldn't be any different if I couldn't choose the right amount of fuel and thrust to land on a fake moon, or level up my sneak enough to stab a fake skeleton with a fake knife.
There is some value in these games, though.
Through Kerbal I learned a lot about the mechanics of space flight. While the lessons are stilted and simplified, they further my interest in and my understanding of real science, real space flight. By giving me a cartoonish version of something real, the game lets me hold it in my hands, twist it, hold it up to the light, and start to understand.
Skyrim is not so positive. The cartoonish thing Skyrim lets me hold is the culture that formed it. It's a very manly-man Tolkien fantasy with a lot of serious issues. But it serves: when I hold Skyrim in my hand and start gluing other people's pieces onto it, I can see all the weaknesses in that culture, and explore my steadily-increasing distance from it.
Even if you don't read into it as much as I do, Skyrim's strength is the setting, not the mechanics. High-fidelity fantasy world you can wander around in? That's what you'll remember about Skyrim. You won't fondly remember the lockpicking puzzle.
So, why do we do it?
Why do we slap useless gameplay into these things?
1) Pacing. By keeping the mind engaged, players can remain interested in the world even when their preferences aren't lining up and they aren't interested in the bit of setting they're currently looking at.
2) Engagement. By allowing players to choose how they approach the game, we also change how they approach the setpieces. This helps players grip the concepts in the world and hold them up to the light.
3) Synchronization. By giving all players the same emergent tools, we allow every player to have their own unique experiences with the same foundation. Sharing those experiences with other players (or themselves in the past), we allow players to have conversations about the concepts in the game. Even if it's just bragging about headshot counts.
Thinking about gameplay from this perspective is very freeing.
Instead of thinking "what kind of gameplay do I want in this game?" maybe we should think -
1) How do I pace the game so that the player remains interested even when their mood drifts out of synch with the setting?
2) How do I let the player explore the ramifications of change in this world?
3) What commonalities do I rely on to help players understand each other's experiences and choices?
...
I haven't gotten any further than that, yet.
Friday, July 11, 2014
Density
I've been struggling to talk about density of space in games. Here's my latest attempt!
What's Density?
There are a lot of ways to measure 'density' of space. How far you can see, how quickly and freely you can move, how many enemies are around, how many resources, how many NPCs.
But I find these are all proportional. If you can see further, then you can move more quickly/freely and there are fewer encounters per square meter. Similarly, if you are stuck in a cramped little maze, you can't see very far, you don't move very freely, and there are more encounters per square meter.
These things vary over the course of a level. That's the heart of good level design. Here's a huge area with a ravine you can't cross, a monster closet, an area with a bunch of resources clumped up. However, if you average all the variations together, you'll find that the level revolves around a specific density, and all the different elements that can be used to measure density all reflect that choice.
Because of that, we can really use any of these things as a measure of density. We don't have to painstakingly consider them separately.
I'm going to use how the player sees as my measure of density. The more space the player sees at once, the sparser the space is.
Of course, this isn't just camera-view space - it includes HUD popups and overlay maps. If you have a map that's easy to reference, or floating decals showing points of interest outside of your view, then you can see a lot further than your camera view indicates. That means your space is sparser, which means you'll move faster/more freely, and you'll have fewer resources/encounters per meter.
With those assumptions in mind, let's get a bit aggressive with the concept now that it's been laid out.
How Dense is Dense?
When people think about spatial density, they normally think in terms of something like "rooftops are sparse, vents are dense".
They aren't wrong. However, in most games those are outliers, not part of the core experience. You can tell, because if you pretend that vents or rooftops are the point of the game, you can easily see that there would be different mechanics in place to make the game more fun. In most games, rooftops and vents are changes of pace, not distinct levels.
You can see the core gameplay break down in these places. In fact, in most modern games, the vent sequence is guaranteed to not have any enemies in it, since you're too cramped to even fight. Space is too dense to maneuver.
That said, you can get a lot more sparse than rooftops. What about the boat sequences in Windwaker? What about the "lost in the desert" sequences in Quest For Glory 2? You can get very sparse!
The thing I noticed is that you can't really get very sparse or cramped before violent gameplay disintegrates. Violent gameplay is about removing enemies from play, and that fundamentally doesn't work if there are too few enemies. As you get sparse, the gameplay becomes about getting to the few things you think you see, rather than removing them from play.
You can get very dense and still have violent gameplay - old robotron games show that - but there's still a limit. As your movement gets more and more constrained, maneuvering gets tighter and tighter. As density goes up, violent gameplay slowly changes from violence into racing with obstacles. A good example of this is Tempest 2000, which is technically a "violent" game but it's mostly about desperately trying to wiggle from side to side in the tight confines given you.
However, other kinds of gameplay work fine in dense and sparse spaces.
Most games have one core kind of play, and it revolves around a specific kind of density. Density fluctuates from level to level, moment to moment, but the gameplay is intended to work at a specific density and that's the density their levels keep flowing back towards. In contrast, consider Skyrim. It has several largely unrelated kinds of play that allow it to support dense and sparse spaces natively, rather than as exceptions.
Skyrim has three kinds of gameplay that live side by side. It has the violent medium-density-space gameplay - raiding dungeons, clearing bandit camps, fighting dragons. But it also has the low-density gameplay of exploring the world and the high-density gameplay of stealing things from townsfolk.
Each type of space has a different kind of fundamental gameplay, even though they all use the same user interface.
This isn't to say Skyrim is very good at it. Skyrim is notable mostly for this existing at all, not for doing it well. The different kinds of play do not offer meaningfully intertwined reward systems, a heroic character will never see the denser half of the game, and the play balance is completely awful unless you mod the hell out of your game. But it exists!
I think this is the future of open world games.
I look at games like Saints Row or older GTA games (haven't played the new one), and I see games struggling to have multiple densities. You can be on foot, you can be in a car, you can be in a jet. These are obviously trying to see space from different perspectives, trying to change the density of the play. Unfortunately, they don't quite have it figured out. They don't seem to be sure what they actually want.
Being in a jet does change how you see the world, but it doesn't change how the world interacts with you. This means the new sparseness is not a native density, but an exception: it's typical space smeared awkwardly into a jet's visor, rather than a different kind of play supporting that new sparseness at a deep level.
The spaces don't need to clash and feel disconnected, like with Skyrim. But they do have to change.
Let's Talk Gameplay
If we wanted to come up with an open-world game that supports a wide variety of densities, we would need to consider how to link them together.
Let's start stock, with a typical open-world game setting. Rather than fantasy, let's set it in modern times - we'll call this a GTA-like rather than an RPG.
The medium-density setting of the urban environment is what most players are used to. In this environment they run around, jump cars off riverbanks, shoot cops, etc. Basically every GTA clone ever made.
We also need a lower- and higher-density way to play. And, importantly, they have to reflect on each other.
Let's say the high-density space would be places you actually go into. Shops, homes, and the like. In these spaces there wouldn't be very much call for violence - you could shoot a shopkeep and go on a rampage, but there's not any significant reward for it. Instead, these tight spaces are about arranging people and things.
It's about stocking a friend up with beer he likes by putting it on his shelf, or about hooking up some people that have never met each other by introducing them and kicking off a conversation, or its about sabotaging the air conditioning so it gets abysmally hot. It's about the things in this dense space and your inventory, and using them to affect each other. As a key part of this: these aren't quests. It's all open world. Sabotaging an air conditioner always has the same kind of effect everywhere. Putting something on someone's shelf - or taking something from their fridge - registers in the same way even if people have different responses.
Some possible rewards are obvious - you get resources if you steal them, and havok can be its own reward. However, we want our rewards to echo properly, they need to affect the player in other spaces. In this case, a good reward might be whether or not someone will follow you as an NPC if you phone them, and how powerful they will be when they do.
That's high-density.
Low-density, we have a lot of options. We could make some kind of wilderness/outskirts thing. But this is a techie wonderland, so I have two ideas.
The first is drone flying. You can use a drone to wander the city. Unlike wandering as a human, the drone cannot stop and chat - it doesn't even go down to street level unless you want to crash it. Instead, the drone scans for specific people whose phones you've bugged, open wifi networks, and so on. The city is a glowing map of flowing data, allowing you to search for points of interest, tidbits of data to harvest, and track individuals. The city is also large - real city size.
The second option is exactly the opposite: drone evasion. After curfew, drones watch the city. You can't use vehicles - they'll be spotted immediately. Instead, you have to move on foot. Everyone's gone home, the city is much less dense. It's just you and the glowing patterns of light that indicate where the drones can see. Change your gear to change how long it takes a drone to realize you're a person, or how hard it is for street-level cameras to identify you.
These kinds of play can all feed back on each other in relatively interesting ways. Cause a ruckus during the day in medium-density space, and that area will be crawling with cops and drones at night - leaving fewer in the rest of the city. Sneak somewhere at night to hack into security and change what you can see during a drone expedition. Do a good drone expedition to find a weak point in the mafia's defenses.
Normally this would all be scripted missions, but if the play exists, these can be emergent situations. Scripted missions are mostly useful for hiding parts of the game that don't flow well, don't emerge naturally. If our spaces blend together well and support each other, we don't need nearly as much scripting.
This is a pretty conservative kind of design, too. There are a lot of much more out-there designs where the spaces get a whole lot more dense and less dense. A game on a starship where you get stuck in your crew's dreams at night, for example. A camping game where you spend the day hiking and the night trapped in a two-person tent with three other people.
There's lots of options. I just wanted to show you that density goes a whole lot further than most people might think.
What's Density?
There are a lot of ways to measure 'density' of space. How far you can see, how quickly and freely you can move, how many enemies are around, how many resources, how many NPCs.
But I find these are all proportional. If you can see further, then you can move more quickly/freely and there are fewer encounters per square meter. Similarly, if you are stuck in a cramped little maze, you can't see very far, you don't move very freely, and there are more encounters per square meter.
These things vary over the course of a level. That's the heart of good level design. Here's a huge area with a ravine you can't cross, a monster closet, an area with a bunch of resources clumped up. However, if you average all the variations together, you'll find that the level revolves around a specific density, and all the different elements that can be used to measure density all reflect that choice.
Because of that, we can really use any of these things as a measure of density. We don't have to painstakingly consider them separately.
I'm going to use how the player sees as my measure of density. The more space the player sees at once, the sparser the space is.
Of course, this isn't just camera-view space - it includes HUD popups and overlay maps. If you have a map that's easy to reference, or floating decals showing points of interest outside of your view, then you can see a lot further than your camera view indicates. That means your space is sparser, which means you'll move faster/more freely, and you'll have fewer resources/encounters per meter.
With those assumptions in mind, let's get a bit aggressive with the concept now that it's been laid out.
How Dense is Dense?
When people think about spatial density, they normally think in terms of something like "rooftops are sparse, vents are dense".
They aren't wrong. However, in most games those are outliers, not part of the core experience. You can tell, because if you pretend that vents or rooftops are the point of the game, you can easily see that there would be different mechanics in place to make the game more fun. In most games, rooftops and vents are changes of pace, not distinct levels.
You can see the core gameplay break down in these places. In fact, in most modern games, the vent sequence is guaranteed to not have any enemies in it, since you're too cramped to even fight. Space is too dense to maneuver.
That said, you can get a lot more sparse than rooftops. What about the boat sequences in Windwaker? What about the "lost in the desert" sequences in Quest For Glory 2? You can get very sparse!
The thing I noticed is that you can't really get very sparse or cramped before violent gameplay disintegrates. Violent gameplay is about removing enemies from play, and that fundamentally doesn't work if there are too few enemies. As you get sparse, the gameplay becomes about getting to the few things you think you see, rather than removing them from play.
You can get very dense and still have violent gameplay - old robotron games show that - but there's still a limit. As your movement gets more and more constrained, maneuvering gets tighter and tighter. As density goes up, violent gameplay slowly changes from violence into racing with obstacles. A good example of this is Tempest 2000, which is technically a "violent" game but it's mostly about desperately trying to wiggle from side to side in the tight confines given you.
However, other kinds of gameplay work fine in dense and sparse spaces.
Most games have one core kind of play, and it revolves around a specific kind of density. Density fluctuates from level to level, moment to moment, but the gameplay is intended to work at a specific density and that's the density their levels keep flowing back towards. In contrast, consider Skyrim. It has several largely unrelated kinds of play that allow it to support dense and sparse spaces natively, rather than as exceptions.
Skyrim has three kinds of gameplay that live side by side. It has the violent medium-density-space gameplay - raiding dungeons, clearing bandit camps, fighting dragons. But it also has the low-density gameplay of exploring the world and the high-density gameplay of stealing things from townsfolk.
Each type of space has a different kind of fundamental gameplay, even though they all use the same user interface.
This isn't to say Skyrim is very good at it. Skyrim is notable mostly for this existing at all, not for doing it well. The different kinds of play do not offer meaningfully intertwined reward systems, a heroic character will never see the denser half of the game, and the play balance is completely awful unless you mod the hell out of your game. But it exists!
I think this is the future of open world games.
I look at games like Saints Row or older GTA games (haven't played the new one), and I see games struggling to have multiple densities. You can be on foot, you can be in a car, you can be in a jet. These are obviously trying to see space from different perspectives, trying to change the density of the play. Unfortunately, they don't quite have it figured out. They don't seem to be sure what they actually want.
Being in a jet does change how you see the world, but it doesn't change how the world interacts with you. This means the new sparseness is not a native density, but an exception: it's typical space smeared awkwardly into a jet's visor, rather than a different kind of play supporting that new sparseness at a deep level.
The spaces don't need to clash and feel disconnected, like with Skyrim. But they do have to change.
Let's Talk Gameplay
If we wanted to come up with an open-world game that supports a wide variety of densities, we would need to consider how to link them together.
Let's start stock, with a typical open-world game setting. Rather than fantasy, let's set it in modern times - we'll call this a GTA-like rather than an RPG.
The medium-density setting of the urban environment is what most players are used to. In this environment they run around, jump cars off riverbanks, shoot cops, etc. Basically every GTA clone ever made.
We also need a lower- and higher-density way to play. And, importantly, they have to reflect on each other.
Let's say the high-density space would be places you actually go into. Shops, homes, and the like. In these spaces there wouldn't be very much call for violence - you could shoot a shopkeep and go on a rampage, but there's not any significant reward for it. Instead, these tight spaces are about arranging people and things.
It's about stocking a friend up with beer he likes by putting it on his shelf, or about hooking up some people that have never met each other by introducing them and kicking off a conversation, or its about sabotaging the air conditioning so it gets abysmally hot. It's about the things in this dense space and your inventory, and using them to affect each other. As a key part of this: these aren't quests. It's all open world. Sabotaging an air conditioner always has the same kind of effect everywhere. Putting something on someone's shelf - or taking something from their fridge - registers in the same way even if people have different responses.
Some possible rewards are obvious - you get resources if you steal them, and havok can be its own reward. However, we want our rewards to echo properly, they need to affect the player in other spaces. In this case, a good reward might be whether or not someone will follow you as an NPC if you phone them, and how powerful they will be when they do.
That's high-density.
Low-density, we have a lot of options. We could make some kind of wilderness/outskirts thing. But this is a techie wonderland, so I have two ideas.
The first is drone flying. You can use a drone to wander the city. Unlike wandering as a human, the drone cannot stop and chat - it doesn't even go down to street level unless you want to crash it. Instead, the drone scans for specific people whose phones you've bugged, open wifi networks, and so on. The city is a glowing map of flowing data, allowing you to search for points of interest, tidbits of data to harvest, and track individuals. The city is also large - real city size.
The second option is exactly the opposite: drone evasion. After curfew, drones watch the city. You can't use vehicles - they'll be spotted immediately. Instead, you have to move on foot. Everyone's gone home, the city is much less dense. It's just you and the glowing patterns of light that indicate where the drones can see. Change your gear to change how long it takes a drone to realize you're a person, or how hard it is for street-level cameras to identify you.
These kinds of play can all feed back on each other in relatively interesting ways. Cause a ruckus during the day in medium-density space, and that area will be crawling with cops and drones at night - leaving fewer in the rest of the city. Sneak somewhere at night to hack into security and change what you can see during a drone expedition. Do a good drone expedition to find a weak point in the mafia's defenses.
Normally this would all be scripted missions, but if the play exists, these can be emergent situations. Scripted missions are mostly useful for hiding parts of the game that don't flow well, don't emerge naturally. If our spaces blend together well and support each other, we don't need nearly as much scripting.
This is a pretty conservative kind of design, too. There are a lot of much more out-there designs where the spaces get a whole lot more dense and less dense. A game on a starship where you get stuck in your crew's dreams at night, for example. A camping game where you spend the day hiking and the night trapped in a two-person tent with three other people.
There's lots of options. I just wanted to show you that density goes a whole lot further than most people might think.
Tuesday, May 06, 2014
Starship Grid+
A few days back I posted a video about how grids, voxels, and Minecraft-style bricks aren't well-suited to ship design.
Fundamentally, voxel- or grid-based play is about either controlling flow or ordering a chaotic topology, neither of which are concepts starship games use. I caught a little flak from Space Engineer fans, because Space Engineer almost sort of kinda makes a vague attempt to be about controlling flow. Theoretically, in the future, Space Engineers could be about controlling flow and then their construction method would work well.
But I thought a little about the other half of the equation: grids are also useful for organizing chaotic topology. Could we make a starship construction system out of that?
My idea is that you start with a large-scale grid, a 3D grid where each tile is something like 10x10x5m. You can put all sorts of stuff in there, use mirroring, and all that good stuff. Not every module is 1x1x1: many modules are more awkward shapes that aren't even cubic. For example, a particular engine might be shaped like a pyramid, growing larger and larger as it goes further back.
Some modules can also be arbitrarily extended, such as interior deck space: a long wafer of starship would be a deck, and you could drag it to scale it longer or wider, each "tick" of "wider" or "longer" being one tile unit. You wouldn't make them taller, though: if you wanted another deck level, you'd attach another deck wafer. You could shape these to "hug" the complex shapes of the core functional modules.
Within each deck wafer there is a smaller grid, something like a 2m grid. This grid would be 2D simply because handling it would get too complex otherwise. Within this 2D space you can place various rooms and facilities that are intended to be pressurized, such as bunks, kitchens, gardens, hallways, doors, airlocks, cargo closets, atmospheric exchangers, etc. The large grid means there would be a 5x5-tile "fine grain" grid per large-scale tile, but it wouldn't be a simple 5x5 grid: each kind of deck wafer might have a different shape within that space, and a different reaction to being expanded in various ways. At the minimum, most of the edges would be covered in a hull tile, excepting for occasional spots where you could run a hallway through to another area or put in an airlock.
By giving the deck wafers an internal layout and having it depend on the gross layout of the ship, you create a complex topology inside the ship. The player is then challenged to put the facilities inside that space not simply according to what space is available, but also with concerns as to where the halls are, which parts of a room can have maintenance access to an automated system, which areas should be restricted to what kind of security level...
The best part about this approach is that it could easily be turned into a functional map, where the player moves through that space. Whether in 3D or 2D, the player could be made responsible for his decisions - forced to access the automated systems that were hidden behind someone's wall, forced to traverse the length of the ship, forced to search for a stowaway in all the nooks and crannies, fight a fire, whatever. Leaving the pressurized areas of the ship would be possible, but only if you put on a bulky space suit and not in situations where the ship is accelerating, being bombarded by radiation, or so on.
You can actually use this more deeply, too. While there would undoubtedly be a lot of stock parts, something like a reactor would also be made up of an interior grid. If you wanted to make your own, you could get a particular shape of chassis and put reactor parts into it. Reaction chamber, coolant, control computers, power station, and so on. In doing so you could create a reactor of your own design. This may be a bit complex - for example, if you create a chain of power stations, is that better than just having one? Depends on your application! And, of course, you may have to repair or resupply it during gameplay, so be sure to lay it out reasonably!
Similarly, you can go finer-grain. You don't like the default cabin? Well, each 2x2x3m fine-grain tile consists of a 2x2x3 grid. Place things inside that - walls, furniture, functional elements. Newly researched technologies, epic cultural artifacts, whatever. Now you have a custom room.
You could go even finer, allow the player to construct individual objects using a more typical voxel grid system, then determining the bounds of the object for inclusion into the room editor or equipment system.
Now, just laying out the ship like this is pretty ugly. Ships locked to a large grid layout are generally brutish and bland. A fine grid can work out because you can sculpt it somewhat, but when the grid is 10x10x5m, steps and sweeps are not as feasible. Rather than force the player to carefully create custom shapes for every time they don't like the flat brick approach, we allow the player to warp objects. Each object has a spine and each node in the spine can be moved out of alignment to warp the whole object along a spline. This is really not hard, it's a simple envelope deform.
This offers a number of advantages aside from looking nice.
The first is that a single, continuous object is both cheaper and more durable than the same amount of space using different objects. Rather than breaking your ship up with a deck wafer here and there and there, having one deck wafer that bends to be in those spaces is much more efficient.
The second is that attachments inherit rotation from their root. So if you have a bent deck or module, the item attached to it will be arranged along that tangent or normal instead of the global one. This allows for things like angled wings, huge solar arrays that don't collide, and other grid-breaking alignments.
The third is that a lot of modules are awkwardly shaped due to the requirements of their construction. IE, since particle accelerators have to be arranged in strict lines, your fusion reactor has long-ass prongs coming out of it. By warping either the reactor or the modules passing nearby, you can dodge and weave to keep your ship tightly designed. While there's no penalty for having spidery, sprawling ships, since you have to actually move through them during gameplay it's often hugely advantageous to have a more compact ship.
More interestingly from my perspective, warping the spine of the object also warps the fine-grain mesh within the object. If you've got a deck wafer that is curling right, the outside grid tiles are going to be much larger than the inside grid tiles. Most things can't be compressed that much: if you have a kitchen, you could put it on the outside track and it'd be a more spacious kitchen than normal, which is nice. But if you put it on the inside, you wouldn't even be able to fit a human inside that crushed space, so you can't place a kitchen there.
So the curling introduces a new kind of topological challenge. Put hallways on the inside track, because they are okay with being crushed. Don't bend things like reactors too sharply, because some of the interior components will be crushed and the reactor will not work... but, on the other hand, some reactors might be okay with being warped in one direction but not another, or you could design your own with the final warping in mind from the start.
Of course, as we can go finer-grain, we can also warp finer-grain.
This doesn't matter much for rooms like staterooms, which are probably something like 2x2. Warping really only works if you have something much longer than it is wide - for example, a hallway, or a row of hydroponic plants. Why would you ever want to warp one?
Fundamentally, these long rooms are very much like the deck wafers: you stretch them longer and longer to get more space and performance. There's an overhead with each room, and by simply extending them you save a lot. For example, a hydroponic garden uses 5 space watts plus 1 space watt per tile. The final tile on each end of a hallway is a bulkhead tile, which costs 3 space credits extra and also can't have rooms attached.
If you draw a zig-zag hallway, you end up with 3 hallways and 4 bulkheads. However, if you draw a single long hallway and warp its spine to move from one side to the other, you have only 1 hallway with 2 bulkheads. Of course, this doesn't turn as sharply, so you do end up obstructing some tiles that would have been available otherwise, so it's up to you whether that's worth it. Is it worth saving 6 space credits? It could end up being more than that, depending on how much zig-zagging you need to do.
You can also warp items that you create. Are you creating a custom chair out of voxels? Sounds great! No reason to make it all one object, though. Why not model the back of the chair separately, then add it into the editor and warp its spine so it has a graceful curve to it? Looking to make a fancy shirt? Why not warp the edge between two colors, or create a graceful scoop neck instead of a blocky square-neck.
In these situations, the spin might not just warp: it might also bulge, allowing you to grow or shrink the radius of the voxels in that area. Want to shape your character? Resize the arm spines for bulging biceps. Creating an alien? Stretch out the neck and then give it ominous bulges.
This also works in tandem with the recent idea of the Starship Vignette. If you design a starship with retrofits programmed in right at the start, then your ship's shape needs to be able to handle new modules in new shapes. By warping them cleverly, you can allow your ship to handle several different engines or whatever by making sure they're in the right place to attach properly, and out of the way of the prongs. You can try to get around this by just building sprawling ships, but it'll be really awkward and still might not work any better than reshaping things better.
...
Of course, all of this is just a thought experiment. The content required to create such a game is pretty significant, and I'm working on For SCIENCE at the moment. However, I'm confident in the technology: I've created many demos in Unity where you warp meshes via envelope spline deforms, and they work fine. The game doesn't require any magical AI or anything. It's roughly as complex as Space Engineers or Kerbal.
Even though I don't specifically plan to make this game, I wanted to post it as an example of how you can stretch the concept of construction further than most people think.
Fundamentally, voxel- or grid-based play is about either controlling flow or ordering a chaotic topology, neither of which are concepts starship games use. I caught a little flak from Space Engineer fans, because Space Engineer almost sort of kinda makes a vague attempt to be about controlling flow. Theoretically, in the future, Space Engineers could be about controlling flow and then their construction method would work well.
But I thought a little about the other half of the equation: grids are also useful for organizing chaotic topology. Could we make a starship construction system out of that?
My idea is that you start with a large-scale grid, a 3D grid where each tile is something like 10x10x5m. You can put all sorts of stuff in there, use mirroring, and all that good stuff. Not every module is 1x1x1: many modules are more awkward shapes that aren't even cubic. For example, a particular engine might be shaped like a pyramid, growing larger and larger as it goes further back.
Some modules can also be arbitrarily extended, such as interior deck space: a long wafer of starship would be a deck, and you could drag it to scale it longer or wider, each "tick" of "wider" or "longer" being one tile unit. You wouldn't make them taller, though: if you wanted another deck level, you'd attach another deck wafer. You could shape these to "hug" the complex shapes of the core functional modules.
Within each deck wafer there is a smaller grid, something like a 2m grid. This grid would be 2D simply because handling it would get too complex otherwise. Within this 2D space you can place various rooms and facilities that are intended to be pressurized, such as bunks, kitchens, gardens, hallways, doors, airlocks, cargo closets, atmospheric exchangers, etc. The large grid means there would be a 5x5-tile "fine grain" grid per large-scale tile, but it wouldn't be a simple 5x5 grid: each kind of deck wafer might have a different shape within that space, and a different reaction to being expanded in various ways. At the minimum, most of the edges would be covered in a hull tile, excepting for occasional spots where you could run a hallway through to another area or put in an airlock.
By giving the deck wafers an internal layout and having it depend on the gross layout of the ship, you create a complex topology inside the ship. The player is then challenged to put the facilities inside that space not simply according to what space is available, but also with concerns as to where the halls are, which parts of a room can have maintenance access to an automated system, which areas should be restricted to what kind of security level...
The best part about this approach is that it could easily be turned into a functional map, where the player moves through that space. Whether in 3D or 2D, the player could be made responsible for his decisions - forced to access the automated systems that were hidden behind someone's wall, forced to traverse the length of the ship, forced to search for a stowaway in all the nooks and crannies, fight a fire, whatever. Leaving the pressurized areas of the ship would be possible, but only if you put on a bulky space suit and not in situations where the ship is accelerating, being bombarded by radiation, or so on.
You can actually use this more deeply, too. While there would undoubtedly be a lot of stock parts, something like a reactor would also be made up of an interior grid. If you wanted to make your own, you could get a particular shape of chassis and put reactor parts into it. Reaction chamber, coolant, control computers, power station, and so on. In doing so you could create a reactor of your own design. This may be a bit complex - for example, if you create a chain of power stations, is that better than just having one? Depends on your application! And, of course, you may have to repair or resupply it during gameplay, so be sure to lay it out reasonably!
Similarly, you can go finer-grain. You don't like the default cabin? Well, each 2x2x3m fine-grain tile consists of a 2x2x3 grid. Place things inside that - walls, furniture, functional elements. Newly researched technologies, epic cultural artifacts, whatever. Now you have a custom room.
You could go even finer, allow the player to construct individual objects using a more typical voxel grid system, then determining the bounds of the object for inclusion into the room editor or equipment system.
Now, just laying out the ship like this is pretty ugly. Ships locked to a large grid layout are generally brutish and bland. A fine grid can work out because you can sculpt it somewhat, but when the grid is 10x10x5m, steps and sweeps are not as feasible. Rather than force the player to carefully create custom shapes for every time they don't like the flat brick approach, we allow the player to warp objects. Each object has a spine and each node in the spine can be moved out of alignment to warp the whole object along a spline. This is really not hard, it's a simple envelope deform.
This offers a number of advantages aside from looking nice.
The first is that a single, continuous object is both cheaper and more durable than the same amount of space using different objects. Rather than breaking your ship up with a deck wafer here and there and there, having one deck wafer that bends to be in those spaces is much more efficient.
The second is that attachments inherit rotation from their root. So if you have a bent deck or module, the item attached to it will be arranged along that tangent or normal instead of the global one. This allows for things like angled wings, huge solar arrays that don't collide, and other grid-breaking alignments.
The third is that a lot of modules are awkwardly shaped due to the requirements of their construction. IE, since particle accelerators have to be arranged in strict lines, your fusion reactor has long-ass prongs coming out of it. By warping either the reactor or the modules passing nearby, you can dodge and weave to keep your ship tightly designed. While there's no penalty for having spidery, sprawling ships, since you have to actually move through them during gameplay it's often hugely advantageous to have a more compact ship.
More interestingly from my perspective, warping the spine of the object also warps the fine-grain mesh within the object. If you've got a deck wafer that is curling right, the outside grid tiles are going to be much larger than the inside grid tiles. Most things can't be compressed that much: if you have a kitchen, you could put it on the outside track and it'd be a more spacious kitchen than normal, which is nice. But if you put it on the inside, you wouldn't even be able to fit a human inside that crushed space, so you can't place a kitchen there.
So the curling introduces a new kind of topological challenge. Put hallways on the inside track, because they are okay with being crushed. Don't bend things like reactors too sharply, because some of the interior components will be crushed and the reactor will not work... but, on the other hand, some reactors might be okay with being warped in one direction but not another, or you could design your own with the final warping in mind from the start.
Of course, as we can go finer-grain, we can also warp finer-grain.
This doesn't matter much for rooms like staterooms, which are probably something like 2x2. Warping really only works if you have something much longer than it is wide - for example, a hallway, or a row of hydroponic plants. Why would you ever want to warp one?
Fundamentally, these long rooms are very much like the deck wafers: you stretch them longer and longer to get more space and performance. There's an overhead with each room, and by simply extending them you save a lot. For example, a hydroponic garden uses 5 space watts plus 1 space watt per tile. The final tile on each end of a hallway is a bulkhead tile, which costs 3 space credits extra and also can't have rooms attached.
If you draw a zig-zag hallway, you end up with 3 hallways and 4 bulkheads. However, if you draw a single long hallway and warp its spine to move from one side to the other, you have only 1 hallway with 2 bulkheads. Of course, this doesn't turn as sharply, so you do end up obstructing some tiles that would have been available otherwise, so it's up to you whether that's worth it. Is it worth saving 6 space credits? It could end up being more than that, depending on how much zig-zagging you need to do.
You can also warp items that you create. Are you creating a custom chair out of voxels? Sounds great! No reason to make it all one object, though. Why not model the back of the chair separately, then add it into the editor and warp its spine so it has a graceful curve to it? Looking to make a fancy shirt? Why not warp the edge between two colors, or create a graceful scoop neck instead of a blocky square-neck.
In these situations, the spin might not just warp: it might also bulge, allowing you to grow or shrink the radius of the voxels in that area. Want to shape your character? Resize the arm spines for bulging biceps. Creating an alien? Stretch out the neck and then give it ominous bulges.
This also works in tandem with the recent idea of the Starship Vignette. If you design a starship with retrofits programmed in right at the start, then your ship's shape needs to be able to handle new modules in new shapes. By warping them cleverly, you can allow your ship to handle several different engines or whatever by making sure they're in the right place to attach properly, and out of the way of the prongs. You can try to get around this by just building sprawling ships, but it'll be really awkward and still might not work any better than reshaping things better.
...
Of course, all of this is just a thought experiment. The content required to create such a game is pretty significant, and I'm working on For SCIENCE at the moment. However, I'm confident in the technology: I've created many demos in Unity where you warp meshes via envelope spline deforms, and they work fine. The game doesn't require any magical AI or anything. It's roughly as complex as Space Engineers or Kerbal.
Even though I don't specifically plan to make this game, I wanted to post it as an example of how you can stretch the concept of construction further than most people think.
Wednesday, April 23, 2014
Violence in Sci Fi Construction Games
There's a lot of cool games in the pipeline these days, and a lot of them are about building cool things in scifi settings. The problem is, they all then universally talk about blowing things up with the things you built.
That's really a bad call.
Combat is not compatible with the sort of internally-focused construction games these people are building. We've become so used to adding combat to everything that people have forgotten to think about whether combat is a good fit. I think the reason most designers seem to lose track of whether combat is a good fit is because they are used to customization rather than construction.
See, in most space combat games, you can customize your ship. Add in a better laser, change how much energy is going to your shields, restock on missiles, and stick in a better engine. Customization is fine for a combat game, because it's fundamentally the same as equipping a character. You are changing how your ship relates to the world around it: improved firepower, faster speed, more cargo, whatever.
But with a lot of these new games, you aren't simply customizing a ship. You're constructing it, brick by brick. For example, in Space Engineers, you build a ship out of Minecraft-style bricks.
These ships are built with combat in mind, because uh... because... ... well... uh... lasers are cool?
The problem is that this kind of construction is an internally-focused system. The end result of weapons, shields, engines, and other combat stats ends up feeling very forced, because the actual construction of the ship is about making a ship exist. This is not about making a ship relate to the outside world, it is about making the ship exist in its full complexity, with all the walkways and landing pads and sleek planes and whatever.
If you just care about how it relates to the outside world, you end up with a very ugly optimized ship. It feels wrong and stupid-looking. Even if you do that, the combat is never very interesting because it is too, well, too realistic. Things get damaged arbitrarily. Things resist arbitrarily. It's hard to tell how much damage you're doing. It's hard to tell how much damage you're actually taking. There's too much noise introduced by the extremely fine grain of detail that everything has.
You really need to consider whether your game is about customization or construction, because construction is not compatible with external challenges.
When you're building something where each piece relates to specific other pieces in direct ways, the challenges need to be about THAT. This trap moves a person towards that trap. This walkway connects that hall to this warp core. This wire hooks that light to this power source. That building creates a certain amount of cash but annoys all other buildings within 200m.
But there are base-building games that are externally-focused. For example, every RTS.
An externally-focused base-building game looks the same as an internally-focused game at first glance. They share a lot of similarities: putting things down in specific places, managing resources, and so on. However, an RTS base is not very internally complex. The buildings don't relate to each other very directly, but instead only indirectly through resource production and consumption. Where you choose to put them is more about the constraints of the map and your guess as to your enemy's tactics, rather than having to place them to directly relate to other buildings.
You could argue fine points. For example, you could argue that a combination of turrets and walls is sometimes used, and those do physically relate to each other. Similarly, you could argue that something like a goo field directly relates to other buildings. In the end, the line can be a bit vague, but I don't think anyone would argue that building long lines of walls is the core gameplay of Starcraft.
Putting aside the sometimes blurry edge cases, I would argue that internally-focused construction games are inherently a bad match for combat gameplay. Combat boils your avatar's performance down to some stats, while complex construction is focused on exactly the opposite.
That's really a bad call.
Combat is not compatible with the sort of internally-focused construction games these people are building. We've become so used to adding combat to everything that people have forgotten to think about whether combat is a good fit. I think the reason most designers seem to lose track of whether combat is a good fit is because they are used to customization rather than construction.
See, in most space combat games, you can customize your ship. Add in a better laser, change how much energy is going to your shields, restock on missiles, and stick in a better engine. Customization is fine for a combat game, because it's fundamentally the same as equipping a character. You are changing how your ship relates to the world around it: improved firepower, faster speed, more cargo, whatever.
But with a lot of these new games, you aren't simply customizing a ship. You're constructing it, brick by brick. For example, in Space Engineers, you build a ship out of Minecraft-style bricks.
These ships are built with combat in mind, because uh... because... ... well... uh... lasers are cool?
The problem is that this kind of construction is an internally-focused system. The end result of weapons, shields, engines, and other combat stats ends up feeling very forced, because the actual construction of the ship is about making a ship exist. This is not about making a ship relate to the outside world, it is about making the ship exist in its full complexity, with all the walkways and landing pads and sleek planes and whatever.
If you just care about how it relates to the outside world, you end up with a very ugly optimized ship. It feels wrong and stupid-looking. Even if you do that, the combat is never very interesting because it is too, well, too realistic. Things get damaged arbitrarily. Things resist arbitrarily. It's hard to tell how much damage you're doing. It's hard to tell how much damage you're actually taking. There's too much noise introduced by the extremely fine grain of detail that everything has.
You really need to consider whether your game is about customization or construction, because construction is not compatible with external challenges.
When you're building something where each piece relates to specific other pieces in direct ways, the challenges need to be about THAT. This trap moves a person towards that trap. This walkway connects that hall to this warp core. This wire hooks that light to this power source. That building creates a certain amount of cash but annoys all other buildings within 200m.
But there are base-building games that are externally-focused. For example, every RTS.
An externally-focused base-building game looks the same as an internally-focused game at first glance. They share a lot of similarities: putting things down in specific places, managing resources, and so on. However, an RTS base is not very internally complex. The buildings don't relate to each other very directly, but instead only indirectly through resource production and consumption. Where you choose to put them is more about the constraints of the map and your guess as to your enemy's tactics, rather than having to place them to directly relate to other buildings.
You could argue fine points. For example, you could argue that a combination of turrets and walls is sometimes used, and those do physically relate to each other. Similarly, you could argue that something like a goo field directly relates to other buildings. In the end, the line can be a bit vague, but I don't think anyone would argue that building long lines of walls is the core gameplay of Starcraft.
Putting aside the sometimes blurry edge cases, I would argue that internally-focused construction games are inherently a bad match for combat gameplay. Combat boils your avatar's performance down to some stats, while complex construction is focused on exactly the opposite.
Subscribe to:
Posts (Atom)