Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Games Books Media Book Reviews Entertainment

Review:Real-Time Strategy Game Programming 82

Posted by Hemos from the making-games-better dept.
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
This discussion has been archived. No new comments can be posted.

Review:Real-Time Strategy Game Programming More

Review:Real-Time Strategy Game Programming

Comments Filter:
  • ClanLib [clanlib.org] is one gaming API. I haven't gotten to deep into it, but it looks promising. As with many OpenSource projects, the documentation on their web page is a bit lacking. They have the functions, but usually no description or only a few words on it; a tutorial or two using the functions would be handy.

    I start a week of vacation this week, I may just have to help them out with that.
  • I'd just like to say that this sort of review is very appreciated. Too many of the past reviews on Slashdot have been basically typing what's on the back of the book and table of contents with little review (of the sort, "This book has X, Y, Z" instead of an analysis of how well the describe X, Y, or Z).

    Thank you.
  • You are very welcome. :)

  • Re:The entire idea seems pointless to me. (Score:3)

    by whoop ( 194 ) on Thursday June 03, 1999 @05:44AM (#1868640) Homepage
    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.
  • Different person here...

    I can comment as far as DirectX 5, where (while I saw no problem with just DirectDraw) Direct3D was still horrid.

    (Btw, DirectX does exist in linux, through WINE... but I consider Crystal Space a far, far better high-level 3D API).
  • This is why I only criticized D3D above. Should I finish and port any graphics-intensive apps (not likely... Deadlines approaching, I wrote a text-based interface for the only one I had serious amounts of finished code on (the 3D usage was rather gratuitous, needless to say), and decided that it was better that way. Funny world, eh?) I'd use DirectDraw.

    Pardon my grammar, btw. English is not exactly structured the way I had it be if I had designed the language... ahh, well.
  • Posted by gamesgod:

    It also won't hurt in getting some industry experience. Like trying to get a job at a game company. Get to know other developers, make lots of friends and contacts. At some point your home project might become a published deal.
  • Don't get me wrong, I am interested in game design. I just expected a book more devoted to the *construction* of RTS games. As you pointed out, there are already several resources (eg, Game Developer post mortems) on the design of RTS games. But few on their construction.

    I am already fairly skilled at program design in general (patterns, architecture, etc.), and am in fact currently designing some systems at work in addition to my game at home.

    Design is incredibly important. But this book claims to be about "programming" which I believe is generally considered to mean lower-level implementation as opposed to "design", "analysis", etc.
  • No, thank you. I worked hard on that review and it is nice that it is appreciated.
  • I beg to differ.

    I have no problem with a game programming book being exclusively focused on DirectX, even if I don't use it personally. As I pointed out, I could always port such platform-dependent usage to a comparable API, such as OpenGL, if I wished. Or, I could just use the concepts expressed.

    However, a game programming book must be about game programming first.

    This book promised "RTS Game Programming *using* DirextX" but delivered several chapters just on DirectX.

    As a comparison, consider "Concurrent Programming in Java" which I previously reviewed. It is a book on concurrent programming which just happens to use Java as its implementation example language. It is *not* a book on Java programming.

    That is what I was expecting. Perhaps I was misled by the term "using" in the book's title.

    I think my point is valid.
  • That was one thing I forgot to mention in the review. The author says to get used to 80-hour weeks because that will happen for sure, and it is the only way to make a professional game. (paraphrased)

    McConnell is clear in Code Complete about such bullshit gonzo attitude.

    Maybe that's how the "primitives" do software development but I already quit one major software company because of that sort of perpetual "Red Queen" environment.

    The "gurus" know better, it's not like this stuff hasn't been written about since Brooks wrote The Mythical Man-Month.

  • I've made some comments in the threads. Some elaborate on points in the review, while others introduce other points I had forgotten to include in the review itself.

    The need for a good RTS game programming resource is clear. I have a web site devoted to that goal at http://www.cgocable.net/~mlepage/rts/

    I am *not* a professional game developer, though I *am* a professional developer. I am learning some of these game programming techniques from first principles, so in some ways I am far behind current technology (eg Age of Empires) but in others I am ahead (eg sound application of design patterns).

    Since my free time is divided between reading books, working on my game, and documenting on my web site, among non-computer-related pursuits, the work is slow. But check it out if you're interested in RTS game programming.
  • I'm glad you enjoyed the review.

    Your interpretation is correct. By all means provide your own memory management if necessary. Meyers and Stroustrup each provide a wealth of material on how to do it properly. And that way is to customize the new/delete operators. That's what they are there for.

    And you are correct, not everyone has to agree with my review. :-)
  • Unfortunately I don't have the book with me at the moment. The author is pretty fixated on performance, to the point where I would say it impedes with the pedagogical objectives of the book. In short, I want a book that teaches me (effectively) how to program RTS games. The examples need not be "the fastest possible" or indeed even "production performance class." That would typically interfere with the ability of the reader to learn from the book.

    The author can note that such code may not be fast enough for a production game, but explain the concepts used to rectify that, and leave the performance tuning as an exercise. I have enough books on efficient design and tuning code already.

    I don't need pages devoted to an assembly implementation or a "really clever implementation."

    I think if you follow the advice (mostly from Stroustrup and Meyers) at http://www.ses.com/~clarke/cpptips/perf_eff_opt then you can't go wrong.

    A similar pedagogical issue is all this "roll your own" container madness. I'd rather the book used the STL throughout, *even* if it were not suitable for a production version of the game (which I haven't had demonstrated to me yet). Then the author wouldn't have to introduce and explain his own containers and their usage: he could refer the "intermediate to advanced" reader to a good STL book. At least the STL is Standard.
  • What exactly is Windows-specific about my review?

    I reviewed the book. I am a Linux programmer. I am making a Linux RTS game at home. I program on Linux at work.

    I don't understand.
  • Actually there are links to several more RTS projects for Linux on my web page.
  • Leave the troll. It obviously never even read the review.
  • If you need sound, it doesn't help.
    If you need input, it doesn't help.
    If you need 2D or iso-3D (for things like Civ:CTP), it's inefficient and really gets in the way.

    No, OpenGL's only useful in the context of true 3D software.
  • What pirating? I didn't think we had that problem.
  • 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 [devolution.com]
    ClanLib - http://www.clanlib.org/ [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.)
  • 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'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.

    There are good books on networking technology (Tannenbaum), project structuring (Design Patterns, many others), 3D graphics (ask Rosenthal for recommendations here :), but you have to figure out how to make a game out of them yourself.

    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.
  • Sounds like it was written by a wannabee for wannabees. You want to learn DX6? Read the documentation. You want to write a RTS? The ai is the hard part, everything else is a piece of cake by comparison.

    Incidentally, I only know one coder here that buys games programming books, and I doubt he actually reads them.
  • How do you make that a hotlink? Check out http://www.w3.org/MarkUp/
  • OpenGL is not the best choice for 2d, it was designed for 3d and does not have much in the way of 2d features. But RTS games do not necessarily need to be 2d, Total Annihilation: Kingdoms [cavedog.com] is going to be a 3d-accelerated game, the units are all 3d objects in the origianl and the maps are 3d. (we might want to consider putting pressure on Cavedog [cavedog.com] for some Linux support, Total Annihilation [cavedog.com] is a great game and I always hate it that there not a Linux port) Another RTS game that I once saw a demo of was completely 3d (I forget the name of it, sorry). It used a diagonal view and all the units and buildings were full 3d objects (it was directx and I saw it running on a voodoo2, it looked very nice)

    So, it certainly is possible to use OpenGL to it's full power in a RTS game, and, I think at least, preferrable. I find 3d games are generally nicer than 2d games (not to say that there are no great 2d games out there, I love the civ series, even though I have not tried CTP yet, I am sure I will love it)
  • Is there any good sites on game programming under linux? I've found it hard to get beginner help on linux programming in general, so maybe I'm blind :)
  • excessive pirating? i think you might be mistaken. the game engines would be GPL'ed (very cool) & free, and you would pay for the content (the artwork, sound effects, levels)
  • Real-time strategy games are way too special for me as I have sunken years of my time (nevermind study!) programming RTS, making clones (full re-code with gfx ripped off of course) of Dune2 and C&C series in 1994-97. You can have all source (buggy not finished as I quit games programming once and forever) at my site.

    Point here is that DirectX for RTS is irrelevant. In fact most RTS use only fraction of it to just initialize screen and gain direct assess to video memory. There is NO need in it at all. My old DOS based code could be easily ported to it. I think the author uses DX as a buzz-word only. Besides, in my experience no generalized drivers are fast enough (unless hardware accelerated as 3D are)

    Dune32 shots/source [investigatio.com]

    Although in my view book is worthless (for me) I wish I had it back in 1994, when I had to do all these things on my own!

    However, as a humble person who was interviewed there [investigatio.com] and talked to some guys, I would caution those wannabes who think to make big $$$ in the Games industry. Those wonderful games such as DungeonKeeper, MagicCarpet et al, are not making much money! Problem is that it takes lots of time and enegry to produce a game, while sales are not high (piracy)! Cash-cows for such companies are sports-games, boring to program, but people buy them. So, if you think to make your life as a games progammer -- think twice. I personally changed my mind and going for an MBA. Although games programming (w/o books, when YOU do design things) is a good teacher.

    Projects I have been into are outdated now, some of the source was lots (stable one :( ) and all I have now is open for any crazy guy to lurk in. Don't think it's on much value though (except fast ASM). Peace, don't flame me too much, I am just a very tired games programmer who gave up his love.



    AtW,
    http://www.investigatio.com [investigatio.com]
  • Couple of comments...

    While focusing mainly on graphics, I found Michael Abrash's Graphics Programming Blackbook, (probably butchered his name and the book title sigh) an excellent resource for game design.

    Also, not sure how many people have played Dark Reign, but I'm very impressed with the game engine that Auran (http://www.auran.com/), and just how do I make that a hotlink?, designed for the game. They are currently working on their next engine for the Harn world.

    I don't know if they would be willing to offer any support, but it's worth asking.

    Another site/game you might look up is Omega Tank, this is a RTS game designed as a thesis project and looks to be a fairly good basic implementation of an RTS game. It still needs to be tweaked, but with a couple of freindly questions to the author I believe it might be possible to get a peek at his source code.

    On the gaming side, I'd suggest checking out Insomniax (http://www.insomniax.net/) There are a lot of good players there and some excellent resources as to what makes a good design.

    My site RTSG (http://www.rtsg.com/), Real-time Strategy Gaming, though sorely neglected also has a number of articles produced by the staff that might give help to game design.

    Anyway if you need assistance or advise drop me a line and I would be happy to give you pointers, but at the time have little time to actually show you implementation.

    Lando

  • Hmmm,
    Sorry but I cannot agree. The main reason of course is because I am a hard-core gamer. I don't play FPS much, prefering RTS games. The only reason I still have a Windows box around is to play games. So saying that games will die out under Linux is an alien thought to me.

    Your statement about copying program under Linux also need to be brought to light... Are you saying that just because the Linux community has the ability to copy games, that most of them will? Working as a computer professional, yes scary isn't it, I prefer spending money on games that are well developed, while it may be argued that sometimes games have perchance fallen to my grasp, any game that is well developed and worth playing I buy.

    Another point is that Linux is getting a great deal of press recently, we already have the basic apps that people need to use Linux full time, but we need games to provide entertainment to those out there that don't like playing with code.

    And what are you talking about Linux not matching DirectX??? It seems to me, going on rumor here, that Microsoft eventually threw in the towel and let game programers have direct access to the hardware because Microsoft could not write adequate drivers...

    It's my belief that open source is a lot more flexible and robust than closed source software all we really need is to get the hooks into the vender's drivers so that we can write the code to use the hardware, that's happening... I seem to recall TNT2 code being released within the last day or so.

    Hopefully, that explains why I feel you are wrong about the future of gaming under Linux.

    Lando
  • p241 K&R Ansi C:
    External identifiers that begin with an undersocre are reserved for use by the library [variables, functions, etc]. as are all other identifiers that begin with an underscore and an upper-case letter or another underscore [#define'd macros].

    More clearly:

    extern char * _some_buffer;

    and
    #define _A_something
    #define __other_macro

    are all 'reserved'

    whereas
    extern char * myvar;
    and
    #define _x_Macro

    would all be fair game for you to use in your program.

    So if I used 'header gaurds' of
    #ifndef _header_graphic_h_
    That's really just fine, but if I
    #ifndef __header
    or
    #ifndef _Header

    I may risk clashing with the C library, and I was warned.

    The idea that the complier could refuse the complie the code is silly of course ... It has to compile the C library doesn't it?

    --Shaun
  • I have a little C experience but for the most part I program perl. But with linux couldn't an API be created (similar to x windows) just for playing games? It could specialize in graphics and sound in 2D and 3D. Maybe even a virtual enviroment for the game to run. using a specialized engine would simplify game coding because you could use a standard library and it would be built from the start for high graphics loads. Glide, GFX, Mesa or any other driver set could be incorporated into it for the 3D to 2D conversion.
  • I would have to agree ... writing games isn't so different from writing some other program; you just use different libraries. Learn a programming language and how to write programs. Learn the libraries you might want to use.

    Please don't give me a "Game programming" book that introduces me to C and Windows and how to use a joystick. Give me a book that talks about game design -- what makes a game fun? What data structures and algorithms do games typically use? Why would you choose 2D over 3D or vice versa? What kinds of games are better as single-player? How do you write decent game AI?
  • I'll second the recommendation for "Death March". I picked it up during the time I worked at Konami. Because of the time I worked at Konami! And you know what? From what I gathered from the other developers who'd worked in other shops, the 80-hour week was the rule rather than the exception. I was called into my manager's office one day because he noticed I habitually left at 5pm, despite being on schedule. Sorry, I actually like my wife and kids. If I'm not behind, I'm going home to spend time with them.

    Welcome to game programming, where the motto is "Work harder, not smarter."
  • Well, if the rules for C++ coding are correctly stated (i.e., if this is actually how C++ code should be written), then games that are written should follow the rules. Actually, this might be a good test as to whether the rules are valid, a point that hasn't been proven to my satisfaction (although good arguments have been made for various of the specific rules).
    E.g.: was there a good reason for him to write his own memory allocator? If so, then *perhaps* the standard C++ approach is flawed. If not then his code is flawed. But this is subject to analysis, and saying it's against the "rules" don't answer. A working program is a test of the rules.
    OTOH, I'm not particularly interested in devoting myself to another proprietary library. Those things change or get dropped. I'm still recovering from the cyrogenic suspension of FoxPro.
  • 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
  • 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
  • I strongly recommend DeathMarch by Edward Yourdon. The full title is 'The Complete Software Developer's Guide to Surviving 'Mission Impossible' Projects".

    Yourdon has a lot to say about projects with impossible schedules, impossible
    deadlines, no budget, conflicting goals, and constant overtime.

    Constant 80-hour weeks aren't a sign of dedication; they're a sign of project managers who aren't doing their job.
  • I beg to differ. There is nothing inherent about Visual C++ which requires you to write the kind of crap c++ code the review talked about. I work with it daily and have used it to code ANSI Standard C++ programs many times (you know 'using namspace std' stuff?).

    Now if you mean relying on MFC (ARRGHH!!!) I can't help but agree with you. I try never to use that waste of disk space MS claims is a great OO class library! Even if I need to do Win32 stuff, I try to role my own class wappers because it reduces the overhead and I can use proper C++ constructs and style. But this has nothing to do with the development environment. Most of what the review speaks of seems to me to be a C convert to C++ still using the old bad habits (for C++ not C) of preprocessor directives everywhere and confusing a class with a struct. I suspect this same crap code could be written in Borland C++ Builder, Watcom C++ or whatever.

    This has more to do with a bad coder than a bad coding tool.

  • "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."

    Ok, I may be taking this out of context, or misinterpreting your point. But, isn't one of the most important aspects of writing a computer game, the written design? I've read several articles (Post Mortem) in Game Developer Mag. These articles are written by a game dev. after the release of their game, discussing problems and successes. More often than not, the authors have found that the lack of a thorough and concrete design had negatively impacted the development of their product. Sure it isn't something that seems fun when you love to code, but at some point you need to come to realize that you just can't sit down and "hack" things out.
    I, like you, do like to see implementation as part of my learning process. Infact, this is more lacking than books written on design. I was actually thinking about picking this book up when I saw it. I think I'll stay away from it, or just read it in my local library (aka Barnes & Noble ;-) ).

    Sixpack
  • >>I am already fairly skilled at program design in general (patterns, architecture, etc.), and am in fact currently designing some systems at work in addition to my game at home.

    Design is incredibly important. But this book claims to be about "programming" which I believe is generally considered to mean lower-level implementation as opposed to "design", "analysis", etc.
    >>

    Ok, now I understand where you're coming from and see your point. "Don't judge a book by its cover" takes on new meaning with programming books, I guess.

  • The time is right. The money for a commercial game these days is probably way undervalued, if you consider what goes into a game. And in some aspects, the money is not always spent evenly over the course of the game. Take Starcraft for instance. One person with 18 months of solid time could easily program the gameplay, graphics and AI. However, the cutscenes would take an order of magnitude more time to complete. That's where the money is getting spent. Starcraft's cutscenes are awesome to watch, but they're not the game itself, and Starcraft would be just as awesome without them.

    One of the biggest problems is that from a marketing standpoint, game players want the visual stimuli. They want full motion videos integrated into their video games. If the game doesn't come on at least 4 CD's, how good could it possibly be?
    Games need to more and more resemble real life. It needs to be fully 3D, with extremely realistic graphics, and of course it has to be fast, but if I need to upgrade to a platform that won't be available until next year to get what I want, so be it.

    The biggest issue with money is that someone who's programming a game and expects to get paid for it will see the money issue as an obstacle. You can program a game for free. Just sit down at your computer and start typeing. Just don't try to program Quake II on your first try or you'll be so overwhelmed that you'll get discouraged and quit.
    Start with something simple, even if its been done before. Program minesweeper and tetris. They won't make you any money, but you'll learn those valuable design skills.

    Then, once you've done that, aim for something simple, yet unique, even if it copies off an old trend. Try minesweeper 3D for instance, something that will require some creative layouts and will give you some practice with more advanced graphics programming.

    Once you feel ready to take a shot at AI, don't try to program the AI in starcraft. Program a checkers game. The rules are simple. When you want a more advanced challege, try chess. You might wonder how programming chess will help you when you want the computer to know when to move a marine from one corner of the map to the other. At least when you try to figure that out, you won't be struggling with the fundamentals.

    And don't forget the most important thing. Game programming isn't all about the graphics and the AI. Its about captivating your audience. It doesn't matter how elaborate your game design is, if the player gets bored with it after 10 minutes, then the game was a failure.

    Perhaps I have gotten off on a rant.

    -Restil
  • It's the classic mistake that all authors of game programming books make: they spend 75% of their time talking about C compilers, Windows programming, specific interfaces to joysticks and graphics and sound, and overly large utility classes. The author should have included a library to handle the system interfacing, briefly talked about it in one chapter, put the source code on the CD, and then focused on actual game design and programming issues. The end result would have been 100-150 pages of solid reading.

    I suppose a 700 page tome is considered more impressive.
  • From the review...
    The author employs leading underscores in his header guards (p121)
    Oh no. I do this in C, but I didn't know it was considered bad. Please enlighten me.
  • Thank's to everyone who replied.
    I appreciate it.
  • I didnt mean that linux users alone pirate software. I merely meant that with the pirating that happens in the computer world, the amount of linux users will not be able to support many computer games. I realize that my message made it sound like pirating was a linux only problem, but that was not my intention.
  • Programming in Linux?
    Dont know much about web site help, but the best
    book ever written for learning C IMAO is
    K&R C for yourself.
    It teaches basic C and has a chapter on the
    unix side of it.
    To learn linux programming is fairly tough when
    you have to teach yourself and i would recommend
    reading a non-platform specific C tutorial first.
    Wish you luck in your coding.
    Have fun.

    PenguinII
  • 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.
  • Hey, if writing a game was easy, everyone would be doing it.

    The fact of the matter is, you can't learn something as general as coding a complete game from start to finish from a book. There's just too much information to be read.

    In addition, games have historically pushed the technical envelope, code wise. It's not realistic to expect a book to give you inspiration for your next title. Quake was a huge hit, because the technology was so far ahead of everything else on the market at the time. There's no way the implementation could of come from a book.

    Books are a good way to get started. But don't expect to be the next ID if you can't come up with the radical designs on your own.

    Bughammer
  • There's more to DirectX than Direct3D ! DirectDraw is neat and fast for example.
  • I don't think the reviewer was against writing memory allocators, per see. I think he was objecting to the fact that the book author didn't integrate the memory allocator into new and delete. By overriding new and delete, as the reviewer suggested, you are in fact writing a new memory allocator (or at least customizing the standard one). But I have to admit, that part of the review confused me a bit.

    Some of the things the reviewer objected to (page long inline functions, premature optimizations that didn't achieve anything, etc.) really did sound remarkably stupid. What's the point of optimizing a structure from 16 to 13 bytes (to save 3 bytes!!! whoopee!!!), only to have the compiler pad it to 16 anyway? You've broken the "rules" (or, more accurately, the standard guidelines) and achieved absolutely nothing. You're code is more complicated and harder to follow, but you've gained nothing in efficiency. To quote Donald Knuth, "Premature optimization is the root of all evil." Coding like this is what gives C++ a bad name. Yes, it might (through some stroke of luck) still work, but what's the point? Why not code properly, make it work even better, and make the code more maintainable?

    I really, really liked this review. It was critical, and critics are supposed to be critical. Of course, some people my disagree with the reviewer, and that's valid too.

  • I had a similar problem when working on a fairly large-scale game for a software engineering class. I turned up, in my monumental search for the Perfect API, something called SDL, the Simple DirectMedia Layer. I can't attest to its flexibility or ease of use, since I didn't end up using it, but it boasts "portable low level access to a video framebuffer, audio output, mouse, and keyboard." It is LGPL'ed and impressively platform independent. But what I, or even its website [devolution.com], have to say is probably not so gleaming; Probably a more solid endorsement is the fact that Civ:CTP was written using it.

    Hope this helps,
    Dan

Slashdot Top Deals

A Fortran compiler is the hobgoblin of little minis.

Close