I was asked a little while ago how I would do a space survival game, since I've been ragging on them recently. I also mentioned it in a video or two. So let's talk.
Let's get started simple. Let's say I'm a Star Citizen dev, out to put survival mechanics into my pew pew shooty game. I already have gorgeous starship interiors, now it's time to leverage them. How do I do it?
Well, my goal is to turn survival into a yarnball. A soft, complicated challenge that interlaces with a lot of other things. I also want to make sure that it unfolds into a narrative according to the choices the player makes.
So I implement a The Simslike survival system. Every time you make a space jump, your various meters go up. Hunger and filth, for example.
Actually using kitchens and showers is a repetitive and uninteresting task, so rather than requiring you to use the facilities, we simply reduce the meter if you have them. If you have a kitchenette, your hunger goes up 90% slower. A full kitchen? It doesn't go up at all... until your food runs out.
We do want to push the player to exist in that space, so we do allow the player to use a facility for a temporary boost - until the end of the next jump. If we use the kitchen, we get a +20%, but it uses up a bit of food. If we use the shower, we get a +10%, but it doesn't use up anything. This bonus doesn't reduce your meters, it simply enhances your performance. It doesn't stack.
To make this into a more narratively cohesive experience, we have to decide on the narrative we want. And the narrative we want is how the pressures of space travel shape our life aboard a ship.
This is not simply about "life aboard a ship". The point is to turn challenges - the challenges of a human surviving in space - into narrative beats. The ship is our tool to do that, but the challenge it parses is the challenge of survival.
If we want a gritty feel, we could get things like life support involved. But the ships in Star Citizen are ridiculously high tech, so instead we're thinking more about the social narrative. How does the mind fail, rather than the body.
So we add a few more meters. Loneliness, claustrophobia, boredom.
When they go up, you have to bring them down. Find someone to talk to. Land on a planet or space station and step outside. Have some fun by daredevil flying or fighting or driving a different vehicle.
...
A new player buying a new ship finds it comes with a little pocket gym. The gym reduces the meter growth of those three stats by 50% each, maybe.
But the player knows they are playing solo, and are planning to go on long explorations. So the big threat here is loneliness. The others can be dealt with in the middle of nowhere by visiting any random rock, but finding a person will be tough.
So the player rips out the gym, replaces it with a media console that constantly blares news shows and comedies. She puts portraits of her family on the wall, or pinups maybe. She buys a wisecracking robot companion.
These keep her company. And she can use them to boost: give the family a kiss, get +30%. Watch a TV show, get +40%, but use up a media slot - she'll need to buy the next season of Game of Space Thrones or trade SpaceYouTube caches with someone else to get those slots filled up with new stuff. Better to keep that cache intact, so it burns at the slower default rate and lasts longer.
And sure, she gets twitchy from the claustrophobia and the boredom. But that's why canyon racing was invented.
...
On the other hand, someone else might be playing on a team. They know loneliness won't be an issue, because there's another player around here. So they max out the others. They buy giant 3D landscapes for their walls - radically reducing claustrophobia, but actually increasing loneliness. They replace their gym with a video game console.
They can go for a long ways without having to land or play around, but they have to chat with someone every two jumps to stay happy.
No problem, they're sitting next to you.
...
We can see how the player's construction choices change the narrative. The player is choosing what narrative beats to include, which ones to play up or limit. One of those players is having a long, lonely journey hopping from planet to planet. The other is on a road trip with friends.
Those are very different narratives. We didn't write those narratives: we allow the challenges to be faced in a way that turns them into narratives.
We can push this in a lot of ways. For example, if we make it so that talking to a specific person works worse every time you do it, then those long journeys get more challenging because you have to find new people to talk to. If you burn media to keep your boredom under control, maybe you change one of those "size three hardpoints" from a gun to a giant subspace antenna that lets you transfer media from space stations a hundred light years away. Need food? There's a variety of greenhouses both internal and external...
These ramifications are polish on a core concept. If we didn't have the core progression, they'd be pointless. Most of this would be pointless if the player had to return to a station every time they logged off, for example: long journeys would be limited by a player's capacity to sit at their desk and play. But since you can log off in midjourney and come back, we can assume many players will go on very long journeys.
The question becomes: what of the players that don't?
What about the players that are short-haul? Players that specialize in fighting or shipping people or freight over shorter distances?
It's a common thing. A lot of players want to sit and do A Mission Now, and be done in half an hour. They don't want to log off midmission and come back to the same thing.
Can we make our survival systems create their narratives, too?
Well... no. It's not survival. But we can use the same core mechanics.
...
We could try to add stats like paperwork that go up as you dock... but what sort of narrative unfolds with that?
Not much of one. How can we make it messier and more entangled?
Well, most short-haul specialists will have specific hub stations - or, at least, specific preferred factions.
This is where it can't be Star Citizen, because their faction system has a ceiling. But if we throw that away, we can allow the player to build their contacts with the faction.
Rather than focusing entirely on the ship, we can allow the player-generated content to include people. Both NPC crewmembers aboard your ship and people you have agreements with on various space stations.
I would do it using a similar modular setup to the one used for ships and interiors:
As you rank up, you get a better "dossier" for that faction.
Like a ship, a dossier has specialties and hardpoints. This dossier specializes in freight permissions. This one improves insurance and rates on being a passenger liner. This one's exploration-based.
The hardpoints are people. This one's a tier 3 diplomat hard point, and you can slot in any NPC diplomat that rank or lower to act as your "weapon", giving you access to more options, more goods, more security, more sites. Reduce the rank by one just like you'd do for hardpoint turrets, and hire that person as a crewmember on your ship instead of being specific to their home space station...
Because the dossiers are essentially ships, we can offload our survival mechanics onto them.
As time passes and things happen, you might gain criminality, or disinterest, or distrust. These can be reduced if you equip the right kind of person on your hardpoints, but otherwise you'll have to do faction missions to clean them up.
And now, again, we've turned a challenge into a narrative.
Building small dossiers is easy, but you quickly learn you need to tweak it to suit your style. Do you do some... not so legal missions? You'll want a lawyer and a fence installed. Do you do a lot of business with other factions? You'll want a politician, to keep the distrust low. You go on long journeys? You'll want a reporter, to keep disinterest under control. You trade with a lot of different systems from that faction? Buy a one-rank-lower trader as a crewmember, so you get that advantage in every system.
These could even be tweaked per-faction. Both by the player, depending on their interactions with the faction... and by the devs.
Your Vulcan-ish faction might never gain disinterest, but gives bonus distrust if you sell science data to other factions. Your Klingon-ish faction loses interest extremely rapidly but never gives out criminality...
This has an extremely high ceiling. At upper levels, you might be adding the president of a space station to your dossier, or using a cross-contact politician to transfer stats to another faction's dossier.
And you can go negative. You're disliked by the Vulcan-ish faction? Add specific nemesis to your unhappy dossier. It's got a few good hard points - contacts from other factions or even turncoats from this faction - but you have to fill all your negative hardpoints first, adding in suspicious cops, angry politicians, and persistent bounty hunters.
Again: build your own narrative out of the challenge. *You choose* how your story of banditry or war unfolds.
...
Hopefully this has been a fun exploration of how to make player-created content that can turn simple things (survival, faction rank) into more robust, soft, complex mechanics that create a narrative.
To be clear: I think you could create an entire game around these concepts, rather than the shooty pew pew gameplay that I find so dreary.
There's also a lot to talk about in regards to things like resource tiering and keeping inflation under control, and it's tightly related. But... I think this is long enough.
Showing posts with label space. Show all posts
Showing posts with label space. Show all posts
Tuesday, June 18, 2019
Tuesday, April 17, 2018
A Simple Game about Huge Space Nations
Like everyone else, I love and hate 4X games.
Hearing the epic story of an entire species as they romp through the galaxy weaving their ten-thousand-year story in with friends, enemies, and supernovas? Yes please!
But the actual gameplay is so bland. It always goes in one of two ways. It's either "fun at first but now we've done the same thing 50 times" or "that thing is polished away, so it's not even fun at first".
I like the stories of interstellar civilizations!
Much like I like the stories of the families in The Sims.
4X games have some elements to create a foundation for these stories. Tech trees, alien races with reliable personalities, planets with different characteristics, and so on. However, the pattern falls apart in the midgame, as playing well becomes more important than having a story.
The Sims takes the opposite approach: after you've gained a few job levels, you probably have some breathing room. You can focus entirely on leveling up your skills and jobs in The Sims, but there's no real pressure to do so. The midgame allows you to develop the stories as you see fit. In short: the beginning of the game forces you to choose an approach, and then it gets easier so you can see what kind of stories arise from the approach you've chosen.
I've been brainstorming to see if I can think of a cool 4X-like design that does something similar, and here's one I like.
One of the big issues is that fungible resources like cash are disconnected from the continuity of your story. When you spend money to do something, you're not connecting it to a previous story beat. Therefore, instead of using space cash, how about constructing chains of assets?
For example, you have a garden planet. It has four slots: two industry, two evolution.
You might choose to mount a "mining" industry onto your planet. Rather than producing cash, it has some more specific slots: materials, orbital, metropolis. You can then start to slot in things like advanced armor, orbital construction yards, and a cultural center. In turn those have slots, and you can continue to build out a chain of Things Your Species Has.
This chain allows for context to be preserved. Your space fleet was built at the orbital construction yards supported by the mining industry of your home planet. This not only gives the player cues for their internal story, but it also gives the game opportunities to create interesting challenges: if the mines run out, it's not just a matter of losing a random facility on a random planet. Within a few years your construction yard will turn into a ghost town, and a few years after that, your fleet will start to fall apart.
That's an interesting situation from every perspective... especially if we punch it up with characters that are part of this. We can seed them all ahead of time: the mine foreman, the construction foreman, the admiral. In the beginning, you meet them, and the admiral doesn't care about the mine foreman's problems... as time passes, you can see the changing situations written on the characters, as the mine foreman becomes destitute and the admiral starts bickering with the construction foreman about why his ships can't be properly maintained.
You don't have to go that far, of course. I'm just doing whatifs.
Replacing that mining industry would be a priority. The easiest solution might be to put a "fossil fuels" asset on the planet. It takes up and evolution slot and has an industry mounting slot, which you could then move the mining industry onto. Bang, everything's solved. Right?
Wellllll...
A big part of this is that the chain of assets is not simply a chain of fungible things. The space fleet isn't simply "the same as every other space fleet but from a specific planet". Instead, the space fleet inherits all the "side effects" of its parent cards. Side effects are always passed down. Some are good, like "advanced armor". But some are bad.
The mining industry might have a side effect of "exploited underclass". This means that the docks, the space fleet, the cultural center: all would have an exploited underclass. Adding in the fossil fuel cards also creates a "toxic" side effect. Now the docks, the space fleet, and the cultural center have both an exploited underclass and a toxic side effect.
In addition to providing more materials for the implicit and explicit story we're weaving, they also provide a hook for an entire game mechanic: stories made out of the side effects rather than only the assets. The toxic + underclass combo is rife for a "black lung outbreak" story, where millions of underpaid workers are dying of toxic fumes and the corporations are trying to conceal it. This kind of story is great for allowing the player to explicitly specify what kind of space nation they're running. How far will the player go to help the underclass? To help the economy? After all, any choice they make will send a shockwave down the chain: if they spend a lot of effort on helping the miners, then the mining industry will suffer a temporary (20-year?) penalty. Halfway through that, the penalty will propagate to the dockyards and cultural center. Halfway through that, it'll hit the space fleet.
Now, the real secret of this approach is that it's only half of the system. That's the physical half, covering things and physical technologies.
The other half is the social half, covering rules, governments, cultures, social technologies, and so on.
The two sides interact. Assets for the social half are provided both by physical assets and by the vignettes inspired by physical side effects. Assets for the physical half are provided both by social assets and the vignettes inspired by social side effects.
So if you side with the miners, in addition to a physical penalty, you'll get a social card. Perhaps "worker's unions". Siding for the corporations has a physical bonus, but also gives you the social card "monstrous corporations". If you don't play them, you'll hit your hand limit and you won't get any more physical-side vignettes until you do.
You can add any additional complexity you like in terms of things like maps and factions and battle mechanics, but the heart of the system is simply a physical and social chain, where you try to manage the fallout of your older choices, especially as side effect build up.
I think it'd be fun! I prototyped it a bit, but it requires a lot more assets to work, so I'd have to put in a lot more effort to make a playable.
What do you think?
Hearing the epic story of an entire species as they romp through the galaxy weaving their ten-thousand-year story in with friends, enemies, and supernovas? Yes please!
But the actual gameplay is so bland. It always goes in one of two ways. It's either "fun at first but now we've done the same thing 50 times" or "that thing is polished away, so it's not even fun at first".
I like the stories of interstellar civilizations!
Much like I like the stories of the families in The Sims.
4X games have some elements to create a foundation for these stories. Tech trees, alien races with reliable personalities, planets with different characteristics, and so on. However, the pattern falls apart in the midgame, as playing well becomes more important than having a story.
The Sims takes the opposite approach: after you've gained a few job levels, you probably have some breathing room. You can focus entirely on leveling up your skills and jobs in The Sims, but there's no real pressure to do so. The midgame allows you to develop the stories as you see fit. In short: the beginning of the game forces you to choose an approach, and then it gets easier so you can see what kind of stories arise from the approach you've chosen.
I've been brainstorming to see if I can think of a cool 4X-like design that does something similar, and here's one I like.
One of the big issues is that fungible resources like cash are disconnected from the continuity of your story. When you spend money to do something, you're not connecting it to a previous story beat. Therefore, instead of using space cash, how about constructing chains of assets?
For example, you have a garden planet. It has four slots: two industry, two evolution.
You might choose to mount a "mining" industry onto your planet. Rather than producing cash, it has some more specific slots: materials, orbital, metropolis. You can then start to slot in things like advanced armor, orbital construction yards, and a cultural center. In turn those have slots, and you can continue to build out a chain of Things Your Species Has.
This chain allows for context to be preserved. Your space fleet was built at the orbital construction yards supported by the mining industry of your home planet. This not only gives the player cues for their internal story, but it also gives the game opportunities to create interesting challenges: if the mines run out, it's not just a matter of losing a random facility on a random planet. Within a few years your construction yard will turn into a ghost town, and a few years after that, your fleet will start to fall apart.
That's an interesting situation from every perspective... especially if we punch it up with characters that are part of this. We can seed them all ahead of time: the mine foreman, the construction foreman, the admiral. In the beginning, you meet them, and the admiral doesn't care about the mine foreman's problems... as time passes, you can see the changing situations written on the characters, as the mine foreman becomes destitute and the admiral starts bickering with the construction foreman about why his ships can't be properly maintained.
You don't have to go that far, of course. I'm just doing whatifs.
Replacing that mining industry would be a priority. The easiest solution might be to put a "fossil fuels" asset on the planet. It takes up and evolution slot and has an industry mounting slot, which you could then move the mining industry onto. Bang, everything's solved. Right?
Wellllll...
A big part of this is that the chain of assets is not simply a chain of fungible things. The space fleet isn't simply "the same as every other space fleet but from a specific planet". Instead, the space fleet inherits all the "side effects" of its parent cards. Side effects are always passed down. Some are good, like "advanced armor". But some are bad.
The mining industry might have a side effect of "exploited underclass". This means that the docks, the space fleet, the cultural center: all would have an exploited underclass. Adding in the fossil fuel cards also creates a "toxic" side effect. Now the docks, the space fleet, and the cultural center have both an exploited underclass and a toxic side effect.
In addition to providing more materials for the implicit and explicit story we're weaving, they also provide a hook for an entire game mechanic: stories made out of the side effects rather than only the assets. The toxic + underclass combo is rife for a "black lung outbreak" story, where millions of underpaid workers are dying of toxic fumes and the corporations are trying to conceal it. This kind of story is great for allowing the player to explicitly specify what kind of space nation they're running. How far will the player go to help the underclass? To help the economy? After all, any choice they make will send a shockwave down the chain: if they spend a lot of effort on helping the miners, then the mining industry will suffer a temporary (20-year?) penalty. Halfway through that, the penalty will propagate to the dockyards and cultural center. Halfway through that, it'll hit the space fleet.
Now, the real secret of this approach is that it's only half of the system. That's the physical half, covering things and physical technologies.
The other half is the social half, covering rules, governments, cultures, social technologies, and so on.
The two sides interact. Assets for the social half are provided both by physical assets and by the vignettes inspired by physical side effects. Assets for the physical half are provided both by social assets and the vignettes inspired by social side effects.
So if you side with the miners, in addition to a physical penalty, you'll get a social card. Perhaps "worker's unions". Siding for the corporations has a physical bonus, but also gives you the social card "monstrous corporations". If you don't play them, you'll hit your hand limit and you won't get any more physical-side vignettes until you do.
You can add any additional complexity you like in terms of things like maps and factions and battle mechanics, but the heart of the system is simply a physical and social chain, where you try to manage the fallout of your older choices, especially as side effect build up.
I think it'd be fun! I prototyped it a bit, but it requires a lot more assets to work, so I'd have to put in a lot more effort to make a playable.
What do you think?
Wednesday, April 15, 2015
Space Games and Physical Programming
Most space games take inspiration from pulp sci-fi. They are about exploring amazing new places, encountering strange new people.
Those pulp stories abstract out all the complexities NASA has to deal with. The spacefarers have a relatively easy time surviving the rigors of space, and are mostly challenged by the amazing new things they encounter instead of basic space travel. This simplification allows authors to tell a good story, fast.
But games require complexity.
Most space games introduce complexity from the standard genres. So you add in more guns, more engines. Sometimes more cargo space. You have a statistical challenges, fighting, trading. Complexity introduced from other genres.
But space has its own complexity. Obviously. Just surviving is a challenge. You don't need the artificial challenges of combat. Instead, just reintroduce a small amount of the natural complexity of space travel.
Physical programming is one way to do this.
Physical programming is the basic idea that various components can be connected in various ways and moderate their own behaviors accordingly. For example, you might have a heater attached to a thermometer, and the heater will turn on if the thermometer drops below a specific value. Pretty simple idea.
Physical programming is about having all that stuff reflected in physical systems. Ideally, systems that you can clearly see in the main world. So you would be able to look at the ship and see the heater, whether it's on or off. See the thermometer, how high or low it is. Even, ideally, see the target temperature we've set up.
This contrasts with a more common approach, where the heater would have a built-in thermometer and you'd be able to dial a number into the heater's configuration. Obviously, that's more efficient - but it's not physical. It's software. Digital. Integrated.
Using very primitive basic components is a good way to allow us to control exactly how much complexity we want to expose the players to at the start, and still allow the players infinite freedom to tackle more complexity if they want.
If you look at old space modules like the Vostok, you can see the kind of aesthetic this produces. It's also an opportunity to talk about a specific example of what you might have to build.
Let's say an astronaut is going up just a bit, then right back down. They might only need one air tank. You can leave it for the astronaut to control - they can turn a nozzle and get a burst of air on their own. You don't really need to "program" it, you can just trigger it with a hotkey. You might include a barometer so you know when to open the air.
But if the astronaut plans to stay up for long, they'll need more air. The Vostok has a ring of air tanks. In theory you could still do this manually - a different hotkey for each tank, personally keeping track of which ones are empty or full... but that's a lot of hotkeys, especially if you also need to do ventilation, electronics, etc.
The answer is to add automation. Physical programming requires that automation to be physical, to be visible.
You might start simply: you have a knob with calls for air, but it's connected to all the tanks - at each nozzle, it is broken by a mechanical switch. When you turn the knob, the pressure travels down the cable and hits the first mechanical switch. If it's open, the tank is opened and closed by the motions of the control knob. If the switch is closed, the pressure continues on to the next tank.
Now you have one button to control the air flow, and you can manually click on a switch when a tank runs out to move to the next tank.
Of course, that can be automated as well. Each tank has a pressure gauge on it, and you can use that to control whether the switch is open or closed. Now you have a knob to control the air, and it'll automatically fall through as the tanks run dry.
You can automate it even further by connecting the barometer to the knob and automating it - when pressure gets low, pump more air in. This might need to be made more complex in situations where there's no leakage, because then you're worried about oxygen running out rather than air pressure getting low.
It might seem odd to introduce painstaking mechanical solutions for basic things, but this allows us to precisely control how much complexity and challenge the player will encounter. The visibility of each component allows players to understand what they are looking at immediately, and also allows for us to do "topological programming".
Topological programming is a subset of physical programming where the size and placement of the pieces is extremely important. For example, in Space Engineers, the conveyor system is topological programming. But it's baby stuff.
An example more in-line with our earlier example would be the barometer. The barometer does not "read out a number" - you aren't transmitting a number over a cable. Instead, the barometer has a peg which moves up and down depending on the pressure. To make the compressed air activate at a specific pressure, you lay a switch over the barometer at the right physical point. It gets tripped when the peg moves. Variants allow for one-way activation, different kinds of activation depending on the direction, etc.
The barometer also isn't a specific "size". It's as long as you want to stretch it. Cords and cables can't run across it unless they are a switch. You can also add complexity by changing the fundamental shape we're attaching this to: if it's a tube, like most space capsules, then you can attach it vertically but not around the circumference. It's not a curvable object.
So we can make it as limited and challenging as we like - or make it easier and simpler to work with. Whatever our target complexity is. We can even do all different kinds of complexity in the same game using various tech tiers.
Or tech which is good but fragile. For example, a barometer which outputs a digital number might be possible, but it malfunctions slightly in direct sunlight and gives erroneous readings.
Moreover, because these are programmed onto a physical space, you can cut and paste functional "programs" by literally cutting and pasting. If we have a great system for monitoring pressure and using air tanks, we can copy that meter of tube and put the exact same design on another ship. We could even define it as "stretching" - the air tanks are an array of repeating elements, and if we define them as such when we lay down the initial code, we can scale the system to larger or smaller tubes by simply increasing or decreasing the number of repeating elements.
In this way even beginners can use advanced systems. This is a great way to let people play without forcing them to wade through a bog of details. It's also a great way to allow the systems to scale up to incredible complexity, since people can creatively combine subroutines.
Simulating these systems might seem annoying - it might seem like there's too many moving parts to do it reasonably. But very few of these mechanical bits need physics simulation, or even frame-to-frame simulation. The vast majority of them are event-based rather than simulation-based, which means that 99% of the time they are as lightweight as their models. LOD can even fix that, and in extreme cases you could unload their physical piece completely, just leaving their event response intact.
Physics simulation is, after all, not the point. Neither is damage simulation. The idea is to draw "game-level" complexity out of actual space travel issues.
Start with air. Heat. Ventilation. Keep moving up. Water. Food. Waste. Radiation. Keep moving up. Fitness, sleep, play, socializing, training. Keep moving up.
You can also do the other half of the equation. Rocket engines. Vernier thrusters. SAS. Docking ports. Electricity constraints. Solar panels. Combine them: socializing with visitors, maybe.
The point here is to stop playing up the complexity of combat or trading. Unlike Kerbal, we're also not reveling in the complexity of orbital mechanics. Instead, we're reveling in the complexity of humans surviving in extreme conditions thanks to these wonderful machines we've built.
Our simulation should make it fun to try to get your astronauts to flourish in space.
Or underwater, maybe. That could be awesome, too.
Anyway, this was a tough essay to pin down, I hope you enjoyed it.
Those pulp stories abstract out all the complexities NASA has to deal with. The spacefarers have a relatively easy time surviving the rigors of space, and are mostly challenged by the amazing new things they encounter instead of basic space travel. This simplification allows authors to tell a good story, fast.
But games require complexity.
Most space games introduce complexity from the standard genres. So you add in more guns, more engines. Sometimes more cargo space. You have a statistical challenges, fighting, trading. Complexity introduced from other genres.
But space has its own complexity. Obviously. Just surviving is a challenge. You don't need the artificial challenges of combat. Instead, just reintroduce a small amount of the natural complexity of space travel.
Physical programming is one way to do this.
Physical programming is the basic idea that various components can be connected in various ways and moderate their own behaviors accordingly. For example, you might have a heater attached to a thermometer, and the heater will turn on if the thermometer drops below a specific value. Pretty simple idea.
Physical programming is about having all that stuff reflected in physical systems. Ideally, systems that you can clearly see in the main world. So you would be able to look at the ship and see the heater, whether it's on or off. See the thermometer, how high or low it is. Even, ideally, see the target temperature we've set up.
This contrasts with a more common approach, where the heater would have a built-in thermometer and you'd be able to dial a number into the heater's configuration. Obviously, that's more efficient - but it's not physical. It's software. Digital. Integrated.
Using very primitive basic components is a good way to allow us to control exactly how much complexity we want to expose the players to at the start, and still allow the players infinite freedom to tackle more complexity if they want.
If you look at old space modules like the Vostok, you can see the kind of aesthetic this produces. It's also an opportunity to talk about a specific example of what you might have to build.
Let's say an astronaut is going up just a bit, then right back down. They might only need one air tank. You can leave it for the astronaut to control - they can turn a nozzle and get a burst of air on their own. You don't really need to "program" it, you can just trigger it with a hotkey. You might include a barometer so you know when to open the air.
But if the astronaut plans to stay up for long, they'll need more air. The Vostok has a ring of air tanks. In theory you could still do this manually - a different hotkey for each tank, personally keeping track of which ones are empty or full... but that's a lot of hotkeys, especially if you also need to do ventilation, electronics, etc.
The answer is to add automation. Physical programming requires that automation to be physical, to be visible.
You might start simply: you have a knob with calls for air, but it's connected to all the tanks - at each nozzle, it is broken by a mechanical switch. When you turn the knob, the pressure travels down the cable and hits the first mechanical switch. If it's open, the tank is opened and closed by the motions of the control knob. If the switch is closed, the pressure continues on to the next tank.
Now you have one button to control the air flow, and you can manually click on a switch when a tank runs out to move to the next tank.
Of course, that can be automated as well. Each tank has a pressure gauge on it, and you can use that to control whether the switch is open or closed. Now you have a knob to control the air, and it'll automatically fall through as the tanks run dry.
You can automate it even further by connecting the barometer to the knob and automating it - when pressure gets low, pump more air in. This might need to be made more complex in situations where there's no leakage, because then you're worried about oxygen running out rather than air pressure getting low.
It might seem odd to introduce painstaking mechanical solutions for basic things, but this allows us to precisely control how much complexity and challenge the player will encounter. The visibility of each component allows players to understand what they are looking at immediately, and also allows for us to do "topological programming".
Topological programming is a subset of physical programming where the size and placement of the pieces is extremely important. For example, in Space Engineers, the conveyor system is topological programming. But it's baby stuff.
An example more in-line with our earlier example would be the barometer. The barometer does not "read out a number" - you aren't transmitting a number over a cable. Instead, the barometer has a peg which moves up and down depending on the pressure. To make the compressed air activate at a specific pressure, you lay a switch over the barometer at the right physical point. It gets tripped when the peg moves. Variants allow for one-way activation, different kinds of activation depending on the direction, etc.
The barometer also isn't a specific "size". It's as long as you want to stretch it. Cords and cables can't run across it unless they are a switch. You can also add complexity by changing the fundamental shape we're attaching this to: if it's a tube, like most space capsules, then you can attach it vertically but not around the circumference. It's not a curvable object.
So we can make it as limited and challenging as we like - or make it easier and simpler to work with. Whatever our target complexity is. We can even do all different kinds of complexity in the same game using various tech tiers.
Or tech which is good but fragile. For example, a barometer which outputs a digital number might be possible, but it malfunctions slightly in direct sunlight and gives erroneous readings.
Moreover, because these are programmed onto a physical space, you can cut and paste functional "programs" by literally cutting and pasting. If we have a great system for monitoring pressure and using air tanks, we can copy that meter of tube and put the exact same design on another ship. We could even define it as "stretching" - the air tanks are an array of repeating elements, and if we define them as such when we lay down the initial code, we can scale the system to larger or smaller tubes by simply increasing or decreasing the number of repeating elements.
In this way even beginners can use advanced systems. This is a great way to let people play without forcing them to wade through a bog of details. It's also a great way to allow the systems to scale up to incredible complexity, since people can creatively combine subroutines.
Simulating these systems might seem annoying - it might seem like there's too many moving parts to do it reasonably. But very few of these mechanical bits need physics simulation, or even frame-to-frame simulation. The vast majority of them are event-based rather than simulation-based, which means that 99% of the time they are as lightweight as their models. LOD can even fix that, and in extreme cases you could unload their physical piece completely, just leaving their event response intact.
Physics simulation is, after all, not the point. Neither is damage simulation. The idea is to draw "game-level" complexity out of actual space travel issues.
Start with air. Heat. Ventilation. Keep moving up. Water. Food. Waste. Radiation. Keep moving up. Fitness, sleep, play, socializing, training. Keep moving up.
You can also do the other half of the equation. Rocket engines. Vernier thrusters. SAS. Docking ports. Electricity constraints. Solar panels. Combine them: socializing with visitors, maybe.
The point here is to stop playing up the complexity of combat or trading. Unlike Kerbal, we're also not reveling in the complexity of orbital mechanics. Instead, we're reveling in the complexity of humans surviving in extreme conditions thanks to these wonderful machines we've built.
Our simulation should make it fun to try to get your astronauts to flourish in space.
Or underwater, maybe. That could be awesome, too.
Anyway, this was a tough essay to pin down, I hope you enjoyed it.
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.
Thursday, March 10, 2011
Small Worlds
These days, games tend to be designed with the idea that bigger is better. A wider world. Vast expanses of space filled in with variations on standard content. Examples abound, especially in RPGs. For example's sake, take a look at Oblivion. Not only are there vast stretches of general terrain, but the majority of architecture (dungeon and inhabited) also reuses a lot of the same content.
While there's nothing wrong with this idea, let's briefly consider what would happen if you took those million man-hours and dedicated them all to a much smaller surface area. Say your entire RPG happened in a high school.
With the kind of content creation thrown at a game like Oblivion, every character in the high school - every student, every teacher, every janitor - they are all unique characters. You never encounter a faceless or cloned NPC. Every corner of the school is carefully designed. You never think one room is the clone of another room unless that's what the designers were going for.
The increased density changes a lot of things. The first thing it changes is the player's perception of the environment. When the player is in an environment that is (A) very dense in unique content and (B) going to be their major haunt for many hours, their awareness stretches. They will become aware of smaller details, smaller presences, smaller changes.
This is no surprise: players pay attention to what matters in a given game. In an adventure game, every pixel might matter, every word might be a clue. But in a vast open-world game, few things actually matter. Just keep your eye open for the cool car you want and listen for the game to start up the battle music that says you're being attacked. The other cars are unimportant, and you don't have to always look around you to see if bears are arriving.
However, there are loads of other things that a denser game environment changes.
The cost of content is dramatically changed because the content interacts with itself a lot more. In a game like Oblivion, every unique NPC only reacts to their own tiny corner of the plot. This is accepted: the NPCs don't ever do anything that feels like free will, and even if they did, they're separated by vast amounts of space.
But when you condense to a smaller space filled with the same number of NPCs, suddenly you can't ignore the fact that they see each other. The denser the space and the more mobile the NPCs, the more your NPCs have to interact with other NPCs and content. So each NPC becomes more expensive to build.
They're not any more expensive in terms of graphics, but they are in terms of scripting and testing. After a certain point, you'll need a kind of basic social AI for them since it becomes too difficult to script for every condition they may encounter. Even if you had a full-blown perfect AI for each character, you'd still have to configure the content carefully so the game unfolds in a way which pulls and entertains the player.
You can cut down on this by cutting down the mobility and density of the space. For example, in Phoenix Wright, the space is very dense, but the characters cannot move about. You'll spend most of your time directly interacting with unique NPCs in unique situations, but none of the NPCs are programmed to figure out what to do with themselves: every inch is carefully scripted.
This solution has obvious limits, but you could do somewhat similar techniques that aren't so restrictive. For example, imagine a game version of Magical Shopping Arcade Abenobashi. There are hundreds of characters, but they are all variations of the same half-dozen fundamental characters reinterpreted on different worlds. So the different versions of the NPCs never interact: you're left with a fairly dense space and lots of interesting characters, but you don't have to worry about the crippling recombinatorial explosion of them interacting with each other.
There are also other concerns about "dense space" games.
For example, most dense space games have to have time as a major element. While player time is always important, that's not what I'm talking about. I'm talking about game-world time that matters: changes to the state of the game world over time.
Because the game world is so much smaller, changes to the game world usually touch a whole lot more content than you might think. If you choose to nuke or not nuke that town in Fallout 3, either way the percentage of the content it affects is on the order of 0.01%. But replacing a single teacher in our theoretical high-school game will affect on the order of 2-3% of the content, since it is all much more tightly interwoven.
In addition, it's harder to do "disconnected" stuff. While you can kill 50k bandits in Oblivion, it's usually significantly harder to have those kinds of "fire and forget" encounters in a much smaller world. If you manage to write them in somehow, they often end up expanding the world dramatically in the process, sort of like the way that Persona games classically have a very dense home base but a completely not-even-vaguely-dense dungeon section. Anyway, a higher percentage of your interactions are likely to be world- or content-altering to some degree.
In the end, this usually means that dense space games will probably focus on a ton of tiny, incremental changes to the world. This is not how we normally think of game design: we usually think in terms of numeric systems and level maps, rather than tiny changes to NPCs. Our industry's inexperience at this is another reason that games with dense space will probably be more difficult for us.
At least, games with dense space that have loads of NPCs. There are plenty of dense space games you could make that have few or no NPCs. For example, Sim City is a dense space game with no NPCs. But that sort of game isn't really what I mean: I'm talking about RPGs.
And some RPGs are already condensing space, at least some of the time. For example, Dragon Age's relatively dense "base camp". Of course, the play in these parts is generally not really there: the NPCs don't interact with each other, time doesn't really pass, nothing really changes. It's just a handy way to talk to NPCs that aren't in your party. Still, it's a shadow of the sort of thing I'm talking about.
...
I've kind of babbled on a bit, but what I am fundamentally saying is that bigger doesn't necessarily mean better. There are advantages to having a smaller, denser space: the player feels a stronger connection to the space and it offers opportunities to have much more dramatic and subtle NPC events/arcs. There are also costs.
I hope to see more games use less space.
Monday, September 27, 2010
Star Maps
It's really common for star maps to be in 2D. I think this is unfortunate, so I'd like to talk about making the transition to a 3D star map.
The difficulty in a 3D star map is that the human mind really tends to think of surfaces rather than freefloating objects. Just look at how difficult it is to make out what is going on when looking down on scaffolding: how many levels high is it? Which slats are on which levels? This is a problem that many games are beginning to encounter as they try to build very high (tall) levels. Mirror's edge has some examples, as does Prince of Persia: it's easy to lose track of what is "beneath" you, even though you passed through a few moments ago. Which part of the level is that, down there?
And those games have it easy, because at least they're working with surfaces. A star map is just points of light.
There are several things we can do to ease the problems.
One is to introduce surface-like elements, including things like radial disks around certain stars, and trade routes that have broad, flat surfaces. It's critical to keep these things to a size that can be easily extrapolated, so you can tell the distance. Having a disk around a star that grows based on population makes it impossible to use that disk to determine what z-level the star is on. If the disk is always the same size, though, we can guess where the star is by looking at the perspective-induced difference is size.
Having a flat "z-surface" with "raised lines" is pretty common in games. This is descended from old submarine sims. I find this to be a pretty poor solution, only slightly better than no marks at all. A single flat surface with no relation to any of the actual points of light isn't a very useful surface, so the surfaces should integrate the stars.
Gently sliding the camera into position rather than simply "popping" into place is also somewhat useful, as it gives parallax information. This only works until the user switches screens due to the way we process visuals, so it might be useful to slide the camera into place every single time the user switches screens, even if the galactic camera has no reason to have moved. Even a tiny motion is sufficient to give parallax.
Keeping the same "up" and "north" is also useful. It's tempting to let the player control the pitch and yaw of the camera, since it's a 3D world and your instincts are based around flight sims and FPS games. But in actuality the only control the player needs is zoom: always keeping the same up, down, north, south, east, and west means that the players will be able to memorize the location of stars using the same faculties they use to memorize the location of the door in their room, an icon in their desktop, the shift stick in their car. Humans are bad at rotational pattern recognition, and there's no gameplay reason to allow rotation.
All of these will help, but they have the fundamental problem that they're still representing freefloating dots and rails rather than surfaces. It might be worthwhile to create surfaces instead. We can, for example, build a number of surfaces into the star region, and stars have to be on a surface. Due to the vertical requirements, the best solution is probably thick tubes or large freefloating objects instead of a terrain-like surface.
You will have problem with opacity, though: how will you see stars on the opposite side of an object, or occluded by an object? On the plus side, your travel routes could be inherently linked to the topology, making it feel like more than just a visual aide.
This brings up the problem of opacity in general. Stars are not the only things in space. Things like nebulae are often important tactical considerations, but rendering them is difficult to do without mucking up the display: large opaque blobs will hide everything inside them or on the other side. Also, since they are arbitrarily sized and shaped, it can be very hard to determine where in space they actually are.
National borders have the same problem: they are a 3D perimeter of arbitrary size and shape. How do you draw them so they don't confuse the viewer or obscure other important things? Transparency might seem like the answer, but in fact it just makes things even muddier.
I don't know if there's a perfect solution, but I'm playing with two solutions.
One uses the "stars on surface" approach as mentioned above, except that the "surface" is automatically generated to include all stars not part of your nation/reach. This essentially puts your nation inside a bubble. This has a lot of downsides, though. It requires that you have "flight sim" controls due to opacity issues, which in turn means that if your nation is larger than about a dozen stars, you start losing track and thinking of them as "those stars" rather than individual stars.
The other idea is the "panned opacity". I think of this like radar: the opaque walls of nebula and borders are drawn, but only in a transitory thin slice as the "scanner" travels. This seems to work okay, but it feels kind of "foggy".
None of this is necessary if you have a surfaced-based space, though: you can just color the always-visible surfaces the color of their owners.
Another "solution" is to simply radically downplay the importance of the 3D star map to the player. The AI can take advantage of that 3D space to build an interesting world, but the player's game takes place in a small enough region that he can't get lost. Also, if the player is an avatar instead of a nation, the player will have an easier time of it because they won't have to remember where every star is and what they are doing, just two or three.
What are your opinions on 3D star maps?
The difficulty in a 3D star map is that the human mind really tends to think of surfaces rather than freefloating objects. Just look at how difficult it is to make out what is going on when looking down on scaffolding: how many levels high is it? Which slats are on which levels? This is a problem that many games are beginning to encounter as they try to build very high (tall) levels. Mirror's edge has some examples, as does Prince of Persia: it's easy to lose track of what is "beneath" you, even though you passed through a few moments ago. Which part of the level is that, down there?
And those games have it easy, because at least they're working with surfaces. A star map is just points of light.
There are several things we can do to ease the problems.
One is to introduce surface-like elements, including things like radial disks around certain stars, and trade routes that have broad, flat surfaces. It's critical to keep these things to a size that can be easily extrapolated, so you can tell the distance. Having a disk around a star that grows based on population makes it impossible to use that disk to determine what z-level the star is on. If the disk is always the same size, though, we can guess where the star is by looking at the perspective-induced difference is size.
Having a flat "z-surface" with "raised lines" is pretty common in games. This is descended from old submarine sims. I find this to be a pretty poor solution, only slightly better than no marks at all. A single flat surface with no relation to any of the actual points of light isn't a very useful surface, so the surfaces should integrate the stars.
Gently sliding the camera into position rather than simply "popping" into place is also somewhat useful, as it gives parallax information. This only works until the user switches screens due to the way we process visuals, so it might be useful to slide the camera into place every single time the user switches screens, even if the galactic camera has no reason to have moved. Even a tiny motion is sufficient to give parallax.
Keeping the same "up" and "north" is also useful. It's tempting to let the player control the pitch and yaw of the camera, since it's a 3D world and your instincts are based around flight sims and FPS games. But in actuality the only control the player needs is zoom: always keeping the same up, down, north, south, east, and west means that the players will be able to memorize the location of stars using the same faculties they use to memorize the location of the door in their room, an icon in their desktop, the shift stick in their car. Humans are bad at rotational pattern recognition, and there's no gameplay reason to allow rotation.
All of these will help, but they have the fundamental problem that they're still representing freefloating dots and rails rather than surfaces. It might be worthwhile to create surfaces instead. We can, for example, build a number of surfaces into the star region, and stars have to be on a surface. Due to the vertical requirements, the best solution is probably thick tubes or large freefloating objects instead of a terrain-like surface.
You will have problem with opacity, though: how will you see stars on the opposite side of an object, or occluded by an object? On the plus side, your travel routes could be inherently linked to the topology, making it feel like more than just a visual aide.
This brings up the problem of opacity in general. Stars are not the only things in space. Things like nebulae are often important tactical considerations, but rendering them is difficult to do without mucking up the display: large opaque blobs will hide everything inside them or on the other side. Also, since they are arbitrarily sized and shaped, it can be very hard to determine where in space they actually are.
National borders have the same problem: they are a 3D perimeter of arbitrary size and shape. How do you draw them so they don't confuse the viewer or obscure other important things? Transparency might seem like the answer, but in fact it just makes things even muddier.
I don't know if there's a perfect solution, but I'm playing with two solutions.
One uses the "stars on surface" approach as mentioned above, except that the "surface" is automatically generated to include all stars not part of your nation/reach. This essentially puts your nation inside a bubble. This has a lot of downsides, though. It requires that you have "flight sim" controls due to opacity issues, which in turn means that if your nation is larger than about a dozen stars, you start losing track and thinking of them as "those stars" rather than individual stars.
The other idea is the "panned opacity". I think of this like radar: the opaque walls of nebula and borders are drawn, but only in a transitory thin slice as the "scanner" travels. This seems to work okay, but it feels kind of "foggy".
None of this is necessary if you have a surfaced-based space, though: you can just color the always-visible surfaces the color of their owners.
Another "solution" is to simply radically downplay the importance of the 3D star map to the player. The AI can take advantage of that 3D space to build an interesting world, but the player's game takes place in a small enough region that he can't get lost. Also, if the player is an avatar instead of a nation, the player will have an easier time of it because they won't have to remember where every star is and what they are doing, just two or three.
What are your opinions on 3D star maps?
Sunday, November 09, 2008
Space Navigation
This is a technical essay for beginners on the subject of AI navigation in space games.
A few weeks ago, I tried to build a space-fleet-combat-game. In the process, I learned a whole lot about how to get an AI to navigate in space. Recently, one of my friends tried the same thing, and I realized it might be worth doing an introductory essay on space navigation, plotting intercept courses, taking into account gravity wells, etc.
Proper space games, whether Star Control 2-style or Wing Commander-style, have a few factors that make them completely different from other games. First, the main engines point directly backwards and turning isn't instant. Second, you keep going on the same vector: no (or very low) friction.
This totally destroys the old fashioned interception calculations that you might use for a first-person-shooter or RPG, because as time passes, the target will be in a different location relative to you (whether it's you, he, or both that are moving).
The easiest way I found to calculate out a basic intercept course is as follows:
Get the distance between you and your target. Divide it by your average speed. That is the ETA.
Calculate the new positions of you and your target at ETA, but cap your vector at a certain constant number of seconds (3 is good for most action space games). IE, if the enemy is moving x+1m/s, in ten seconds he'll be at x+10m. However, if you are moving at x+1m/s, in ten seconds you'll be at x+3m, because your vector vanishes after three seconds. We negate our own vector because we plan on changing it radically.
Now, determine how long it would take to reach these virtual positions. IE, how quickly you can turn to the proper heading and close at speed. Do not bother taking into account your current vector. This is the estimated course (EC).
If the EC is roughly the same length as the ETA, go for it. If it's significantly different, increase or decrease your ETA significantly and try again until you find an EC that works or your ETA becomes stupid (error out).
This system works in most space games because most space games have a maximum speed cap. If your maximum speed is 100m/s and you're traveling at x+100m/s, accelerating along the z axis will make you arc away from that and to z+100m/s, no x velocity at all. This is true both of 2D and 3D space games: most of them impose this artificial speed cap so that people have a hope of being able to navigate intuitively.
The slower you turn and the longer it takes to reach your maximum speed, the more of a factor your current velocity will be, and the longer your personal velocity cut-off time should be. In addition, when calculating your estimated course (EC), you should take into account that your average speed will be lower than your maximum speed because you have to accelerate - and if your acceleration is slow, that will be more important. Obviously, the longer the thrust, the closer to your maximum speed your average speed will be.
...
Now, if you're like me, you're the sort of person who doesn't want a speed cap. If you're traveling at x+100m/s and you start thrusting along z, you'll reach x+100m/s & z+100m/s. No speed cap except maybe light speed.
This makes navigation difficult because you have to factor in your vector much more strongly, often moving to negate it. On the surface, you should just be able to do away with the velocity cutoff. However, it's not quite that simple.
First, you need to calculate not just where the enemy ship will be at ETA based on his current vector, but also based on his acceleration. If a ship is accelerating away, you need to take that into account or you'll be hopelessly off course.
Second, this system produces radically inappropriate intercept speeds. You'll blow by your enemy doing 0.3c, you won't even see the bastard as he blips by. So you need to put in some kind of rough vector matching mixed into the basic intercept package. It's possible to program, but the actual physics of the matter make it highly difficult: unless your ship has many times the thrust of the ship you're intercepting, it will take you a long, long time to close and match vectors. And if you've got any human-controlled ships, forget it!
Another factor in this kind of game is the light-speed cap, which is a common thing to want to include. The idea is that the speed cap is light speed, and the closer you get to light speed, the more thrust it takes to change your vector.
There are a lot of problems with this. In basics, this means that your current velocity will screw up your acceleration. Plotting an intercept course may involve having to slow down so you can accelerate along another vector.
Of course, the truth is that the issue is radically more complex than that, because you're always operating from your own frame of reference. You aren't going 0.9c: everything else is. The light speed limit is no good for gameplay unless you (A) are a physicist or (B) throw away any realism it may have had.
...
With the described system, basic navigation is possible. However, most games want more advanced navigation: they want to be able to orbit planets, do gravitational slingshots, present broadsides, interpose specific faces of their ships, ram (and avoid ramming), etc, etc, etc.
Each of these things requires some pretty significant tweaking... and, of course, the basic calculations presented here are not exactly optimized. They give pretty rough (but functional) intercepts.
There's the basics. Hope it helps.
A few weeks ago, I tried to build a space-fleet-combat-game. In the process, I learned a whole lot about how to get an AI to navigate in space. Recently, one of my friends tried the same thing, and I realized it might be worth doing an introductory essay on space navigation, plotting intercept courses, taking into account gravity wells, etc.
Proper space games, whether Star Control 2-style or Wing Commander-style, have a few factors that make them completely different from other games. First, the main engines point directly backwards and turning isn't instant. Second, you keep going on the same vector: no (or very low) friction.
This totally destroys the old fashioned interception calculations that you might use for a first-person-shooter or RPG, because as time passes, the target will be in a different location relative to you (whether it's you, he, or both that are moving).
The easiest way I found to calculate out a basic intercept course is as follows:
Get the distance between you and your target. Divide it by your average speed. That is the ETA.
Calculate the new positions of you and your target at ETA, but cap your vector at a certain constant number of seconds (3 is good for most action space games). IE, if the enemy is moving x+1m/s, in ten seconds he'll be at x+10m. However, if you are moving at x+1m/s, in ten seconds you'll be at x+3m, because your vector vanishes after three seconds. We negate our own vector because we plan on changing it radically.
Now, determine how long it would take to reach these virtual positions. IE, how quickly you can turn to the proper heading and close at speed. Do not bother taking into account your current vector. This is the estimated course (EC).
If the EC is roughly the same length as the ETA, go for it. If it's significantly different, increase or decrease your ETA significantly and try again until you find an EC that works or your ETA becomes stupid (error out).
This system works in most space games because most space games have a maximum speed cap. If your maximum speed is 100m/s and you're traveling at x+100m/s, accelerating along the z axis will make you arc away from that and to z+100m/s, no x velocity at all. This is true both of 2D and 3D space games: most of them impose this artificial speed cap so that people have a hope of being able to navigate intuitively.
The slower you turn and the longer it takes to reach your maximum speed, the more of a factor your current velocity will be, and the longer your personal velocity cut-off time should be. In addition, when calculating your estimated course (EC), you should take into account that your average speed will be lower than your maximum speed because you have to accelerate - and if your acceleration is slow, that will be more important. Obviously, the longer the thrust, the closer to your maximum speed your average speed will be.
...
Now, if you're like me, you're the sort of person who doesn't want a speed cap. If you're traveling at x+100m/s and you start thrusting along z, you'll reach x+100m/s & z+100m/s. No speed cap except maybe light speed.
This makes navigation difficult because you have to factor in your vector much more strongly, often moving to negate it. On the surface, you should just be able to do away with the velocity cutoff. However, it's not quite that simple.
First, you need to calculate not just where the enemy ship will be at ETA based on his current vector, but also based on his acceleration. If a ship is accelerating away, you need to take that into account or you'll be hopelessly off course.
Second, this system produces radically inappropriate intercept speeds. You'll blow by your enemy doing 0.3c, you won't even see the bastard as he blips by. So you need to put in some kind of rough vector matching mixed into the basic intercept package. It's possible to program, but the actual physics of the matter make it highly difficult: unless your ship has many times the thrust of the ship you're intercepting, it will take you a long, long time to close and match vectors. And if you've got any human-controlled ships, forget it!
Another factor in this kind of game is the light-speed cap, which is a common thing to want to include. The idea is that the speed cap is light speed, and the closer you get to light speed, the more thrust it takes to change your vector.
There are a lot of problems with this. In basics, this means that your current velocity will screw up your acceleration. Plotting an intercept course may involve having to slow down so you can accelerate along another vector.
Of course, the truth is that the issue is radically more complex than that, because you're always operating from your own frame of reference. You aren't going 0.9c: everything else is. The light speed limit is no good for gameplay unless you (A) are a physicist or (B) throw away any realism it may have had.
...
With the described system, basic navigation is possible. However, most games want more advanced navigation: they want to be able to orbit planets, do gravitational slingshots, present broadsides, interpose specific faces of their ships, ram (and avoid ramming), etc, etc, etc.
Each of these things requires some pretty significant tweaking... and, of course, the basic calculations presented here are not exactly optimized. They give pretty rough (but functional) intercepts.
There's the basics. Hope it helps.
Tuesday, May 15, 2007
Mapping Space to Other Things
I have become more and more interested in mapping space to something besides space.
As I've said before, the basic idea of space (how you perceive it and move through it) is treated too generically for my taste. In essence, every game is fundamentally about navigating space. Sometimes the space is very fine and open, like a fighting game or a first person shooter. Sometimes the space is clunky and restrictive, like skill trees and dialog. But space is always treated as "generic". The only difference between here and there is simply that here is closer to the gold that we've placed on an arbitrary point in space.
Why not make a space intrinsically linked to some part of the gameplay?
For example, imagine a game in which you can fly. As you fly higher, it gets colder and harder to breath. There is a strong relationship between space and some part of the gameplay. This is rendered meaningless if you can't fly, though: the idea is that you have to be able to change your position and, in doing so, change the game dynamics.
That's the most basic kind of linking, and many games already have a vague Z-axis play modifier: falling. But that's basically saying "The difference between being here and being there is that being there sends you here."
How about something much more complex, though? How about a game where one of the play spaces is radiation? Walk right, you can sense ultraviolet. Walk left, you can sense infrared. Keep walking, and your senses keep panning away from the human norm.
If this was the main play field in a platformer, it could reveal platforms that are only visible to certain kinds of radiation - then you might have to go jump on that platform, which is invisible to you when you reach it. Or maybe it lets you see through things which are opaque to other wavelengths! Alternately, it could be a secondary play space, like the "sphere grid" the new Final Fantasy games use.
You could link space to anything. You could link it on one, two, or even three axes. You could link it to length of weapon, age, speed of attack, time, space in another play space, the health of a follower, gravity, research speed, the height of ladders, charisma: anything.
Suddenly you've got this weird game where where you stand affects how you play. If it's the primary play space, you've suddenly got a platformer where jumping while on the right side of the level might have a very different result than jumping while on the left side. Or where you can fly, but only where the updrafts are hot enough. Or something.
If it's not the primary space but is instead something like a power-up grid, the result of marching around on it is not scripted - the painful limitations inherent in scripting no longer exist. Walk far enough to the "fire" side of the grid and you take damage if the weather is less than 90 degrees outside. But nothing is stopping you: specialize as foolishly as you want.
Of course, you don't have to map it to space. You could map it to time, but that's pretty common. You could map it to velocity: While moving left, there is no gravity. While moving right, there is a lot of gravity. You could do all three, and make the player's head explode.
I think that would be fun.
As I've said before, the basic idea of space (how you perceive it and move through it) is treated too generically for my taste. In essence, every game is fundamentally about navigating space. Sometimes the space is very fine and open, like a fighting game or a first person shooter. Sometimes the space is clunky and restrictive, like skill trees and dialog. But space is always treated as "generic". The only difference between here and there is simply that here is closer to the gold that we've placed on an arbitrary point in space.
Why not make a space intrinsically linked to some part of the gameplay?
For example, imagine a game in which you can fly. As you fly higher, it gets colder and harder to breath. There is a strong relationship between space and some part of the gameplay. This is rendered meaningless if you can't fly, though: the idea is that you have to be able to change your position and, in doing so, change the game dynamics.
That's the most basic kind of linking, and many games already have a vague Z-axis play modifier: falling. But that's basically saying "The difference between being here and being there is that being there sends you here."
How about something much more complex, though? How about a game where one of the play spaces is radiation? Walk right, you can sense ultraviolet. Walk left, you can sense infrared. Keep walking, and your senses keep panning away from the human norm.
If this was the main play field in a platformer, it could reveal platforms that are only visible to certain kinds of radiation - then you might have to go jump on that platform, which is invisible to you when you reach it. Or maybe it lets you see through things which are opaque to other wavelengths! Alternately, it could be a secondary play space, like the "sphere grid" the new Final Fantasy games use.
You could link space to anything. You could link it on one, two, or even three axes. You could link it to length of weapon, age, speed of attack, time, space in another play space, the health of a follower, gravity, research speed, the height of ladders, charisma: anything.
Suddenly you've got this weird game where where you stand affects how you play. If it's the primary play space, you've suddenly got a platformer where jumping while on the right side of the level might have a very different result than jumping while on the left side. Or where you can fly, but only where the updrafts are hot enough. Or something.
If it's not the primary space but is instead something like a power-up grid, the result of marching around on it is not scripted - the painful limitations inherent in scripting no longer exist. Walk far enough to the "fire" side of the grid and you take damage if the weather is less than 90 degrees outside. But nothing is stopping you: specialize as foolishly as you want.
Of course, you don't have to map it to space. You could map it to time, but that's pretty common. You could map it to velocity: While moving left, there is no gravity. While moving right, there is a lot of gravity. You could do all three, and make the player's head explode.
I think that would be fun.
Subscribe to:
Posts (Atom)