OK, I don't think I'm going to be getting any more sleep this morning with this idea blooming in my head (or is it this bloomin' idea in my head?). For lack of a name for this project, I am simply going to title this post "The Crowdsourced Game", but will likely proceed to use this thread long after the project has a name. That will be one of the first things to decide on, though, and in the spirit of the project, I don't want to be the only one with input on the name of it. Let's gather a few suggestions for names and then I can post a poll to see what names people like. I don't think we have enough people to consider this crowd-sourcing yet, but it's in the same spirit at least.
As I said, this idea is blooming. I had a couple thoughts this morning that really allowed the idea for this project to start to take shape. For those who don't know what I'm talking about, I suppose I should begin with some background -- what is this idea?
The idea is, as the subject suggests, crowd-sourced game development. Instead of placing the entire burden of developing a game on one developer or a small group of developers, I would like to run at least an experimental project to see what kind of success we might get out of a project that allows anybody to contribute to a game, and merge the best of everyone's contributions into a "super-game". We have a
crowd-sourced encyclopedia,
crowd-sourced genetic research in game form,
crowd-sourced movie production,
crowd-sourced news and
crowd-sourced general discussion of what's interesting, and there apparently even
has been
crowd-sourced game development in the past, but, as far as I can tell, not in a form that continues to evolve and improve over an indefinite period.
Little Big Planet is probably the closest thing I can think of to what I'm thinking about. However, it has more restrictions than I imagine in "my" (or rather "our") experiment/project. The main restrictions I'd like to experiment with removing are:
1. Confinement of each user's content: I want a game where anybody can integrate their content anywhere into the game rather than dividing the game up into discrete units where each person only managed their own worlds.
2. Limiting the type of content contributed: I want a game where people can contribute their own fundamental content rather than being limited to just level design. People should be able to contribute new and improved artwork and code affecting the fundamental behavior of the game.
Impossible? It sounds pretty far out, but I want to give it a try and see what happens. And the idea that has been blooming in my head this morning has made this all start to seem much more realistic than I was previously imagining. The idea is that
SourceForge may already be designed for this sort of activity, if we use it right. Source control software is designed for merging code changes from different version levels and releases... perhaps it's possible we could use it to merge changes from different users. It allows us to "label" code so you can retrieve a specific set of code despite what other code has been contributed on top of it... perhaps it's possible to use that to mark candidates for playing and review. Scrolling Game Development Kit 2 can output all the graphics, code and level design to a single file (in HTML or SGDK2 format) while retaining the independence (as far as source control merging is concerned) of sprites, rules, map layers, plans, and many other aspects of a game that users may want to contribute. Source control merges are line-based, and SGDK2 files (and HTML files) are currently designed to maintain separate sprites on separate lines. So two users could add two different sprites to the same project, and, theoretically, have their changes merge together nicely.
As I think about it more, I think that the SGDK2 file format is almost the ideal form in which to maintain a crowd-sourced game, to which people of a wide range of skill levels can contribute equally. User One user wants to update all the graphics; he or she can submit an edit in which the SGDK2 file's graphic sheets and framesets are all updated (so long as the ordering of the already-existing cells and frames are not affected). User Two wants to add some new graphics; he or she can submit an edit which introduces new frames from a new graphic sheet into the same frameset, so that level designers have a larger palette to work with. User three wants to design a new level; building on the work of users one and/or two, or without the help of either, he or she can add new maps, and link them in by adding plans to existing maps to transport the player to and from the new maps.
Certainly there will be some changes that can't be merged. Editing tiles within an existing map won't be merge-able with other changes to the same map (although a manual merge would be practical if the game is being checked in in HTML5 format where the map data is readily view-able and directly editable in a text editor). Editing graphics within a graphic sheet likely won't merge well with other edits to the same graphic sheet. But with the magic of SGDK2 framesets, hopefully we/users can find a good way to update individual tile and sprite graphics without editing existing graphic sheet images -- just add new graphic sheets and then replace the frameset frames using the new cells instead of directly editing the existing cells.
But it's not time yet to get too far into the details. We need to begin by naming the project, exploring the forms of source control that are available that could support this, and formalizing the high-level plan. I think I should write a more formal description of this project that can entice new users to explore this idea with us, and help them understand what it is we're going to play around with here. As always, this document too will be subject to everyone's input. I want the most interesting-looking page I can have to make the first impression on a new potential user. Then we can post that on the project's SourceForge web site homepage. Or perhaps the homepage should be a wiki, further inviting improvements to the project at all levels.
I have a day job to get to work on today, but I do hope to get back to this soon, and start developing this idea if not developing any actual code. I have been slowly working on the CleanGame project to try to make it HTML5 compatible. I'm making some progress, and I do think (thanks user to #Sharp) that is a good place to start. When that project can be played in HTML5 form, then not only can anybody contribute to the project in SGDK2 format or HTML5 format, but anybody can pick up their own set of modifications by merging whatever set of changes they like, and post it wherever they like to play on a wide variety of platforms. Brought to you by Open Source
... no pay-to-play HTML5 game editor is going to give you this. Let the evolution begin... and proceed without restriction!
