by date
Plan for Joshua Ritter
Plan for Joshua Ritter
| Name: | Prairie Games | ![]() |
|---|---|---|
| Date Posted: | Jun 10, 2003 | |
| Rating: | 4.0 out of 5 | |
| Public: | NO | |
| Comments: | YES | |
| RSS Feed: | or Subscribe with . | |
| Profile Page: | View profile page for Prairie Games |
Blog post
The GPL and independent game development
I have been meaning to write an essay on GPL code and independent game development. I guess I'll start with getting some ideas down + feedback in a GarageGames .plan.
Firstly, I want to clear up a major point of confusion: The GPL has nothing to do with commercial usage. It is a copyleft license that basically says, when you release a binary that contains GPL sources, you need to release all the sources that have been linked to create that binary. It is not a commercial license, as such it does not forbid commercial exploitation.
I have put a lot of thought into independent game making with the GPL. In many ways, independent games can uniquely benefit from GPL released code. I stress independent because major publishing houses will most likely fear the GPL, or could want you to combine your game with something like Gamespy. GPL and proprietary are incompatible.
Some points on making games under the GPL, please note the lack of religion:
1) Content doesn't fall under the GPL. This is the crux for games using the GPL to be commercially viable. It is also why games need to be viewed differently than other GPL products, where the source is the product.
2) Consumers don't care in any way, shape, or form that the source code for a game is available.
3) Only code for which a binary is released needs to follow the GPL. The entire tool-chain can remain closed source, etc. Lack of tools creates a significant barrier in generating a game's content. A k-rad "programmer" can't simply snag the code and make something that competes with your product.
4) Collaboration is much simplified from using code that requires a per coder license. Host a CVS on sourceforge, etc.
5) Security issues with multiplayer games exist. Password protected servers are a good option(play among friends)... as is cheat detection with banning on the server. The game sources to Quake III Arena and UT2003 are available, as are many other games. In many ways, having the sources available aids the community of your game to police itself. Server sources/rules for non-player hosted games can be kept closed source.
6) The copyright holder on any code can choose to relicense their original sources under a different license at any time. This doesn't retroactively remove the GPL from code already released under it. Though, the course can be changed. It is also possible to dual license sources, GPL + closed source option (usually for $$$).
7) You are free to use other GPL sources + any sources under a GPL compatible license.
8) Others have to live by the same rules you do... and if they have hangups about the GPL they'll skip right past your code. If they don't, more power to them, they still have to create a game + content, possibly without any tools. While, you are forging ahead making new games.
The choice for independent game developers isn't whether or not to use Open Source code. It's whether to use:
A) Proprietary code + open source licenses that are compatible
B) GPL code + open source licenses that are compatible
Of course this is all secondary to team formation and management... but that is another topic altogether.
-J
Firstly, I want to clear up a major point of confusion: The GPL has nothing to do with commercial usage. It is a copyleft license that basically says, when you release a binary that contains GPL sources, you need to release all the sources that have been linked to create that binary. It is not a commercial license, as such it does not forbid commercial exploitation.
I have put a lot of thought into independent game making with the GPL. In many ways, independent games can uniquely benefit from GPL released code. I stress independent because major publishing houses will most likely fear the GPL, or could want you to combine your game with something like Gamespy. GPL and proprietary are incompatible.
Some points on making games under the GPL, please note the lack of religion:
1) Content doesn't fall under the GPL. This is the crux for games using the GPL to be commercially viable. It is also why games need to be viewed differently than other GPL products, where the source is the product.
2) Consumers don't care in any way, shape, or form that the source code for a game is available.
3) Only code for which a binary is released needs to follow the GPL. The entire tool-chain can remain closed source, etc. Lack of tools creates a significant barrier in generating a game's content. A k-rad "programmer" can't simply snag the code and make something that competes with your product.
4) Collaboration is much simplified from using code that requires a per coder license. Host a CVS on sourceforge, etc.
5) Security issues with multiplayer games exist. Password protected servers are a good option(play among friends)... as is cheat detection with banning on the server. The game sources to Quake III Arena and UT2003 are available, as are many other games. In many ways, having the sources available aids the community of your game to police itself. Server sources/rules for non-player hosted games can be kept closed source.
6) The copyright holder on any code can choose to relicense their original sources under a different license at any time. This doesn't retroactively remove the GPL from code already released under it. Though, the course can be changed. It is also possible to dual license sources, GPL + closed source option (usually for $$$).
7) You are free to use other GPL sources + any sources under a GPL compatible license.
8) Others have to live by the same rules you do... and if they have hangups about the GPL they'll skip right past your code. If they don't, more power to them, they still have to create a game + content, possibly without any tools. While, you are forging ahead making new games.
The choice for independent game developers isn't whether or not to use Open Source code. It's whether to use:
A) Proprietary code + open source licenses that are compatible
B) GPL code + open source licenses that are compatible
Of course this is all secondary to team formation and management... but that is another topic altogether.
-J
Recent Blog Posts
| List: | 03/29/08 - TGEA 1.7 Build System and Embedded Python 03/14/08 - MegaTerrains - TGEA Update 01/18/08 - Minions of Mirth: Undead Wars Expansion 01/04/08 - Physics Overhaul - Video 12/26/07 - Web Integration - Video 12/21/07 - New MMO Client - Trees - Day/Night Video 12/18/07 - Minions of Mirth - 1.26 - Holiday Edition! 11/28/07 - TGB/TGEA integration first pass |
|---|
Submit your own resources!| Bill Bouma (Jun 10, 2003 at 21:17 GMT) |
#3. It is becomming common practice, and not a bad idea to release "mod" tools to extend the life of your game and get free content created.
So if you use GPL code it prohibits you from making a modable game.
Besides, it isn't all that difficult to make tools if you have the source that reads in and uses the results.
| Prairie Games (Jun 10, 2003 at 21:27 GMT) |
The point I was attempting to make is that you don't HAVE to release your tools. You certainly can if you wish to foster modding.
I agree with your statement about tools for simple translators, though many tools don't fall into this category. Take a look at the Quake3 level processing tools for instance, think about generating this work from the code that reads the results. Ouch.
-J
Edited on Jun 11, 2003 01:48 GMT
| Samo Korosec (Jun 11, 2003 at 11:02 GMT) |
For example, Blender is a GPL application. This means that the source for all parts of it have to be availible, lest they fall under the category of "system libraries" - like OpenGL or QuickTime. From what I know (at least how I understood Loic's explanations) is that also all software linked to it would have to be "open" - which is the reason LGPL came into being. I think the GPL even goes as far as demanding binarias that were created by GPL software to be GPL (there is a special case exception made for the GCC compiler suite).
For most projects, a BSD licence is more of an option, since it's really "free" and is more likely to have people use your code (and spread it that way). Dual licencing is an option, yet a somewhat complicated one.
Also the FSF does not consider (and is strictly against) art as GPL-able so the output of GPL-ed tools itself does not to be "open", since art is a "final product" and individual to each person and it would be unethical (and weird) to take someone's art, change it a bit and slap your copyright notice to it in addition to the author's one. The licence is code-only, which in turn means that a full gamedev suite under a GPL licence would not be as bad, since it's often the art/ideas behind it that cound, and you can certainly protect these.
| Prairie Games (Jun 11, 2003 at 16:49 GMT) |
The BSD license is great, though not all code is under it. There is some very good stuff under the GPL. I think the important thing to consider is how important is it to keep the sources for your released binaries closed. Some people may find it very important, I don't.
I am an independent developer, I don't have others making up my mind for me on the issue. Though, I also get on the shelf. I would love to use GPL sources for a retail product, there is some talk of doing just this. I will be plenty loud if it happens.
The main concern I think is that by releasing some code, it's going to make it very easy for someone to make a ripoff. I won't address this here as I get quite involved in my .plan. I don't believe this. I also don't believe all code should be free. I am not a commie. If it made economic sense for me to hold back my tool-chain, you are damned straight I would.
You could give away your entire codebase, as many people have... and watch as nobody does anything (substantial) with it... people are lazy. Code is work, even to understand. Why work when you can play?
Sure shots are the stuff of E3. It's about decisions. I have used my brain cells, to the best of my ability, to come up with what I believe to be reality.
-J
Edited on Jun 11, 2003 18:11 GMT
| Samo Korosec (Jun 11, 2003 at 18:26 GMT) |
I think with games it's a whole different than that with other software, since it's a lot of "art" involved. The thing that many people "forget" with GPL is that unless someone copies your game with simply better art in all departments it just doesn't make sense. But if it has a better story, better graphics and better cinematics it's not really the same game anymore - and for the artists it makes more sense to joing the GPL-ed project than to go with a rip-off.
I mean, if someone clones your game that uses GPL he ultimately (even if you have to go to court for that) has to give you back all the code improvements. So forking the code for the same kind of game doesn't make sense. Which leads (at least my with my thinking) to the conclusion that taking the GPL code of one game only makes sense if one wants to develop a different kind of game, but wants a functional framework for it. Even if it's a 1:1 copy with better art/effects/price there just so much more one has to consider (installed user base, people sticking to the "original", support, etc) that the success of a copy is not a given thing.
I think originality counts, make a game that's fun to play and people will love it and pay for it. It's the reason why people are chosing Mac (ease of use) or Linux (great for unix-style jobs, cheap) over Windows PCs, because each offers them something Windows doesn't. Look at Apple's iPod - just because Apple took the time to _think_ and come up with a nice concept they managed to make the arguably best mp3 player - using the same components everyone else had at hand. Only that most ofhers tought in the way of "Oh, ya, let's do the mp3 player thing, let's see what the others got and make something with a fancier color..". The same should be considered by game developers, as illustrated by the GG team and the Deer Hunter example. Think before you start, the rest is trivial after that. With GarageGames providing a distribution platform for indie game developers the question of GPL or not GPL is not that important.
But if someone wants to consider GPL (or similiar) as a licence, I can only advise to read up all the material, it can give you a lot of headaches later if you don't...
| Prairie Games (Jun 11, 2003 at 18:55 GMT) |
I've chosen GPL + other open source licenses for my independent work...
Proprietary is fine and dandy, there is just less of it, and smaller numbers of people working under a given source license. One or the other has to go as they are mutually exclusive.
The GPL enforces me to release code that I would likely be releasing anyway... and it opens up the option of using other GPL code. That isn't such a bad deal, you get stuff, by giving stuff. Your sources, your money, your time, whatever. What a planet!
Oh, and these ideas are pretty much geared for games... if your product is source code (an engine, whatever)... the ways I see the GPL working is via a dual license for people who want to keep their sources private(for $$$), charging for support, charging for custom code, etc
-J
Edited on Jun 11, 2003 21:12 GMT
| George McBay (Jun 12, 2003 at 04:53 GMT) |
That way people tend to contribute back to the core technology, but if they want to keep their game-specific logic to themselves, they can. And while I do think many (perhaps most) programmers are TOO sensitive about giving their code away, there are a few legitimate reasons why you might not want to release everything as GPL. As one example, it makes it a lot easier for griefers to cheat in multiplayer action games when everyone has full access to the source...
| Prairie Games (Jun 12, 2003 at 05:13 GMT) |
Griefers are a plague, source and no source. I agree with you though, source could make this easier. Play with friends, require email validation, etc. I think griefers, and the solution to them, is more than a tech/source issue.
Many AAA multiplayer games give away the game source for modders, and most come with a BAN feature :)
-J
| 0x336699 (Jun 13, 2003 at 02:27 GMT) |
Cube is an open source (zlib license) 3D multiplayer game that reminds me a little of Quake. Its author has an interesting solution to the problem of open source network games and cheating:
From the readme that comes with cube's source:
Quote:
If you release a cube based game with source code equivalent to the
binaries, some minor changes can give anyone an aimbot or other cheats
in online games. There are several ways to make this less easy, some
of which are:
1. only distribute binaries (the ZLIB license allows this).
Executables can still be hacked, but unless you have a really large
online community, noone will probably bother.
2. write a network proxy, such as qizmo used with QuakeWorld (whose
sources are also open source). The proxy is a small closed source
program that checksums the executable, and maybe also some game
media. You can then make servers or game admins request this
information and ban cheaters.
3. release the sources with an incompatible network protocol or other
changes compared to the binaries you release.
4. build serious cheat detection into the game. Since all clients are
their own "servers", you can make them all keep track of stats for
the other players, such as health etc. you can make all sorts of
consistency checks on shots, movement speed and items. If the
discrepancy for a certain client becomes too big, all clients but
the cheater can send their "vote" to the server for having him
banned. Even better, you can add server side stat checking.
For the cube's own game I chose option 3, i.e. you can only play the
official cube game using the binaries supplied by me, and you can't
compile your own clients for multiplayer use (you can still make
custom clients that work with matching custom servers, or play cube
single player maps compatible with the real thing). This situation is
not ideal, but there is no easy way around it.
This scheme is probably very easy to defeat if you are capable of
using disassemblers and packet sniffers, but please contrain yourself
and don't ruin the fun of the cube multiplayer community. Thanks.
Edited on Jun 13, 2003 02:41 GMT
You must be a member and be logged in to either append comments or rate this resource.



4.0 out of 5


