Status Report From the Open Source Games Community
qubodup writes "Free Gamer, an open source gaming blog, has recently become the center of open source artists, developers and gamers. In its forums, the GPU-hungry Classical Java RPG and the Neverball-killer irrlamb have found their second home. So did sub-communities like extremist free gamers, who insist on games not only be free software but also to contain free content and want to build a knowledge base of existing free games. There are also free content artists, which address an old problem of open source games and want to supply graphics and sound for projects in need of game media."
Avast, free and easy booty be the best kind of booty around, arrrr!!
wtf, zonk, you're supposed to be editing before you post. freegamer.net is obviously not an open source games blog. I think the submitter meant to link to http://freegamer.blogspot.com/. I have no clue how someone could screw that up though.
*crickets chirp*
Leave it to today's gamers to want "frustrating gameplay" as the Irrlamb site says. Neverball is the same way; more focus is put on trying to make the controls as difficult as possible to use.
This trend towards games with bad control and frustrating gameplay is just terrible. Back in my day, we called such games "bad".
If I develop a game, and I want to distribute it under a copyleft license, what license should I use? Due to the lack of a native file system implementation on some platforms, the code and its related assets (graphics, sound, maps, etc.) must be combined into one executable file, but the GNU licenses appear to require that a single executable file be distributed under a single license. Licenses based on the Creative Commons Attribution License ("CC-BY") are not intended for software; instead, Creative Commons recommends GNU licenses for software. However, the GNU software licenses are not compatible with any of the Creative Commons licenses. Section 4(a) of the Creative Commons Attribution License versions 2.5 and 3.0 allow a contributor to require that downstream distributors remove the contributor's copyright notice, but the GNU licenses do not allow the removal of copyright notices. Is there a way to solve this without having to track down every single artist on Wikimedia Commons individually and ask them for waivers of this requirement?
*by which a tumbleweed rolls*
these games *DIE* because the developers pick tools that nobody wants to maintain in the long run. Look at irrlamb: written in scons, needs boost. This is bound to die a quick death as a project. Java gaming? maybe, sure it is cross platform, but your app is horribly VM limited and performance will sucky no matter how you tweak. You kill your project and game by choosing the wrong development tools.
frozen-bubble keeps getting revived but in the end is not compileable with newer versions of SDL_perl. A tragedy, but I ain't gonna fix this, even if it won fancy awards.
the better the toolkit, the longer lived the project - look at the old quake engines...
I would donate plenty of money to anyone who picks a sane tookit to develop a 3D MMORPG that *encourages* development (no python, no boost, no java, plain autotools, C, no c++, SDL+GL, gtk+, no wx). Bring it on.
"I would donate plenty of money to anyone who picks a sane tookit to develop a 3D MMORPG that *encourages* development (no python, no boost, no java, plain autotools, C, no c++, SDL+GL, gtk+, no wx). Bring it on."
Nebula is a good basis for a game.
the practices you mentioned, would a typical hack or code-monkey have any inclination in applying them?
Granted, and such a person would run into problems in any programming language, which is what I was trying to say. The results might not be as insidious, but the problems would still exist.
I don't think the controls are what makes it hard. It's an interesting control method, sure, but once you get used to it, no harder than an FPS...
Consider an FPS, actually. You could have a game with really "easy" controls, like an auto-aim. We call that an aimbot, aka, CHEATING.
Or, you learn the controls you're given, and you find that it's not just the controls that make the game hard. It's the game itself -- in Neverball, it's the physics of momentum in a world where it's easy to fall off the edge.
By the way -- this is hardly new. A LOT of old games have much more frustrating gameplay. In general, it's arcade-style games anyway -- the idea, I guess, being that you'd lose, but you'd be SO close that you'd have to try again, so you'd put in more quarters. But it is actually fun -- the flipside of it being frustrating is, it's that much more rewarding to finally beat it.
I don't like the trend these days towards easier games, by the way -- towards games which have an "I can win" setting (even if I like that setting), which have like 5-10 hours of gameplay to make sure everyone can finish it (even if they don't really have the time to be playing games anyway), to the point where it's just not worth it to buy a game anymore, if you can rent a console game and finish it before you have to take it back.
Don't thank God, thank a doctor!
Java itself is open source, so you can tweak it if you have a problem.
Besides, this has been discussed to death, and I seem to remember the conclusion is that Java can be fast, and that most of the reasons people don't like it for game development are purely academic. For example, complaining about a "stop-the-world" garbage collector -- I believe newer VMs use a generational gc, and even if they didn't, it's still not a significant impact -- it's stopping the world for less than a frame.
So what's wrong with using an old version?
Yeah, let's go back to Quake, where they had to invent their own fucking C! Or maybe something like Unreal Tournament, which, to its latest version, has developed its own embedded scripting language.
The thing is, you're talking about reinventing the wheel for no apparent reason, and you seem to have arbitrarily selected which toolkits a project should use, and which it shouldn't. Yes, scons will be the death of the project! (Except it's just a build system, and Make isn't that good.)
Yeah, let's throw out Python and develop our own scripting language instead! Or better, use straight C!
I just love tracking down memory leaks. Let's do our own memory management, for no reason!
But, conversely, let's use GTK+ instead of rolling our own UI entirely in GL!
Look, I realize there are toolkits out there that suck. But that's no reason to throw the idea of a toolkit out, and just go with as bare-bones as you can get. And frankly, I'd be much more encouraged to develop a game that, say, embedded Python -- a game where I could actually have an eval loop when I hit tilde, and control much of the game from there.
Don't thank God, thank a doctor!
There is a nice effort going on the mentioned site (freegamer) and forum to unite the creative power of open source game development. Many new project could be created if a solid free licensed media library can be put together at such a place so that people with ideas are not left without the help of a community and precreated resources. It is just building up there by creative people who want to share their free game media, ideas and creative power.