Slashdot Mirror

New submitter rombust writes: Will ClanLib turn around the tides and finally challenge SDL? The latest 4.0 release already offers what Unity and the Unreal Engine charges 30% for, but now after 16 years of development, using only hobbyist developers, it will take on the giant of open source game SDKs! Dedication that's rarely found in the Open Source community without commercial backing.

Zangief asks: "Almost any gamer has, at some point, the idea of making their own game. I am no exception, so I've been playing around with SDL, which appears to be the logical decision over the craziness of DirectX. However I have also noticed that other alternatives, such as ClanLib. There is something else? Are there any other libraries, dev-kits, or tools that would be good for indie developers?"

Long-suffering Slashdot reader WrinkledShirt contributes this review of John Hall's Programming Linux Games, and lays out the good and the bad in a book that's one of the few of its kind. More games are always good -- hopefully books like this one will spark some inspiration.

Programming Linux Games author John Hall pages 415 publisher No Starch Press rating 7.5 reviewer WrinkledShirt ISBN 1-886411-49-2 summary Well-written guide to a wide range of game-writing tools for Linux, but not a definitive reference work for any single task.

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)

1. The Anatomy of a Game
2. Linux Development Tools
3. Linux Gaming APIs
4. Mastering SDL
5. Linux Audio Programming
6. Game Scripting Under Linux
7. Networked Gaming with Linux
8. Gaming with the Linux Console
9. Finishing Penguin Warrior
10. 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.

Denis Oliver Kropp writes "Yesterday was the release of the new ClanLib and of ClanBomber. ClanLib is a game SDK by ClanSoft (www.clanlib.org). ClanBomber is the first fully playable game that uses this API. It compiles under Linux and Win32, uses X11 or DirectX. ClanLib (and the game) even support joystick under both environments. ClanLib will support svgalib and GGI in the near future. Check out the screenshots at www.fischlustig.de/clanbomber "

Christian Reiniger of the new Linux Game Development Project has written up a nice piece that you might want to read if you want to see more games on Linux, and how this new project will aid that. The way I see it, the apps are coming, and in many cases, already here. We just need the games. The following was written by Slashdot Reader Christian Reiniger The Linux Game Development Center Rationale

Linux is gaining much attention these days. People who were anti-Linux for a long time suddenly discover that it has changed much the past few years, ultraconservative magazines feature positive stories about Linux at prominent places and The Big Ones in the computer business are almost crowding to support the former "hacker OS".

Good press is always welcome - but can Linux live up to its new image? Can it avoid to dissapoint the people finally giving it a try?

Well, the "It doesn't have a nice, easy to use desktop" and "There are no applications for it" arguments are vanishing in a puff of colorful smoke and the "It's too hard to install" problem is quietly dissolving. But there's still that nasty "But I can't play my favourite games in Linux!" thing.

Linux has games. Linux has good games. But that other operating system has several orders of magnitude more good games than Linux. That's bad. And difficult to overcome, as it's not only because of technical reasons. But we, the free software community, have have a long history of solving But we, the free software community, have have a long history of solving problems and shipping around obstacles. There is no reason why we should not be able to solve this issue, too.

So what's the current situation, what needs to be done and what can be done? Here is a short overview of the major issues:

• Despite Linux's rapid growth - both in terms of user base and existing software - it still is not generally perceived as viable platform for high quality games. Some of the often cited problems are without doubt true, but most of these are already at the verge of being solved and the others mainly need more public discussion.
• While many game-related SDKs and applications exist or are in the make, there is no comprehensive overview of them available.
• As all of these SDKs have their strengths and weaknesses, much can be gained by making them as modular and interoperable as possible, so that game developers can combine them to an almost optimal solution.
• For both commercial game developers wanting to port games to Linux and yet-inexperienced Open Source® developers aspiring to write free games, easy to read documentation and online help via mailing lists and/or irc are very valuable.

Quick Summary

In essence we are suggesting that this new Linux Game Development Center be a kind of meta-project. It would be dedicated to advocating Linux as gaming platform, collecting knowledge about Linux game development and using it to help all interested people, providing facilities for discussion to Linux game developers and, last but not least, encouraging and helping existing free (Open Source®) game SDK projects coordinate with one another.

Please note that this is not an attempt to impose standards or rules on anyone. We just want to do what we can to help everybody coordinate their project with the others and to encourage all game SDK developers to develop compatible libraries.

This is also a call for developers, users and game SDK projects to join our efforts.

History

In the beginning ... there were many unrelated games SDK projects started by many different groups with little or no inter-group communication or coordination.

The initial initiative of starting the Linux Game Development site came from Ian Crawford (you can read his announcement of the site here).

It was first meant as a meeting and coordination point for people developing native and free Linux games, but its scope was soon widened to support Linux game development in general - the phrase "This site aspires to be the headquarters for all Linux game development" is from that time.

Cut - Switch to the PenguinPlay mailing list. Shortly after Ian's announcement of the site, Sam Lantiga suggested on the PenguinPlay mailing list that people could get together on IRC to discuss the future of Linux game development. His idea was considered as "really good" and after the first meeting the thing was extended to all people involved in pushing game development for Linux. Here are the archives of past meetings and the plans for future ones.

