Bethesda recently announced it will make the Creation Kit, the development and modding tool for Skyrim, available early next month so players can get to work on enhancing the RPG. Judging by the success of the new Fallout titles, and Bethesda’s older games such as Morrowind and Oblivion, the Skyrim Creation Kit should assure the game exists in minds and on hard drives for many, many years to come. This raises a compelling question: Why don’t all developers release modding tools for their games?
If only it were that easy. First, let’s cover off some important facts about the majority of development tools. Any serious, AAA game in development will have a dedicated tools team building programs or writing scripts to aid in content creation. Tools are almost as vital as the game itself. Modding tools released publicly are almost always these same tools, altered slightly to be easier to use and to protect IP, if necessary.
Depending on the level of support the tools team has, these programs will be incredibly powerful and user-friendly, like Naughty Dog’s Charter, used to build the Uncharted games, or complex, unorthodox creations hacked together to serve the needs of the moment. In this case, a program might start out with a single purpose — say, compiling AI scripts — but evolve into something with multiple uses — compiling all game scripts — or a feature it was never intended to have — script highlighting and automatic expansion of common functions. It’s not hard to see how a tool might go from being simple and straightforward to use, to something unwieldy that only a select few know the quirks and full functionality of.
In a perfect world, tools would get the same treatment as the game, with everything from interface design to tutorials fleshed out following solid design principles. But, ultimately, developers are there to ship a game, not a tool.
So, imagine a tools team that doesn’t have the resources of a developer like Naughty Dog, Epic or Valve. The tools team might consist of a single programmer, and that programmer might have to split their time between the game and tools support. When the priorities are broken down, the tools will receive the absolute minimum attention required to get the job done, especially if those tools will only be used by a small number of people who can be quickly schooled in their operation with a face-to-face chat.
Now, let’s say said programmer is asked to make the tools shippable. Hundreds, if not thousands of people are suddenly going to be privy to software never intended for mass consumption. It has hacks, an inconsistent interface, horrible bugs and nothing even resembling proper error handling. Features must be documented, work flows explained and custom file formats detailed.
Again, ideally, you’d have all this information at hand. And it always is — in code. A trained programmer can usually reverse-engineer a file format based on its structure or class in code. In fact, given time, they can nut out exactly how a program works. But you’re not releasing source code, and you probably wouldn’t want to (at least not without comments and a good surveying of potential IP issues). You’re releasing a program, and the user of this program won’t always come from a programming background. They might be intelligent, but intelligence does not grant clairvoyance.
Some tools aren’t even programs, they’re scripts to supplement apps such as Autodesk Maya. You can bundle these up and release them, but requiring users to purchase a piece of software costing thousands of dollars or, worse, forcing them to pirate it, is not really conducive to building a supportive community of fans.
Why not just whack a “use at your own risk” disclaimer on tools you release and be done with it? The answer to this question lies in brand perception. Sure, you’ll get kudos from some for getting the tools out their for modders, but curious others will fire up your programs, attempt to read your hastily-constructed tutorials and guides and shake their heads in dismay. At best, they’ll come away thinking “It’s a bit over my head, but that’s alright.”
At worst, they could take away a new, negative perception of you as a developer. Instead of thinking about the great game you made, all they can think about are the shoddy, undercooked modding tools you released. A lack of proper documentation could lead to mods that compromise the stability of the game, which could lead to crashes or corrupted saves. The blame might land on the mod developer but, for the less educated, that hate is going to be aimed directly at the developer.
Who knows what conclusions your fan base will come to? For some developers, this is too big a risk to take. Better to keep the mystery of how your game works under the hood than to expose its unsightly innards.
At the end of the day, it comes down to what it will add to the game and the player experience. Releasing internal tools isn’t always the best choice for every developer. Its benefits cannot be denied, but having nice, presentable and easy-to-use tools shouldn’t compromise the quality of the product you’re actually selling.
I’m sure we’ll see more games embracing modding in the future, at least those who still recognise the PC as a formidable gaming platform, but know that it’s not something every game can accommodate, be it because of time or budget constraints, or the realisation that sometimes, it’s not always wise for the magician to reveal his secrets.
UPDATE: A lot of people are suggesting the main reason is the rise of DLC. It may be a contributing factor, but I’m not convinced. Good points I’ve seen are value-add from user-created content, the life-extending nature of empowering users with development tools and the “gating” abilities of official content (a map from the developer might allow ranking and advancement features, whereas a user-made map would not). There’s also a guarantee of quality and balance with developer content (in most cases), and you don’t run the risk of damaging your install or save games.
Leave a Reply