Slashdot Mirror
How to Mix Open Source and Games
MikeDartt writes "Linux Today has an excellent article on how to best mix game creation with open source software and the Bazaar model of development. In short, the author looks at why games are different from other pieces of software, and suggests that the technical aspects of the game (engine, modeler, scripting language, etc.) be OSS, with the proprietary/differentiating focus on design and art. "
Several things about this article left a bad taste in my mouth. The author (Hargreaves) attempts to sterotype game programmers and game programming. Hargreaves claims that all game programmers:
1. Don't care about quality, only ego.
2. Produce poor, quick, hackey code.
3. Don't understand scripting languages.
4. Are less usefull than Artists/Designers
He also goes on to say that
5. 3d engines are trivial to program.
Although these stereotypes may exist in the game programmer community, I believe that this is a romantisized view and is not grounded in reality. Here are my rebuttles.
1 and 2. If game programmers didn't care about quality, then most of the titles that ship wouldn't have the level of polish that they do. When you buy a game off the shelf at best buy, take it home, and play it, you usually don't have to worry about whether you have the correct libraries or fear that it will crash. Also, if game programmers produce such low quality code, why is 3d engine licensing so prevalant? Not just Id, but also Unreal, Monolith and friends.
3. At GDC this year, there were several talks about scripting languages that I found quite interesting. Nihilistic is using an embedded java interpreter for their scripting language. Why would the open source community be better at this?
4. There are plenty of titles out there with bad art that are still a lot of fun to play. I wouldn't say that nettrek or xpilot have particularly good art, but a lot of people find these games more fun than the latest stylized buggy games. Programmers are just as important if not more because they implement, rather than simply adding spice.
5. If 3d engines were trivial to develop, why is the industry in a licensing frenzy? Please remember that 3d engine != 3d API. An engine has much more responsibility than simple triangle texture mapping.
Finally, I don't see how such a money driven industry can profit from open source. RAD and other companies like it make all of there money licensing game engine utilities, and would have no source of income if they opensourced their products.
--Tom
I maintain an ancient but popular free game named Omega (see my web page). When I took over maintainance, it have been almost five years since the last substantive change.
;-).
A comabination of bad code, almost superb design, and bad licence had killed it. The design was so good that any programmer who started working with it was immediately tempted to upgrade all the code to fit it (an unrewarding task which caused every one of them to give up almost immediately), and the license not only stated that no money could be made on it, but also forbade the distribution of modifications without the author's permission.
The first thing I did was rewrite the UI for the inventory (it'd been a sore point for everyone; hard to learn and hard to use). I showed that to the author and the current maintainer; the maintainer gave me permission to take over, and the author gave me permission to change the license. Working with him, I chose the LGPL, modified to fit the needs of an expandible game (more on this later).
In just a couple of days, I started recieving offers of help from people who had been working on Omega for all those years. The sheer volume of fixed code was almost incredible. Even when I was drawn aside for several months by my work schedule, their work proceeded. If code had been money, my investment in the inventory code would have paid off hundredfold
I credit this partially to the resumption of development on a formerly-thought-dead project (which isn't something most people have an option for), but also to the change in license.
The license fits my idea of gaming. Specifically, I wanted the game to be free, but at the same time I also wanted it to have secrets -- as this article points out. So I started by defining the terms of the LGPL. In my game's context, I defined the "library" (the part protected by the viral clauses) to be the engine, the entire part written in C, plus all of the original game no matter what language. In other words, there's no way to keep a secret that's already out, and I wanted to make sure that a fully playable game was always freely available. I then defined the "application" -- the completely unprotected part -- as being add-on modules.
I haven't finished the licence, nor have I linked Python into Omega. Once I finish the second I'll be able to define the terms I need to make sure the original game remains free and my secrets remain protected.
One other interesting thing I'm doing is adding a cheat mode and relatively strong anti-crack to the savefiles. I want to discourage people from cracking any part of the game for the purpose of cheating, so I'm making cheating legit, and making the only penalty being that all cheaters get moved onto a "cheater's hiscores" list so that they don't get in the way of the legit players. I'm not sure how this will work, but we'll see.
-Billy
You all know that ID, and John Carmack in particular, is a large supporter of OSS. Nevertheless they keep their games proprietary. Why? Well, simple. IMHO, OSS and games don't mix.
Allow me to elaborate. OSS model works very well for software that can be maintained and improved *over time* by different people. An operating system and lots of utilities fall under this category. However, games are generally played for a (relatively) short time and then abandoned in favour of newer games. For example, ID released Doom code, but how many people are gonna play it now that Q1 and Q2 are out and Q3 is on its way?
With OSS, you give away the software for free and make money on support. Works great for operating systems. Doesn't work at all for games.
As for the game engine being free and the art & design proprietary - that's a valid point. But consider this: ID has sold Q1 and Q2 game engines to several other companies which then developed their own 3d shooters based on ID's engine. Do you think they'd be able to make money by selling the game engine had it been OSS? How many companies need support to go with it?
___
If you think big enough, you'll never have to do it.
I have a few objections to the essay...
1. A lot of us don't look for flash and novelty in our games as the definition of fun. Some of us will go play Half-Life at a friend's house for half an hour because he just got a Voodoo3 and wanted to show off, and then go home and play Nethack. And enjoy the latter more. Look at today's slashdot article on the Pac Man high score for lots of discussions on "classic" video games. On the other hand, many people *do* look for flash, so I can't fault him on this one.
2. The author seemed to think that stability in games is nothing more than a nice perq, saying that an annoying bug in a game will simply cause you to return the game and never buy from that company again. IMHO, it must not be a very engaging game, if you give it up for a bug and don't lament it. The games that are worth playing, you'll play despite the bugs (and home the company releases a patch). I don't know how many times I screamed in irritation after hours of Alpha Centauri (yes, I admit it, I play games on Win98. I'll go cower in shame for daring to say that on slashdot, I promise) on Iron Man mode (no saving in exchange for 2x score) only to have an invalid page fault pop up during the computer's turn. Yet I go back and play it again because it's *fun*. It's engaging...Engrossing...It may not be the flashiest thing in the world (and, indeed, the graphics are often quoted as the worst aspect of SMAC) but the gameplay is enjoyable, and the replay value is very high.
I think I had a few more, but I can't remember...Overall, it was a well-written essay.
I think the Bazaar method of software developement for games could work, but we have to change a couple underlying assumptions first. The first step is to get beyond the mass-produced crap stage we are at now. The others follow....
I think OSS for games would work something like the way Quake has developed, from Wolf 3-d to Doom to Qauke 1,2,3. Each step is really the same game just taken to a new level. I disagree that we need a constantly revolving buffet of games. I am most happy when I really get to sink my teeth into a game and get to knows its most intimate secrets. Having to shift from shallow game to shallow game (at $50 a pop) gets old rather quickly.
An Open(tm?) game would just continue to evolve over time. You only have to cover three or four genres and then work to make it customizable over those areas. I'm thinking...Real-Time-Strategy (Starcraft), First Person Shooter (Quake), Godsim (Civ,CTP/Alpha Centauri) and of course an RPG.
Just have one extremely customizable game for each genre (remember how the author mentioned that the themes were more important than the file selection system, we have experience with themes) and then improve on it. Networking would be a big issue (multi-player is how games "should" be played), but sprites, stats, and behavious could all be easily customizable. It would be a larger undertaking, but I think it could have the significance of a GNOME or KDE for the community (i.e. open it up to a larger audience).
I think there would be value in selling the "distro" (a la Redhat) as it were, if it included all the tools and various "live" games. From that mythical Open 3-d Studio (which I'd like to see) to the network code, to hackable examples for each genre. I would buy it.
I think it's silly to dismiss a possible future of free/open games. With all it's pitfalls, it does have that magic dust that works in the free software community, it's SEXY, baby!!
(Disclaimer: the above opinions are from a hard-core gamer,i.e. would rather game than code, or much else(99 out of a 100) so take it with a bit of salt)
+&x