The Liberated Pixel Cup style guide, which is the cornerstone of coordinating collaboration in Liberated Pixel Cup themed artwork.

We announced Liberated Pixel Cup just a little over two months ago. In the time since the announcement, a stunning number of things have happened: we hit… exceeded!… the fundraising goal for the project, completed a style guide, base asset repository, and interactive demo, wrapped up the art phase, and we are now well into the coding phase.

I'm happy to see things going so well. Liberated Pixel Cup is an important project to me, and its success is near and dear to my heart. This isn't just because I think "games are cool" either: there are actually a lot of motivations behind Liberated Pixel Cup. I discussed one of these in depth on my personal blog in a post titled "Why games matter to free software and free culture". If you're looking for a larger-policy reason for working on free software and free culture games, you may wish to read that.

But there are other reasons why I think the Liberated Pixel Cup is important that were outside the scope of that post. One of these is that games are one of the few direct intersections of free culture and free software (or otherwise directly functional) works (the other major instance of these I think of being 3d printing). Ideally, we'll want to see only more and more of these combinations in the future, but what we see is that when we do, a lot of interesting questions are raised. And getting these movements to connect is surely important generally. It's also true that getting into game development is presently extremely hard as you end up splitting your efforts between designing a game engine and designing artwork assets, so reducing the barrier for certain types of games seems to be a worthy goal.

But one of the biggest reasons for doing Liberated Pixel Cup was very specific: doing distributed free culture projects is hard and has barely happened at all in the way that distributed free software projects has. I wanted to prove that there is a way to do distributed free culture projects and achieve a coherent result.

Background thinking on distributed free culture projects

Free software projects have operated in a distributed fashion for some time. But for whatever reason, there are few examples of successful distributed free culture projects. Sure, there's the obvious exception of Wikipedia and wikis generally. However, these are very much so the exception, and it's even arguable that while free culture projects, these fall more on the data and factual information side of things than on the highly creative and artistically directed projects side of things (one might argue that Wikimedia Commons is more on the side of creative works, but this is more of an aggregation of creative works than work to create a coherent and stylistically consistent whole).

Probably the most famous example of artistic free cultural works that comes close to free software works is the Blender Foundation's films. There's a lot that comes close here: obviously first of all in that they use a major piece of free software (Blender) as the key part of their pipeline, but more specific to workflow aspects, the Blender Foundation films release their works in much the way that a free software project releases their works: with all the source files used to build the film attached under a free license so that anyone can build, modify, and study the project.

But for the most part, Blender films aren't developed in a decentralized manner (or haven't been, at the time of this writing). For Sintel, Big Buck Bunny, and Elephants Dream, the development of the work was done by a small and closely knit team of artists behind closed doors and the entirety of the film was released all at once at the end of the project. This is not to say such a pattern would comparatively disqualify something from being called free software, but it would make it a non-distributed project along the lines of what we call in free software "throwing code over the wall".

This hasn't gone unnoticed by members of the community; if you frequent the BlenderArtists forums, every now and then someone brings up the idea of doing a distributed open movie project that anyone can join and contribute to. These projects tend to start with a bunch of enthusiasm but after not too long seem to generally fizzle out (I'm not going to point to any in particular because I don't want to make anyone feel on the spot, but it's easy enough to find on your own by doing a search for the terms "open movie" and browsing through the archives).

Why does this happen? Is it simply that distributed free culture projects aren't possible in the way that free software projects are? I don't believe this is true, and have been trying to think it through for some time.

