Open Source Game Development 147
Boudewijn Rempt writes "Amazon's recommendation system recommended me "Open Source Game
Development: Qt Games for KDE, PDA's and Windows" when I was looking
for an introduction to OpenGL. While it does contain two chapters on
OpenGL, there's much, much more. It's not just an introduction to writing
open source games, it's a complete introduction to participating in
open source projects like KDE." Read the rest of Boudewijn's review.
| Open Source Game Development: Qt Games for KDE, PDAs and Windows | |
| author | Martin Heni, Andreas Beckermann |
| pages | 554 |
| publisher | Charles River Media |
| rating | 8 |
| reviewer | Boudewijn Rempt |
| ISBN | 1-58450-406-4 |
| summary | Complete guide on writing small to medium games for Linux, Windows and PDA's using Qt. |
As maintainer of Krita, the KOffice paint application, I need to know about graphics. Unfortunately, the four months of retraining from sinologist to Oracle Forms developer that launched me into a life of coding didn't include anything on graphics, and certainly not on OpenGL. Which is very much where Krita 2.0 is going.
So... I was looking for an easy introduction to OpenGL to kind of ease my way into the Red and Orange books. And Amazon's weird recommendations system recommended Open Source Game Development: Qt Games for KDE, PDAs, and Windows by Martin Heni and Andreas Beckermann to me. Intrigued, I ordered the volume forthwith. Turns out that that was a good move: this is an excellent book.
In the first place, the text is very clear and concise, but never dry. Forget about the ho-ho-I'm-funny chatty style that's prevalent in many technical books. This book comes to the point immediately. Then, the information is carefully ordered and the presentation very neat and clear. Those would be good points for any book.
But what makes Open Source Game Development: Qt Games for KDE, PDAs, and Windows even more interesting is that it's much more than its title indicates. It is squarely intended at the hobby coder who wants to work on what the book calls "desktop games" -- not the multi-million dollar multimedia productions that demand a new graphics card every half year, but the games that you play while thinking out a knotty problem or that have some educational value for your kids. The kind of project a single coder, or a small team can complete and maintain while still staying sane. And, of course, that kind of game, defender or zaxxon-type games, maze games or tetris-style games work are perfectly suited for pda's and mobile phones, too,
Actually, this book is the perfect introduction to joining a big Open Source project I've seen. Of course, the focus is on Qt and KDE, which means that if you always had this itch to join KDE development but didn't have the necessary skills, this book will help you get there in a very pleasant way.
One way this is done, is by always first giving a general introduction to a topic, and then more detailed discussion in the next chapter. So, first we've got a very good "Qt Primer", and three chapters "KDE Game Development", "Qt Game Development Using Microsoft Windows" and "Game Development and PDA's". And there's a chapter on "OpenGL" in general, and then a chapter on "OpenGL with Qt".
The first part of the book deals with this type of introductory material. The second part discusses "Artificial Intelligence", "Pathfinding" (this chapter was a revelation to me -- I never understood how that worked. If only I had this information while trying to write games for my ZX Spectrum!), "Particle Effects" and "Math and Physics in Desktop Games". The material in these chapters is foreshadowed by the very first chapter "Introduction to Desktop Gaming", which deals with game balancing, architecture and the ins and outs of developing free software. Armed with these chapters, you can add enough game play to your games to make them satisfying to play.
The next three chapters discussion the Qt network classes and how to use them in your games, the KGame library (free software, of course), that contains a lot of boring groundwork that's the same for most games -- players, input devices, network stuff. For me personally, the "XML" chapter wasn't that useful, but then, I'm a corporate cubby-hole programmer by day, and XML is my bread and butter. It's amazing how many billable hours XML can add to a business application project.
A very important chapter, "Open Source and Intellectual Property Rights" makes it very clear what's allowed and what not. The summary chapter, "A Practical Summary" is a novel idea -- at least, I hadn't come across something like this before -- and it works quite well, tying all strands together. There are plenty of references to earlier chapters, so if works like a kind of hands-on index. Not that the actual index isn't top-notch, too.
I should make clear that this book is not just about coding for KDE. That's what most interesting to me, but if you want to code a game for Windows, for a Qtopia or Qt/Embedded environment, then this is the right book. After all, with the release of Qt4 under GPL for Windows (Qt was already released under GPL for X11 and OS X, as was Qtopia), Qt is a good choice for Windows hobby programmers. You get a high quality toolkit that really helps with the boring ground work, and excellent documentation. Coupled with the clear text in this book, there's nothing to hold you back.
Andreas Beckermann is the author of Boson, an OpenGL real-time strategy game based on Qt and KDE. His experience in working on Boson really is apparent in this book. Martin Heni has written a couple of games that that are in KDE's games pack, and has won a prize for his QTopia game Zauralign.
Oh, and the chapters on OpenGL and OpenGL with Qt were enough to make me understand the OpenGL Krita already has and did prepare me quite adequately for the big Red and Orange books. And I've got the itch to write a little game now..."
You can purchase Open Source Game Development: Qt Games for KDE, PDAs and Windows from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
You sold me :-) (Score:3, Interesting)
Thanks for an useful review.
Does it answer a really important question? (Score:5, Interesting)
Re:Does it answer a really important question? (Score:3, Interesting)
Making the game opensource does not supply people with the game content, only the engine code
Reason? (Score:4, Interesting)
I mean, besides of the OpenGL-QT bindings you will have to do (mostly just to create a GL window to render if it is similar to SDL) there is nothing magical in the GL-QT combination. I would recommend to get a nice KDE book AND a nice OpenGL book also, as the author said, besides the blue and red books (which I personally use just for reference . Another great book for OpenGl is the OpenGL Super Bible [Sams], and you can find a bunch of KDE books including the KDE Bible.
Of course if you want to go the "student" way, there is, as I have found, PLENTY of information on all of these topics. Just get into Gamedev.net, the Nehes tutorials are one of the best in my opinion.
Now, if looking for game development I would personally incline to SDL, which will provide you with almost everything you need like input support (joystick, mouse, etc), audio and also OpenGL.
As a last comment, could I ask the SlashDot editors do to their job and check (at least) the book reviews grammar/spelling. My native tongue is not English but it kind of hurted my eyes to read the review (which was quite nice anyway).
Re:Does it answer a really important question? (Score:3, Interesting)
This flies in the face of the Guild Wars model, but for the WoW model, where you pay for both the disc and the account, it can be amended so that for example, you are forced to buy a certain minimum of months of play.
In my uninformed opinion there really is no reason for paid-account MMORPGs to be closed source. They might say that it's to prevent cheating, but I say that open sourcing would kill cheating dead.
Re:Does it answer a really important question? (Score:4, Interesting)
Yeah, the buzzword makes sense for games too, a company could make a game and give away the code while maintaining a good online game community/forums etc. Setup some servers and go!
What I would do is making open source the client, keeping the server, then, let the community improve the client and I would improve the network infraestructure, of course with the client code it would be deadly easy to replicate the server, but there is where the company would have to provide some *special* value on its servers (something like Xbox Live community).
Re:I like CrystalSpace (Score:3, Interesting)
I tried some of the free engines including CrystalSpace, unfortunately (at least, last time I checked) there ARE NOT precompiled libraries or binaries of that library. I tried compiling it but I really got pissed off after two hours of trying so I threw it up.
The problem with the Open Source engines (at least in my experience) is that they are not readily available, as a game programmer, I do not need/care to compile the library nor to modify it, I am completely happy with a
3d engine resources (Score:3, Interesting)
I've recently took an intro course to GL and for a project written an MD3 (quake3 mesh animated model) renderer in Qt (bindings are easy and well documented with "Qt Assistant"). I've wanted to increase my knowledge of GL over the summer by building a relatively primitive rendering engine in C++, and perhaps evolving it over the course of the next few years. I'm considering starting with an importer for Quake3 maps (BSP trees). Ultimately I'd like to build something similar to (of course I'm sure much less advanced) that of the Irrlicht engine [sourceforge.net].
I've read through the Red Book [amazon.com] and have already bought the Superbible [amazon.com]. Has anyone any other resources which might help me design and build such a system?
A better one is Programming Linux Games, John Hall (Score:1, Interesting)
The author died recently (9th Month of 2005), and his page is still heldhttp://overcode.yak.net/ [yak.net]. To summarize his death, a new and unusual Mole formed on his shoulder and within a Year it spread cancer throughout his body and lymphnodes. He was dead in a Year! He was a great man that I participated with in the forums at LINUXGAMES.COM. His book is a good reference, but is since depricated by the slowling changing APIs. John is an ex-employee of when LOKI was in business.
Those doctors made his last Year of life a living hell with all the medication they gave him. Remember folks: Vitamin-C suffocates cancer; therefore, avoid the consumption foods and drinks known to deplete Vitam-C such as Alcohol-tainted water and animal-flesh and most medication (like Aspirin).
Re:Linux Games (SDL, OpenGL) (Score:3, Interesting)
I'm working on a couple of doom3 mods right now which more or less agrees with GP and disagrees with Parent. They're both single-player "total conversions", which require a significant amount of work from volunteers, since none of the assets from the original game will be used in the final product. They both use the "Walled Garden" as GP puts it: developers and content creators are welcome to join the project after demonstrating sufficent skill and motive. However, the source, and the content isn't open outside of the occasional media release we make to let people following the mod know that we are in fact still alive. I know for sure that when the games reach their "when it is done" state, we will make a source release along with the normal release of the games. I can't say what will become of the media for the game, since I'm not an artist. A condition of both projects is that artists have to basically "surrender" their rights to their work to the project, although some of us have made contracts that the game cannot go commercial without renegotiating the agreement.
However, the point I'm trying to make is that it seems some artists are in fact willing to donate their time, especially if they're trying to beef up a portfolio. Interestingly enough, both of the projects have a surplus of willing artists and a distinct lack of coders. [For interested coders (or artists I guess), see the end of this post for shameless plug]. Walled Garden doesn't work perfectly though, obviously. A huge downside to it is the sheer amount of time it takes to get anything done. Since everyone is working on a volunteer basis contributions trickle in slowly. A second problem is member turnover. Often times members will leave the team or simply go without communication for months on end, citing lack of progress, personal reasons, education, etc. It is very hard to keep volunteers motivated, especially on a project which progresses so slowly. OTOH, a leader may decide to keep a very small team of highly-dedicated volunteers and avoid the turnover problem, but then introduces that things get done that much slower since there are less people and the process is even more closed. Interestingly enough, both the projects I'm working on exibit each of these characteristics: one has the Cathedral-Garden and the other the Bazaar-Garden.
In this way I agree with the GP in that the so-called Walled Garden does work as a possible open source game development method. However, it does not work well. I'm not sure if there's a better organization method, but if anyone thinks of something I'd certainly like to know about it.
I agree and disagree with the parent. He claims that "In that way, open source will NEVER compete against the big studios. The only "hope" is to make people look at less "graphic intensive" but more "fun" and innovative games." I agree that open source games will not compete with game studios - in terms of timeline. I strongly believe that a group of skilled and motivated volunteers create a game which is just as more "innovative" and fun as any studio, but it will likely take them a significantly longer amount of time. In this respect I disagree with the parent. High quaility models, animations, textures, sounds, music, code, and others are not out of reach of a volunteer project, they just take longer to create, for the simple and obvious fact that people aren't being paid to do it.
If you're wondering why a single coder is working on two projects at the same time, the reason is simple: I noticed that both projects had a reasonable amount of overlap and decided to join both teams and develop the requirements of both games that were the same.
The two projects are:
Re:Stop Making Engines, Start Making Content (Score:3, Interesting)
Re:Linux Games (SDL, OpenGL) (Score:2, Interesting)
Even today, there are so [freeprogra...ources.com] many [garagegames.com] good 3d game [slashdot.org] engines- but very few games. Probably because people don't find it appealing enough to make the content.
* lon3st4r *
Sam's OpenGL Super Bible (Score:2, Interesting)
And while I'm posting (this doesn't happen often), I'd like to throw my two cents into the fountain of this Indie games debate. Good for you if you want to write a game, however... Do something new, do something creative, do something that you and your friends and family members and immediate contributors can realistically accomplish. And for the love of sanity, DO IT FOR FUN! If you're in it for money and it's not your full-time job, then don't bother.
Also, if you're a good programmer and find your game lacking content, consider procedural content. It really depends on the kind of game you're writing. The downside is that it can remove the beautiful, personal touch of human-generated content, and it is also very hard to do. The upshot is that if you really enjoy programming and are making your game for you own personal enjoyment, the challenge can be very exciting and entertaining. The second upshot is that procedural content when done well and applied to the right kind of game, can greatly add to replayability. This is the path that I've chosen for the game I'm writing right now (In-depth pausable real-time tactical starship combat). I'm having a blast!