Monday, May 30, 2011
In Profundis Progress (5/28)
Work on switching over to pyglet continues. Also redoing the graphics for performance improvements. Not particularly interesting I know. Right now most of the work has been infrastructure, gruntwork, and preparation for... the future....
Saturday, May 28, 2011
In Profundis Progress (5/28)
Work continues, although it hasn't been straight development work. I've been reading up on the Pyglet graphics framework and it looks like I should be adapt the code to it without a huge amount of trouble. This means better performance, meaning it'll work on more people's computers without stuttering, which has been a concern. My development machine is a very cheap laptop, but that's on purpose; if it works on this, I reason, it should work on most machines.
I've also gotten the hosting and domain registration for the game's website, which is where the alphas and betas will go up. It's just a placeholder page for now, but when it's ready you can point your browsers to http://inprofundis.com/.
I've also gotten the hosting and domain registration for the game's website, which is where the alphas and betas will go up. It's just a placeholder page for now, but when it's ready you can point your browsers to http://inprofundis.com/.
Friday, May 27, 2011
Website coming soon
I registered the domain name and hosting today. Worried about the cost, but I don't think free Google hosting will suffice for password-protected file distribution. Or will it? More to come.
Sunday, May 22, 2011
In Profundis Progress (5/22)
I'm back baby!
So, here is the thing that's been consuming my development time lately. Cellular automation for use in real-time games frequently has to be heavily optimized. When you're cycling though every cell of a hundreds by hundreds array every frame, then even the overhead from those cells in which you just check contents and decide nothing needs to happen is significant.
My current strategy for negating this is to not use a big loop that iterates through every cell. Instead, I keep a list of every cell that _might_ change this frame. I calculate those and, any that do change, I add adjacent cells to the list for the next frame.
It's much MUCH faster, but it's worth noting that this is entirely because, for most of the game world, large portions are static between each frame. Stone is largely inert, so we don't need to worry about it except how other things react to it -- they are the initiating factors in that, so their routines handle the work. Empty spaces (that don't contain weird gases) are similar. These two cell types are 90% of the world. By removing them from consideration, it's worth a huge performance gain.
A huge gain, but it turns out, not huge enough. I remind you that, before, we kept performance under control by only updating the screen and a short distance outside of it. Under this system we update the whole world, and factoring in all of the cells that CAN change, it's a bit too much to reliably handle.
There is a way around it. We sort the update list, using one of the handy-dandy, heavily-optimized Python sort functions, with the sort key being a simple Cartesian distance from the player or cursor. Then we can just pop off the first few hundred or so every frame, and leave the rest for the next frame. If the player never goes anywhere near them they won't get handled, but as soon as he does they'll enter consideration.
It's a cheat, but real-time game development is basically a convoluted series of cheats, a set of makeshift concessions to processor speed and memory limits. Now that we have multicore machines and multi-gigabyte memory spaces this fundamental fact is sometimes obscured, but it doesn't change it.
So, here is the thing that's been consuming my development time lately. Cellular automation for use in real-time games frequently has to be heavily optimized. When you're cycling though every cell of a hundreds by hundreds array every frame, then even the overhead from those cells in which you just check contents and decide nothing needs to happen is significant.
My current strategy for negating this is to not use a big loop that iterates through every cell. Instead, I keep a list of every cell that _might_ change this frame. I calculate those and, any that do change, I add adjacent cells to the list for the next frame.
It's much MUCH faster, but it's worth noting that this is entirely because, for most of the game world, large portions are static between each frame. Stone is largely inert, so we don't need to worry about it except how other things react to it -- they are the initiating factors in that, so their routines handle the work. Empty spaces (that don't contain weird gases) are similar. These two cell types are 90% of the world. By removing them from consideration, it's worth a huge performance gain.
A huge gain, but it turns out, not huge enough. I remind you that, before, we kept performance under control by only updating the screen and a short distance outside of it. Under this system we update the whole world, and factoring in all of the cells that CAN change, it's a bit too much to reliably handle.
There is a way around it. We sort the update list, using one of the handy-dandy, heavily-optimized Python sort functions, with the sort key being a simple Cartesian distance from the player or cursor. Then we can just pop off the first few hundred or so every frame, and leave the rest for the next frame. If the player never goes anywhere near them they won't get handled, but as soon as he does they'll enter consideration.
It's a cheat, but real-time game development is basically a convoluted series of cheats, a set of makeshift concessions to processor speed and memory limits. Now that we have multicore machines and multi-gigabyte memory spaces this fundamental fact is sometimes obscured, but it doesn't change it.
Thursday, May 19, 2011
In Profundis (lack of) Progress (5/19)
Been working on rewards so far and trying to work with Kickstarter's survey system to get necessary information for fulfilling them. Will let you know when work on the game itself occurs.
Monday, May 16, 2011
The project make the goal
If I were the kind of person to say things like "woo-hoo," I'd be saying it now.
Maybe I should give it a try. Here goes:
"Woo-hoooo!"
Hm, unfulfilling. Especially since the hard part starts now.
But thanks everyone for believing in my idea, and the project.
Maybe I should give it a try. Here goes:
"Woo-hoooo!"
Hm, unfulfilling. Especially since the hard part starts now.
But thanks everyone for believing in my idea, and the project.
Friday, May 13, 2011
In Profundis progress (5/13)
The biggest change, which is so big that I've been taking a break from development for a few days to consider what it means, is to the way the sim looks at which cells to calculate.
Originally, it just iterated through a loop through the whole world, from bottom to top, examining each cell and deciding what should happen there. That took a long time.
More recently, it'd just been updating a frame around the currently visible portion of the world. That's much faster, but causes certain bits of weird behavior in some circumstances. For example, if enough water pouring off screen in a place eventually it'll fill in the cells in the no-update region off the bottom of the screen, and then it'll pool on top of that. If the screen then scrolled down somewhat, it'd suddenly all start falling as the "plug" dissipates. Similarly, water flowing off-screen will eventually act as if it's reached a wall and begin pooling, but if you move forward it'll start flowing out again.
The new system is a rather more radical change. Now the game has a list of cells to update, compiled originally by scanning through the world. Cells that are mostly inert, like walls and empty spaces, don't make it into the list, and thus no cycles are spent on them. When an operation is performed on a cell, the game adds nearly adjacent cells to the (initially empty) list of cells for the next frame. Those calls are "activated." Since the most distance away a cell can affect the world on a single turn is one space, we never have to add too many cells to the list.
If a space containing some possibly-active element, such as a liquid or boulder, does nothing this turn, it is left off the list for the next frame. The simulation doesn't even consider it until something happens close enough to it that it might be upset. Minecraft does something similar with its sand; sometimes you'll find a place where the world generates sand blocks that are unsupported, or even hanging in air
When the player does something that affects the game world under this system, the nearby cells have to be added to the update list in case there's any simulating to do. That's what causes Minecraft's sand to suddenly realize that gravity exists and begin falling.
Originally, it just iterated through a loop through the whole world, from bottom to top, examining each cell and deciding what should happen there. That took a long time.
More recently, it'd just been updating a frame around the currently visible portion of the world. That's much faster, but causes certain bits of weird behavior in some circumstances. For example, if enough water pouring off screen in a place eventually it'll fill in the cells in the no-update region off the bottom of the screen, and then it'll pool on top of that. If the screen then scrolled down somewhat, it'd suddenly all start falling as the "plug" dissipates. Similarly, water flowing off-screen will eventually act as if it's reached a wall and begin pooling, but if you move forward it'll start flowing out again.
The new system is a rather more radical change. Now the game has a list of cells to update, compiled originally by scanning through the world. Cells that are mostly inert, like walls and empty spaces, don't make it into the list, and thus no cycles are spent on them. When an operation is performed on a cell, the game adds nearly adjacent cells to the (initially empty) list of cells for the next frame. Those calls are "activated." Since the most distance away a cell can affect the world on a single turn is one space, we never have to add too many cells to the list.
If a space containing some possibly-active element, such as a liquid or boulder, does nothing this turn, it is left off the list for the next frame. The simulation doesn't even consider it until something happens close enough to it that it might be upset. Minecraft does something similar with its sand; sometimes you'll find a place where the world generates sand blocks that are unsupported, or even hanging in air
When the player does something that affects the game world under this system, the nearby cells have to be added to the update list in case there's any simulating to do. That's what causes Minecraft's sand to suddenly realize that gravity exists and begin falling.
Monday, May 9, 2011
In Profundis progress (5/8, part 2)
Did some more work today on speeding up the simulation. Before, the cells that were calculated were all of them within the borders of the screen plus a small area outside of it. Current work is towards switching to a system where changed cells in a given frame mark cells adjacent to them for calculation in the next frame. The idea is that changes don't happen randomly; they're always spurred by other changes. So, there's no need to, say, check a boulder every frame to see if it should roll. If it's stable on a given frame, it won't be checked again unless the space around it is disturbed.
Since most of the game world is fairly static each frame, the result is potentially much more efficient world calculations, meaning being able to simulate more of it each frame. The biggest drawback is that gases are unsuitable for this system, since they'd be constantly spreading bit by bit regardless of whether the neighbors change. Even so, it's a promising direction for development.
Since most of the game world is fairly static each frame, the result is potentially much more efficient world calculations, meaning being able to simulate more of it each frame. The biggest drawback is that gases are unsuitable for this system, since they'd be constantly spreading bit by bit regardless of whether the neighbors change. Even so, it's a promising direction for development.
Sunday, May 8, 2011
In Profundis progress (5/8)
Been going very slow due to frustrations with the Kickstarter project and trying to work on another article about it, to get up whatever little publicity I can in the few days until the project inevitably fails. I don't think the game will be abandoned when the project fails to make its goal, but it is going to take me longer, much longer probably, to work on. As such, it'll probably be longer between posts here unfortunately.
Thursday, May 5, 2011
Gamasutra article up
The Gamasutra article offering a rough view of the cellular automation liquid algorithm in In Profundis is up.
Tuesday, May 3, 2011
In Profundis progress (5/3)
Pushing boulders now works.
Additionally, there is now a faint ghost cursor that accompanies your character as he wanders around the world. Not like the one you've seen in videos of edit mode, an understated one. It acts as a kind of context-sensitive prompt. For the demo, the object it covers represents the action you will perform when pressing the action key. Empty space next to a wall: insert piton. Empty space away from wall: fire airgun. Overlapping wall: pickaxe. In fluid or sand: shovel out some material.
The cursor can be adjusted a bit; if you hold the up key, it moves into the air above your head. If you crawl, it goes down below your feet. People who have played the classic Tecmo puzzle game Solomon's Key will get the idea, regarding which blocks you can affect at a given moment.
Additionally, there is now a faint ghost cursor that accompanies your character as he wanders around the world. Not like the one you've seen in videos of edit mode, an understated one. It acts as a kind of context-sensitive prompt. For the demo, the object it covers represents the action you will perform when pressing the action key. Empty space next to a wall: insert piton. Empty space away from wall: fire airgun. Overlapping wall: pickaxe. In fluid or sand: shovel out some material.
The cursor can be adjusted a bit; if you hold the up key, it moves into the air above your head. If you crawl, it goes down below your feet. People who have played the classic Tecmo puzzle game Solomon's Key will get the idea, regarding which blocks you can affect at a given moment.
Sunday, May 1, 2011
In Profundis design ideas (5/1)
Work on the game has been slow this weekend (which is to be expected, since those are the days I spend 1. delivering pizzas, and 2. cursing fate), but I figured it'd be useful and perhaps interesting to discuss some of the ideas I have for the game. These are all things I have been playing around with and may, or may not, someday implement. Perhaps (or perhaps not) someday soon.
#1: Basic equipment
Okay this one is pretty set-in-stone, and in fact is the current feature I'm working on, hopefully to be finished before the Kickstarter project concludes. In Profundis is intended to be a kind of game where just getting around is a large part of the challenge. Your guy's abilities by himself are pretty much limited to jumping, crawling, swimming, pushing, and climbing -- and climbing only works if there is a cracked stone surface to scale, which are not usually common enough to rely upon. Everything else you can do relates to your equipment in some way.
In the real game equipment will be handled from an inventory screen. (I have persistent recurring visions of a roguelike-style inventory screen, but that would probably scare off a lot of players.) Each item would be rated by weight, and you could take a certain amount with you on an expedition. The various bits of kit you take with determine your abilities. In the meantime, for testing, I'll just enable unrestricted use off all the items. I intend to make this version of the game available as a playable alpha.
If you find that you've brought inappropriate stuff, you can go back and reload, but at a cost. Living on an alien planet is not without its expenses. Every expedition takes at least one day of game time, and thus a certain amount of funds. The idea is that this cost slowly increases the more days you spend. So, even if you seem to have inappropriate stuff with you, you still want to make what use of it that you can before you return.
The basic pieces of equipment planned are:
Pitons: These are basically simple metal spikes. By themselves they are useless. They are intended to be used with the Hammer or Air Gun. Once inserted into a rock face, they can be used to climb. Pitons remain in place after being inserted, even across many days, so as you spend more time at the site you gradually transform hostile terrain into something traversable. This is a general theme for the game, how you reshape the cave to your purposes. But pounding spikes into the rock can also cause cracks to form, and this is another theme: remaking terrain to suit your purposes is dangerous. Sufficiently cracked walls can break, and expel whatever material was built up behind it into your face. Once hammered in, these pitons are generally unsuitable to later reuse, but that's okay as pitons are one of the cheapest pieces of equipment you have.
You can also tie a rope onto a piton, either in your inventory or one that's already in the rock. More on that below.
Hammer: One of two ways to insert pitons. The Hammer is not consumed and doesn't wear out, making it a rarity among In Profundis equipment. It can be used while climbing, so as long as you can get hold of the wall, you can continue pounding in new pitons on your way up or down the surface. The problem is that you can't get around overhangs with just the hammer; pitons hammered into ceilings are not suitable for climbing. For that you'll need to use something else.
Air Gun: Something else like this. Powered by consumable cans of compressed air, this device can be used to shoot pitons out towards other surfaces. I'm still figuring out how this will work; I'm thinking about a targeting system where you aim a cursor. Firing a single piton is not very useful, but firing a piton with a rope tied to it is quite handy. It'd be nice to use a full physics simulation for the ropes. Nice, but no, I don't think it's going to happen; we're already consuming a lot of processor time with the cellular engine, and I don't think we'd actually get that much use out of swinging ropes, even if they would be bloody flash to see. The way ropes are projected to work is, when the piton strikes the rock surface, the rope will unfurl downward ten units from where it hits. If you can grab onto that rope (it's freely climbable at this point) and get to the end of it, you can tie another rope to the end, and in this way descend until you run out of rope.
Tradeoffs to the air gun: the rope weighs the piton down so the range, while not short, isn't very long. It is long enough that, unless you have an unusually powerful light source with you, you'll have to rely on the automap to fire at the appropriate location. And if something breaks the rope the rest of it, below that point, falls.
Air Can: These power the air gun. There are other uses projected too, relating to the gas pressure system I've got planned, but in the meantime they'll just serve as gun "fuel."
Flashlight: Abstracted into an increased viewing range. In the full game this will have batteries that can die. Being without a source of light is a big problem; fortunately batteries have a good lifespan. In the full game, if you run out of battery you can fall back on torches, but they produce less light and additionally carry other dangers.
Pickaxe: A very useful tool. With this, you can smash tunnels into the rock, entering adjoining chambers or, in a pinch, digging a staircase back up to the surface. But the tradeoffs are great -- you don't always have enough knowledge of what might be on the other side of that wall, the noise is considerable and prone to causing rockslides or alerting monsters, and worst of all, pickaxes are heavy and wear out over time. Also, and importantly, it is impossible to get a good swing with a pickaxe while climbing.
That's all for now. More ideas later!
#1: Basic equipment
Okay this one is pretty set-in-stone, and in fact is the current feature I'm working on, hopefully to be finished before the Kickstarter project concludes. In Profundis is intended to be a kind of game where just getting around is a large part of the challenge. Your guy's abilities by himself are pretty much limited to jumping, crawling, swimming, pushing, and climbing -- and climbing only works if there is a cracked stone surface to scale, which are not usually common enough to rely upon. Everything else you can do relates to your equipment in some way.
In the real game equipment will be handled from an inventory screen. (I have persistent recurring visions of a roguelike-style inventory screen, but that would probably scare off a lot of players.) Each item would be rated by weight, and you could take a certain amount with you on an expedition. The various bits of kit you take with determine your abilities. In the meantime, for testing, I'll just enable unrestricted use off all the items. I intend to make this version of the game available as a playable alpha.
If you find that you've brought inappropriate stuff, you can go back and reload, but at a cost. Living on an alien planet is not without its expenses. Every expedition takes at least one day of game time, and thus a certain amount of funds. The idea is that this cost slowly increases the more days you spend. So, even if you seem to have inappropriate stuff with you, you still want to make what use of it that you can before you return.
The basic pieces of equipment planned are:
Pitons: These are basically simple metal spikes. By themselves they are useless. They are intended to be used with the Hammer or Air Gun. Once inserted into a rock face, they can be used to climb. Pitons remain in place after being inserted, even across many days, so as you spend more time at the site you gradually transform hostile terrain into something traversable. This is a general theme for the game, how you reshape the cave to your purposes. But pounding spikes into the rock can also cause cracks to form, and this is another theme: remaking terrain to suit your purposes is dangerous. Sufficiently cracked walls can break, and expel whatever material was built up behind it into your face. Once hammered in, these pitons are generally unsuitable to later reuse, but that's okay as pitons are one of the cheapest pieces of equipment you have.
You can also tie a rope onto a piton, either in your inventory or one that's already in the rock. More on that below.
Hammer: One of two ways to insert pitons. The Hammer is not consumed and doesn't wear out, making it a rarity among In Profundis equipment. It can be used while climbing, so as long as you can get hold of the wall, you can continue pounding in new pitons on your way up or down the surface. The problem is that you can't get around overhangs with just the hammer; pitons hammered into ceilings are not suitable for climbing. For that you'll need to use something else.
Air Gun: Something else like this. Powered by consumable cans of compressed air, this device can be used to shoot pitons out towards other surfaces. I'm still figuring out how this will work; I'm thinking about a targeting system where you aim a cursor. Firing a single piton is not very useful, but firing a piton with a rope tied to it is quite handy. It'd be nice to use a full physics simulation for the ropes. Nice, but no, I don't think it's going to happen; we're already consuming a lot of processor time with the cellular engine, and I don't think we'd actually get that much use out of swinging ropes, even if they would be bloody flash to see. The way ropes are projected to work is, when the piton strikes the rock surface, the rope will unfurl downward ten units from where it hits. If you can grab onto that rope (it's freely climbable at this point) and get to the end of it, you can tie another rope to the end, and in this way descend until you run out of rope.
Tradeoffs to the air gun: the rope weighs the piton down so the range, while not short, isn't very long. It is long enough that, unless you have an unusually powerful light source with you, you'll have to rely on the automap to fire at the appropriate location. And if something breaks the rope the rest of it, below that point, falls.
Air Can: These power the air gun. There are other uses projected too, relating to the gas pressure system I've got planned, but in the meantime they'll just serve as gun "fuel."
Flashlight: Abstracted into an increased viewing range. In the full game this will have batteries that can die. Being without a source of light is a big problem; fortunately batteries have a good lifespan. In the full game, if you run out of battery you can fall back on torches, but they produce less light and additionally carry other dangers.
Pickaxe: A very useful tool. With this, you can smash tunnels into the rock, entering adjoining chambers or, in a pinch, digging a staircase back up to the surface. But the tradeoffs are great -- you don't always have enough knowledge of what might be on the other side of that wall, the noise is considerable and prone to causing rockslides or alerting monsters, and worst of all, pickaxes are heavy and wear out over time. Also, and importantly, it is impossible to get a good swing with a pickaxe while climbing.
That's all for now. More ideas later!
Subscribe to:
Posts (Atom)