I usually just leave off commenting, but I personally don't think this is appropriate for this list.
Blog: http://random8.zenunit.com/ Twitter: http://twitter.com/random8r Learn: http://sensei.zenunit.com/ New video up now at http://sensei.zenunit.com/ real fastcgi rails deploy process! Check it out now! On 24/08/2011, at 2:38 PM, BGB <cr88...@gmail.com> wrote: > sorry, I don't know if anyone here will find any of this interesting. > > > I just recently ran across a project (Xonotic) which shows something > interesting: > Quake1 derived projects are apparently still ongoing, and managing to deliver > reasonably good looking games (sort of surprising, really, as I had thought > Quake1 had mostly petered out several years ago...). > > > this points out something: > the only "real" drawback of the Quake engine is mostly that it is GPL. > say, if one uses it, they are either stuck making a GPL'ed game, or having to > license an engine such as Source or idTech4 or similar, and possibly remake a > lot of their content to fit the engine (since these engines are not really > either particularly backwards compatible or cross-implementation compatible). > > I am almost left thinking that maybe something "sort of like the Quake > engine, but available under an MIT or BSD license" might be better, as then > one can use the same engine for both open-source and proprietary games. > > but, one can argue: > "but, hey, isn't the Linux kernel GPL, and people can use it for lots of > stuff?..." > but, this is partly because of an oddity of how the GPL is interpreted > (mostly by Torvalds and friends), namely that in this case, the GPL only > applies to the kernel itself, but not to anything run on top of the kernel > (this is a special case mostly for things like VM's and OS's, where the GPL > doesn't apply from one to the other). > > (also, a lot of what is done with the kernel in commercial settings involves > the use of loopholes, which I guess sort of puts the rage on RMS...). > > the problem though is that it doesn't likely apply to games, since a game can > be considered a "single program" (because it is generally all code in the > same process and often directly linked), meaning that the GPL would apply > itself to the entire work (unless of course, all of ones' content were purely > data-files and scripts, where the VM special case could apply). > > > well, my own project is sort of "Quake-like", but is not derived from the > engines' source. > I am almost left wondering if I should just release the whole damn thing as > MIT as, otherwise, I am not likely to really make any money off this, and my > engine is still "less good" than many of the modern Quake-engine variants > around. > > also, as has been mentioned before (on here, I think), my creative and > artistic skills are notably lame, which is a problem (this being a large > portion of a 3D game project). > > > BTW: if anyone wonders what my BGBScript language was mostly intended for, > the above is part of it (sort of, me and "goals" is a bit uncertain, but > game-scripting was a major potential usage domain, as was scripting for 3D > tools and similar). > > > but, yeah, it could all matter if, say, in the future game engines became > more like open platforms which people can build-on, rather than one-off > pieces of technology intended for delivering a particular game, and ideally > without the same level of vendor lock-in which has traditionally been the > case (or the need to license engines or pay royalties to deploy games or > stand-alone content for them...). > > > or such... > > > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
