## Puzzle concepts

I’ve been doing more experimenting with the engine, trying to come up with a workable puzzle concept. Below are some videos and reasonings.

First off, the game objective. Assuming that it’ll have something to do with the fluid, one possibility is that the player has to make the fluid flow in a particular way or direction. We could represent this as having to “paint” particular objects with colours that are injected into the fluid. For example, in the video below, the player would have to paint the top box red and the bottom box green. (The opposite would make for a rather more difficult puzzle!) The boxes don’t yet react to paint in any way.

(Apologies for the lousy video quality. I’ll do a better job next time)

The light-blue shapes can be moved freely by the player. I feel that this gives them a bit too much power, though. What happens if we constrain that movement to a specific line segment only? We could then do something like this.

Another problem is that “the movement of the fluid” is inherently a bit vague. When did we apply “enough” paint to a box, or sent “enough” paint off the screen? We can work around this in various ways, but one way to make it more binary, black-and-white, is to augment the paint by fixed, rigid objects. We can then make something like below.

The pellets are floating ‘on’ the fluid, so they have no effect on the fluid motion. In particular, you can see that they don’t block the flow when they get stuck in a hole. With some work, I could probably get such two-way interaction, but it’s not necessary right now.

Differences in pressure cause the fluid to flow one way or the other. Right now, you cannot see which areas have high and low pressure – the only way to find out is to look at the way the fluid behaves.

The objective of the above scenario could be to get the pellets off the screen, or to some particular destination. Maybe pellets with different colours would only be affected by fluid in the same colour, which might open the way to some interesting puzzles.

However, a big problem with all concepts mentioned so far is that the fluid simulation is inaccurate. For example, if fluid flows into a closed region, you’d expect pressure in that region to rise, and counteract the pressure on the outside until the flowing stops. In this simulation, that’s not what happens: the fluid just keeps flowing. The inaccuracy is a result of the “backwards advection” method used in Stam’s algorithm, and is not easily fixed without requiring a tenfold smaller time step (which is not feasible on current hardware).

“Why should you care,” you might ask, “it’s just a game. It doesn’t have to be realistic, it just has to be fun.” The problem is that a game is not fun if it behaves too unpredictably. So, as a player, it becomes hard to make the fluid do what you want. I think puzzles will need to be designed with these limitations in mind, and they may prove to be even more limiting than is currently evident.

Another issue is that I’m not yet convinced that a sufficiently rich and interesting puzzle concept using this fluid simulation is even possible. This is a real possibility, but I’m not giving up so easily.