Author here.
It started as a technical demonstration for fluid dynamics in the web browser. Then I saw the js13kgames competition and the decision was made to make a game out of it. A game in which the fluid mechanic counts. The decision for the Lunar Lander genre then was quiet easy.
Does someone know more games then the two I mentioned in the README (Plasma Pong and Pixeljunk Shooter) with more or less realistic fluid dynamics?
This is great list. Thank you very much. I added most of the games. It is precisely through this post that I have a strong desire to follow your postings,blogs,.... Unfortunately there is no button for that.
Maybe one of the more interesting technical aspects is the usage of WebAssembly here. I used Emscripten, so the main part is written in plain C. But I threw away all the JavaScript overhead and used just the plain size optimized wasm file. This was easier than expected.
You might be surprised that a lot of phones can run this at a decent frame rate. Adding mobile touch support could be good. It runs the start screen well on my Nexus 6P.
Really cool stuff! Both technically and on the game design side
> Does someone know more games then the two I mentioned in the README (Plasma Pong and Pixeljunk Shooter) with more or less realistic fluid dynamics?
A friend of mine, Thomas ten Cate, tried but eventually shelved a project to make a fluid-dynamics based game tha he called Archimedes[0]. Before he moved on to other projects he blogged about it[1]. Does that count?
I remember a DOS (or early Windows) game like this. A top-down, 2D game for two players or 1 + CPU. There were no obstacles, but every time you moved through the background fluid, more fluid was created in your colour (purple / pink), and you could envelop the enemy player by 'swooshing' it around over them.
Was it Ichor[1][2]? A bit later than the "early Windows" days I think (I remember hearing about it around 2007), but it also matches your description and it was the first thing I thought of after playing the game in the post
Back in 2013 I e-mailed the original developers with some WebGL fluid dynamics demos, and asked if they'd be interested in porting Ichor to WebGL, and they were, but it died down soon after.
The Ichor source is on GitHub as well, although it doesn't have a license.
Yes I know. The simulation of the ship is not accurate. I had code written for more advanced physics but I skipped it for the js13kentry. Time was running short and I was afraid the game gets too hard.
Actually you land on planets with an atmosphere. So you have some "dampening" from the atmosphere.
This is great - especially the pixel-perfect collision detection. But honestly, these colonists don't really deserve mail service if they insist on building their cities in such difficult environments.
You would need only two controls, trim and rudder (direction instead rudder might be easier to comprehend). Wrong trim and point of sail could broache or even capsize the boat. Oh, and you could add not just the winds but the sea currents and waves also.
That is exactly what I am asking. So far I haven't seen such a game. But I think it is easy doable with a few changes. I will remember it as a possible idea for a game entry next year.
The boundary between air and water makes the simulation much more difficult. While you can neglect the effects of air on the water, not having a well defined boundary for where the water simulation ends means that CFD 101 level techniques aren't enough anymore.
You don't need 3D fluid dynamics for 2d sailing game.
You would have 3 separate 2d layers for wind, sea currents and then wave layer. The waves don't have to follow the wind, but they they could have specular reflection from the land. It would make sailing in complex archipelago or narrow choke points more realistic.
You could get pretty realistic lift on the sail from simple (potential or vertex panel) methods. But the drag's gonna be a bitch to get right. And you probably have to neglect wave motion. Would be really fun to try though.
For this game - any idea to expand it? I finished 8 levels in one go, and it seems that there is a lot of potential for even more challenging currents, whirlpools, floating pieces, etc.
I definitely have too many projects to tell you for sure. Just look at the two sites [1] [2] and you know what I mean. I have as many projects in the backlog as you can see on these 2 pages. And actually I don't want to concentrate on one. The motivation changes about every month, because I do this in my spare time. And from time to time a project has a status where I can publish it.
So at the moment my motivation for this game is to add more realistic physics for the ship (turns instead of right and left) and a level editor to learn Vue. Then just look at the other comments. You see a lot of great ideas.
But building a 13k game next year based on the Voxel Space Engine is also in my head :-)
I see (and emphatize with!) too many projects and ideas.
As a side note, I am learning Vue.js right now (my motivation: brining deep learning to the browser, with nice, modular interfaces: https://inbrowser.ai/).
> the result varies depending on the FPS and your actions.
you should try to decouple physics simulation from your rendering code. (i.e. pass a constant/fixed dt to your simulation step). simulation should not depend on framerate.
But with a chaotic system like fluid dynamics, you wont get the same behaviour each time even if you do stuff like pass delta-t to the simulation. Sensitive dependence on initial conditions, and all that chaos theory stuff comes in to play.
That is, two run-throughs with very slightly different delta-t's will give different outcomes.
There's a difference between "numerical stability issues introduce small chaotic perturbations" and "the game is literally unbeatable if you play on platform X because the physics step doesn't properly scale Y to framerate and a trivial conservation-of-energy analysis yields an impossibility result for level 3".
It would be nice to have a vertical speed indication in the ship or nearby. Perhaps some semaphore like lights in the bottom of the ship. It's difficult to look simultaneously at the ship position and the speed indicator.
Also, sometimes adding an official name for each map somehow make the game look better. Nice game, I must try again because I lost all my ships in the "volcano" level.
Edit:
Putting the light to show the vertical speed in the landing pad may make more sense in universe.
Also, the buildings look very similar to the old gorilla.bas game :).
It would be nice to be able to disable the simulation in the introduction and final screen, so I can keep the page open to play later, without using too much battery.
"Space Taxi" added a bit more depth to the lunar lander concept by adding multiple pads and various vector fields for gravity to act in. Some game modes would accelerate you not downwards but instead towards the center of the map, away from it or around the center in a circle some way. Quite the brain-teaser for my kid brain back then that hadn't previously been exposed to physics/maths like that.
Exactly. This is at the moment nothing more than a nice technical demonstration. Actually my initial code implemented already mechanics for rotations. But then I skipped this feature for this entry. I was afraid the game gets too hard for landing.
This is great! I would love love a boat maneuver game with the same engine. A killer simulator would be one that takes into account wind and current, single vs multi-engine, bow thrusters, prop walk, etc.
Note that this is different from the sailing suggestion below, which has all kinds of three dimensional aspects to. Purely thinking about e.g. docking where all the controls you have is thrust and rudder.
I played this game too. And I was close trying to implement such a game. But then my fluid grid would be much much larger and the game much slower. I thought about adaptive grids. Fine on the viewing screen and coarse outside. But to implement this would have taken me too long for this game entry.
This happens to me when I use the Internet Explorer.
My best guess is, that the problem is, that the game tries to use all the computing power available. The game does use the "setTimeout(Loop, 0)" trick to accomplish this. Usually there is no problem if the event queue is a queue. Then the setTimeout function is the last one in the queue and keypresses are handled first. If the events are handled differently, for example by using a stack, such games are in big trouble.
I had a similar issue with FF. IT looks like the canvas kept losing focus and FF was interpreting the letter keys as search terms sometimes. I believe when it looses focus with the keydown caused the sticking issue.
"Fluid Simulation for Computer Graphics" by Robert Bridson would be my suggestion for getting started with grid-based methods. The SIGGRAPH course notes on his website are very similar to the 1st edition. [1] It's no longer the state of the art (which is probably APIC), but the new methods are all based on the same fundamentals.
Particle-based methods like Smoothed Particle Hydrodynamics (SPH) are simpler to implement and are more intuitive than grid-based methods, but they're also harder to analyze mathematically. SPH is the method used by PixelJunk Shooter. "Fluid Simulation for Video Games" by Michael Gourlay is mostly about a different fluid technique (vortons), but does include SPH. [2]
One of the prices is the book "HTML5 Games: Novice to Ninja" [1]. However the best way to learn is to read other code. Look at the js13kgames entries [2]. There are more than 1000 games entries. All with source code.
This game was brilliant fun, just got over 12k after playing it over and over again. It really reminds me of white water rafting, you really can move very efficiently, quickly and with little thrust if you properly read the course. Simple game, but great depth.
This is great! I made it all the way to 8, but couldn't win :)
I like the idea of having to examine wind streams to plot your way through the map. This is an awesome tech demo, would be keen to see something more polished & fleshed-out.
Ok, then the obvious solution is my counterintuitive one. You have to cross where the wind is the strongest at the bottom. As fast as possible of course.
Regarding usability: I keep getting confused by the controls: indicating where you want to go vs which thruster to use. Back in yonder days I used to play Lunar Lander on Windows (https://en.wikipedia.org/wiki/Lunar_Lander_(video_game_genre...) but there the controls indicate which rocket you're firing: down for going up, left for going right, etc.
On my computer the game runs at 40 FPS. So there is still room and I can increase the timestep if you want.
This game simulates the Navier-Stokes equation on a grid of the size 256x128. Four times the size would already reduce the game to 10FPS or even more. Of course you can try to rewrite it to run on the GPU. An alternative would be to use so called Smoothed Particle Hydrodynamics. This is particle and not grid based. But this technique has other drawbacks.
I love the faster one. Grabs much more attention. Great game! A satisfying thud on touchdown would be nice. (OT: this was the very first lunar lander I played on my father's ZX81: https://www.youtube.com/watch?v=jlS3fr3t4Fg)
The problem with higher speeds were instabilities in the numerics. So I reduced the internal time step. Never tried to increase the speed again after solving a few of those problems.
Lander used to be the first game I would program when I got a new computer as a kid. I remember writing it for the TI-99/4A, Commodore 64, and the Amiga 500 (in Modula 2). Your game brings fond memories of those simpler times.
Amazing what you can do these days with the tremendous speed of computation available on modern hardware, even with the js13k constraints.
Very cool and great use of webassembly. Bug report: if you get low enough in the last level and thrust upwards, the black smoke somehow mixes with the purple smoke outputs and they start instead covering the screen in black smoke.
I also had problem with the last level - on the several attempts I had left, after about 10 seconds the sim would seem to bug out and it looked like there was a very, very strong wind along the bottom, which looked like it was friction-pulling the rest of the play area so that everything was blowing fast to the left, leaving it (apparently) unplayable.
After playing for < 10 minutes it started getting noticeably slower and my MBP Retina was spinning up its fans. I am using latest Chrome. Is this a sign that web games are not yet ready - or simply that either the game isn't optimized enough or perhaps even that Chrome is a poor choice for browser games?
Very likely started thermal throttling because apple is notorious for not putting adequate cooling on their mac books.
This game uses fluid dynamics calculated in real time, i don't think its designed to be super optimized but rather super true to physics. Most of the time game optimization involves cheaping some of the complex calculations to be less accurate but still "good enough" see https://en.wikipedia.org/wiki/Fast_inverse_square_root for an example.
In other words you'll run into this issue any time you do anything taxing for more than 10 minutes on a mac book.
My desktop is a E5-1230 v5 (i7 class CPU from 2015) and I played for 15-20 minutes with no noticeable slow down or increase in fans. I was using chrome.
I think your experience has more to do with laptops being much slower than desktops than anything do with how poor chrome is. As for "optimized enough", seems like the whole point was to put non-trivial physics in the game, and not to cheat.
https://i.imgur.com/EksA6Rw.png Woo! +1 to the comment about larger levels. Though I'm only getting about 20fps on my laptop as is. Multi-core? GPU? Awesome little game, in any case!
I would recommend that in a future version the craft is actually rotated by the "air" too for extra challenge, perhaps having rockets that rotate left and right and make the downward facing rocket more powerful to compensate.
Not working in Firefox 60.0.1 (64 Bit, MacOSX). The game runs, but the lunar lander blows up instantly when the game starts. The audio is only in the left channel, but works, as does the space bar toggle for sound on/off, and the explosion uses fluid dynamics which are working.
Awesome! Couldn't win yet, but I'll keep trying :)
On a more technical note, I wonder if you could use a Lattice-Boltzman-based flow simulation instead of classical CFD. Could be faster depending on "grid" size.
From a quick search, there are quite a few on Github. Can't point to a specific one, though. I implemented a very basic 2D version on one of my MSc classes, and although we used MATLAB, it was quite fast depending on grid size/fluid properties.
I opened it on Firefox and everything worked out fine.
I realized that on Chrome all the graphics were weird. No colors on the home page, I couldn't see the windows at the buildings. Maybe there is something not rendering right in Chrome.
I use Chrome Version 60.0.3112.113 (Official Build) (64-bit) on Fedora 25
You have to fly to the top left. Then fall down. But immediately after you have started falling you need all your thrusters to stay on the line and land safely.
Does someone know more games then the two I mentioned in the README (Plasma Pong and Pixeljunk Shooter) with more or less realistic fluid dynamics?