Slashdot Mirror
Review:Real-Time Strategy Game Programming
Highly Anticipated
I found out about this book early this year. It was scheduled to be published in February by some small publisher I had never heard of. It was the only substantial source I could find on real-time strategy game programming, and it wasn't yet available. After a month or two of delay, it was released I ordered it directly from the publisher.
I couldn't wait for this book. It was aimed at intermediate to advanced programmers, so I had high expectations. I wanted something that would help me significantly in my own efforts to produce an RTS game for Linux. Even though the book was written using DirectX, it promised to cover game objects, landscape, pathing, and other such topics.
Initial Reactions
I was hopeful when the book arrived, after scanning through it. It had promising diagrams and meaty chapters on the topics I was interested in (Chapters 15-19, which actually comprise almost half the book). However, there was more DirectX coverage than I had bargained for.
The more I read, the more disappointed I became. I read the entire book, some parts several times, and indeed have used it while programming. It became clear to me that this book did not have the quality of an O'Reilly or Addison-Wesley product. What follows is an extensive deconstruction.
Topics
As evident from the table of contents, the book covers a lot of material. That lack of focus in itself is a flaw. I found the discussion of game ideas interesting, but I wanted a book devoted to the construction of RTS games, not their design. For the most part, Chapter 8 is composed of screenshots and descriptions of popular games in the genre, such as Age of Empires and Starcraft. You would think anyone purchasing this book would have played most of those games!
I found the discussions of the development cycle, coding style, and so forth in Chapter 3 excellent. But frankly, I have many great books on those topics and didn't need more. I think the same could probably be said for any intermediate to advanced reader. In the same vein, I didn't need information on data structures and utility libraries. Yet Chapter 6 is thrust upon me, composed of two pages of text and fifteen pages of source code from the CDROM (some of which the author admits to having never used).
Chapter 7 teaches the reader how to use the Visual C++ integrated development environment. It has screenshots of most wizard dialogs, and even gratuitous shots of the author's colour preferences and the Windows calculator. Is this intermediate to advanced fare?
While unrelated material receives valuable coverage, other important topics I was anxious to read about are shirked. There is no real coverage of multiplayer aspects or networking concerns. In addition, many topics are not covered deeply. For example, fog of war is described, yet the author presents no implementation details.
DirectX Coverage
I was hoping the DirectX material would be limited to some introductory chapters and API usage. As long as the algorithms were discussed, I could always port the code to another API myself.
Chapters 9, 10, 11, and 20 are fully DirectX specific. Chapters 12 through 14 cover additional graphics topics. That would be great, except I didn't need a graphics book. I'm not sure why the author feels a presentation of Bresenham's algorithm is in order (p222). Chapter 17, while not about DirectX, is highly Windows specific.
I can't say whether the DirectX code the author presents is quality or not, but if you are a DirectX programmer perhaps the book might appeal to you more.
Source Code
The author states in a note: "For this book, there was a lot of rewrite in order to make things more consistent and readable. I do not code this consistently or perfectly in real life."
I find that statement somewhat ironic, as I have many problems with the source code in the book. First of all, it is put forth as C++, yet makes heavy use of the preprocessor while avoiding the Standard Library. The author uses assignments in constructors where initializations are preferred. He also writes a standalone memory allocator instead of overloading operators new and delete (p579). That is not the C++ way.
The source code has absolute paths in its include directives (p106). The author employs leading underscores in his header guards (p121), and is not afraid to copy header declarations in order to decrease compile time (p159,241).
The author seems to miss the point of object-oriented programming, using inheritance to save typing (p307). The author derives from WORLDCOORDINATE such diverse classes as SINGLE_TILE and WORLDOBJECT (p426,529,531). Clearly the relationship should be containment, thereby expressing "has-a" as opposed to "is-a."
The author makes further coding errors, such as half-page-long virtual inline functions (p557-558) (see Effective C++ for details), recursive deletion of linked lists (p58) (which risks overflowing the stack), and incorrect copy constructor signatures (p631) (preventing copying of const objects).
The most intriguing error I see is premature optimization. For example (p389), the author "optimizes" a structure to 13 bytes, while noting that floating point members might increase its size. Yet padding would dictate that the structure occupy 16 bytes anyways, and indeed, that proves to be the case using the egcs-1.1.1 compiler.
One note the author writes (p363-364) is just plain wrong, apparently confusing the const and static keywords. The author also employs an incorrect syntax for bit fields (p388-389).
The author presents too much utility code. For example, not only does the author present seven and a half pages of container implementation, he repeats it later "for reference" (p336-343,629-637). Another seven pages of container implementation are, in the author's words, "nearly identical" (p678-685). Finally, if the reader needs yet another string class, one is presented (p293-300).
Editing
I'm not sure if the book was rushed or just poorly edited. Some paragraphs are just hard to understand, bordering on incomprehensible. But more often I find the author rambles, often repeating a paragraph, only slightly rephrased (p31,32,306).
The author writes in a confident tone, almost cocky. He is not afraid to tell the reader when his code is really good, although to be fair he also occasionally admits its shortcomings. Also, he seems to have an opinion on everything. I just think a little restraint would give his words more weight.
The gratuitous source listings should not have made it to publishing. I especially don't appreciate the author merely dumping unexplained untested code into the manuscript (p346-352).
I think strong editing could have helped those problems, and also imposed greater focus on the material. There seems to be a real confusion as to reader's skill level, which is supposedly intermediate to advanced. The author talks of the complexity of a doubly linked list as if the reader had never seen one before (p637).
Pedagogical Issues
The most glaring omission in this book is a sample game implementation. I would have been thrilled to have seen a tiny RTS game, even if it were implemented using DirectX on Windows. Instead, we are presented with libraries, code fragments, and demo apps.
The book could benefit from standard textbook fare: checklists, summaries, exercises, and the like. I find the index to be lacking. And although the author recommends Booch diagrams (forerunners of UML class diagrams) for understanding architecture, he only uses them twice, prefering instead to overwhelm the reader with source code.
Value
Is this book worth it? First, it's quite expensive. Although it is 700 pages long, much of that is padding. Really Chapters 15-19 are the meat of the book, and some of that information is available from other sources (eg, Game Developer articles and various web sites).
I've been extremely critical of this book, mostly because there are enough poor computer programming books without adding to their ranks, and enough excellent ones to serve as examples. Yet not all is marred. The book still has some excellent parts and good discussion. They are just overshadowed by its faults.
Unfortunately, this is the only book on real-time strategy game programming available. So, if you're really serious about programming such a beast, you'll probably want this book despite its shortcomings.
If you'd like to pick this book up, head over to Amazon.
TABLE OF CONTENTS
- Welcome
- Gameplay
- Getting Started on Your Game
- Documents
- Development
- Standard Macros and Data Types
- Background
- Great Ideas
- Working With DirectDraw
- How to Draw as Easy as 1, 2, 3
- How to do Your ABC's
- The Drawing Manager
- Loading Graphics
- The Black Space and the Wild Void of Life
- Animation
- The Landscape
- The Interface
- Objects and Creatures in the World
- Pathing
- DirectSound
The title of this book would catch my attention while browsing down the aisles at Barne's & Noble. But alas, experience tells me you'll never find a good game programming book at bookstores, until a real programmer puts something together and it published by O'Reilly.
Why would anyone want/need a book like this? Well first off, to save research time. If I had a reasonable book with at least abstract concepts of different pathfinding algorithms, details on their pros/cons, networking issues detailing pros/cons of how often to transmit a unit's current position, etc, I'd be a happy camper.
I played with a DirectX wrapper in Delphi once. I put together a terribly simple engine. You could click on a unit, move it around, but that was about it before I got busy doing other things. Sure Delphi isn't the mecca for gaming programming, but it taught me about the hassles with finding these sort of topics. After hours of perusing web pages, newsgroups, trying to remember/find notes from college classes that lightly touched these areas, I found the need for such a book is strong. It would be most prefferable if someone with a good bit of experience making a full game authored it as well.
Something like the reviewer mentions, a sort of college textbook on RTS game programming would be perfect. Present the material in a straightforward way, talking to intermediate/advanced programmers, delve into the beauty of a good algorithm and less into how-to-use-Visual-C++-for-dummies (redundant?) and it will sell 100 times what this book will ever sell.
They are thin, wrapper libraries that allow "cross-platform" development. They both appear to be relatively easy to use and offer differing feature sets (Different percieved needs for games development...). Give them a look-see and maybe you'll find what you're looking for.
URLs:
SDL - http://www.devolution.com/ ~slouken/projects/SDL/index.html
ClanLib - http://www.clanlib.org/
Keep in mind that these aren't your only options, there are others in varying levels of usefulness but these are the current front-runners that appear to be sticking out of the crowd (Cross-ELF/JUGL is one of the other libraries, allowing a unique ability- one main binary set for DOS, Windows, and X11 with a batch file to execute the loader engine for each platform. The main drawback to it is that it's poorly documented and fairly primitive.)
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Ability is good.
Documentation is good- sadly, you're going to really need it.
Usability, or rather, ease of use and low overhead is paramount for a good game. DirectX fails in this regard, making the task of writing a game unpleasant at best, untenable at it's worst.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
I've read a lot of game programming books over the years, and have yet to see one I would call "good", let alone "excellent". They all share the same small set of problems: out of date technologically, clumsy (or just plain wrong) code/solutions, poorly written. Not to sound cynical, but if the people who write game programming books were good enough to write real games, I suspect they would.
:), but you have to figure out how to make a game out of them yourself.
There are good books on networking technology (Tannenbaum), project structuring (Design Patterns, many others), 3D graphics (ask Rosenthal for recommendations here
Game programming under linux:
- use X, it's not that bad
- use Glide or GLX (or Mesa if you don't care about speed so much) for 3D.
I'm not sure how 'optimized' you want it...
OpenGL has an ancillary and auxillary set of libraries and APIs to deal with windows, menus, overlays, mouse, keyboard, controllers, etc.
It's the GLUT libraries, GL Utility Toolkit. I guess do a search for Mark Kilgard, or GLUT, or go to OpenGL.org.
They also have resources for game design, I think.
GL itself will only get you 2d and 3d output, you need other stuff for networking, sound, and UI. GLUT does the UI nicely, if not optimally. It's an introduction, at least, and it's very simple to use =) We had to crash course it and learn it and write a game in a week for our first Graphics homework assignment.
-AS
-AS
*Pikachu*
Input?
GLUT handles mouse, keyboard, trackball, stereoscopic glasses, menus, gloves, etc.
GL Utility Toolkit, not GL itself.
GL itself does fine for 2d, since 2d is really a subset of 3d.
GL itself is a low level API; iso-3d mode has to be done yourself, just as true 3d mode, or fisheye 3d modes...
IIRC, however, there are camera and perspective models that allow iso-3d transforms and manipulation, as well as true 3d perspective and transforms...
-AS
-AS
*Pikachu*
Ive been trying to make games for linux for a while
and basically have had major problems is what to do
input and output with.
Originally i used svgalib but after many people telling
me its dead, I searched around and switched to GGI
GGI is not too bad for graphics, but GII, ggis input
library is basically undocumented and unworkable.
Now im at the stage im at now- I need a good API to
program my game in, requiring full screen with mouse
I have tryed DGA but have not been able to find one scrap of info on it. Direct X 6 may suck etc etc... but at least they have a reasonable API for people new to game programming. BTW im not trying to bag out linux- it rules, just pointing out a major weakness.