Posts tagged “Archimedes”
◂ Back to all postsI’ve decided to change course. Drastically. The fluid engine works nicely, and although it’s fun to play with, it’s not exactly a game just yet. I had this idea, which I alluded to in my previous post, of making it into a creative construction game.
Continue readingBeavers live on wood, bark and aquatic plants. I would have guessed that they ate fish, but they don’t.
Beavers can hold their breath for up to 15 minutes.
Continue readingI’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.
Continue readingThis week has been one of mostly refactoring. I’ve been streamlining the code to make it easier to add new objects and features later on. This will prove useful, because the gameplay clearly needs a lot more experimenting to get it right.
Continue readingI had hoped that the editor would allow me to quickly test gameplay concepts by using “soft rules”: rules that are communicated to the tester verbally by me, instead of being enforced by the program.
Continue readingTo be able to test different configurations, I had a rudimentary text-based file format to describe levels in. It was fairly simple and easy to edit, but still, hand-typing coordinates is not my idea of fun.
Continue readingIn the days of MS-DOS, things were simple. If you developed a game, you usually wrote it for one specific VGA or SVGA resolution, such as 320x200 or 640x480.
Continue readingThis week I worked hard on getting the fluid solver in the style of Jos Stam working. The basics were easy enough, but Stam makes some simplifying assumptions, so the continuation was not quite trivial.
Continue readingFrom 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.
Continue readingWork on this project has been standing still for some time while I was working on another project. But this week I picked up work where I left off: making the fluid simulation even faster.
Continue readingThe fluid simulation was beginning to approach results of decent quality. However, it was still far too slow. Most of the screenshots I’ve shown so far were done on a 64x64 grid, which barely ran in real-time even on my fast Intel i7 machine.
Continue readingI’m a very visual type of guy. A picture really does say more than a thousand words. It should come as no surprise that my way of coding and debugging reflects this.
Continue readingLast week, I wrote to my fluid dynamics professor for advice on the free surface fluid simulation. It was a positive surprise to see that I had run into exactly the same problems as he had in his research.
Continue readingIt’s been a busy week with little to show for it. As I wrote last time, I more or less gave up on the SPH particle-based method, and opted to fix my grid method instead.
Continue readingI realized that the problems I was having with the tracking of the water volume were not as easy to fix as I thought. It seemed that grid-based (Eulerian) methods are very suitable for a continuous fluid, but not so good when a sharp boundary between water and air is needed.
Continue readingTo find the source of the instabilities, I pulled my code apart into more independent steps, that could individually be turned on or off. This did result in a speed hit, but allowed me to quickly trace the source of the problems to the advection routine.
Continue readingSince no existing code fit my requirements, I started working on my own fluid simulator a few weeks ago. The idea was to try both a grid-based and a particle-based method, and see which worked better for my situation.
Continue readingI looked around for existing code or libraries to do the fluid simulation for me. There are some, but most are either GPL-licensed or too expensive, so they are out of the question for a small-time independent developer like me.