Back in college when I first learned about Free Software (the term "Open Source" didn't exist way back then!), one of the things that drew me to it the most was the idea of Open Source games.
In fact I spent quite a bit of time myself tinkering open source game development of various sorts in those early years. I still do from time to time. But mostly I just think about how much better the current situation ought to be.
As many, many others have pointed out, games are a key need for Linux to succeed as a desktop operating system. I also suspect Open Source games in particular are going to be vital for ensuring the long term success of embedded Linux, since so many such systems include at least a few games and since the manufacturers aren't going to want to pay commercial licenses for them.
Unfortunately, in the Open Source development community game development seems to not be taken nearly as seriously as it is in the commercial world. Game development is sort of considered a hobby-time activity, or something newbie coders do to learn skills, before moving onto more important projects like the kernel, or a desktop environment, or whatever.
As a result of this, the FOSS game development communities haven't gained the wealth of shared libraries that has enabled other FOSS communities to flourish. There are some exceptions like SDL and pygame, but this barely scratches the surface of game development infrastructure we need.
Now, I'm not talking so much about low-level libraries like hardware abstraction or 3D rendering, but the next layer up - unit movement logic, combat algorithms, UI code, network layer management, and so on. The meaty bits that every game needs, yet gets custom reimplemented each time.
You can particularly detect this issue when looking at the successful open source game projects. By and large most of them are monolithic apps, sharing little or no code libraries (aside from SDL). I suspect a common reason for this to be that when person A starts hacking on a new game code, the last thing they want to think about is incorporating someone else's (likely incomplete) library - maybe it's ignorance, maybe lack of appreciation of the values of open source development, perhaps some not-invented-here-ishness, or the developer has some particulars about language, coding style, or whatnot. Whatever the case, assuming the game does get far enough along to attract other developers, inertia usually sets in to prevent the massive changes needed to create or incorporate a shared game library. Oh, and we can't forget about the most important bit - for many people it's just plain *fun* and satisfying to code these meaty bits yourself.
Of course, library development in general is quite tough, since it takes care in defining a good API and keeping it consistent from release to release. The oft-avoided chore of code documentation (and tutorials!) becomes a key necessity. The bug load can be higher, since the quantity and variety of use is wider and since the bugs themselves can be trickier to figure out. For the game developer, waiting for a library fix can take an excruciatingly long time.
Yet the lack of shared game libraries especially surfaces as a problem when looking at the many, many incomplete or out of date games out there. One game may have a great network layer, but the authors never got around to implementing AI code so it can only be played multi-player. Another has beautiful 3D graphics, but the game logic itself is rather anemic. Another has great gameplay, but the graphics appear to be from the year 1992. The problem exacerbates itself when the developer(s) inevitably move on to other more important projects, and if anyone remains to maintain the code, the work of updating and filling in the missing bits can be far beyond the time commitment available.
But now imagine if these games had been developed with modular libraries to share? With a shared network layer, all the games could benefit from security fixes, performance enhancements, and so on that future game developers may wish to add for their games. An AI library for 2D tile-based games could enable faster development of solo play of that class of games, covering well-known basics like shortest path algorithms, cost/benefit analysis, etc. Game UI libraries built atop SDL (sort of a gtk/qt of games?) with a flexible theming engine could make whipping up or improving game interfaces faster and easier to modernize down the road (esp. for small-resolution embedded devices, multi-head setups, and so on.)
Let's look at an example. Take FreeCiv and LGeneral, both long-standing successful open source game projects. Both are 2D-tile turn-based games written in C that deal with moving units around on a board, engaging in combat, etc. Under the hood, they both have similar data structures and algorithms, and often have identical concepts like hit points, movement points remaining, paths, combat odds, special unit powers, and so on.
Now imagine going through both codebases and extracting the core unit management code into a shareable library (let's call it libgamepiece). LGeneral has a pretty rich set of unit data, including supply, experience levels, and effects of weather on movement; good stuff! FreeCiv has a number of specialty functionality like being able to create cities, bribe other units, and so on. We'll probably want to adopt something like a mixin style approach, to provide a basic (efficient) core unit class, that can be extended for a particular game. Perhaps in our library we include some stock "snap in" bits like morale, unit grouping, and so on.
Now, getting LGeneral and FreeCiv to switch to this derived library is probably not in the cards - at least not in the near term. It's likely the library would have dropped specialized functionality that was too complicated to fit into the initial API, thus risking feature regression. As a new library, it would probably also have a number of new bugs, and established projects would (wisely) prefer to stick with their already proven code.
But instead, the new library would demonstrate its value for *new* games. Game developers wishing to make freeciv-like games would be able to start by building on top of this library rather than recoding all of that from scratch. Some developers might use the lib only for prototyping purposes, but ideally they'd be able to use it permanently, so as others add new features and fixes to the lib, many games would benefit as well.
We could also imagine going beyond code libraries to also include media libraries. In modern commercial games, the code "engine" is often the easy part (and often licensed from a vendor) - it's generating the masses of custom artwork, 3D models, music, sound effects, and so on that consumes the bulk of the budget. But why don't we leverage the power of open source here too? Principle unit artwork might be too game-specific to share, but terrain tiles, UI decorations, secondary units, sound effects, background music, and others could be quite amenable to sharing. Using de facto established standard data file formats alone could help a great deal here - simply copy the formats (and their corresponding data file handling code) from existing open source games, and you can reuse much of the graphical assets from them as well.
So imagine one day when Linux has access to a wealth of different special purpose game libraries. A game developer's work then becomes largely an integration task, at least to the first playable version, allowing them to focus on getting the new game concept right, not in reimplementing basic game coding work that's been done and redone time and time again.
Ultimately, this could translate into more (and better) games for Linux, making it more viable for both desktop and embedded uses. Who knows, if this were to really blossom, given the long shelf-life of open source games, Linux could one day become a *better* gaming platform in many respects than Windows.
good work