Water simulation #
One of the most fun things about SimBlob is the water simulation. It isn't great though, and I keep looking for ways to make it better. Using the Navier-Stokes equations is the “right” way to simulate fluids, but they're complicated and expensive, so many people have come up with approximations or alternatives. Here are some resources:
- Fluid Dynamics Model (includes demo for Windows)
- Fluid Dynamics with Erosion
- Real-Time Fluid Dynamics for Games
- Reflections on Water Simulation
- Practical Animation of Liquids
None of their solutions directly works for me, since I'm using a hexagonal grid and have a dynamic landscape underneath the water.
[2005-07-11] Update: I tried some approaches based on the above, but they didn't work for me. It's quite possible that I'm missing an essential step in my simplification.
Labels: programming , project
SimBlob 2, now for Mac #
I've added a Mac makefile to the download, but I haven't tested it myself. The main changes involved file paths. On Linux and Windows, OpenGL is #include <GL/gl.h>; on the Mac, it's #include <OpenGL/gl.h>. On Linux and Windows, GLUT is #include <GL/glut.h>; on Mac it's #include <GLUT/glut.h>. I admit that the Mac directory names make more sense, but it's annoying given that the include has been GL/gl.h for a decade on other systems. The other change involved the linker options; you have to specify a -framework. Thanks to my friend Richard T for figuring all of this out.
Labels: project
SimBlob 2, now for Windows #
When I started working on Simblob 2 back in 2002, I decided to use OpenGL and GLUT. Even though I was developing in Linux, I didn't want to end up in the situation I had with Simblob 1, which only works in OS/2. I finally took advantage of the portable libraries for SimBlob 2 and got it running on my new computer, which runs Windows XP.
I use Cygwin in Windows, so the Unix level libraries are fairly similar. The main difference was that the paths are different. In Linux, I used -lglut -lGLU -lGL, and the compiler was able to find all the headers and libraries. To make it run in Windows/Cygwin, I changed it to -I/usr/include/w32api -L/lib/w32api -lglut32 -lglu32 -lopengl32. Also, glext.h wasn't automatically included, so I had to insert #include <GL/glext.h>. In addition, the multitexturing functions (glActiveTextureARB, glClientActiveTextureARB, and glMultiTexCoord2fARB) don't seem to exist on my system, so I worked around that by using a single texture instead. I'll figure that one out later. I might need to use wglGetProcAddress to get those functions (unfortunately that function is Windows specific).
The one remaining problem I'm having is that when I quit the program by closing the window, GLUT's main loop doesn't exit. It instead starts eating up 100% of the CPU and never terminates. I'm not yet sure if this is a GLUT issue or a Cygwin issue. My workaround is to use Ctrl-C to exit instead of closing the window.
At the moment Simblob depends on Cygwin. You can't just run the Simblob executable; you have to have Cygwin installed. I'd like to try using the MingW option (gcc -mno-cygwin); I just need to remove some other dependencies on Unix libraries first.
I should probably spend some time learning autoconf or some other tools that help manage builds on multiple platforms.
I don't have a Mac handy, but it shouldn't be too hard to make Simblob 2 work on a Mac.
Labels: project
Games in Javascript #
A few weeks ago Google Maps got me thinking about writing simple games in Javascript. In particular, how much of The Silver Kingdoms could I implement in a browser? If I drop the terrain and make it a 2D overhead game (or possibly isometric, but that might be harder to implement), what I would need from the browser is (a) AJAX support (so the simulation can run on a server and send updates to the browser) and (b) transparent overlays for sprites. There are some nice advantages of writing in a browser. The basic graphics code is already there (image display, animation, positioning, layering) and the basic UI code is already there (mapping clicks to objects, overlapping windows, form controls). The real question is whether it's feasible—can the browser smoothly animate lots of sprites on the screen at once?
A few days later I read that someone had created a Star Wars hack on top of Google Maps. And then I saw someone had created an animated Microsoft campus invasion hack. There's now a wiki page with a list of Google Map hack game ideas.
There are only 9 sprites on the animated invasion hack, but it feels rather choppy. I'm not sure if this is a browser issue, an issue with the demo, or an issue with the Google Maps API. If it's a browser issue then it's unlikely that any nice games are going to be written on top of Google Maps. If it's a Maps issue, then a game using its own map might be feasible.
Some links I've collected while looking for ways to implement a simple game (SimCity-ish) in Javascript:
- Examples for drag and drop of objects in Javascript
- A drag and drop map, like Google Maps, but with your own maps
- A description of the canvas element in Firefox 1.1 and Safari, which could be used for drawing graphics in the browser
- A library for special effects in Javascript (including drag and drop)
I hadn't been considering using Google Maps itself, because a SimCityish game where you can't actually modify the city would be boring. I think it might be feasible to build a war or transportation game on top of Google Maps, but the game would need some notion of what the objects on the map are, and that might take some image recognition heuristics. It's unlikely I'll actually implement a real game this way, but I might try a little demo game.
Update [2005-12-16]: Take a look at this game.
Labels: design