From my previous posts, it must now be clear that free-surface fluid dynamics is hard. This is mainly caused by the free surface. Without that, it is possible to write a fluid-in-a-box in a little over 100 lines of C code, as Jos Stam did in his paper Real-Time Fluid Dynamics for Games. However, I could not go down that road. I needed the free surface. I wanted my game to have waves, droplets, splashes, sprays, fountains! How these would make a game, I would figure out after I got the simulation to work.
But then, yesterday while I was lying in bed unable to sleep, it hit me. An game concept popped into my head, almost fully formed. And it did not need a free surface! In a nutshell, the screen would be a fluid-in-a-box, with internal walls, and “fans” that the player could turn on or off to control the flow. The objective would be to transport an object or multiple objects in the flow from A to B. To make it more interesting, the player would himself be a character inside the flow. I don’t know why, but I’d probably make him a jellyfish. He’d need to swim to the fans to turn them on or off. But due to the flow and a limited speed of swimming, not all parts of the level would be reachable at all times! That could make for really interesting puzzles. Also, because a flow is a sort of fuzzy thing, it might be possible to use it at times to circumvent the intended design of the puzzle, turning it into a less sharply defined “fuzzle”.
So I started ripping out the free-surface code to replace it with Jos Stam’s algorithm. Since I’ve implemented it once before on the GPU, I’ll build a GPU implementation right away. I have a good feeling about this!