One of the things that has blocked the project for so long has been a shift of the engine from Pygame, which is easy to use but relatively slow because it does its rendering in software, and furthermore doesn't play well with any Python speedup module other than Psyco, to something else that's hardware accelerated and will work with PyPy. That something else being: pyglet.
But despite the fact that it's been around for a few years now there's not a huge amount of stuff on the web about pyglet. Most of what I've found has been its own documentation and a presentation called Stretching pyglet's Wings. A few months ago I did a promising graphics test that taught me a bit about how pyglet puts together its images. Now I've gotten something like that going in a tile engine, and it looks promising.
The reason for making the switch, and also for trying out weird cellular automatic schemes, is that, under the old system, I wasn't getting the performance that I was looking for. When you're simulating only a portion of the world instead of the whole thing each frame, some things start to act funny at the edge of the simulation frame. For something like Life that would be deadly, but here in practice it doesn't seem to cause huge amounts of problems so long as we spend some time at the start of simulation calculating over the whole map, in order to let fluids settle.
But it does have one problem that has always bothered me greatly, and that is, we can't have running "rivers" in the simulation between two distant points, because if one of the points is outside of the simulation frame the whole flow stops. This means that most bodies of fluid the player encounters are static, which greatly limits the utility of having a cellular engine game in the first place.
Well performance-wise pyglet looks like it's got what it takes. It can display a whole screenful of tiles nearly instantaneously. Pygame takes a lot more time to do stuff like that unless you use tricks like only drawing parts of the screen that have changed, which is somewhat problematic for a scrolling game, and even more problematic for one where arbitrary tiles may change each frame.
Glad to hear some good news about this! :)
ReplyDeleteIs this game still in development? I kind of forgot about it until I watched this movie about indie game devs called "Indie Game: the movie" and it made me think of you. :)
ReplyDeleteYes, but I'm kind of in a muddle.
ReplyDeleteI've been thinking hard about this, and have become convinced that I've made some poor design decisions. Like the number of fluid slots in each cell; having 8 levels of liquid ultimately just slows down the sim. And the maze-based world builder produces environments that are a lot less interesting than the mostly random stuff I used in early demos. And I've also played some very unusual but interesting games, like the Atari 2600 Mountain King.
This, combined with the job and other things, has meant most of my work on In Profundis lately has been design work. I promise though: I haven't given up, and I won't.
(I mentioned Mountain King because it's really inspiring. I especially like the diamonds in that game, how the more times you attempt to finish the game, the rarer they get, because the ones you collected before are still gone.)
ReplyDeleteOK thanks. You might want to post an update over on Kickstarter, seems a lot of people have given up on you. :(
ReplyDeleteThe thing is, there's not a lot *substantive* to show, and I feel extremely self-conscious about that. And an extremely negative comment showed up here a while back and kind of sent me into panic mode. I feel like I'm stuck between a rock and a hard place here, and I don't want to antagonize anyone with yet another "nothing to show for my time" message.
ReplyDelete