Ah, progress! Basic support for larger tiles is in now. In fact, I might make the tiles much larger but just display scaled-down versions during the game, which would allow for smooth scaling of the playfield between scales. I used a trick like that fscaling smooth-scaling map screen in Mayflight (a particular favorite effect from that game). I'm not sure I can do this with Pygame however -- one of the reasons I tried moving to pyglet is it can blit images while scaling them in transit. Pygame only scales through the creation of a new surface, which must then be blitted to the destination, which might be too much overhead for me.
One benefit of using larger tiles is the game doesn't have to blit so many images, which is worth another modest framerate increase. The disadvantage, of course, is that less of the world fits on the screen.
In design news, I've started planning out in detail how the random substance properties will work. There are planned to be three kinds of substances: liquids, gases and solids. Liquids are flowing materials like, but not limited to, water. Sand is also a "liquid," for instance. Gases hang in the air and slowly spread out. Both may or may not end up having pressure support, if I can figure out a relatively inexpensive implementation (which is one of the reasons I obsessed over finding ways to speed the game up for a while). The third type, solids, are basically stone walls, which are more reactive in their properties.
So what do I mean by a random substance? The idea is that, at the start of the game, in addition to substances with fairly obvious attributes, there would also be some with unknown properties that must be deduced through observation and experimentation. From the promo video, this is like throwing a torch into a pool of unknown liquid to see if it's flammable. My idea is that the first world the player explores in a campaign would have little or no random substances, but each one after that would have a little more randomness. Another idea, which I mentioned in an interview, is that the planets explored by the player would be divided into solar systems, and each system's would have its own "elements." So, different planets would have different maps and layouts of substances, but the behaviors of those substances would be the same throughout.
If I do this right it could be one of the most interesting aspects of the gameplay. I find that many of my favorite roguelikes are the ones with randomized equipment, which turns figuring out what your stuff does into a logic game. However, it is also true with many of those roguelikes that the identification game isn't as interesting as it could be, or is only a real requirement in the early phases of the game, as once the player learns what everything is there is nothing left to learn.
Anyway, all this is still some time off in the future. I'm going to work on the graphics a bit and fix up the platforming engine before then, I think.
Sounds great! I like the idea of figuring out substance properties through experimentation.
ReplyDeleteOn another note, if you get pressure into the game, make sure you somehow disable the self-adjusting surface levels for sand (if you treat it as a liquid). :)
On ANOTHER note, I just had an idea that I'll share and you can feel free to ignore. :)
As a fourth way to utilize the cellular automation, you could have micro organisms that work like invisible gases (but lack pressure), only they spread inside other media. Bacteria that lives in water, air, oil, etc. Getting infected by one could lead to various status effects, some good and some bad, and there could be different ways to cure them.
Maybe it's a little out there, and they could be too similar to gases to justify implementing. I don'w know. The idea just hit as I wrote this. If gases can have lasting status effects on living things, I guess it would be almost the same thing (only they're always in open space).
If drawing the tiles one at a time is slow, couldn't you make some surfaces (maybe full-size) just for visible regions of tiles and update them as things change? I bet a straight blit is fast if you're not doing any scaling or depth conversion or alpha blending, and I would think that you need that anyway if you want your scaled tiles to look good.
ReplyDeleteYou still can't scale without creating a new surface, which would then have to be blit into position. Updating that intermediate frame would require more new surface creation as it changes.
ReplyDeleteDocumentation for transform.scale claims you can optionally supply an existing destination surface instead of creating a new one: http://www.pygame.org/docs/ref/transform.html#pygame.transform.scale
ReplyDelete(Not that I'd expect surface creation to involve anything expensive.)
transform seems to want the destination surface to be the same size as the scale supplied. It might be possible to use it with subsurfaces. I'm standoffish about creating so many surfaces because internally the game already makes a lot of subsurfaces to save time, and further we'd have to create them in real-time, with uncertain time costs. (I could do an experiment to see what the time costs are, but at the moment I'm going to let performance issues go and work on other things, like improving the platforming engine.)
ReplyDelete