I was recently looking at some actual extreme environment bases - artic, subaquatic, orbital - and marveling at just how tiny they are. Video games have unrealistically massive levels, it's true, but reality has unrealistically tiny levels a lot of the time.
There are a wide variety of video games, but most video games have the gameplay as the constraint and the levels as the opportunity. IE, you can run around at X speed, jump Y height, have Z weapons, now here is a level to conquer with those constraints. Whether we're talking about PacMan or Battlefield or candy crush, that's how it is.
If you decide your whole game will take place in one tiny location like, say, six people living in a schoolbus for a month, that won't work. The level is too small and has to last too long: it cannot be the opportunity part of the game.
Instead, it becomes the constraints.
If we consider the level as constraints instead of opportunity, we can start to craft a game where a tiny level can work. But we can't have a game with no opportunity: we also need to create an opportunity system.
One option we have is to make the gameplay elements into opportunities rather than constraints, and allow the players to craft their own gameplay. For example, if your base is a deep-space probe scanning the skies and doing science, you can allow the player to create more interesting science experiments and analyze a stream of unique data using customized heuristics. The level would be your constraints: only so many computers, so much memory, so many telescopes. There would be a struggle to do more with the same resources.
Another option is to have two levels: a closed level and an open level. For example, you are on a tiny scout spacecraft landing on a new planet. You only have a small payload for samples and limited time for analysis, so you have to decide what you can analyze and/or bring back. The inside of the space ship is a level, but so is the exterior where you go hunting for samples.
My favorite is the "ratcheted constraint" system, where you build/improve your tiny space between missions. In this form, the tiny space is an opportunity between levels, as you expand it and modify it. Then you have to live with it as a constraint on the missions.
That's the way Gravity Grain will work.
Of course, in addition to simple statistical limits, confined tiny spaces also offer constraints in terms of useability. If there are multiple crew members in the same tiny space, they are going to run into issues with who is using what pieces, when. So if you're building your own tiny base, as it goes from miniscule to tiny and the number of crew increase, the challenges change. Good layout and scheduling becomes steadily more important...
Well, either way, I think it will be fun.
Showing posts with label gravity grain. Show all posts
Showing posts with label gravity grain. Show all posts
Monday, June 02, 2014
Friday, May 30, 2014
Gravity Grain: Content content content content content content content content
My last project - For SCIENCE! - developed in a pretty straightforward manner. I put it on pause mostly because it turned out to not really be any fun. I learned a lot from it, and starting up my next project really punched me in the face with those lessons. So let's talk about it again!
The reason For SCIENCE! was so easy to develop was because my mood was strong throughout. I never felt uninspired by my game. And a big part of that was the content. By buying content from the asset store, I filled my game with detailed, fully-textured models right from the start. Even in its early stages, every test run felt like I was building something. A lot of devs can get away with placeholder art, but I evidently can't.
When I moved on to Gravity Grain, I knew I'd need a lot of content, so the first thing I did was create a content creation system. But this really distracted me from creating the game. As I should have realized, content creation tools are really something separate from the game. In fact, the concepts are so distinct that I literally packaged my voxel-object tools up as their own library, so they could be used and reused and imported and exported into any game, anywhere.
STOP! Why?
... Why not just import actual models, at that point? Why not just let people make great stuff in Blender or Maya and import it through the standard Unity asset pipeline? Why create a complicated, difficult-to-maintain voxel system?
Sure, the voxel system had some theoretical advantages. Shared materials between all in-game objects. Easy and meaningful deformation and damage. But... it's a TON of work, and the result has a very specific kind of awkwardness even with the cool smoothing mechanics. It would be more rewarding in the long run to give the players and developer(s) the kind of freedom you get with professional modeling tools.
So, I'm throwing it away.
I'm going back to the proven method I used in For SCIENCE!: getting third party content and feeling like I'm making progress rather than struggling to create both a tool and a game simultaneously.
The reason For SCIENCE! was so easy to develop was because my mood was strong throughout. I never felt uninspired by my game. And a big part of that was the content. By buying content from the asset store, I filled my game with detailed, fully-textured models right from the start. Even in its early stages, every test run felt like I was building something. A lot of devs can get away with placeholder art, but I evidently can't.
When I moved on to Gravity Grain, I knew I'd need a lot of content, so the first thing I did was create a content creation system. But this really distracted me from creating the game. As I should have realized, content creation tools are really something separate from the game. In fact, the concepts are so distinct that I literally packaged my voxel-object tools up as their own library, so they could be used and reused and imported and exported into any game, anywhere.
STOP! Why?
... Why not just import actual models, at that point? Why not just let people make great stuff in Blender or Maya and import it through the standard Unity asset pipeline? Why create a complicated, difficult-to-maintain voxel system?
Sure, the voxel system had some theoretical advantages. Shared materials between all in-game objects. Easy and meaningful deformation and damage. But... it's a TON of work, and the result has a very specific kind of awkwardness even with the cool smoothing mechanics. It would be more rewarding in the long run to give the players and developer(s) the kind of freedom you get with professional modeling tools.
So, I'm throwing it away.
I'm going back to the proven method I used in For SCIENCE!: getting third party content and feeling like I'm making progress rather than struggling to create both a tool and a game simultaneously.
Thursday, May 22, 2014
Gravity Grain: Mining is Hell
Mining is the most boring game mechanic that was ever thought up. You trade time for a dribble of resources. In the most boring exchange known.
It's boring in Eve. It's boring in Space Engineers. It's boring in FarSky. It's just boring.
Gravity Grain features mining!
HA HA HA HA... ha...
No, it's not nearly as bad in Gravity Grain.
My philosophy is that player time should only be spent on personalization, and then only as much as the player wants. So you can spend any amount of time designing a ship. Then you can put it together largely automatically while you do other things... or you can participate in putting it together in order to customize some of the details. While putting the ship together does take time, Gravity Grain has a time-acceleration system so you don't have to actually wait through it if you don't want to.
Similarly, a player goes on expeditions and missions with the ships they designed. I want them to have to spend time with the things they personalized, and only on those things. So they spend time managing the crew and the crew's resources. They spend time trying to repair damage from a meteorite hit, or running from a pirate. These things reflect on their ship design, their crew choices, the cargo they carry...
But the actual act of mining does not reflect their choices much.
So I don't want them to spend time on it.
I want them to spend time on the mining expedition, the mission, but not the actual act of mining.
Fortunately, there's an easy way out: time acceleration!
When the player goes to mine an asteroid, she has to park her ship on the asteroid using landing clamps. This is done in real time, because it reflects upon the ship design. It's affected by her customization. Then she starts up the gravity auger. This, too, is done manually. But once the gravity auger has punctured the asteroid, there's nothing more for her to do and she is encouraged to accelerate time and get it over with nice and quick.
There isn't any need to choose exactly which square foot to mine: the asteroid is considered a unit. And when you've sucked it dry, it breaks into much smaller pieces that float away. In theory you could mine them, too, but unless your first asteroid was quite huge, they'll probably be too small to deal with.
But, as you can see, it's an automated process. You just let it run until it's obviously finished. Then you can make the choice and customize your mission: do you pursue some of the fragments, too, or just head back with your current haul?
In this way, mining is made painless.
...
Now, unlike something like Space Engineers, FarSky, Terraria, etc, valid mining spots aren't something you just stumble across. Asteroids are scattered tens of thousands of kilometers apart, or further. You'll need some kind of survey ship in the region to scan the area with a telescope to identify likely good mining targets. Then you can either take a scout ship out to sample them for actual good targets, or just cross your fingers and head out with a mining ship without the local survey. Scanning takes time... but is it something that takes the player's time?
Well, it runs automatically in the background, continually scanning. If you want to focus it on specific regions, you can. That doesn't take much time, though. So it doesn't really take the player's time. The player can time-accelerate, or build a ship, or customize the crew, or whatever.
Anyway, all this talk about a game that's still just a voxel tech demo is obviously just hot air. But I wanted to make it clear that wasting a player's time is pretty high on my shit list.
A player's time should be spent on the parts of the game that let them express themselves, rather than bled away on some arbitrary treadmill desperately forcing them to slow down. That's just a sign that your game can't keep players without resorting to cheap tricks.
It's boring in Eve. It's boring in Space Engineers. It's boring in FarSky. It's just boring.
Gravity Grain features mining!
HA HA HA HA... ha...
No, it's not nearly as bad in Gravity Grain.
My philosophy is that player time should only be spent on personalization, and then only as much as the player wants. So you can spend any amount of time designing a ship. Then you can put it together largely automatically while you do other things... or you can participate in putting it together in order to customize some of the details. While putting the ship together does take time, Gravity Grain has a time-acceleration system so you don't have to actually wait through it if you don't want to.
Similarly, a player goes on expeditions and missions with the ships they designed. I want them to have to spend time with the things they personalized, and only on those things. So they spend time managing the crew and the crew's resources. They spend time trying to repair damage from a meteorite hit, or running from a pirate. These things reflect on their ship design, their crew choices, the cargo they carry...
But the actual act of mining does not reflect their choices much.
So I don't want them to spend time on it.
I want them to spend time on the mining expedition, the mission, but not the actual act of mining.
Fortunately, there's an easy way out: time acceleration!
When the player goes to mine an asteroid, she has to park her ship on the asteroid using landing clamps. This is done in real time, because it reflects upon the ship design. It's affected by her customization. Then she starts up the gravity auger. This, too, is done manually. But once the gravity auger has punctured the asteroid, there's nothing more for her to do and she is encouraged to accelerate time and get it over with nice and quick.
There isn't any need to choose exactly which square foot to mine: the asteroid is considered a unit. And when you've sucked it dry, it breaks into much smaller pieces that float away. In theory you could mine them, too, but unless your first asteroid was quite huge, they'll probably be too small to deal with.
But, as you can see, it's an automated process. You just let it run until it's obviously finished. Then you can make the choice and customize your mission: do you pursue some of the fragments, too, or just head back with your current haul?
In this way, mining is made painless.
...
Now, unlike something like Space Engineers, FarSky, Terraria, etc, valid mining spots aren't something you just stumble across. Asteroids are scattered tens of thousands of kilometers apart, or further. You'll need some kind of survey ship in the region to scan the area with a telescope to identify likely good mining targets. Then you can either take a scout ship out to sample them for actual good targets, or just cross your fingers and head out with a mining ship without the local survey. Scanning takes time... but is it something that takes the player's time?
Well, it runs automatically in the background, continually scanning. If you want to focus it on specific regions, you can. That doesn't take much time, though. So it doesn't really take the player's time. The player can time-accelerate, or build a ship, or customize the crew, or whatever.
Anyway, all this talk about a game that's still just a voxel tech demo is obviously just hot air. But I wanted to make it clear that wasting a player's time is pretty high on my shit list.
A player's time should be spent on the parts of the game that let them express themselves, rather than bled away on some arbitrary treadmill desperately forcing them to slow down. That's just a sign that your game can't keep players without resorting to cheap tricks.
Monday, May 19, 2014
Gravity Grain: Gangly Ships
One of the things I hate about modern space-ship building games is that they always produce the same kinds of visual profiles: boxy, utilitarian. 45-degree angles are considered the height of fashion. People can go out of their way to build interesting ships, but if they do, it is at the price of lower efficiency: more weight, more vulnerabilities, etc.
Now, I don't actually hate boxy ships. I just don't want every ship to be boxy.
Gravity Grain features a similar kind of construction system. If I don't go out of my way to make another kind of layout preferable, Gravity Grain will have boxy ships.
The major mechanic Gravity Grain will use is "exclusion zones" - (usually) spherical zones of danger around specific modules. For example, a fusion reactor might have a 200m heat exclusion zone, while an inertialess drive might have a 300m "gravity wobble" exclusion zone. In theory I could model propagation and stuff, but it's easier to both model and understand these things as spheres in space, regardless of how full or empty that space is.
As you enter the heat exclusion zone, your suit would have to work overtime to keep you cool - your time here is limited to your battery life. Similarly, there are many kinds of things that can't function while in an exclusion zone. A bed can't be slept in. An IR transceiver can't broadcast. A telescope can't focus.
More critically, if any two exclusion zones overlap, that area is destructive. If you have two reactors close to each other, or a reactor and an inertialess drive, the place where they overlap will quickly cause damage to anything in that area, whether it's a tile or a person. You can easily rip your own ship apart, and you probably will do exactly that at first.
Obviously this means you have to spread your ships out. That'll be the first thing people learn when building a ship, and I imagine we'll see a lot of long, cylindrical ships from newbies.
But there are a lot of clever tricks hiding under the surface, if you want better performance. Use nacelles: the space between them might have overlapping exclusion zones, but it's just empty space, so it's fine. Use ship modes: balance modules that produce exclusion zones so they either scale back as another one scales up, or turn on and off such that no two ever overlap. And, of course, the ever-popular mechanical extensions - swing things far from the ship to turn them on...
You can even creatively use exclusion zones as shields or weapons, if you're clever. Fire an "inertialess missile" at an enemy, and wherever its field overlaps with an enemy's own internal fields, the enemy takes damage. Doesn't even have to hit - actually, it'd be most effective if it was fired at great speed, then decelerated to a relative stop and just sat near an enemy. Gatling turrets are your best friend, I guess.
All of these reasons lend themselves to spread-out ships. In addition, mass is not as big a concern in this game - structural elements are very, very light, so wasting space on them doesn't really affect your performance characteristics. Of course, those kinds of lightweight elements are also very, very easy to rip apart...
And there are reasons to want a dense ship. First off, a dense ship is easier to land. Also, FTL speeds are based on bounding boxes, so dense ships are faster at warp, if only modestly. Lastly, dense ships tend to have their critical systems in the center, well-protected against meteorite impacts or weapons fire, and are very hard to physically sunder, unlike ships that are mostly long, frail connections. Obviously, a dense warship is also much easier to properly armor, as you need much less armor.
The warp speed thing alone should lead to some fun "fold-out" designs, where the ship is sleek in warp mode, then drops into realspace and extends various kinds of projections, wings, and so on, unfolding for better exclusion-zone performance.
Now, I don't actually hate boxy ships. I just don't want every ship to be boxy.
Gravity Grain features a similar kind of construction system. If I don't go out of my way to make another kind of layout preferable, Gravity Grain will have boxy ships.
The major mechanic Gravity Grain will use is "exclusion zones" - (usually) spherical zones of danger around specific modules. For example, a fusion reactor might have a 200m heat exclusion zone, while an inertialess drive might have a 300m "gravity wobble" exclusion zone. In theory I could model propagation and stuff, but it's easier to both model and understand these things as spheres in space, regardless of how full or empty that space is.
As you enter the heat exclusion zone, your suit would have to work overtime to keep you cool - your time here is limited to your battery life. Similarly, there are many kinds of things that can't function while in an exclusion zone. A bed can't be slept in. An IR transceiver can't broadcast. A telescope can't focus.
More critically, if any two exclusion zones overlap, that area is destructive. If you have two reactors close to each other, or a reactor and an inertialess drive, the place where they overlap will quickly cause damage to anything in that area, whether it's a tile or a person. You can easily rip your own ship apart, and you probably will do exactly that at first.
Obviously this means you have to spread your ships out. That'll be the first thing people learn when building a ship, and I imagine we'll see a lot of long, cylindrical ships from newbies.
But there are a lot of clever tricks hiding under the surface, if you want better performance. Use nacelles: the space between them might have overlapping exclusion zones, but it's just empty space, so it's fine. Use ship modes: balance modules that produce exclusion zones so they either scale back as another one scales up, or turn on and off such that no two ever overlap. And, of course, the ever-popular mechanical extensions - swing things far from the ship to turn them on...
You can even creatively use exclusion zones as shields or weapons, if you're clever. Fire an "inertialess missile" at an enemy, and wherever its field overlaps with an enemy's own internal fields, the enemy takes damage. Doesn't even have to hit - actually, it'd be most effective if it was fired at great speed, then decelerated to a relative stop and just sat near an enemy. Gatling turrets are your best friend, I guess.
All of these reasons lend themselves to spread-out ships. In addition, mass is not as big a concern in this game - structural elements are very, very light, so wasting space on them doesn't really affect your performance characteristics. Of course, those kinds of lightweight elements are also very, very easy to rip apart...
And there are reasons to want a dense ship. First off, a dense ship is easier to land. Also, FTL speeds are based on bounding boxes, so dense ships are faster at warp, if only modestly. Lastly, dense ships tend to have their critical systems in the center, well-protected against meteorite impacts or weapons fire, and are very hard to physically sunder, unlike ships that are mostly long, frail connections. Obviously, a dense warship is also much easier to properly armor, as you need much less armor.
The warp speed thing alone should lead to some fun "fold-out" designs, where the ship is sleek in warp mode, then drops into realspace and extends various kinds of projections, wings, and so on, unfolding for better exclusion-zone performance.
Subscribe to:
Posts (Atom)