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. "
Grr. Okay.
As an artist (written, visual, music, etc.), I feel that art should only be open if the artist wants it open, and I don't want most of what I do open. Do you want to know why?
Because I hate my job, and I love my art.
I am an artist because it makes me happy, and I work to pay the bills. They are NOT the same thing. Sorry. When I have enough money to not have to work and get any more money, then I'll give my stuff away. No problem. Maybe I'm too concerned about the real world of my life and those that are dependant on me. (shrug) Who knows? All I know is that I have obligations, and if I can get money from doing something I love and live in a fashion I like, I am sure as hell gonna do it.
Another point: I don't want everyone to have the PSD's of my photoshop editing because I don't want them to butcher it. I don't want it changed, because everything is there for a reason.
Art is NOT programming. It doesn't break. But there is a line here with levels for games (like quake or half-life). This is the hard part:
Is a level programming or art, or both? Can source be art? Can a program be art? I can answer the two of them as a "Yes" and one as "both."
But should it matter? In the long run? Really? All I am concerned about is my own ass and those around me. Sorry if that sounds selfish, but I don't like being poor.
Thanks for your time:
Dan
This is true for some games. Like stupid shooters and arcade ones that will be warezed anyway. But I'm more interested in simulations and rpg.
In the racing simulation domain, it's the support, the docs, and the engine who counts, but also what the users will do with it. For example, gp2, gplegends are 2 games that have been extensively upgraded by people who reversed engineered them to build new cars, new seasons, new tracks.
Had them been opensourced, this developpement would have been far more efficient, and it could have boosted the sales of a few games. (Especially since a few companies can't do everything an user can... like for example the company that brought us sports car gt and didn't implement extern car damages to not hurt manufacturers' image)
My point is that it is feasable for those kinds of games to exist, and be successful, even if they had been opensourced... as long as the support is sufficient and good.
. . . . . . .
may u!sh 2 sm!le at dz!z bad nn.!m!tat!ion
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
The first thing that catchs my attention in the article immediately turns me off to it:
... do not have support costs. Interoperability and reliability are irrelevant.
... and so on. For multiple months we attempted to install that version of the graphics runtime software, and even newer versions. In all cases, the install script never went farther in the process. When the company's support line was called, they said "oh, we don't see that problem here" and hung up!
[Games]
This two sentences have at least 3 inaccuracies as far as I am concerned...
1. Games do have support costs. Support costs include phone calls/email about how to play the game. They include revisions to the documentation. They include writing articles,
press releases, etc.
2. Interoperability is crucial! What good is a game designed to run on Linux if it doesn't work with the user's hard drive, or mouse, or joystick, or whatever? What good is it if the version of language runtime it uses interferes with the proper operation of the operating system? What good is it if it requires kernel changes that make the system unstable?
3. Reliablity is important. If the game crashes every time the user goes to save the game, or any time the user doesn't have a particular video card, then it doesn't get played.
A few years ago while visiting my in-laws I noticed my father-in-law had gotten a new program for kids to learn to read. The software company which created it is one which people have heard of - you might even have gone to see their new jungle based movie recently . Anyways, the packaging advertises that it ran on the machine my father-in-law had. It's memory and disk requirements were met by his machine. So we plugged it in and started thru the install steps. The software asked that a particular version of a graphics support library be installed. Neat, I thought, and clicked on the button to say "go ahead and install that version". The install script did. Then we start thru the install script again. Again we are prompted to install the particular version
Clearly, if we had access to the source, we could have fixed the problem and continued. Instead, he was out the cost of the software (because of course, once you've opened the software package, it can't be taken back...)
URL: http://xanga.com/lvirden > Quote: Saving the world before bedtime. Even if explicitly stated to the contrary, n
I guess that depends on your definition of spectacular. Spectacular to look at or spectacular successes. Games like nethack were a spectacular success when they came out, other games like nettrek/xpilot/freeciv and muds etc have been spectacular successes in that people still play them, even many years after they originally appeared (though they have gradually evolved over time).
Yes the engine isn't everything, but neither is the art - it's the 'gameplay'. This is hard to define but definately largely involves how the game engine responds to the player - from speed, to ironing out annoying bugs/network problems, to the interface design. At the end of the day it comes down to the skill of the programmer. Great looking games that are irritating to play are ... irritating - not fun.
I think the author makes some valid points but takes it a little too far. I'm not saying a 'precompetitive' engine wouldn't be a good thing.
It's very easy to think up the storyline to the greatest 3D first person RPG - to think of this feature and that, it's very hard to program the game so that the player interacts with the world in what feels a natural way for anything other than running around and shooting. This (IMO) is the next great challenge and it's essentially a programming one (as you have to implement all your ideas in the end) and cutting edge games will need to employ cutting edge programmers
I may be a cynic but I would suspect that the game industry prefers to produce 'consumable' games with low replay value rather than long lasting games because it can then sell more - built in obselence. I think the sort of games you find made on the internet (see above) are more of the 'slow burn' variety - but they are games nevertheless and successful at that.
Gab
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 think part of the misconception here is that the game company would spend years developing the game engine in a closed area and then free it to everyone. This isn't what is intended by the Bazaar model. However, it's probably what that company's lawyers would tell them :). The idea would be to be open from the near-beginning. Get a game engine going, help work on it, make it GPL. If most 3D gaming companies worked on one excellent GPL'd rendering engine, then the variety in games would be in the artistic quality and gameplay. Yes, art should be art. Art has always been seen as valuable in society. Art sometimes requires no effort but is still valued because of esthetics. A GPL'd game engine may use non GPL'd levels, artwork, music, game theory, etc. Game companies would be rated on creativity, not who had the money to license Carmack's latest engine ($500,000 US).
- Michael T. Babcock (Yes, I blog)
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
The article misses the boat and makes wrong assumptions in more places than I have time to list. Other posters here touch upon many of those wrong assumptions, so I'd like to throw out a curve ball instead. Follow my imaginary conversation for a minute.
Me: Open Source would be a very, very bad thing for multiplayer gaming.
Idealist: Whoah Dude.. How could that be?
Me: Simple. Too many people would cheat when they play.
Idealist: No Dude. Most people always play fair.
Me: Come closer.
Idealist: (Walks over closer to me)
Me: (smacks idealist across skull with a crowbar, breaking bones)
Idealist: (In pain) Dude... Why did you do that?
Me: Because I could... and I'll do anything to defeat you. You trusted me. You lose.
A dirty little truth about Multiplayer games is that if they are even remotely popular, an incredible amount of effort goes into hacking the games so a player can cheat or have some sort of advantage. The first day a game is available, there'll be some users putting it under the microscope, analyzing every byte of every network packet, testing dynamic modifications, and seeing what happens. Save game files will be dumped and examined. Process Memory Space will be scanned relentlessly and the object code reverse engineered.
And the result? Reduced playing experience and enjoyment for everyone.
If you give people access to the source code, It will only happen quicker, be more insidious, and more widespread. Most popular games get their executable code hacked sooner than later. With the source code, hackers won't be limited to patching existing code in place; they'll be able to add and expand the code!
Oh, and please don't start in "But there'll be other people who'll fix the source code so it'll be secure." Please spare me. It's perfectly possible for my client to convince your client that I am secure and compatible, while it runs my special build of the game. There are a lot of things I can do that'll never see. Play any RTS games? How about removing the fog-of-war? Adding an AI extension to make my units dodge whenever a missile is target at them? But I made it look like I just can click the mouse really, really fast! And how was I to know that's where your secret base was? Luck guess I guess...
And don't say that a Client-Server model where only the client code is released is the fix to it all. It ain't. People like to tell me that Quake II and Half-life are secure if the server is secure. Not true. Where there is a will, people find a way to cheat. Ever heard of zBot? It's a little proxy that sits between you and the Quake/HL server. The server tells you the location of everyone while your client handles changing directions and issuing commands. It can see that you just issued a weapon fire command, and that nothing is in your current line of fire, so hey, why not insert a command packet saying you are now pointing straight at this guy over here... That's why packet encryption is in there and has to get updated. (/Sarcasm on) Give me the source code and I don't need to break your stinking encryption - the client has to decrypt it before it can use it, and I got the source... hehehe.. Your ass is mine now! Boy, I'll bet you will really enjoy playing online with me and my hax0r buddies. It'll be a great and enjoyable experience for you. (/sarcasm mode off)
Commercial games have had to go to great lengths (and many patches) to combat cheating. With open source games, if you have to release the source to the anti-cheat efforts, then why bother?
And why would I know anything about this? It's what I do for a living...