In Profundis Progress 7/21

I've got gases partly reimplemented, they aren't displaying properly at the moment though.

I'm also putting in some of the infrastructure for randomized material properties. To explain:

One of the basic ideas of the game is that you encounter liquids, gases and even walls with unusual properties. They might be bouncy, or sticky, or flammable, or explosive, or poisonous, or have any of a number of other possible attributes.

Here is my plan for implementing this.

First, there is one of each type of substance (fluid, gas, stone) that is not random, but is otherwise boring. For fluids this is water, for gas this is "breathable," for stone this is "inert." My idea is that this substance is the most common of its type in each world, except maybe in the weirdest areas, just to keep down player confusion. (If everything you touch immediately explodes it doesn't make for a very interesting game.)

There are also a number of other predefined substances. Sand and oil are the two major types of these we've seen to date, both holdovers from World of Sand.

Each world also bears a difficulty value, which increases as the player explores more worlds. As difficulty goes up, at world generation time the game will randomly switch out more of the stock substances. So a game might not have sand, but another fluid. It might clump like sand, or it might slide around the ground, or it might slowly eat through stone, etc. Higher difficulty values also make it more likely that dangerous attributes are selected. Later on it would be possible for each substance to actually have two such attributes.

My problem here is: will this make for interesting gameplay? This is the biggest question of the design. My hypothesis is that it will if the player is given a limited number of ways to figure out what substances do, akin to the rogue like scroll of identify and Nethack's many ID tricks. I think this should be balanced so that players can't test out *everything*, just some things, forcing him to put up with whatever special attributes other things turn out to have.

Even if it's interesting, will it turn out to be enough to carry the game? The exploration aspects, the navigation and treasure seeking, and the resource management game of making efficient use of your equipment, all of these things together are what I consider to be In Profundis. If that turns out to be fun by itself then we can make an initial release and add in stuff like fighting/communicating with aliens later. If it doesn't, well then we might have to add in other actors earlier rather than later.

In Profundis: New Video

The work on the graphics engine has borne a bit of fruit.  Have a look:

http://www.youtube.com/watch?v=JBdauy4GaHU

Notes:
This is the first time I've shown off the engine using larger tiles.  Of course the graphics for walls are fairly plain right now.  What isn't shown is that there are now up to eight kinds of stone, which will have randomized properties.

The big thing that's visible here is that sand and water now has a smooth surface.  In particular this looks nice when a single level of water is moving around at the surface of a pool.  At the moment this is only cosmetic, and a bit glitchy at that.  Notice how, when water meets up with sand at about the same level, the sand angles down but the water stays level, and so it looks like it's being held up by air.

Also, the known "map" areas out of sight but still onscreen are now displayed using outlines.  There is some intelligence there that outlines the edges of the region but not the tiles in the middle.  It's not perfect yet; you can see some dots in regions where aborted walls are drawn, and the line isn't complete at the right-hand sides of slopes.  Not to mention, in some cases where sand is underwater, a black corner is drawn on the sand.

The update engine now uses a hybrid of the first system, which was a simple for loop, and the second system, which kept a list of all the tiles that might change this turn and iterated through them.  Now it iterates through the cells in a spiral pattern from around the "focus," which is either the player's location or the cursor.  It keeps a "dirty" flag on cells that might need updating next frame, allowing the game to avoid looking at every cell with complex interactions, like fluids, just to determine that they don't have anything to do this frame.  There are a couple of bugs with this too at the moment: sometimes the game forgets about liquids on "steps" and they are left to just pool there, and in edit mode placed fluids don't do anything until an adjacent space is modified.

I've also started planning out how gasses will be returned to the game.  They probably won't be updated as often as liquids, which befits a more diffuse way of spreading.

In Profundis Progress 7/15

1. Considering redesigning the character some more. It's not that it's not okay, but it's more like, we already have a CA-type game with graphics of sort of that style (Terraria). I'd like to distance this game as much as possible from that.

2. Abandoning the "coordinate list" more of keeping track of updates. The sort is just too much of a performance penalty. Someone MeMailed me a while back and suggested using a quad tree to keep track of which cells needed to be updated, but I frankly don't see how I would get substantial advantage from that. I will admit I am no expert on the structure though. It seems to me that any advantage gained from that wouldn't be greater than just iterating through them and using update flags to rapidly skip by any cells that don't need calculation.

In Profundis Progress 7/13

Some heartening progress over the past couple of days! I've somewhat successfully gotten the graphics rendering to display more smoother graphics for liquids without resorting to making hundreds and hundreds of tiles covering every possible liquid state. I'm not sure as to what the performance hit is for it yet, more news soon.

In Profundis Progress 7/11, pt 3

I think I've discovered the best way to smooth over the liquid tiles. It does require a fair amount of extra tiles to be generated, but it shouldn't be any slower than the current system.

I did a bit more looking into the state of Python. There are some very promising avenues on the horizon for it, that should be of interest to other Python game developers:

1. There is an optimizing compiler for Python coming up called, in the style of Monty Python references, Unladen Swallow. It's developed by Google so it has some strong support behind it, and the word is that eventually it will make it into the stock CPython distribution. That, coupled with the existence of Cython, make it clear that there is strong hope for dropping Psyco in the future.

2. There is some murmuring in the community about creating a version of Python for iOS. That's a target platform for me. I don't know what the performance will be like (word is that it's not bad), and anyway the "gold rush" phase of iOS development seems to be over, but it's still a bit of a vanity thing for me to make an iPad version. We shall see.

More In Profundis Progress 7/11

Additionally, I reimplemented an extra little quirk of vision: you can no longer see through sand or sediment more than a full layer (meaning, for example, you can no longer see the stone floor beneath sand dunes), and full tiles of other liquids halve vision range through them.

In Profundis Progress 7/11

Today, I'm working on a bit that will simplify liquid tiling. Instead of drawing each tile and referring to them all one at a time from the source, I'm just loading in a mask for the liquid, colorizing and saving it for later use at startup. This means, instead of having 16 tiles for every liquid in the game (8 for visible, 8 for map), I just have to have 16 tiles, period. The game makes the colors itself.

This is important because one of the biggest complaints with the videos was the blocky graphics. Smoothing them out is not as simple as some people seemed to think it would be. The easiest/fastest way to do it would be to create tile graphics for every possible slope of liquid surface, but with at least 8 possible liquids in a world, maybe more, that quickly runs into many, many tiles, which would take a long time to draw. This way, I just have to draw a basic set of tiles and colorize them ahead of time. The biggest drawback is that adds up to a lot of tiles; over 1,000 by my reckoning per liquid, but compensating for that is that each is only 32x32 pixels.

Well, we'll see how it turns out.