Project Ensemble is an experiment in crowd design, where players, developers and artists collaborate to collectively design a browser-based multiplayer online game.
Ensemble is currently suspended. There are plans for the future to revive the idea in a slightly different format.
I offer no guarantees that a decent game will come out of this. I do expect this will be an interesting and fun learning experience for many though. So put protective gloves on or something and stick around.
The initial “game” is extremely basic and consists in moving colored dots around and empty world. It is up to the community to decide how this basic game should evolve. This process revolves around three channels :
- Suggesting and voting for features. Anyone can make suggestions about the next feature to add to the game (see below for examples). A list of the suggested features (located below the game canvas) allows to vote for or against each of them. On a regular basis, one of the top-ranked features of the moment is selected and implemented.
- Making Pull Requests. Developers can choose to bypass this process, and directly implement themselves the changes they would like to see in the game. These changes can be submitted through Github pull requests. Pull requests are accepted unconditionally, provided they don’t contain anything inappropriate and work properly.
- Submitting art. A form is provided to enable artists to send me artwork that they would like to see added to the game, such as sprites or animations. For these as well, submissions are accepted unconditionally.
Note that although pull requests and artistic contributions are initially accepted without a vote, it is perfectly possible to subsequently submit suggestions (via the first channel) that repel or alter these types of contributions (e.g. decide to remove a change added via a pull request, or change its effects slightly).
The collaborative aspect should be of particular interest to game developers, as it provides an environment to learn and practice with game development (in particular, browser-based multiplayer online games). Making pull requests to an existing project is a notorious way to acquire experience with development, without having to worry about setting up and maintaining the project, allowing to focus on the development itself.
For less tech-savvy enthusiast, the other two channels allow to have significant impact on the development and to take part in the experiment with the rest of the community.
Obviously, a likely outcome of such a process is that the game would quickly become an unplayable mess. To avoid that, I reserve myself an editorial right to alter the content as I see fit, if it seems appropriate to solve incompatibilities between contributions or to prevent the result from becoming truly unplayable. The idea however is to exercise this right as little as possible and to explore what interesting situations and emergent gameplay could arise out from this process.
Examples of contributions
The term “feature” is deliberately vague, to reflect the fact that they can be about virtually any aspect of the game or the project.
A player might decide that colored dots are boring, and suggest that they should be spaceships instead. Or maybe an artist could submit a nice spaceship sprite with the same idea in mind. A subsequent suggestion could be to assign health bars to the spaceships. Another one could then be to allow the spaceships to shoot at each other.
In this scenario, a trend becomes apparent as the suggestions follow up on each other. But this is absolutely not a requirement; contributions and suggestions don’t have to follow any ongoing trend. A situation where the suggested features go in multiple directions simultaneously (“level-up your banana-shooting spaceship to save the captured princess from zombies” …) is perfectly acceptable in this experiment, and possibly more interesting.
Suggestions and contributions can be technical or visual in nature and related to any aspect of the game : core principle, gameplay, interface, etc. They can also pertain to the project itself, such as improvements to the voting interface or changes in the process.
In order for this experiment to be feasible, the scope of the suggested features has to remain relatively small. When the time comes for me to pick a feature to implement, this aspect is taken into consideration as well, in addition to the number of votes. Is is therefore entirely possible that the top-ranked feature is not selected, but the third one instead. This allows for a faster cycle of implementation and a more dynamic growth. Suggestions should be made while keeping this in mind. Suggestions with a big scope should be decomposed in smaller suggestions, to be submitted over the course of a few implementation cycles.
An example of a series of features of acceptable scope:
– “Add health bars to characters”
– “Allow characters to perform simple offensive actions upon pressing a key”
– “Make attacks affect the health of the targeted characters”
An example of a feature of inappropriate scope: “Add a fighting system where damage is affected by a complex system of classes, attributes and skills”.
Although this is less an issue for pull requests, I nevertheless invite contributors to make regular small-size pull requests rather occasional big fat ones.
About implementation pace
As I will, at least initially, be the only person in charge of implementing the selected features (as well as maintaining the project, reviewing pull requests, etc.), the implementation time may vary significantly each time, depending on several factors. The delay between the selection of features may vary as well. Care will be taken however to maintain a healthy implementation pace for the project.
Rules of acceptance
Submissions (through any of the three channels) containing inappropriate content will be systematically rejected.
Pull requests should ideally keep a limited scope, and be well commented as this is a collaborative project. Obviously, they should not break the code, and will be reviewed for that and tested before being accepted. It is strongly recommended to make your code as modular as possible, to facilitate the collaborative process.
To deliver this experience, the following tools have been selected:
– Node.js for the server;
– Socket.io for the client/server communication;
– The Phaser game engine for the client-side of the game;
– AngularJS and the whole MEAN stack for the project interface.
Obviously, developers wanting to contribute with pull requests to the existing code will need to be familiar with these technologies (as well as with git). However, new libraries or Node modules can be included if they are required for some new features (and should be part of the pull requests in these cases).
Depending on how the game evolves, different tools might be used, either by using additional ones or replacing existing ones.