This article is a two part series on, well, SourceMod! This time I’m laying off the code, and I’m going to discuss SourceMod’s past, present, and future. This first article is a quick timeline of events, and a look at why SourceMod died.
- October 7th, 2004: SourceMod is officially announced as a multi-scripting and administration platform for the Half-Life Source engine.
- December 1st, 2004: The Source SDK is first released.
- December 25th, 2004: SourceMod releases its source code.
- January 2005: PM decides to start a “SourceHook” project to embed inside SourceMod.
- March 2005: Realizing that the Source SDK was highly inadequate for plugins, as plugins were already hacking memory without any cohesion, PM and I decide to split SourceMod into two separate projects: Metamod:Source (with SourceHook), and SourceMod.
- May 26, 2005: After many revisions and much work on PM’s part, Metamod:Source is finished and released.
- May 2005: The SourceMod Core is completely abandoned. Work briefly starts on a new version, “core2.” The idea of a new core is quickly abandoned, and SourceMod is internally considered “on permanent hiatus.”
- August 2005: The SourceMod team goes back to AMX Mod X.
- March 22, 2006: A public quorum in IRC is held to decide if the community still wanted SourceMod. The reaction is positive, and the remaining developers decide to continue the project at an unknown future date, using a single language: Pawn.
That is how we left things off. So, why did SourceMod fail if AMX Mod X was such a success?
Why SourceMod Died
1. Too Ambitious
SourceMod’s original goal was to have multi-way scripting. This means reimplementing something like COM or Mozilla’s XPCOM, a huge task that simply wasn’t feasible in a short amount of time. Logically, this goal doesn’t even make sense. Supporting multiple language platforms is an absolute nightmare, and does not make sense for an embedded system. It was an incredibly flawed goal in multiple ways, and is SourceMod’s single greatest point of failure.
Another ambitious goal was having an embedded administration server (sort of like WebMod). This was foolish because not everyone has access to MySQL or a GSP that would allow random ports to be opened. Furthermore, it would require an inordinate amount of work for an unnecessary, non-essential feature.
2. Too Complicated and Unstable
Do not read “unstable” as “crashy,” but as in API stability. The API was constantly changing as it grew more and more complex, and the fundamental design issues were never resolved (such as unloadable dependencies and plugin execution). On the lucky chance that the code actually compiled properly, it was unusable or hard to understand.
3. Top-down Structure
We built SourceMod from the top-down. It could hook things, add console commands/cvars, load modules, print messages, et cetera — the essentials of what AMX Mod X could do. But, it never had one important feature: scripting. Nothing was testable, demonstrable, or releasable, because the multi-way scripting platform was never completed. By the time it was usable, the design was flawed and had to be scrapped. The project largely stagnated because there was nothing to show – all of the working code was simply unusable without the scripting layer finished.
4. Unfamiliar Development Team
The AMX Mod X team was mostly a tightly knit group, where everyone was familiar with policies and coding styles. SourceMod introduced new members who proved to either be useless or unfamiliar with these practices, or eventually wandered away due to the problems above.
Valve had to be on the list. Half-Life 1 is far more flexible and usable for mod-independent plugin authors than Half-Life 2. As Valve continued (and continues) to break their software, their own API, add unpopular changes, ignore developers, and deny simple features which exist in many other games, motivation to complete SourceMod dwindled. Our internal list of grievances goes back to the beginning of 2005, and includes:
- Denial of simple engine changes (such as being able to intercept log messages).
- Denial of IGameEvent changes for property enumeration.
- Denial of a fix to let plugins print text to the screen.
- Inability to have a timely fix for UserMessage enumeration crashing.
- Inability to have a beta release system for mods.
- Inability to forewarn developers of major changes.
- Denial of a better menu interface, which is universally regarded as garbage.
- One-time removal of simple menus, which were supposedly re-enabled only “temporarily” due to huge public backlash.
- Denial of trivial changes to make SourceMM easier to load, since GameInfo.txt is overwritten.
- Inability to fix unloading issues with Valve Server Plugins.
- Inability to fix the issue of VSP load failures not showing what the problem is.
- Inability to fix VSPs not being able to intercommunicate.
- Disabling client command execution (engine API!) with an extremely poorly thought-out update (whose breakage extended across a myriad of plugins and API calls), not admitting broken backwards compatibility, and providing no workaround or forewarning.
- Inability to provide working, documented, mod-independent API for very simple functions, such as telling a bot from a player, telling whether a player is really dead, telling a bot from a spectator proxy, or even changing player/entity positions.
Supporting one mod alone is difficult, but supporting all of them is very hard, and with many mods altering the Source SDK significantly, cross-platform support becomes much more difficult. When you add Valve’s unannounced API breakage into the equation, Source looked like a doomed platform to us.
What Next, Then?
In tomorrow’s continuation of this article, I will write what our current goals are, and by when we hope to achieve them.