Well, the irc meetings became a regular event (each Saturday) and the possibility to have a real-time discussion through irc gave a big push to our work. We started discussing on how we could coordinate our efforts better, how to make Linux more appealing to professional game developers etc. After a few meetings we came to the conclusion that it would be best to merge the SDK projects (ClanLib, CrystalSpace, GAMES and PenguinPlay) to one, giving it the full support. It seemed to be the right thing, but we were a bit uneasy with it, as merging projects is a very, very difficult task.

Then Charles Durst threw in an proposal for a clearing house project, i.e. a project that would give developers from different game SDK projects a good way to communicate with each other, remind these developers to keep the different SDKs compatible to each other etc. He first proposed that PenguinPlay could become this "meta-project", but we found Ian Crawford's "Linux Game Development Center" much more fitting.

We started working on the homepage for this and Charles wrote an announcement text we wanted to post on Slashdot or Freshmeat and several newsgroups. However, as we assembled material for the homepage, discussed its structure etc it slowly mutated from the "Linux Game SDK Coordination Center" to a site for Linux game development in general - the "Linux Game Development Center" or LGDC for short. Ian's original site laid the foundation for this (as it was aimed at helping people to develop actual games) and the transformation was completed when the "Linux Game Breeding (LGB)" (aimed at creation of new projects around Linux GameDev) and "Linux Gaming Awareness (LGA)" (aimed at advocating Linux to commercial game developers) projects joined in.

So here we are. The Linux Game Development Center is a project from Open Source® game developers, maintained by them and dedicated to all people interested in the subject. Located at www.linuxgames.org, it serves as a sister site to www.linuxgames.com, the already well-established site targeted towards game players.

The Proposal

The new Linux Game Development Center would:

• Maintain a collection of links to various game SDK projects and a "news page" of the current status and functionality of each.
• Help coordinate efforts to increase compatibility and perhaps create "glue" software between the libraries produced by different game SDK projects.
• Help game SDK developers coordinate with one another (via mailing lists and perhaps IRC get-togethers), and share algorithms and code. This could even help SDK developers abstract out new layers of common or overlapping functionality between projects.
• Help to fill the functionality gaps that are currently preventing any combination of game SDK libraries from being comprehensive enough for many professional game developers to use.
• Help to direct game developers to the right tools for their particular tasks. Making it easy to find software for a particular purpose, within certain platform, language or license requirements. We are considering using existing web-based knowledge base tools such as WikiWikiWeb or faq-o-matic, as well as tables of the features and limitations of each available package.
• Collect the general feedback that game developers might want to give the Linux community about any porting problems they might have. And helping to start, extend or fix projects to meet those needs.
• If neccessary initiate and host "please port this to Linux" petitions and mane the commercial game developers aware of the demand.
• Find volunteers willing to port commercial games to Linux and act as mediator between them and commercial game houses.
• Provide facilities for discussion between commercial game developers and Linux users on how support for Linux can be increased in the future.
• Help rally game SDK development efforts to port existing game libraries to needed, unsupported platforms.
• It could help direct interested people to other projects as needed to help with bugfixing, porting, and documentation (especially with respect to interoperability between projects).
• It could even have a relationship to game SDK projects and Open Source® games somewhat similar to the relationship Debian has with the packages that it collects. It could collect easy-to-find and easy-to-install packages of game SDKs and try to make it easy for a new developer to choose the one(s) that best meets their needs. It could even help develop policies to ensure clean interaction between libraries wanting to be added to the collection.

While game development for Linux would be an important goal of the web site, the most important goal would be the development of quality cross-platform game libraries. For that reason, developers of games and game SDKs for platforms other than Linux would be more than welcome to join us. Especially if they are interested in porting software to or from Linux.

In the end, there would still be multiple, competing game SDK packages, but that should be OK as long as at least one comprehensive open-source solution can be cobbled together from the pieces. As we have seen with multiple distributions, and even the KDE/GNOME projects, competition can sometimes be a very good thing ... if you can see past the flame wars.

The biggest problem with having multiple, competing projects is the resultant (developer and user) confusion. What we are proposing is a Linux Game Development Center that is aimed simply at reducing that confusion by helping people to find, evaluate, combine and use the available tools, or to develop new, missing ones.

Request

At this point, we are mainly looking for:

• More people to work on the web-site (in particular people who have ideas for ways we should do it with existing or new web server and/or database technologies).
• Other game SDK related projects that should be added, or who want to help, or who should at least join the linuxgames mailing list(s).
• Other Game or Game SDK developers who want to be in on the discussions, prioritizing, development, or who just want to influence the direction of the Linux Games project in one way or another.

All interested people are invited to join the linuxgames mailing list and participate in the discussions (send a blank message to linuxgames-subscribe@sunsite.auc.dk)

Current Linux Game Development Projects

These are the current Linux Game Development projects we have been able to locate and invite to participate. If your favorite project is not included, let us know and please join us.

• 3dfx HowTo
• ALSA - Advanced Linux Sound Architecture
• ClanLib
• CrystalSpace
• Daryll Strauss' Linux 3D page
• DUMB
• GAMES - GNU Animation Multimedia Entertain ment System
• GGI - General Graphics Interface
• GSI - General Sound Interface
• Linux game development webring
• Linux Game Programming HowTo
• Linux Game Programming Megasite
• Linux Game Tome
• LinuxGames.Com
• Mesa
• MGL
• PenguinPlay
• SDL - Simple DirectMedia Layer

Charles Durst, Christian Reiniger