It’s little wonder that as the assets needed to make a commercial quality game balloon outwards, amateur developers increasingly turn to modifying, or modding, commercial off the shelf games as an outlet for experimental game design. Over the past few years, I’ve had the luxury of time to mod and develop games both semi-professionally and in an amateur capacity, so I thought I’d share some of the (what should be common sense) knowledge that I’ve learned from experience.
First the obvious: have you, or anyone you know ever tried to program a modern 3D graphics engine? There’s like vector math and thousands of lines of code involved in that, right? If the prospect of independently having to make a 3D graphics engine doesn’t sound daunting, you’re either ignorant or this generation’s John Carmack. It takes a lot of effort to make one of these. So much so, that iD (Doom) and Epic (Unreal) have found a perennial source of income in selling their engine technologies to other professional developers.
And there’s a good reason why there’s a marketplace for these engines: why allocate hundreds or thousands of man hours just to show things on a screen when you could instead allocate to programming game play.
Rapid prototyping is a great way to solidify design, understand what works (and what doesn’t), and have something to show off to interested parties. The more chances you get to iterate through your game’s design, the more polished it will be.
The ability to rapidly prototype does come at a price though. The scope of a mod project is defined by two things - the openness of the system that’s being modded, and the ability of the modder(s) to bend the system. In some cases, such as Bioware's Neverwinter Nights, offer modders a robust toolset for altering the game. Even with those tools though, there are some elements of the game, such as user interface, analog control, and core mechanics (e.g. combat) are barred from significant alteration. So if you want to make a computer D&D adventure, then you won’t mind these limitations. For more aggressive modders though, constraints such as the ones above can be roadblocks.
This is where the ingenuity of the modder comes into play. The modder that can appropriate the mechanics of a game by changing the specifics of the representation has earned a lot of free work. At the lowest level, this can serve as a means of parody and critique. However, if you can pass data out of that mechanic, then it’s advisable to find a clever way to tie it into your more experimental mechanics (so maybe you deal Humiliation instead of Damage =).
Another limitation that one should consider is the original audience of the game being modded and the style of game of the mod. Most amateur modders will have to rely on the game’s original audience being their potential audience. If there’s a mismatch between the two, then the likelihood of getting wide distribution is slim. Of course, if the original game is cheap, you might be able to draw in a few more curious souls.
Finally, modding is all about knowing the rules of the game. When you’re writing code to modify the behavior of a game, knowing exactly how the game responds to that code is critical to creating a successful mod. Anyone who’s worked on team coding projects knows how difficult it can be to work on someone else’s code. Now imagine not being able to see all of it! It can take a while to become fully familiar with a toolset or engine’s behavior. The one tip I can offer to beginner modders is to insert as many debug messages as you can mentally process. Wrap them around functions that are causing you uncertainty, and track any and all data that you think is being affected.
For many of the reasons I’ve listed above, most mods that are put out are exercises in level design. Every now and then though, people are able to redefine a game through modding. Either way, game modding is a great way to stretch your creative instincts, learn some basic coding practices, and have a little fun.