In Profundis Problem: Continually flowing water

One of the reasons there was a bit of a delay in work on the game was because I was mulling over for a while solutions to certain problems with the game as envisioned.  Here I explain one particularly annoying problem that I'd really like to see fixed, but currently don't have a very good solution for.  Maybe one of you might have an idea.  At the very least, maybe some of you might find thinking about this interesting.

In Profundis uses a cellular automation system for flowing water, yet because of the closed nature of the game world, most flow is ultimately user-initiated.  Liquid tends to pool and collect and remain as low as it can get, and remain there collected.  It doesn't actually end up flowing much except at the start of the simulation.  Once it gets to the lowest point it can reach, there it remains until something disturbs it.

This is not particularly interesting from a gameplay perspective.  What would be more interesting is if water could enter and leave the map, or at least flow through two locations in the world, repeatedly and endlessly.  Then the player might have to find some other way around it, or maybe divert the liquid to give himself a safe path.

The problem is that, because of the size of the game world, we can't compute the whole thing every frame and keep within an acceptable speed.  Some distance outside of the visible screen we have to abandon calculations.  This causes liquid to "pile up" when it flows outside the border.  If we recycle liquid between two "portals," unless both of them are within the calculation region at the same time, the flow will stop.  And as the player scrolls around the map the calculation region changes, meaning while approaching the area there will almost always be a time when one portal is in the region and one is outside.  If they are far enough apart, there could result in instances where the player is suddenly beset by a rush of liquid that has "backed up" because of the simulation border, then suddenly uncorked by the scroll.  (This could actually be interesting from a gameplay standpoint, but it goes against the philosophy of the game.)

I'm not sure there is a viable solution to this problem, but here are some possibilities:
* One thing I could do is consider the region between the two portals an "all-or-nothing" region for calculation; if one cell of the rectangular region between the pair is calculated, then do the whole thing.
* The larger the simulated region, the less evident the problem becomes.  If we work on enlarging that area (maybe by slowing down the rate at which fluids flow, which I've been considering for a while), the problem will become less visible.
* It's possible that the problem won't be perceivable to the player most of the time.  Because his range of vision is limited, even on-screen backups won't be too apparent so long as they're outside his field of view.
* The real-world solution to this would be a evaporation/condensation cycle, but that would probably require a scale larger than what we're looking for here.

In Profundis Progress (10/30): Tools and Flags

Still working on the in-world representation of tools.  I've decided that they need to be simulated on their own "layer," that is to say, a given space can contain both a tool or other object and more substantial world simulation elements like water and gas.

What do I mean by a tool?  Tools are objects the player can interact with, place in inventory, but also change the world to his liking.  Changing the game environment is a major theme of the game; the pitons and ropes you place to get around don't go away over time unless something removes them.  Since you can only carry so much at a time, exploring is an iterative process of placing equipment, over multiple expeditions, letting you get further each time.

One thing I'm worried about is that the process of traveling back and forth in the game world, between base for resupplying and the edge of exploration, could end up being boring.  One solution to this problem I'm considering is the use of player-positioned checkpoints.  The idea is, the player could obtain "flags" that he could place in the field.  After planting a flag, the idea is to then "validate" the flag, by traveling back to the base without placing any more equipment.  If this is done, the flag is validated, and the player can then warp from the flag to the base at the cost of the amount of game time it took to make the trip.  Likewise, the return trip can also be validated for reverse travel.

This system isn't perfect; after a flag has been validated going one way or the other, it is possible for the terrain between the two to change and make the route impassible.  This could be partially solved by keeping a list of the cells traversed in the route, and upon teleporting checking each of them to see if they've been modified since the route was validated.

In Profundis Progress (10/28)

I haven't been doing nothing on the project exactly, but I'll admit there's not a lot of actual programming work to show for it lately.  I've been thinking.  Thinking about things like this.  If this seems a little incoherent it's because I'm writing this as I work it out in my head.

One of the ideas of the game is that the player has to manipulate the game world to get around in it.  What you do changes the world, and changing the world is dangerous.  Like, putting a piton in a wall could crack the wall, causing liquid to drip through, possibly weakening the wall further, eventually destroying the rock face the piton is in.

It's not good enough to use a new cell type for each type of tool, because otherwise things like pitons and ropes will block fluids, which is no good.  Instead, each cell needs its own Tool field.  That adds a little overhead to the cell structure and cellturn(), but isn't too bad.

A rope can be tied to a piton.  The question is however, how to represent this rope? Do we arbitrarily plop it down when the piton is placed?  What if the piton is removed then, how will we know to remove the rope?  If multiple pitons are placed vertically so their ropes overlap, how will we know to remove the right ones?

Another thing is, I've learned a bit more about how Python handles recently, particularly I've cleared up in my head how it handles static class variables, which stands to simplify the code a bit and make it more maintainable, but requires going back and redoing some of my old work.

So work is continuing, and in fact should speed up now.  I find my energy for project work tends to come and go, based both on internal and external factors.  Updates should be frequent again, at least for a while to come.

Not forgotten....

Other projects and such have been vying for my time lately, and I've kind of let them for a little while because I'm wondering if what I have so far is "fun."  It has the capacity to be fun, I recognize, the question is if the world builder can take advantage of the potential to create interesting situations.  That is a hard problem; I've got some ideas in that direction, but there's

There's also the matter of some weird bugs that have cropped up in the fluid code with the random fluids.  Notably, when walkable fluids float atop swimmable ones, it's kind of wonky.  The platforming routines need a lot more work.

There's a thousand things left to do, but I'm working on them!  I am sorry it isn't going as quickly as I hoped.  I'm afraid I might not be as good a programmer as I had hoped -- the project is reaching the edges of my capacity to keep it all in my head at once, and that slows things down.  Please bear with me in this difficult phase of the project.