I've been thinking about the discussion from the last IRC meeting, and I wanted run a couple of ideas by you in private rather than sending them to the whole list and risk being flamed for them. [Note: Of course I asked him before posting]
Perhaps the whole question of what to call the Unified Linux Games Project should simply be bypassed as follows (even though it would mean altering the purpose of PenguinPlay significantly).
As described on the PenguinPlay web page:
The goal of the PenguinPlay GSDK project, is to provide the best working environment to create and port game and multimedia applications to the Unix like operating systems.
As described in Adrian's Overview attachment [Note: he refers to a draft of a new PenguinPlay design overview document]:
The PenuginPlay project is an attempt at creating a free (open source), comprehensive, cross platform toolkit for developing games and other multimedia software. Our goal is to make it easy to produce a broad variety of high quality games and deploy them across platforms. (While our primary development platform is Intel based Linux, we indend to port to other Unices and Win32. DOS, MacOS and Beos are possible too).
What I'm suggesting is to change this purpose to something more along the lines of:
The goal of the PenguinPlay project is to act as a clearing house for information and free (open source) software to support creation of comprehensive, cross-platform toolkits for developing games and other multimedia software.
The idea being that PenguinPlay would not be the name of ONE comprehensive toolkit, but rather the name of a project to:
In essence I suppose I'm suggesting that PenguinPlay become more of a meta-project. Kind of like Debian is in relation to the packages it collects. Encouraging the development of free tools. Collecting easy-to-find and easy-to-install packages of game SDKs and trying to make it easy for a new developer to choose the one(s) that best meets their needs. Helping with bugfixing, porting, and documentation (especially w.r.t. interoperability between projects). Perhaps even helping develop policies to ensure clean interaction between libraries wanting to be added to the collection.
As for the current PenguinPlay sub-projects, you could either "spin them off" and just treat them as any other projects would be treated, or contribute them to other teams. It might even be possible for PP to keep them and consider them "glue" or "alternatives" -- as long as they didn't get any sort of preferential treatment in the project listings. (These listings would have to be open, honest, and accurate representations of the current state and usefulness of each project.)
If adopted, this idea would completely remove the question of whether to rename ClanLib or other packages. It would remove a lot of the political problems involved in the appearance of coming in and "taking over" control of existing projects.
PP could still encourage a joining of existing projects if it makes sense to the participants (e.g. pp2d, GAMES, SDL etc.), but the end result would not be considered the "one true" GSDK, but just another library to be considered by game developers looking for tools.
In the end, there would still be multiple, competing packages, but that's OK as long as at least one comprehensive open-source solution can be cobbled together from the pieces. As we have seen with multiple distributions, and even the KDE/GNOME projects, competition can sometimes be a very good thing ... if you can see past the flame wars.
The biggest problem with having multiple, competing projects is the resultant (developer and user) confusion. What I'm suggesting is that perhaps PenguinPlay should be aimed simply at reducing that confusion by helping people find, evaluate, combine and use the available tools, or develop new, missing ones.
In fact I wish that the KDE/GNOME war had such a higher-level project trying to make sure that they cooperate on key interaction technologies like Drag-and-Drop, file/application associations, etc..
Anyway, it's just a thought, and I'm just presenting this as a "straw-man" proposal. Please let me know what you think.
An earlier mail from Christian Reiniger (a forward from someone else) mentioned the possibility of letting PenguinPlay be more of a set of guidelines for anyone trying to make games using free toolkits. In addition the PengiunPlay project itself may additionally offer a set of toolkits on its own, but in no way enforce them.
Personally I think this is a great idea. As it is now Crystal Space is mainly a 3D engine but work in the Crystal Space group has been focused recently in trying to make a more useable game toolkit from it (although still heavily 3D oriented). This work overlaps in large parts with what PengiunPlay is also aiming at. Both projects need sound support, networking, 3D graphics, ...
There has always been a slight difference in goals between the two projects however. PengiunPlay has been from the start mainly a Linux/Unix project although this has never been intended as a permanent restriction. PenguinPlay is also aiming at trying to be a general game engine. Crystal Space, in contrast does not aim at any specific platform. Currently the Linux and Windows platforms are probably considered the most important. Linux is the original platform that I wrote Crystal Space for while Windows is an important platform in the games market. Crystal Space is also more of a 3D toolkit and not a very general game engine in that regards.
Nevertheless I think that many things can be shared between the two groups. For example, I think it would be very nice if there would be one sound toolkit which both projects could use.
I think this emphasizes what should be an important design decision: "work in a component or toolkit oriented way". Here is a possible set of toolkits:
Conclusion? I think it is not feasable to really merge all those projects (like merging Crystal Space and PengiunPlay). The Crystal Space project in itself is rather large as is the PengiunPlay project. I think a merged project would become difficult to maintain.
However, I think that the component approach should work to allow both groups to benefit most from common needed functionality.
What do you think? Let the opinions flow (please post followups to both mailing lists so that everyone can follow).
> What I'm suggesting is to change this purpose to something more along > the lines of: > > The goal of the PenguinPlay project is to act as a clearing house > for information and free (open source) software to support creation > of comprehensive, cross-platform toolkits for developing games > and other multimedia software.
PPlay could be Linux game development knowlegede center - concentrating on enlightening the advantages and disadvantages in each game SDK available. It would be nice if anyone would run a site, where general discussions could take place. Notice however, if that should succed and be effective, I think you'll have to ask all the different game SDK's available to the Linux platform. It requires full cooperation and a bit help from these libraries (including ClanLib ofcourse).
The ClanLib project still needs a lot of developers. We would really appriciate help from the PPlay guys in improving ClanLib...
Hmm, my opinoin of the meta-project idea. I won't actually say yea or nay, only put my thoughts up for discussion.
In many ways the goals of such a meta project are very similar to the goals of PPlay. PPlay wants to have lots of independnet components which can be left unused or replaced by 3rd party API's. The meta project is all about such interoperability. And while PPlay designers might get lazy and break the rules, the meta project can't since it does not control any single project.
I have two problems with the proposal:
The reasons for my second comment are based on the assumption that the current PPlay component projects will continue. If the meta-project is to not give preferentioal treatment to PPlay components, it should for a start not be called PPlay.
Also I beleive the goal PPlay to be valid. A comprehensive, cross platform games API with a uniform interface, and integration (withing the bounds set by the interoperability requirements discussed above). Therefore I beleive PPlay should continue, without retargetting its objectives.
What do I see as PPlay's role in the meta-project?
This will benefit PPlay in terms of interoperabality. I mentioned a fear that we might get lazy and break the rules, thus preventing people from using PPlay component A without using component B. A nice 3rd party set of rules to follow would help us discipline ourselves.
How should this effect the proposed mergers?
It shouldn't. I would like to see PPlay merge with some other projects, I think this will give PPlay a shot in the arm, as well as avoid duplication of work. I don't wan't PPlay to merge with every project in this domain, this would be impossible to do even if it was a good idea (which it isn't). Nor do I wan't to see PPlay "take over" other projects. The whole point is to create a strong system by getting outside code and developers, if such a merger goes through the projects should merge on an equal footing. A name change would probably be required.
How should the meta-project be implemented?
Well if PPlay won't be the starting point for the project, then I see Ian Crawfords GameDev as being the ideal canditate. It already has similar goals, and some web resources.
Hmm, well that's my $0.02.
Ok,
there have already been some thoughts about this new proposal, and I generally agree with them (Note: For those who didn't get all the mails - I put them on http://sunsite.auc.dk/penguinplay/irc-meetings/nextmeeting.html )
I mainly supported the "one gamedev toolkit" idea because of two reasons:
(1) game programmers are likely to be confused if they find many competing projects. However this is a non-issue if all these projects cooperate with each other and write their code to be as interoperable as possible.
(2) All of the projects currently out there are short of manpower, some not very much, others critically. Merging projects would concentrate the available developers on one project, eliminating redundancy etc.
Well, much of the redundancy could be eliminated if the developers of all projects would continuously stay in contact with each other, lending ideas and code. This will however still leave us short of manpower (less serious, but the problem stays). So I suggest we give out a "call for developers"soon.
It's clear that we're not ready for prime time yet, so it's too early to initiate a big discussion with professional game developers right now, but stating something like
The linux game development efforts are now being reorganized. After that we are ready to seriously get into gears. But we need more people for that.
is IMHO the right thing to do now.
Ok, next issue. Adrian pointed out that the Meta-project should not be PenguinPlay. He's pointing out some very serious issues and IMHO he's completely right. Ian?
As for the "duties" of the Meta-project, it should host a set of mailing lists (general/gfx/sound/net/input/??) dedicated for inter-project coordination/cooperation/idea exchange issues and, if possible, all developers from th gamedev projects should be subscribed to at least the general list.
Oh, and the Meta-project should also push the developers to frequently update their docs (Ouch, noo, please, ouuch, help, sorry, SORRY ;)