Beavers 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.
Beavers build dams to raise the water level, creating a still pond to provide them with shelter. They build a lodge in the pond to live in.
Beavers gnaw through trees, and warn other beavers by thumping with their tail when the tree is about to come down.
Dam building is triggered by the sound of running water. When researchers placed speakers in the beavers’ habitat, playing the sound of running water, they found them covered in sticks and mud the next morning.
The longest beaver dam was discovered in 2007 on Google Earth. It measures 850 metres and has been under construction for decades.
Beavers were threatened with a $10,000 fine by the state of Michigan for building a dam.
The word “beaver” is also used as slang for the female genitalia. Then again, what perfectly normal word isn’t in the Urban Dictionary?
Two-dimensional, digital beavers do not exist. Yet.
No truism is always true, not even this one. I recently clashed with two common conceptions in software engineering:
“All problems in computer science can be solved by another level of indirection.” – David Wheeler
“Some people, when confronted with a problem, think ‘I know, I’ll use regular expressions.’ Now they have two problems.” – Jamie Zawinski
The problem, in this case, is the heart of my little content management system, Utterson. As I discussed previously, I want all content to live in a Git repository, which is read and interpreted (later, also written) by the CMS. For example, I would create a blog using magic file extensions like this:
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.
This 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.
I 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. For example, I could say “Now try moving the orange ball into the blue rectangle, but only moving the green blocks.”
To 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. It was time to build a graphical editor.
In 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. If someone’s video card did not support this resolution: tough luck.
This 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. But combined with what I learned in my earlier work on the free-surface simulator, I managed to put together a fast, stable, flexible and pretty fluid solver that I’m more than a little proud of.
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.
Work 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. Since the SOR solver I was using lends itself well to parallelization, and video cards are good at running parallel programs, I tried to run the solver on the video card (GPU).