Slashdot Mirror

Gamasutra's annual game developer salary survey will be coming to subscribers of the magazine in the next issue. As always, it looks at the current trends in payment for folks in the games industry, and some of that info is now available online. "According to the new survey, conducted in association with Audience Insights, the average salary in 2006 over all American game programmers was $80,886 - basically flat on the year before, thanks to an influx of entry level coders to the game business, but with significant increases for veteran programmers. The 2006 average for artists was $65,107, again basically flat on 2005, though average salaries of experienced lead artists and animators rose the most. The game designers' average was $61,538, with salaries scaling within a $5,000 range over the last 3 years over all experience levels." The new survey also marks the kickoff of Game Developer Research, a division aimed at doing quantitative analysis of games and gaming trends.

VonGuard writes "The Game is the title of an article I have up on the EastBayExpress site, and it's an inside look at 4orty2wo, the company behind ilovebees.com and the original ARG 'Who Killed Evan Chan?'. I also have an interview with the 4orty2wo folks in this month's Game Developer Magazine entitled 'Inside the Honeypot'. Read both carefully and you may find clues to a new ARG!" From the article: "One day last fall, Lenore Henry stood by a pay phone on San Francisco's Market Street. She cupped the thick black shell of the receiver to one ear and plugged the other with an errant finger to block out street noise. Behind her, a man clicked on a recording device and poked a microphone at the telephone mouthpiece. A familiar female voice was on the line. It wasn't a recorded voice as before. This one was live. It was 'the Melissa,' and Lenore needed to make it cry."

Winning one of the longer title awards, SEGV has returned with a review, this time of Mickey Kawick's Real Time Strategy Game Programming using MS DirectX 6. For those of you want to know how to program the next Warcraft or Age of Empires, click below. Real-Time Strategy Game Programming author Mickey Kawick pages publisher Wordware Publishing rating 6 reviewer SEGV ISBN 1-55622-644-6 summary Marred by lack of focus and inferior editing, this book is only for the serious RTS programmer who is willing to overlook its weaknesses.

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

1. Welcome
2. Gameplay
3. Getting Started on Your Game
4. Documents
5. Development
6. Standard Macros and Data Types
7. Background
8. Great Ideas
9. Working With DirectDraw
10. How to Draw as Easy as 1, 2, 3
11. How to do Your ABC's
12. The Drawing Manager
13. Loading Graphics
14. The Black Space and the Wild Void of Life
15. Animation
16. The Landscape
17. The Interface
18. Objects and Creatures in the World
19. Pathing
20. DirectSound

Stargazer writes "Scott Draeker, of Loki Entertainment Software (the company porting Civ3 to Linux if you haven't been paying attention) has an article featured in Game Developer Magazine (sorry, no online version). While most of the article focuses on the strengths of Linux, he does go into the power open-source can give to games -- namely, well-designed developer kits and the ability to modify the OS to the game's needs. Heavy stuff, considering all the craziness among distributions that could cause... " BTW, having recieved my copy of the beta for Civ:CFP. Wow. I'm salivating for the review/final version.

A while back there was an uproar when Dave Perry of Shiny Entertainment said he would patent the 3D algorithms used in his next game Messiah. Well... he got slammed by the games developing community, as he richly deserved. Many pointed out that not only were his techniques NOT novel, but also that his claim that "Patents are more universal and more respected than copyrights" did not hold water: only a few countries (US and Japan) allow the patenting of software. Anyway, the July print edition of Game Developer's Mag now reports that Dave Perry will not after all seek a patent.

On a more open note, 47-tek is releasing the source code to its game TEAM 47 GoMAN. It is Direct-X based, but there are tons of people trying to port Direct-X, for instance to GGI. From the features description, there seems to be some nifty code in there.