|
[While commercial products are rarely open source, many different projects have explored the possibilities of opening up the code to the community -- and in this feature, Gamasutra looks at some examples and speaks to the minds behind them.]
The relationship between creator and audience in video games is more complicated than any other creative form. Developers can be artists, teachers, entertainers, scientists, or collaborators -- and often they must fill several of those roles simultaneously.
The role of the player is no less involved: actor, viewer, historian, student, lab rat, or leader -- all are roles he or she must be ready to play. Open source games capture this fullness of purpose, showing them at their most mechanical and most creative.
Giving players access to source code has been a part of gaming's history for years, from the earliest MUDs to Tim Sweeney's ZZT. As console gaming's proprietary hardware and its closely guarded development tools slowly squeezed PC play from its central place in the industry the idea of open source play declined.
Yet, everything connected to media and technology in the last ten years has taught us the future will be collaborative and the future is actually now. In recent years even console games have begun to realize there is profit in involving players in content creation, from Far Cry 2's extensive map editor to LittleBigPlanet 2's creation tools, which were so flexible that Media Molecule designed most of it's in-house levels with them.
And through it all, an active and growing number of PC games have kept the open source flame alive in a variety of ways, from reviving a flagging title to letting new of players learn from a designers work.
Nice Idea, We'll Take It
Crossfire began in 1992 as a topdown four-player action game in the spirit of Gauntlet. Originally developed by Frank Tore Johansen, a professor at the University of Oslo, the game has survived for almost 20 years. The first version of the game had just one map but now there are more than 3,000, as well as 150 different enemy types, 15 character classes, a skill system, and a proliferation of artifacts and treasures.
"I originally came across Crossfire after I bought an old Sun workstation to use as my home system, and so was looking for games for it," Mark Wedel, current release coordinator and one of many contributing Crossfire developers, told me. "The game interested me and I started doing some development work."
"When I started working on it, in 1992 or 1993, the game was an X11 application. This meant that for each player the server would make a remote X connection to the client. This limited the games to systems running X -- and one has to remember that this time frame predates the explosion of Linux and other free Unixes, so this was a much smaller audience."
Over the years the game has survived dramatic transitions in hardware and software, both seen and unforeseen. The first major change was moving to a client/server structure, which allowed the game to take advantage of internet play in a more accessible way.
"Because of the client/server approach, gameplay itself has changed some," Wedel said. "When I first started playing, the game was largely played by people on their own systems -- there may be groups of students at universities playing on a server. But now there are several well known servers, and anyone can play on them, so there are many more multiplayer aspects of the game than there was when I first started."
Over time Wedel became the maintainer of the codebase on Crossfire, a unique position that required him to oversee and maintain all of the incoming changes contributed to the codebase by other users. "Becoming a maintainer does result in one changing what one works on to some extent -- since I would be applying patches, I would be looking at much more code, and I might rewrite some particularly old or ugly sections, which I probably would not have done if I was just a contributor," Wedel said.
It's remarkable that a game as simple as Crossfire has been able to survive for so long. Even with a limited number of variables in its system, the game is strong proof of just how enduring comparatively simple designs can be when given over to a population of interested contributors.
"There are really only so many spells, weapons, and types of armor, and at some point it becomes redundant," Wedel said. "But within the content -- which is maps, quests, sounds, images -- that is basically unlimited. I think the world itself could keep getting expanded forever and if done right, it would not seem repetitive. Doing it well so that it does not seem repetitive would be the hard part. I would liken this to books - no one says that no new books should be written because every possible story has been told - the same would be true for the maps."
Likewise, the continual churn of new technology offers potential to reach new players and reimagine some of the game's fundaments. "10 years ago, when the client was developed, no one had any real idea about smartphones that exist now," Wedel continued.
"But with smartphones now widespread, a client that actually works well with smartphones could be written, taking advantage of the different input characteristics the phone has. It is impossible to say what new technology may show up in the next 10 years that would change the way the game is played."
|
1) Open Source indicates that the game's "logic" has been made available - i.e. the source code has been released, allowing changes to the game's engine (e.g. new features, porting to new hardware) can be made
2) Modding indicates that the game's content can be modified - i.e. graphics, audio, map layouts
There can be some overlap between the two - game physics and entity attributes (e.g. jumping height, weapon accuracy/range) can be either in the code or the content. But generally, while an open-source game is always moddable, a moddable game isn't always open-source...
I'm also unsure about this paragraph:
"Giving players access to source code has been a part of gaming's history for years, from the earliest MUDs to Tim Sweeney's ZZT. The model helped first person shooters proliferate in the mid-nineties with a shareware model that saw developers releasing a handful of missions and then allowing fans to bend their ideas in as many different ways as possible."
Here, three ideas are being mixed up: open-source, modding and shareware. The use of the "shareware" model definitely helped to drive the popularity of these games, but I'm not convinced it helped to promote modding - for instance, if I remember correctly, the "shareware" version of Doom wasn't able to load third-party mods; instead, you had to purchase the full game.
Equally, while modding definitely became popular with these games, it wasn't because the engine code was open source - Doom wasn't open-sourced until 1997 (4 years after launch); Duke Nukem 3D's source code wasn't released until 2003, long after the popularity of these games had peaked.
Instead, what drove the popularity of FPS games (or at least: led to people modifying them and creating new content) was the fact that they tended to use modularised, self-contained data-files for the levels - Doom's WAD files, for example. Even then, the data file specifications generally weren't made publically available - and at least initially, there was often little or no support from the developers (including ID - http://en.wikipedia.org/wiki/Doom_WAD ): instead, fans reverse-engineered the data formats and wrote their own editors; this didn't really change until 1998, when Half Life was released with a built-in editor, which in turn helped to create a little mod called Counterstrike...
Modding != Open Source
I think there's still a bit of confusion in the article between modding and open-sourcing, but I'll concede that there is often some overlap between the two!
In any case, it's interesting to note that unlike modding, the open-source concept has had little or no impact in the commercial gaming world. Part of this may be simply because game development requires a different mindset (and potentially more technical knowledge, plus potentially expensive development tools and hardware) to modding - mod tools can effectively turn content creation to a sandbox game, as Gary's Mod has shown.
In truth though, I suspect the main reason is because game engines are essentially viewed as valuable trade secrets - and these days, with multiplayer being viewed as vital, there's greater risks of people writing hacks and exploits if they have access to the source-code.
Even after checking Wikipedia's Open Source game list - http://en.wikipedia.org/wiki/List_of_open-source_video_games - I can't spot any commercial games which were OSS from day one. Instead, developers tend to release the source code once it's no longer considered to be commercially viable, and for the most part, this source-code is generally used to update and modernise the game - there's dozens of rewritten engines for Doom, Duke 3D and Quake, but far fewer new games.
(the humble bundle's OSS feature is a relatively new phenomena but it remains to be seen if that ends up being anything more than a marketing bullet point)
The main area where OSS concepts have taken root is in the emulation world (e.g. MAME and ScummVM[*]), where there's a much greater focus on communal development and sharing, and this is at least partially due to the fact that these enterprises are not-for-profit.
There's also the "remake" scene, where people try to reproduce old games on modern hardware - for instance, the excellent remake of Head Over Heels. These quite often use OSS and sometimes grant access to the source code, but they also highlight the problem with OSS-style development for games: many are abandoned or put on indefinite hold because of a lack of resource - usually because an artist isn't available, but sometimes because of a lack of developers. And unlike OSS projects with commercial value (e.g. the Linux kernel, PHP, MySQL, etc), there aren't any paid developers to plug the gaps and deal with the boring elements of creating a working product...
[*] Feel free to insert WINE-style "ScummVM isn't an emulator" comments here. The principle still applies ;)
The way I see it, for utilitarian open source projects the requirements are usually pretty static and there's usually a "best" way to do things by some quantifiable measure (ie. efficiency, flexibility, etc). For games as a piece of entertainment / artistic statement, how are the game design decisions (which become the requirements) taken, and what does that process look like (I'm sure very differently from regular top-down hierarchies)