It's been a while now and I still don't have a lot visible to show
for it. Honestly, the switch to pyglet has been going more slowly than I
expected. The thing is, to get the most performance out of it I have
to redesign the main loop to be entirely event-driven, and that requires
learning pyglet's callback system, the examples of which most
frequently use decorator, which are proving unfriendly to circular
imports....
Bleaah. It is coming along, it's annoying
frustrating work but it's happening. And I'm doing it for more reasons
than just performance -- being fully event driven will make the design
of the thing a lot more professional, and make it easier to adapt to
mobile platforms, which mostly use entirely event-driven paradigms
anyway. And pyglet is capable of some special effects, which might help
me out in ways related to the oft-commented blockiness of the water effects.
So
it's coming along. I figured you all deserved a status report
regarding the game. This is getting reposted on Kickstarter so it'll go
out to everyone. You should also all know that the game has a
placeholder website not at http://www.inprofundis.com/ -- it's just a
barebones Wordpress thing at the moment. I'm going to continue to use
the Coin Door Interlock blog for now though for development reports,
though.
More news as it happens....
Saturday, June 11, 2011
Wednesday, June 1, 2011
In profundis Progress (6/1)
More boring stuff. The pyglet changeover continues.
Someone in comments in the last one asked if I was sure that changing to pyglet would be a net performance improvement. I don't know for sure; he is right, the reputation I have of it is largely anecdotal.
However it does look like, as far as rendering goes, pyglet is rather more flexible. Or at least the way I was doing it before was less flexible. Either way, I'm taking the opportunity to change the rendering system a bit. Which is, again, not much to show. (Well this is a development diary, heh. A lot of development, especially in the early phases, looks like this.)
Someone in comments in the last one asked if I was sure that changing to pyglet would be a net performance improvement. I don't know for sure; he is right, the reputation I have of it is largely anecdotal.
However it does look like, as far as rendering goes, pyglet is rather more flexible. Or at least the way I was doing it before was less flexible. Either way, I'm taking the opportunity to change the rendering system a bit. Which is, again, not much to show. (Well this is a development diary, heh. A lot of development, especially in the early phases, looks like this.)
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.
Subscribe to:
Posts (Atom)