One event occurred that lead to my thinking about how to approach a distributed free culture project: during the making of Sintel there was a period where they asked for some outside help improving the characters. I was excited about this, but thought maybe with some more careful direction they could have better results. I sent an email to the director Colin Levy and suggested that they do a sprint instead: it would give them the opportunity to pre-allocate a list of tasks so that multiple people could work on multiple things without conflicting with each others' work (resolving conflicts in 3d modeling is not as easy as it is to do with plaintext source code), they could set aside a series of time where they could give direct feedback to people working on things, and they could have a short timeline in which they could see how well things worked. And the good news is that the Sintel team ran such a sprint (I'm credited in the post as "cwebb") and it was a "stellar success". (There was also later a animation sprint, but that went a bit less well… I did an interview with Ton Roosendaal where he explained a bit why he thought that was.) I'm not trying to take credit for any of Sintel's success here, even in the modeling sprint (I didn't participate, I just sent that email); that would be stupid. But I was excited to see that when properly framing things, something collaborative was possible for a free culture project. This was a small subset of a larger project (which was still mostly done in a throw-the-work-over-the-wall fashion), but maybe some lessons here could be expanded into something larger?

I've continued to think about this and whether or not things could be expanded to larger projects. I had a call with a friend of mine, Bassam Kurdali, who is the director of the first open movie project, Elephants Dream, as well as Tube, a new and exciting open movie film project. I picked his brains on what he thought about running a largeish distributed free culture project would work like.

We came up with the following points:

• For one thing, the idea that you just throw open a project and everyone shows up and just builds their piece of the universe and bam, your world is created! … is wrong. In fact, it's even wrong for software: most free software projects that go far might have a lot of contributors with a large and varied set of interests, but there tends to be one or just a few people setting out a very specific set of "project vision" for the software. If you don't have this, the software heads in all sorts of conflicting directions and falls apart under its own weight and lack of cohesion.
• This is even more so a problem for free culture. When you develop an animated film, a game, or whatever, you need clear stylistic direction. If you don't have that, you end up with a ton of pieces that you can try to mash together but don't really look like they belong together at all. Everyone has a different idea of where the project should go and a different preference in look, and eventually you hit creative difficulties, and the piece falls apart. But is there a way to get past this?
• There are probably two ways to get past this. One is to have a strong "artistic director" of the project who coordinates the entire style of the project from start to finish. And another is to borrow an idea from programming and set up a "style guide". Bassam pointed out that python programmers are more than happy to conform to PEP-8, the style guide that dictates the general look and feel of code. And of course, there are plenty of other conventions in python code imposed by the language's design itself. Could the same system work for artists?

Relatedly, around this time, Jonathan Palecek (CC software engineer, and author of the Liberated Pixel Cup Demo) and I were speaking about an engine he was building and looking around on OpenGameArt for resources to use when prototyping the engine. The trouble we found is exactly the problem laid out above: there are tons of wonderful resources on OpenGameArt. But the problem is that you simply can't use most of them together. There's simply too much variance between the items.

… and then it became obvious. This is the perfect space to try to prove distributed free culture projects are possible with enough direction and preparation…

Why we did what we did

So that's the thinking that lead up to the point of Liberated Pixel Cup. I approached OpenGameArt and the Free Software Foundation about the idea of a competition that bridged both free software and free culture with a specifically laid out style. Once they were both on board (Mozilla would join later) and we knew our general direction it was time to figure out: how exactly would we structure the contest and the style guide specifically?

For one thing, we knew what building a style guide generally would look like, because there was a wonderful project called Tango which had already done the same for vectorish application icons. They seemed to do it exactly right with their existing style guide coupled with a base icon library. So we went this route: we built a style guide, we commissioned a series of base assets, and to show off that in fact that the Liberated Pixel Cup style dream was real, we even built an interactive demo that you can play with.

With that in mind, we had to make a decision on what style we wanted to shoot for. We went with a raster-based top-down, orthographic view tiling at 32x32. But why this specific style? It was no accident; we had these very specific goals in mind:

• We wanted it to be adaptable to a wide variety of types of gameplay. In the "16-bit era" of game consoles, there were a wide variety of games that used this perspective: adventure games, RPGs, real-time strategy games, farming simulations, civilization simulations, and so on. We knew that it was flexible, and flexibility was critical to a design that could be useful for a variety of games for a long time to come.
• We wanted it to be extendable to a variety of thematic genres. Even though the base assets that we commissioned for Liberated Pixel Cup had some specific thematic elements to them (vaguely victorianesque interiors, some traditional fantasy game tropes), there was nothing specific about the elements described in the style guide towards one thematic genre or another. (This was proven true in the art phase of the competition; we got some nice looking science fiction themed submissions.)
• We wanted the style to be easy to collaborate on without a persistent "art director". The style we were going for was fairly well understood by having a lot history of games with similar (though not exactly the same) styling. The orthographic style and the abstracted and highly stylized proportions of the characters we had commissioned were done with clear intentions; for example, we had considered a character style that had more realistic proportions, but such a character style would require either a much more intensive set of art direction (which we could not handle such a resource with the kind of contest we wanted to run) or much longer and more specific descriptions and layouts around the characters. Similarly, there are ways to do tiled games that have a more "faked" but high definition sense of perspective (even though on a flat grid you can't have real perspective lines by definition) but this would again require a lot more hand-holding than just "keep it in an orthographic projection."
• We wanted artwork that looked beautiful but could have a low barrier to entry for a variety of artists. The art style we chose was intended to have specific but easy to understand rules, but ones where fairly new artists could still accomplish nice things that seemed to match, and advanced artists could use their full skills. This affected decisions like "just what kind of texturing/shading are we going to push for?"
• Despite the above, we wanted something that looked nice and, even though borrowing from a long history of games with similar and well understood styling, had distinctive elements. To this end, we laid out the base directions of the art style first, then commissioned a base set of artwork, then developed a clear style guide based on the existing set of work we had. Decisions like the general "camera angle" we wanted, finalized shading directions, how to handle outlines (which are colored instead of black and white in our style), were made based on the artwork produced by our commissioned work. And we do feel that the result was something that was easy to build things off of but had a clear and distinct "Liberated Pixel Cup look" to it.

Knowing all this, we split out the contest into three phases. First, we had a commission / style guide phase. Bart Kelsey of OpenGameArt and I wrote out the core aspects of the style we knew we wanted and then brought on Lanea Zimmerman as our lead artist to work out initial tiles then gradually brought in four other artists (Stephen Challener developing the base characters, Charles Sanchez doing monsters, Manuel Riecke doing character hair/accessories, and Daniel Armstrong building us a bonus castle set). With the artists coordinating we extrapolated what we had into a style guide.

At that point we were able to move into part two, the art phase, which recently wrapped up. And I'm happy to say, it was a success! We got a large variety of entries and for the large part, most of them look like they fit beautifully with the style we set out. And it's hard not to feel validated: we've seen in Liberated Pixel Cup that it's possible to get a large, distributed set of people to collaborate on something big and make things that actually can work together. And now we're finally moving on to stage three of the project, the coding phase; hopefully seeing contributions from the art contest being used in games will make that achievement seem more real.

In conclusion

So among other agendas behind Liberated Pixel Cup was proving that distributed, collaborative free culture projects can be done if approached right. And I believe we showed that it can in this case: with enough forethought, careful planning, and creating the kind of conditions that made artists want to create a cohesive set of works.

Can the approach we took with Liberated Pixel Cup work across all free culture projects? I don't think it's quite that simple; we made some very specific choices as to the decisions we wanted to take given the kind of project we intended to run (eg, the choice for non-realistically proportioned characters being done because we knew with everyone working separately we couldn't have a careful "art director" type person… but if we were working on a film, we probably would go for something with a style that might need more negotiation). But what I do think is that if you have people who know their field well and decide to take the forethought to give a project clear planning and direction, a "distributed, collaborative free culture project" is more than possible. Creating something that's cohesive takes more work than just "throwing open the doors and letting everyone toss in whatever they feel like", but if you take the time to plan things out, you really can get people collaborating on something wonderful and even have it fit together beautifully. And so, I hope we see more of such projects in the future!