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
Do you know this from experience, or are you simply echoing John Carmacks views of DirectX 2.0, circa 1996?
I echo some of the criticisms, but the book has some gems in it too. I personally appreciated the bresenhams code, also appreciated some of the general design chapters and sections on overdraw.
The biggest problem in my opinion is that mickey expects everyone to write age of empires. At a time when we are swamped with RTS games, we need innovation, not everyone using the same base classes. I think its worth pointing out that this is a games programming book, and often the way games coders code is not 'by-the-book' C++. I dont want lessons on C++, i want lessons on Game coding.
unfortunatly the bad form of the c++ source code that you mentioned is mostly the accepted way to program in visual c++, infact there are many aspects of visual c++ that actually discourages the proper programming techniques we have all learned.
:)
i suppose its yet another reason to hate microsoft
Getting good network code going is also pretty difficult when you start looking into prediction, and keeping the different gamers synched.
as for GII ...my guess is there is only one to
three people that submit any code for libggi code
as a developer why not work to help shape libgii ?
some common API I know.. sunsite.auc.dk/linuxgames
a. Crystal Space, Mesa3d
b. OpenPTC, Sprite32, AAlib
c. libggi, libgii, libggi2d, libggi3d, libggiw
d. Simple DirectMedia Layer, PLIB
e. alsalib, GSI, PSL
GlDrawPixels, GlCopyPixels, and GlReadPixels are all great for 2d graphics. They are simple to use, support many data formats, and can do blending and reformatting format in hardware.
What I got out of the book (at $60, sheesh) was
that if I wanted to make an RTS game, first I
would need at least 10^6 dollars and 18 months
at 80 hours a week, hire artists, etc. etc. I was hoping it would give me some steps that I could follow to make one myself.
Yes, there's nothing wrong with using X with MITSHM for
games with 2D graphics. That's what I'm using for my open-
source clone of Ultima7 (Exult), and the speed is fine. You do
have to write a layer of code to handle pixel manipulation at
different color depths, but then you end up with an API that
you have complete control and understanding of.
My experience for writing code for both Unix and Windows:
1. If you're good, you can quickly churn out code that
works fairly well for either platform, and there's no need to
work over-time to do it.
2. The final polishing and debugging for Unix goes fairly
smoothly.
3. The final polishing and debugging for Windows takes
forever, and that's where you get your 80-hour weeks.
And just because you have your code working great on
one version of Windows, that doesn't guarantee that it
will work at all on another.
Chapters 9, 10, 11, and 20 are fully DirectX specific. Chapters 12 through 14 cover additional graphics topics.
Chapter nine tells you (among other things) how to build a wrapper for DirectX. Most everything else (chp 10-14) works with blocks of memory representing 16bit images. Chapter 20 briefly covers playing sounds.
I personally found the Windows specific content fairly low. What he does cover, more "advanced" readers should surely be able to translate the content to "The UNIX Way". For example, the "highly windows specific chapter 17" is really only windows specific by it's inclusion of windows event handling -- which any advanced reader should have no trouble converting to corresponding Xlib concepts. Drawing parrallels between chp 20 and cat >
That said, most of the other complaints are legit. The code is really bad, yet the author is remarkably proud.
I'm working on a multiplayer/networked scortched-earth style artillery game (it'll be announced on freshmeat once it gets a little more playable) and I've been quite happy with GGI for graphics and input. Your problem with input is I think that you are trying to use libgii directly. You probably don't want to do this, rather you want to libggi functions on your visuals, such as ggiGetEvent(). Yes there is some confusion and it is a documentation issue, but really it's not that bad at all :)
A bigger problem for the end user is the lack things like sprites and shapes. Libggi2d is supposed to cover this as an extension but but I'm not sure if it is quite there yet. This isn't a deficientcy in libggi because it was intended as a low-level library and as such doesn't do all these fancy things, but rather provides an extension mechanism for libraries like libggi2d to hook into libggi and work with it. It's a quite powerful system actually, but not all done. I can attest though that if you don't mind having to do a bit of extra pixel twiddling here and there that even the base libggi API is _tons_ better than either svgalib or X for both output and input.
Most compilers support disabling of padding.
For example, gcc -fpack-struct will yield a 13 byte structure.
Possible performance penalty associated with using a structure of that size is another issue.
Perhaps the reviewer has a better example of premature optimizations from the text?
Slashdot used to be a place where people could be
free of Windows-only articles. Now one pops up
once a week.
Please send reviews like this to pc magazine or
someone else who cares.
Note to moderators: please give this a -1 score,
that's where the real discussion takes place,
anyway.
You aren't allowed to use underscores at the start of identifiers, struct names, typedefs, macro nmes, etc, in C. They are reserved for the implementation : i.e. the C compiler, the standard C library, and whatever over libraries are supplied as extensions.
Using macro names starting with _ is Undefined Behaviour, and a compiler is entitled to refuse to compile such code.
What's wrong with leading underscores in header guards? Is this something I shouldn't be doing?
there isn't one.
SDL has graphics/sounds/threading pretty solid...
things inside of it are still being moved around. go join the SDL mailing list
and help out if you want one to exist.
I hear clanlib is nice but its all C++ and err...
I've met this problem too and tried various ways: /dev/kmem rw access like DGA and I can use X events system istead of GII.. /dev/dsp locking. Maybe esound ?
XFree86's DGA. GGI and MITSHM (X Shared Images), and ended using MITSHM - it's fairly easy, doesn't needs
Dunno about sound - but we should standartize on something here - becouse of
If you want an implementation of a RTS for linux?
Look into ALE Clone you can lern many from it.
Thanks, I wasn't aware of that line. Next they're going to tell me I can't use this header guard as well??? ;)
#ifndef malloc
#define malloc
Anyways, is this 'standard' practice in C++ or has someone explicitly spelled this out this behavior in the ANSI C++ spec?
Tom
The design and programming of a game aren't necessarily done by the same people. Even if they are, there's no reason why a single book should attempt to cover every potentially related topic. If it's a book about DirectX, teach DirectX. If it's an RTS programming book, teach RTS programming. If it's an RTS design book, teach RTS design.
One reason why all the game developments books I've seen on the market are uniformly terrible is that they cover too much material thinly. Remember "Black Art of 3D Game Programming"? It's worthless because it covered almost nothing but DOS programming when it should have spent a reasonable amount of time on 3D-related topics.
[1] Bear in mind that the rules previously quoted for C do not apply to C++... I don't recall the details, but I do remember that any identifier containing "__" at any point is reserved for the standard library implementation in C++, while C only reserves those beginning with "__"
[2] malloc is ok, as I understand it, provided you do not included any standard headers that normally define malloc, since the compiler may choose to ignore your malloc macro/declaration in favor of its internal definition.
If you want more Linux, go to a linux web site. If this is supposed to be a tech news web site, it's already to biased towards Linux articles... More Windows, MacOS, etc would be welcome.
All of this is really interesting...
I'm looking for people who are actually interested in writing
such a game.
I'm writing one for the kde project. You'll be able to follow
development at this page :
http://www.ecoledoc.lip6.fr/~capricel/boson/
There is need for developers, graphisms, sounds, scenarist,
testerts...
This is not a Linux site, even though a lot of zealots reside here.
It is a nerd news site.
ClanLib 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.
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.
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.
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.
--
Marc A. Lepage
Software Developer
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.
--
Marc A. Lepage
Software Developer
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.
--
Marc A. Lepage
Software Developer
"Crime and punishment"
In Soviet Russia, Jesus asks: "What Would You Do?"
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.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
What pirating? I didn't think we had that problem.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
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.
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.
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 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 for some Linux support, Total Annihilation 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.
:( ) 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.
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
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 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
AtW,
http://www.investigatio.com
alexc
Join Majestic-12 Distributed Search Engine
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
/* TODO: Spawn child process, interest child in technology, have child write a new sig */
p241 K&R Ansi C:
... It has to compile the C library doesn't it?
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
--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'm a loner Dottie, a Rebel.
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."
Chelloveck
I give up on debugging. From now on, SIGSEGV is a feature.
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*
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.
"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
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.
I have seen so many replys complaining about how DirectX was used so intently in this book. If you wanted to read a book on linux programming, buy a book on linux programming. Game programming will not have a big market in linux for some time. A few companies such as Loki will exist fine for a while, but the market will dry up soon. With the excessive pirating and low number of users, linux games will never sell as much as windows games. That is why anyone serious about making money writing games will still be writing for windows for many years to come. And even though linux is a great operating system, its APIs do not yet match DirectX in ability or documentation. Its sad and it breaks my heart, but it is true.
-- All that is necessary for the triumph of evil is that good men do nothing. -- Edmund Burke
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.
-- All that is necessary for the triumph of evil is that good men do nothing. -- Edmund Burke
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.