Slashdot Mirror
Programming Linux Games
Introduction
The potential for linux gaming has really exploded in the last couple of years. In many cases, the potential has been realized -- Unreal Tournament, SimCity 3000, Tribes 2, Quake 3, Alpha Centauri, and many other successful Windows titles, have all been brought to Linux, with Loki leading the charge. Judging by the bottom line, there's a definite shortage of true cash-cow success stories in this enigmatic part of the industry, and hence, a shortage of good reference material for naive people hoping to produce that next cash cow.
However, we've reached such a point of critical mass of knowledge and technology that books had to start appearing sometime. So, despite the fact that there's no overwhelming market demand for Linux games and a high ratio of hobbyists to dedicated game developers for the OS, here we have a book aiming at taking amateur Linux game development to the next level.
However, much of the technology out there for game programming in Linux is still heavily in development, with many of the APIs and libraries still a long way away from a 1.0 release. Allegro and Clanlib are a couple of exceptions to this trend -- both are popular APIs that sadly don't get much more than a passing mention in the book. Their sexier counterpart, Sam Lantinga's SDL, gets a fair amount of treatment (no surprise there, considering John Hall was the lead author for a team based within Loki) -- but even this fairly feature-complete library, which Loki uses to port its games over from Windows, isn't explored in its entirety.
Instead, there are also crash courses in BSD sockets, package management, TCL, the framebuffer and various sound APIs, and what we end up with here is the consummate cookbook, a jack-of-all-trades-and-master-of-none tome that introduces us to a wide variety of Linux gaming topics while stopping short of being a definitive reference for any of them. Such is John Hall's work, an interesting, wide-ranging introduction to game programming for an operating system that few believed was capable of it not too long ago.
John Hall, an experienced game developer, participated in Loki's Civilization, Call to Power game hack, and is currently working for Treyarch developing that company's Spider-Man title for the PS2.
The Good
As far as cookbooks go, this is a good one, and there isn't much concerning Linux game API programming that isn't touched on. There's an ongoing case study (Penguin Warrior) that is developed over the course of the book. Each chapter introduces a fairly deep concept, gives a decent function reference related to the concept, then incorporates the knowledge into proof-of-concept code, and then uses the new-found knowledge to enrich the case study. The tone is straightforward and the execution is solid. The final game works well enough to give confidence that the reader could take the knowledge in this book and apply it to his or her own project, either to add new features or re-think old ones.
The book is also well-written -- the sample code is extremely well-commented and good error-handling is in place. He makes no assumptions about the knowledge of the reader, dealing with such introductory topics in Linux programming as vi vs Emacs, the FSH and make, although he never gets annoying or patronizing. *cough cough* LaMothe *cough*
Individual chapters stand out as being great introductory resources for material that doesn't have much in the way of documentation. The important aspects of SDL get good treatment in one complete and comprehensive unit. There's also a thorough chapter on audio programming, comparing and contrasting OpenAL, OSS, ALSA, Ogg Vorbis, and ESD (among others), and all this after showing off SDL's sound capabilities one chapter earlier. Many of the pitfalls associated with each of the different technologies, as well as the pitfalls of sound programming in general, are covered here. It's a great jumping-off point for those who don't know much about the audio end of things.
There's even a really neat chapter on incorporating TCL script interpretation within a program written in C. For anyone who's had trouble throwing together their own text parser for initialization scripts, or who's fed up with the constant recompiles needed when tweaking for the most arbitrary of changes of the game's AI, the information in this chapter is a godsend. In the Penguin Warrior case study, it's almost spooky how effective TCL turns out to be in making the computer ship chase and evade the human player.
Finally, I want to reiterate the effective use of the case study, Penguin Warrior. Having seen the way other game programming texts handle using samples to illustrate game programming concepts -- which is often a mish-mash, to say the least -- the way this book approached the issue is refreshing: there's one major project, and each chapter brings us closer to that project's completion. The code works as intended and goes a long way to convince the reader that the libraries and techniques explored in this book are near-commercial-level quality. (Networked games turned out to be choppy on my machine, but that was the only real black mark I could find in the program's execution.) If nothing else, John Hall deserves a good deal of thanks for proving that game development on Linux is a realistic and rewarding endeavor.
The Not So Good
At times, the generalist nature of the book left me wondering if Hall couldn't have gone just a little bit further in some of the topics. There's a decent enough synopsis about deployment using Loki's install tool, as well as packaging in general, although nothing related to the Penguin Warrior game itself, so we don't get to see the theory in practice as much as it could have been. Also, he teases us by early on by starting with the compiler, moving to the make utility, talking a bit about package management, and then mentions automake, but he stops short of really explaining how to bring that into an existing project. Considering all the fun little dependencies needed for multimedia programming in Linux, this would have been a valuable bit of information for anyone not used to deploying on the platform.
Another instance of this so-close-yet-so-far approach occurs when he talks about incorporating Mesa into an SDL program. He tantalizes us with a code sample illustrating how to use the SDL as a replacement for glut, but that's all -- the material doesn't really get deep enough to convince readers that a 3D neophyte really can abandon glut for the SDL, particularly when many OpenGL reference materials out there rely heavily on glut as a teaching aid for windowing and other utility functions. Loki primarily used SDL to handle its 3D utility programming, so at least we know it's possible, but given the exploding popularity of 3D games it's too bad this wasn't covered more.
It's sometimes hard to tell exactly who the book is intended for. The introductory chapters include discussions on topics such as the different gaming genres out there, despite the fact that game programming hopefuls who don't know that Quake is a first-person shooter must make up a really narrow audience. Also, it's almost enough to give one whiplash to see how quickly he dives into using ioctl() when only a couple of chapters earlier he was explaining the basics of using gcc. Next up soon after that? Strap yourself in, we'll be writing straight to /dev/fb0! It's almost comical to think about how much dangerous knowledge a newbie's been given over the course of the book. Still, like I said earlier, he never talks down to the reader, who because of this might feel compelled against better judgement to be whisked along into subject matter that really needs other support material to be of any real use.
Hall's a humble enough guy, which is great insofar as writing style is concerned, but in one of the last chapters, he starts questioning some of the choices he made while coding Penguin Warrior throughout the book. Specifically, he says he probably should have used C++ instead of C, Scheme instead of TCL, and UDP instead of TCP for the networking, and this is cold comfort for people who would have hoped that the author would have picked the best plan of attack from the beginning. That said, C, TCL, and TCP are appropriate choices due to the simplicity of execution and the fact that they introduce useful techniques from a design point of view. Still, there's no point giving readers a sense of wistful "What if?" if you don't have to. It also highlights that this book is more a beginner's API reference than a game programming book per se.
To take that point further, there also really isn't much in the way of abstract game programming theory. This book could have really distinguished itself as special if some content related strictly to game development was here. There's a mention of Gamasutra here, a method of quick division there, the equation of a distance from a point to a line thrown into the mix, and that's pretty much all there is. Topics not really covered include optimization, pathfinding, and cracker-proofing your code, and what is talked about on the subjects of artificial intelligence design, collision detection, and physics is all rudimentary ... For coverage on these sorts of topics, you'll have to look elsewhere.
Finally, and this is really not the fault of the author or the book, but one wonders if the time was right for much of this material -- or, at the very least, its highly generalist approach. DRI is making its presence felt, the various audio APIs out there are improving all the time, and the LSB is coming along nicely, but until there's a proven and stable multimedia base to work from, no definitive guide can be written, and this sort of organized dogpile is really the best we can hope for with so much stuff to cover. The SDL is a top-notch library for graphics programming, and it's likely an entire book could have been spent strictly on graphics programming using it, and the depth that such a book could have attained far surpasses what we're given here. Plus, in a year from now, who knows where any of these sound APIs will be? Of course, these might prove to be just esoteric issues in the grand scheme of this book.
Conclusion
Despite the criticisms I have of this book, I really don't want the message that is conveyed here to be anything but positive. There's a lot working for this book -- the chapters on SDL, sound programming and incorporating TCL and C are excellent, and will be especially helpful for people who are novices in these areas. Considering the alternatives (hitting dryly-written online docs or constantly shaking your Google to see what falls out), this book is a very attractive option. Programming a fully-functional multiplayer game would probably require more effort than might be suggested by the brevity of the chapter on socket programming, but that chapter is a solid introduction as well. The book as a whole is well-written and succeeds for the most part in its endeavor to make the best of a chaotic situation. I'd recommend this book to anybody who appreciates the messy-kitchen style of learning, or to anyone with decent hacking skills who just needs to break the ice when it comes to the Linux game APIs. And even though it gets slightly schizophrenic in its attempt to be both an introductory text and a definitive reference, this is the sort of book that could kickstart a new movement in Linux game development.
Table of Contents (exploded version here)
- The Anatomy of a Game
- Linux Development Tools
- Linux Gaming APIs
- Mastering SDL
- Linux Audio Programming
- Game Scripting Under Linux
- Networked Gaming with Linux
- Gaming with the Linux Console
- Finishing Penguin Warrior
- To Every Man a Linux Distribution
- Glossary of Terms
- Bibliography
Related Links
Sample Code
No Starch Press
Loki
SDL (List of SDL games)
OpenAL
DRI
Mesa
libsndfile
Gamasutra
You can purchase this book from Fatbrain.
why not write some freaking games? Duh.
EVERY single time gaming on Linux comes up we have everyone post about how easy it is to program for Windows and how much more difficult it is to program for Linux.
.02
Until there is some sort of Linux-DX package I really don't see gamers/coders switching over to Linux. Q3 failed pretty bad (mostly due to Linux gamers grabbing the Windows version AFAIK), Loki is going under (Warez, non-interest, etc), and the fact that 3D is a pain in the ass plus all the other problems.
I am glad that someone spent the time to try and teach others but I doubt that there is a large group seriously interested in it.
Just my worthless
Really if you look back, Windows gaming didn't really explode until DirectX was forced upon the world. I remember all the retching and such, but honestly it really stabilized the gaming industry on the PC - ONCE it stabilized itself.
If Linux really wants to move forward with it then I see a few choices.
1. Write a call level capatible equivalent to DX
2. Write an API with official support of the kernel managing group.
then again, perhaps they should leave the games to Microsoft and try to be all the business they can be.
* Winners compare their achievements to their goals, losers compare theirs to that of others.
I am wondering... almost all real games available on Linux are ported (no, I do not mean those games like Tetris, Othello or GNU-chess). Only a few ones are Linux only. What are the chances of developing Linux games and hope that they will run fast and well on Windows, the main market? The problem is that if your games cannot be sold to a sufficient number of people, the game company cannot be sustained for very long.
¦ ©® ±
I bought this book and have thoroghly enjoyed it. As a rather introductory C programmer, I found it to be a helpful reference to general programing techniques with an emphasis on games. I think that this is aimed at the introductory-intermediate crowd and is basically a primer to game programming rather than a complete reference.
Again, I liked the book, but it is one that serious game programmers will probably find less than helpful.
LedgerSMB: Open source Accounting/ERP
Even though SDL and GLUT are different things, I think SDL is a better choice. Comparison of some feaures:
SDL:
1. Direct framebuffers (as opposed to pure OpenGL)
2. OpenGL
3. Timers (realtime systems)
4. Sound (but external sound systems can be used)
GLUT:
1. OpenGL
2. Timers?? (probably)
Direct framebuffers and sounds don't belong to GLUT.
SDL combines different features into a nice packet while still allowing use of external resources. GLUT forces system to be purely OpenGL based, while SDL also allows using direct framebuffers. You can use external sound systems with both of them. I don't know about timers in GLUT, but at least SDL has them (I like them in SDL!).
Great and everything but you need Artists to make the 3D Graphics for the game, etc. The question should be. What should the Linux OS do to attract artists?
I read a "sneak peak" of this book which John sent me as a PDF. It was good, and I'll probably buy a hard-copy. SDL has very fragmented and confusing documentation, this book shows some good examples of how to actually USE sdl for your applications.. which can be assisted by the official SDL documentation.
One major flaw of this book, as of the copy I recieved over 6months ago, is that all the examples assume the developer is using a little-endian processor. I do the majority of my programming on PowerPC and was sorely dismayed by this.
The review stated that the book didn't go into much detail or specifics, but was more of a general overview of theory and practicum with a case-study of implementation...
:) What a great move eh? =)
Exactly what BEGINNING or aspiring if you will,
programmers NEED to develop their knowledge base.
ALSO!!! This sets the man up for a sequel...or someone else who knows the specifics and detailed aspects of the APIs etc...thus he gets royalties on TWO book
Personally I feel he should hook up with RedHat or Suse(take your pick of Linux Dist.) and bundle his book with their packaged products =)
*shrugs* Just a thought.
--Huck
"Just Smile and Nod." --Huck
To some extent, this is already the case.
1. Minor quirks aside, OpenGL is the same on any platform. OpenGL games can usually be ported to Linux with relatively little effort. Although GL has recently lost some ground to Direct3D, hopefully the OpenGL 1.3 specification will improve its acceptance (1.3 was intended specifically to make GL's model of operation more compatible with Direct3D).
2. DRM (support for DRI (3D acceleration)) and fbdev are accepted kernel-level interfaces. You really don't WANT something like SDL or DX in the kernel -- that's just bad design. Much better to use the kernel for minimal hardware interfacing code and leave the rest to userspace, which is exactly what DRI and SDL do.
There's really nothing stopping anyone from implementing a DX-compatible API for Linux on top of the provided kernel services, and in fact WINE is working on just that. I'd rather use SDL myself, though; it's simpler and much lighter than DX, and still has just about everything you need for game programming.
Linux will never be a better Windows than Windows, nor do I think our role as developers should be reduced to simply trying to copy MS. We can do better, even if it means breaking compatibility.
For the record, SDL is a highly portable API. It works on Windows, Mac OS (incl. OS X), BeOS, and just about every modern UNIX.
-John
If someone really wants Game Programming Theory, they can find it elsewhere or even within themselves. This is a fairly wide-open topic, and a deeper coverage of these topics might have been interesting, but in the end, it would have made this book less focused on the main objective of this book: To show people how to program games in the context of Linux
The first two chapters were exactly perfect for me. I've done some programming with Python and some other higher level languages, but much of the way Linux and GCC were organized just sort of mystified me. So, even though Hall says that he doesn't mean to provide a tutorial, the walkthrough of using gcc, ar, creating makefiles, cvs, etc. was just the right amount of information so that I could understand what's been going on all this time. The problem with many of the other manuals for this sort of thing suffer from two problems: 1. They provide too much information (the gcc info entries) and 2. they only provide information on a specific tool, they don't wrap it all together.
:) But I wish I had seen the introductory chapters 6 months ago, it would have saved me a lot of frustrating headaches.
As far as the games/SDL part of the book, I don't have much to add since I haven't gotten that far yet
Bryon
microsoftword.mp3 - it doesn't care that they're not words...
I'm almost certain that this John Hall isn't the same guy as John "Maddog" Hall. Am I right?
If you celebrate Xmas, befriend me (538
WrinkledShirt reviewing a book from No Starch Press?
/. book review to shamelessly promote your product."
Come on now. Not that it's not a good book, it may be, but let's have reviewers without a vested interest, so as not to give the "impression of impropriety", or should I say the "impression of using a
"I don't know half of you half as well as I should like, and I like less than half of you half as well as you deserve."
People may post that, but they're wrong. The ONLY reason there are more Windows games is that more people are paid to develop those games. And the only reason for that is that there are more Windows users.
I've been a professional game developer for over ten years. I've programmed DOS, Windows, N64, Dreamcast, and Playstation 2. I've used DirectX for many years. Through all of this, my complaint about game programming has always been: the tools are horrible! And DirectX (although it's a million times better in its recent incarnations) is no exception to this. Writing games is fun _despite_ the tools, not because of them.
Recently I had the oportunity to use SDL. It took me less than five minutes to have a program running which displayed a 24-bit BMP, full screen, on my Linux box. About fifteen minutes later, I had put together a small Tetris clone. I was stunned. SDL rocks the hell out of anything I have used on any other platform - and that includes five years of developing on Windows, and using the $20,000 Sony PS2 dev kit.
Best of all, SDL is portable to all other UNIXes, Windows, BeOS, MacOS 9, and Mac OS X. I can't vouch for how well it works on those other platforms, but if it's as easy as I suspect, then any game developer should be in heaven using it.
So perhaps by saying "there is no DirectX equivilent" you mean to say that "there is no graphics/input/sound/3D toolkit for Linux which sucks balls"?
This book is very good in my opinoin. It is a complete guide to developing linux games. It also discusses important multimedia toolkits (including a very interesting discussion of the Simple DirectMedia Layer) and teaches the basics of linux game programming. Many books don not take about this. You can learn about the linux gaming world, and how to write and distribute Linux games to the Linux gaming community.
Diplomacy is the art of letting people have your way
You can buy this at a reduced price from Tux Games
Tux Games. Your complete source for native Linux games.
And thought it was really good.
All the detail you need is out there on the web, but often, the detail is not what you need.. you need a broader overview, and a reasonably complete, heavily documented example so you can make your own decisions and avoid the obvious problems.
And thats exactly what 'Programming Linux Games' provides.
I recommend this book to anyone looking at doing games or multimedia programming under linux, and the chapters on sound are particularly interesting.
I gots ta ding a ding dang my dang a long ling long