GAME JOBS
Contents
Building With Someone Else's Blocks: Going Open Source With Games
 
 
Printer-Friendly VersionPrinter-Friendly Version
 
Latest Jobs
spacer View All     Post a Job     RSS spacer
 
June 7, 2013
 
Sledgehammer Games / Activision
Level Designer (Temporary)
 
High Moon / Activision
Senior Environment Artist
 
LeapFrog
Associate Producer
 
EA - Austin
Producer
 
Zindagi Games
Senior/Lead Online Multiplayer
 
Off Base Productions
Senior Front End Software Engineer
spacer
Latest Blogs
spacer View All     Post     RSS spacer
 
June 7, 2013
 
Tenets of Videodreams, Part 3: Musicality
 
Post Mortem: Minecraft Oakland
 
Free to Play: A Call for Games Lacking Challenge [1]
 
Cracking the Touchscreen Code [3]
 
10 Business Law and Tax Law Steps to Improve the Chance of Crowdfunding Success
spacer
About
spacer Editor-In-Chief:
Kris Graft
Blog Director:
Christian Nutt
Senior Contributing Editor:
Brandon Sheffield
News Editors:
Mike Rose, Kris Ligman
Editors-At-Large:
Leigh Alexander, Chris Morris
Advertising:
Jennifer Sulik
Recruitment:
Gina Gross
Education:
Gillian Crowley
 
Contact Gamasutra
 
Report a Problem
 
Submit News
 
Comment Guidelines
 
Blogging Guidelines
Sponsor
Features
  Building With Someone Else's Blocks: Going Open Source With Games
by Michael Thomsen [Business/Marketing, Design]
6 comments Share on Twitter Share on Facebook RSS
 
 
August 24, 2011 Article Start Page 1 of 3 Next
 

[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."

 
Article Start Page 1 of 3 Next
 
Top Stories

image
Microsoft's official stance on used games for Xbox One
image
Keeping the simulation dream alive
image
A 15-year-old critique of the game industry that's still relevant today
image
The demo is dead, revisited
Comments

Jamie Mann
profile image
This was an interesting article, though it seems to confuse the two concepts of open-source and modding:



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...

Todd Boyd
profile image
Ha.. beat me to it.



Modding != Open Source

Kris Graft
profile image
Hey folks, yeah there was a bit of a definitional issue there (i.e. it was wrong!) that we've addressed. Thanks for the great comment, Jamie.

Jamie Mann
profile image
Cheers :)



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 ;)

Joaquin Estrago
profile image
Great article, though I was hoping for some discussion on who (if anyone) decides and sustains the creative direction and vision for an open source game.

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)

Paul Reiche
profile image
So speaking of playing with someone else's blocks, did you credit the little art icon associated with your article?


none
 
Comment:
 




UBM Tech