Last modified: Wed 13 Jan 1999 Send feedback to me, Amit J. Patel, amitp@cs.stanford.edu
|
Over the years I've been collecting information about game programming issues that interest me. I try to avoid topics specific to one platform, such as graphics/sound programming and a review of compilers and libraries. I've tried to collect ideas rather than source code, since I think it's better to go from an idea to code than from code to an idea. I have been collecting this information because I write games---my latest project is SimBlob, a set of games that use environmental simulation such as flowing water and erosion to add new options to a game of economy and war, such as dam-building, deforestation, flooding, and drought. Key:
|
Determining how to walk around on a map is an interesting problem. There are many different approaches, ranging from simple (walk forward until you hit something) to the complex (path finding algorithms with heuristics). I've been writing some pages about path-finding algorithms and ideas; John Lonningdal has several pages about algorithms that are simpler to implement; and I've also saved some articles from rec.games.programmer and comp.ai.games about path-finding. My current favorite is A*, because it can handle varying terrain costs well, and it seems to be faster than most graph searching algorithms. However, it's unclear whether A* is the best choice when there aren't terrain costs to worry about; another algorithm may be optimized for fixed movement costs. Also, A* deals with discrete steps, not with continuous movement, so other algorithms are better when you want to find a continuous path (like a spline path).
The link to my A* code is to the second version [4-Feb-1998], with bug fixes, optimizations, and parameterization for different heuristics and cost functions. The first version of my code is available on Steve Woodcock's pages, and it may be easier to read and understand.
Although the latest game programming craze seems to be 3-D rendered worlds, tile-based (2-D or isometric) games appeal to me because they tend to have more work put into the game play and less in flashy graphics. You can get quite a lot of bang for the buck when using tiles; building worlds from a few key tiles is somewhat like building hundreds of thousands of words from just a few letters. I'm fascinated whenever the whole is much greater than the sum of its parts.
Many war games use hexagonal grids instead of square grids. Squares share an edge with four neighbors but also touch another four neighbors at just one point. This often complicates movement along grids because diagonal movements are hard to weight properly with integer movement values. You either have four directions or eight directions with squares, but with hexagons, you have a compromise -- six directions. Hexagons don't touch any neighbor at only a point; they have a small perimeter-to-area ratio (and therefore used by bees); and they just look neat. Unfortunately, in our square pixel world of computers, hexagons are harder to use, so I've collected some articles that may help you turn common square-grid algorithms into hex-grid algorithms.
Many times I play a game and wish that the computer opponents were written better. Sometimes the computer player is given different rules; other times it has the same rules but gets more money (or other resources) than you. The result is that the game doesn't seem balanced: it's just too obvious that the computer is not playing well, and that the game is brain vs. brawn rather than brain vs. brain. At the same time I don't want AI that's too good; if it were, then it'd always beat me and I'd be frustrated!
I've collected some articles and pointers to information about artificial intelligence in games. The first link is to Steven Woodcock's AI page, which should be your first stop when looking for AI information as it relates to games. There's a lot of interesting reading here!
I have found that the best places to use object oriented programming are user interfaces, operating systems, and games. It's commonly believed that objects are too slow for games, but if you use them appropriately and only where they're a benefit to your design, they should not be a major problem for speed. I've saved some articles discussing objects, games, and efficiency, and there's also a link to an object framework for tile-based games.
Below are articles related to object oriented design but not specifically about games.
Although I'm not a big fan of adventure games, I've found that adventure game writers often have more time to work on story and game design than people working on action games. If you're looking for story ideas or story design tips, or if you're working on a MUD (as I am), take a look at these.
A lot of what is hard about writing a game is getting the design right. What makes a game fun? Unfortunately it seems that guidance on good design is scarce... perhaps because it is an art, not a science.
One of my favorite topics is scripting languages, but I don't see much discussion of them as related to game programming. I think that scripting languages give you a way to write a lot of non-speed-critical code with comparatively little effort. You can design the language to specifically deal with your game, so the amount of work you have to do is less than for a general purpose language. Also, you can write the compiler to optimize for different things (like size instead of speed), allow more features (like dynamic patching at run-time), and even user customization (for enthusiastic users!). Here's a very nice article on Gamasutra:
I am hoping to work on a core of a scripting language--- essentially a virtual machine for running scripts, which could be embedded in all sorts of games. (It would be open source, and free for use in commercial games.) So far I have written only the garbage collector, which takes up 540 bytes of compiled C++ code. My target is 4k for the core virtual machine, which would be modular in that it could be extended with various data types (lists, arrays, numbers, strings, sprites, objects, etc.) and functions (indexing, mathematics, drawing, file I/O, networking, etc.) but would not contain those pieces itself. The core will handle the bare essentials, like memory management, statement execution, expression evaluation, type safety, and serialization (for saving to disk or sending data over a network), but it would not be restricted to any particular type of game. Along with the core I would provide standard libraries, but those libraries would be optional, so each game author could choose to include or not include a particular library, and therefore control how big the virtual machine is. For the implementation I am using many ideas from Scheme. If you'd like to read more about Scheme:
Note: the language I am implementing is not Scheme, although my virtual machine will be flexible enough to allow a Scheme front-end.
I try to avoid getting involved with games programming or design jobs, but there have been so many people asking me how they can find a job or how they can find programmers/designers that I thought I should include pointers to such information. If you maintain such a site (specifically for game developers, please let me know so that I can consider it for this section.
Sometimes I have strong opinions about particular subjects, and I want to write them down. So here goes.. I've started a section on this page with rants I have made into web pages.
Possible topics for future rants:
Some things I just can't justify classifying!
| HOME | ABOUT | PERSONAL | PROGRAMMING | SIMBLOB | FRIENDS | PICTURES | DESKTOP | LINKS |
Last modified: Wed 13 Jan 1999 Send feedback to me, Amit J. Patel, amitp@cs.stanford.edu |
|