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
Guild Wars Friendliness #
There's something about Guild Wars that I don't see mentioned much: it has a very friendly interface that encourages casual play.
- The CD doesn't have to be in the drive. When I'm thinking of playing, I don't need to take the previous CD out of the drive, put the Guild Wars CD in, and then start the game. I can just start the game right away. Since it's no hassle, I play a lot more.
- When I start the game, it goes right to the login prompt. No publisher splash screen. No developer splash screen. No video card maker splash screen. No sound library splash screen. No introductory movie. No copyright screen. No disclaimer screen. No menu. No loading progress bar. It's really quick and easy to get into the game. This encourages me to play more.
- While you're playing the game there are Minimize, Maximize, Close buttons at the top right corner. This lets you easily switch to another application or run the game in windowed mode or just stop playing. It acts much more like a standard application, and it's very smooth. I feel like I can play at any time, and then switch back to whatever I was doing.
All of these seem very minor but I think they add up to something big: I'm playing Guild Wars a lot (over 200 hours). I wish all games would be this way.
Guild Wars #
After playing Neverwinter Nights for a few months, I got tired of it. I played the main campaigns and enjoyed them. The problem is that the mods are much harder to deal with than they should be. It takes a lot of effort to find mods that you can play (level restrictions, number of players, good ratings, etc.). It then takes more effort than it should to download and install them. They come in ZIP, EXE, and RAR formats. They come with multiple files, each of which may have to be put into a different folder. Bioware could have made mods easier by keeping all the mod files in a single folder and by standardizing on the distribution format. For example, if the game could read ZIP files, you could just download the file and put it in a particular folder and it would be ready, without unpacking it. In any case, the main problem I had was that it was hard for me to find and try out mods, so I didn't try many, and I didn't find many that I liked.
I've been playing Guild Wars this week (22 hours so far). This is an action RPG, much like Diablo, but it also has more quests. One thing that struck me was that Diablo 2 wasn't considered an MMORPG, but Guild Wars sometimes is, and the two games aren't substantially different in that respect.
Diablo 2 lets you play offline (one player) or online (one or multiple players). Guild Wars lets you play online only. This seems like a good idea. If you know that everyone's online, you can have a much quicker update cycle (those of you who waited over a year for the 1.09 Diablo 2 patch know why this matters). So far I've had 3 small updates in 4 days. Requiring online play also means you can learn how people play and make game balance adjustments frequently.
Diablo 2, in online mode, puts you in one of many chat rooms. The main purposes of this room are to chat, to find people to play with, and to trade. There are several chat rooms (presumably to avoid overcrowding), including some specifically for trading. When joining a game, you see a list of games that are at your level (Normal/Nightmare/Hell). People generally want to find a game that's not only at their level but in the same general areas. They sometimes do this by announcing their area (“Act III - Staff quest”) in the game name, but there's no easy way to filter or sort the games to find the areas you care about. Once you join a game, you don't see everyone anymore; you only see your party. Every time you join a game, the world resets—all the monsters are back, and the layout is randomized. When you leave a game, you abandon your party.
Guild Wars feels like an MMORPG because it puts you into the game right away. You're in a city, with lots of other people around, and you can see everyone walking around, talking, getting quests, etc. But these cities are essentially chat rooms. Their main purpose is for people to chat, find people to play with, and trade. Once you join a party and go out to play the game, you don't see everyone anymore; you only see your party. Every time you go out, the world resets—all the monsters are back (but the layout is not randomzied as it was in Diablo). When teleport into a city, you abandon your party.
There are of course other differences. In Diablo, you can only get quests once you go into the game. In Guild Wars, you can get quests in the chat area (cities). Since a party may want to go into a city to get quests, the party is not broken up if you walk into a city; it's only broken up if you teleport. In Diablo, if you want to trade with someone, you find them in the chat room and then you have to create a game to trade with them. In Guild Wars, if you want to trade with someone, you can trade with them in the city where you met them; there's no need to go anywhere. Also, Guild Wars has a special trading chat channel. You can tune in to both the regular and the trading channel; you don't have to go somewhere to find the traders. Guild Wars also makes it easier to find a party or to play PvP.
Why does Guild Wars keep the Diablo-style chat vs. game area distinction? I think it's for efficiency. Chat areas handle hundreds of people; game areas handle up to four. Chat areas are easier to make efficient because you don't need strict ordering of events. If you say something and I say something at roughly the same time, it doesn't matter so much which is heard first. And it doesn't matter so much if it takes 250 ms to show up. If you attack someone and I attack someone at the same time, it matters a great deal which one occurred first, and it needs to be decided and sent to all clients much quicker than 250 ms. By segregating the chat (lots of clients, loose ordering of events, high latency) and the game (few clients, strict ordering of events, low latency), you can make both efficient. If you tried to combine the two, you open up a new hard problem: what happens when you have lots of clients and you need low latency? Trying to tackle that rare but important case makes your life as a game developer more difficult. You're spending less time on other things that may have mattered more to the players.
Another thing that Guild Wars doesn't handle is massive persistence. You can only drop items in the game areas, not the chat areas. So if you drop an item, it only has to be seen by a few other clients, and it goes away as soon as you enter a city. That way you don't need to coordinate item locations among tens of thousands of clients. You can assign each city area and each game area to a separate server. Since city and game servers keep no state, you can add more servers transparently. You don't have to require players to choose a server ahead of time and then find that they can't play with their friends, who happen to live on a different server.
So far I've been really impressed with what I can infer of the design of Guild Wars. It's fast, has great graphics, and lots of fun. It's an incredibly addictive game.
Labels: review
Product placement and games #
Product Placement is a way to get your product seen without using traditional advertising. I think product placement could be used for market research too. Imagine an online game that doesn’t offer only Coca-Cola (product placement), but offers lots of drinks. You could then correlate the choice of drinks with demographic information you have about your gamers—age, gender, income, and so on. By watching activities within the game, you could correlate the choice of drinks with MUD personality types (Killers, Achievers, Socializers, Explorers); this might tell you what kinds of magazines you want to advertise in. You could see whether people who hang out together are more likely to drink the same sorts of drinks (energy boosters, soda, water, juices, etc.). You could pay some people to switch drinks and see whether others follow. You can measure correlations between products (do people who drink Red Bull also eat hamburgers?).
Does this creep you out? It should (unless you work in marketing). Product placement is what we have now, but I think in the future we’ll have people using virtual worlds as a way to run experiments on us. In virtual worlds you can measure behavior better. There is of course the question of whether product choice and behavior in the virtual world differs from the physical world, but having detailed data about a million players can complement having sparse data about a few thousand survey participants. Given that games—unlike movies—let players choose what to do, product placement in games seems like a waste. Market research seems to me to be a much more valuable way to use that opportunity.
Labels: design
Playing characters in games #
It’s actually very interesting in The Sims how the pronouns change all the time. I’m sitting there playing the game and I’m talking about, "Oh, first I’m going to get a job, then I’m going to do this, then I’m going to do that." And then you know when the character starts disobeying me, all of a sudden I shift and say "Oh, Why won’t he do that?" or "What’s he doing now?" And so at some point it’s me kind of inhabiting this little person, and I’m thinking, "It’s me, I’m going to get a job and I’m going to do x, y, and z." But then when he starts rebelling, it’s he. And so then I kind of jump out of him, and now it’s me vs. him. You know what I’m saying?
— from Celia Pearce’s interview with Will Wright
Labels: design
Road building applet #
A few months ago I had been thinking about a UI for building roads and rails. When I got Locomotion, I found that the building UI was a little bit annoying, and that inspired me to work on my UI some more. I tried Flash but couldn't find a free and easy way to get started, so I turned to Java instead. The Java documentation on Sun’s site is nice. For example, take a look at their Java 2D documentation.
After playing with it for half a day, I have an applet that lets me build roads. One of the most confusing things was figuring out how to write <object> and <applet>. Ick. (Let me know if it doesn’t work for you.)
The basic idea is that roads (or rails) should be between edges, not tiles. Road segments are cubic splines between two edges. It’s a little tricky to select the right edge; I need to think about that problem a little bit more. There’s a larger version on my other page.
This building UI isn’t directly usable for games like Locomotion. It would need length and angle constraints, diagonals, bridges, and tunnels. To make it more usable, I need to add pathfinding, so that you can drag across the grid and it will figure out which segments need to be built. I will probably get bored before finishing all of that, though.
Web languages: Java #
Given my failure to get started writing Flash code, I decided to try Java. I downloaded Java 5.0 (which comes after 1.4, believe it or not) and Eclipse 3.0. Both of those sites need to have a much easier way to download the software. Java led me down a maze of multiple versions, marketing material, and legalese. Eclipse led me to a page of international mirrors, none of them useful (when I clicked on them, I got a big file listing and had no idea what I needed to download).
Despite some glitches (like some dialog boxes being blank and some being far wider than the screen), I got a simple applet running. My next step is to learn how to draw lines on the screen so that I can start creating a small isometric map. After that I need to learn how mouse events work so that I can let the player select tiles on the map.
The main disadvantages of Java compared to Flash are: it’s not as widespread, and it appears to be a more verbose and cumbersome language. I'd really like to do something with Java3D, but it looks like that is not installed by default on anyone’s machine. I just installed Java and I don’t have Java3D. I don’t want to ask my readers to install new software just to look at my demos. I think Java3D would be much more popular if it were installed by default.
Update: I’m not the only one who had trouble downloading Eclipse.
Labels: project