On the Source from Full Videogames

May 2, 2010

After the Humble Indie Bundle event ended, most of the games from the bundle pledged to go Open Source, sharing their source code with the world.

Before I go on, I think it’s necessary to clarify a few things: (1.) I enjoy all of the games from the Indie Bundle (2.) I bought it (3.) I 100% support the spirit and movement toward both open source software and indie videogame development. In short, it is in no way my intention to detract from the decision to open source these projects, nor from these projects and the developers behind them. I love these people.

This isn’t about the games, or the developers, this is about the developers-to-be drooling over the source code release, under the impression that it will be an excellent learning opportunity.

If it is, then this source code for a variety of commercial games ought to be pretty helpful, too, legally made public courtesy of the developers:

Aliens Versus Predator Gold Edition (10.0 MB), Blood 2 (2.34 MB), Castle Wolfenstein (7.07 MB), Descent 1 (1.42 MB), Doom 1 (Linux) (354 kb), Doom 1 (Atari Jaguar) (303 kb), Duke Nukem 3D (3.83 MB), Freespace 2 (2.64 MB), Half-Life (4.99 MB), Hexen 2 (2.91 MB), Hexen & Heretic (829 kb), No One Lives Forever (5.30 MB), Quake 1 (3.06 MB), Quake 2 (1.40 MB), Rise of the Triad (3.84 MB), Serious Sam (3.74 MB), Unreal (680 kb), Wolfenstein 3D (5.59 MB)
————– (Datafiles are not included, i.e. you’ll still need the original games.) ————–

I’m not suggesting that you download or read those. But there they are if you’re curious.

The indies that released their code for the bundle apologize for its organization – Lugaru‘s developer’s wrote, “The coding style is what you might expect from a self-taught high school student, so it could be a challenge to understand.” The developers of Penumbra likewise noted, “the code is far from clean and as expected quite hackish in places.” Meanwhile, why has it taken more than two weeks for the Aquaria and Gish source code to be zipped and put on a server? If their experience is anything like when some Linux developers politely asked for the source of Battleship 88, the delay is due at least in part to trying to figure out what can be cleaned up or commented in the code to make it less embarrassing, or at least a little more useful (angles in the Battleship 88 are stored in 3 or 4 different measurement systems).

Lugaru screenshot

Lugaru by Wolfire Games

When the people that made Lugaru made it, it was their very first time making Lugaru. It isn’t just indies though. When id Software made Wolfenstein, Doom, and Quake – get ready for it (!) – that was also their very first time making those games. Their code, at least by the standards of untested arrogance typical from someone that has never created anything new (a category that includes most programmers, who throughout their education and work life only wrote functionality to do what has been done), is bound to look like an inelegant mess.

Code for finished games is hacky. Nightmare-inducing hacky. Toxic, maybe just a little bit disillusioning hacky. Trying to learn game programming based on the source code for completed commercial games is like trying to learn the legislative process by reading through current corporate law – in either case, it’s trying to deduce the process from the incredibly complicated and lengthy result it generated, minus the context of compromises and circumstances that made it possible.

Source code from finished commercial projects is useful if someone is interested in tinkering with enhancements, ports, or modification of the games, but their utility as something to study for learning videogame development is rather limited.

In many cases, for anyone other than the developer(s) that wrote it, it would take more effort and expertise to understand, pull out, and repurpose say, a game’s graphics code, than to just write what’s needed for a particular game. Not only that, but the sort of optimizations and features worked into a game’s code are often fairly specific to that game; one cannot, say, easily yank the combat out of Lugaru and slap it into the Penumbra code for improved rendering, nor gut the level code from Penumbra and use it in place of the outside areas of Lugaru. Remember when, as a kid, cartoons showed brains being switched between bodies, and it made conceptual sense, but as we got older it became obvious that the tangled interconnections make this impossible? It’s like that.

(To clarify: it is not that I suppose that anyone would wish to remix two or more videogames together through their source, but rather to highlight the unfeasibility of separating components for use elsewhere; for example, borrowing the graphics or level code from an open source project for application in a new game of your own.)

penumbra screenshot

Penumbra by Frictional Games

As for adapting the code for a Total Conversion Mod – that is, altering the game into an entirely new game – this is generally a big team undertaking on the order of complexity of producing a commercial videogame, and often does not even require most of the game’s source code (only the gameplay portions, at most, which are often in script or standalone dll’s to improve iteration). The majority of that mod work is in asset creation: building levels in the map editor, animating and texturing models in Maya, recording/editing sounds, and so on. That’s effectively what the sequel to any game is, and it’s also what any game is that’s built on a licensed engine (Unreal, Source, etc.), which is to say that it’s not the best starting point for a beginner.

By the time the game is public, the assumptions that went into the program’s initial design are slightly out of date. By the time code gets released later, sometimes the operating system, graphics/audio/networking routines, practices, or (less so in the examples above) programming language can be out of date. Things were done in the program code that these days a graphics API call can do faster in hardware, or optimizations were made that now have only a trivial effect on performance.

But even if you can read the source code from a major commercial project on the day it is released, it still conceals more than it reveals.

Videogame development is an iterative process. What order the features are added is an important part of understanding how a game came together. What did the earlier versions look like during development? What was tried but not kept, or planned and initially accounted for within the code or other design decisions but cut before tried?

Transient business and human elements can have lasting effects. Was part of the code rushed in for a public demo, or faked as smoke and mirrors to win over a budget increase from an internal exec, then left that way because it worked well enough? Is something implemented twice or two different ways because office politics kept two programmers from communicating with each other, or one person moved on mid-project and another came in unsure of how to use the existing functionality? Just as rings on a tree trunk tell bits of the history it lived through, the code for a game is similarly scarred.

rings in tree trunk image

Read “Drought” as “Public Demo”

Near the end of the project, people often get stressed out over stretching out the last of the money, morale, and time – first by sneaking in a few polish details that couldn’t make it in if done “properly”, and later by applying band-aid hacks to sidestep bugs that couldn’t be tracked down. In other words, even if a codebase is kept relatively robust and clean during most of development, during the final stretch it usually gets a layer of garbage crusted onto it during the final changes.

There is, then, at least one big lesson that can be learned from all of these open source projects: if you’re setting out to program something that has never been made before (as opposed to re-implementing someone else’s game), your source code is going to be a bit of a mess by the time the game is finished. You’re firing a machine gun of code at a rapidly moving target that’s constantly changing directions. There are things that are only possible, given the unavoidable limits on time, resources, and sanity, when love for the code that the developers see is set aside for greater love for what the players will see.

There are plenty of programmers that see a finished game’s source code and say, “I could have done better,” then return quietly to doing nothing at all. This of course misses the point entirely, like a house painter that criticizes Picasso for inefficient use of paint or lack of consistent color fill.

Someone looking to do a community mod of an existing game may very well find a game’s source valuable; but for someone looking to learn videogame programming, studying a completed game’s source code is less likely to be the goldmine imagined, and more likely to be a quagmire.

(Originally posted as part of GameDevLessons.com Vol. 14)



Subscribe by e-mail
to receive an update every month of all new HobbyGameDev articles, videos, and game development resources



Comments are closed.

All contents Copyright ©2014 Chris DeLeon, solely to prevent others from copyrighting it.
Permission to reproduce, modify, and distribute this content granted without special request.

Site production by Ryan Burrell.