How stupid do people find those game postmortems that show up on Gamasutra or in Game Developer? "What went right: Purdy pikchurs. What went wrong: Our game sucks." What then could be more annoying than a postmortem on not even a game, but a mod for a game? What a waste of time! It sounds like a really good idea as I sit at my computer, having not slept for several days and watching Monkey Magic episodes. Monkey Magic! Monkey Magic! Monkey Magic!
Neverwinter Nights provided an interesting opportunity for armchair RPG designers by offering the equivalent of a weak SDK with the game. A lot of folks complained about the complexity of the kit when it came out (you had to know some basics of scripting and be willing to learn a kiddie version of C to do anything meaningful with it), but after poking around the various scripts and script extensions in the game, you could modify pretty much whatever you wanted to, provided you were willing to test things to hell and back to find out what would inexplicably fail to work on implementation.
Despite this, there was a huge proliferation of incredibly bad modules published almost immediately, as folks rushed to inflict their beta toolkit monstrosities on the world, and unimaginative and cliched pen and paper campaigns screamed out to be translated into buggy publicly accessible versions of themselves.
I wanted to create a play environment that was at least somewhat logically ordered, balanced, and had some semblance of a believable plot behind it. Originally I actually wanted to do the "Stone Age Campaign" idea I had in mind when working with Sphere, but the limitations of the toolkit took that out right away; it would have required a complete rework of every item in the game. The amount of work wasn’t so much the discouraging factor here as the fact that even if one removed every item from the game and replaced it with something else, the original items would still be there dormant in the code, eating up clock time and producing amazing amounts of bloat for no reason whatsoever. So I was resigned to sticking at least somewhat to the traditional boring early steel age setting that’s so pervasive in the world of "fantasy."
Step one was, of course, trapping someone else to do a bunch of stuff for the module. Enter Kynn! Whereas a real development company would be offering things like money and benefits, all I had to do was appeal to Kynn’s wistful nature and the memory of working with Sphere. That and the fact that we had already worked on another NWN PW, discovering all sorts of horribly broken things about the toolkit and game engine along the way, eliminating (we thought) much of the initial learning curve. How wrong we were.
We bantered a lot about what would be an appropriate project to waste our time on. Naturally, we were thinking first of a PW version of a tactical large-scale combat system, where players would fight for and hold territory. This proved to be unsatisfactory for a number of reasons:
- There were already a bunch of boring and repetitive PvP modules cluttering the server list
- In order for a combat module to be logical it has to end at some point, where one side declares victory, but on a large scale, we would still need to figure out the persistence problem, so we would be saving no headaches at all and still looking at complete restarts on a periodic basis (we figured every week or so)
- Any team combat module designed to last for more than ten minutes at a time will inevitably suffer from numbers imbalance, unless people really like having their characters randomly reassigned to teams every login
Okay, so it would be a PW. PvP+ had to be implemented for a number of reasons:
- No PvP would mean Kynn would be quickly bored
- No PvP would mean no friendly fire damage, enter the world of point blank fireballers
- No PvP limits the play to finding out what the story is via forum spoilers and a leveling treadmill, which although appropriate to a revenue-generating MMORPG, would be incredibly stupid for a small no fee server
The story of Three Towns was cooked up by me over a week or so, with badly drawn maps of what the territories and political structures would be like and some ground rules for feature implementation (and removal). Sticking with the plotline in a hamhanded manner prevented a lot of those weird anomalies that pop up a lot in campaigns, and helped things to make sense over the long haul. (I’ve sent the big supa seekrit plot to the new admin of the server; they probably won’t follow it. It’s pretty weird. :P)
Many of the finer points of the systems weren’t detailed until NWN’s biggest problem – a lack of a working persistent data system – was solved. This in itself took about two weeks of near constant work and testing, plus subsequent changes when limitations popped up in the original design. Truth be told, we actually had an almost-working transparent system working in less than a day, based on creature skin assignment, and the next day a patch came out that destroyed all creature skins on players. Stupid patch problems continued to plague us constantly throughout our tenure on the module, forcing us to waste huge amounts of time fixing fixes.
Kynn’s final system was a pretty sophisticated log parsing tool, to date the best such system I’ve seen. Using this, we could attach and reattach any kind of variable (integer, float, string) to any player or object we wanted, provided I would recompile the module every time it started. (Apparently now there’s a nifty system that slaves the server process to a larger database function which is more elegant, but I don’t know if it’s finalized yet or what its capabilities are. Bioware also claimed at one point to be working on an integrated variable system, but I ain’t holding my breath.) With our hodgepodge persistence system, we could do lots of crazy stuff like scrap, town reputation, murder counts, etc. I think we managed to explore about half of what we could do with the variable system.
What Went Right
We Used Neverwinter Nights. The longevity and commercial success of the game is due largely, I think, to the fact that it comes with a development kit that allows for heavy modding. It’s to date the only game that gives the customer the tools to create and run his own small scale server, tailored (relatively) easily to a massive extent.
Kynn. Kynn solved tons of code problems, and has an excellent understanding of C, giving me a ready resource to badger about scripting problems and questions. And, of course, his persistence tool made a lot of our systems possible in the first place. He’s also better at finding exploits than I am, although until Three Towns he didn’t really experience the annoyance of players wrecking his world through their abuse.
Ironfisted Control. Working from my axiom that "all players suck," we were already committed to working from our own standards of large-scale balance and largely ignoring the playerbase complaints. Rare is the player that can actually see balance issues from the perspective required to make changes that will benefit the whole setting, and if they do they’re hopefully making their own servers. Noncompetitive games theory isn’t a prevalent science among tunnel-visioned players.
Ignoring Fantasy Norms. Fantasy norms, both literary and gaming-wise, are just goddamn stupid. All of them come from a fourteenth-hand watered-down version of Tolkien which, while a very detailed example of worldbuilding and background, is rife with illogic and stupid things which, unfortunately, everyone has come to accept as the norm. The norm is not something we strive for. I would have made the game completely unrecognizable as a D&D game if the toolkit allowed us to; as it was, we could at least create something that was unique, logical, and definitely NOT that Forgotten Realms BS.
Plotting Ahead of Time. While in a large sense, Three Towns was sort of an experiment to see how much we could make Neverwinter Nights not suck, that’s what a closed system test module is for (and there were a lot of those). The plot, backstory, and core ideas behind Three Towns were plotted out way in advance and were there to be referred to and, by and large, were adhered to. While it would be sort of cool to stick a huge ass carnivorous and super powerful dragon in the woods outside of town, it just doesn’t make any goddamn sense, therefore it’s not going in… we managed to avoid a lot of typical stupid fantasy absurdity by sticking to our guns.
Throwing Things Away. We also scrapped a lot of ideas that worked and had complete systems implemented for, because we realized that something about them just wasn’t right. In the code I sent to the new admin, there were three bankers and a complete and complex banking system complete with interest and handling fees between branches, involving about 40 different scripts, modeled after the Fugger banking system of medieval Germanic nations, since this is what might make sense in a Three Towns sort of political environment. We never implemented it because the system would unfairly screw over criminals who would never be able to get cash from victims, since it would all be safely in the bank, and we felt that would be unfair.
Insane Problem-Solving Abilities. Kynn and I are both balance junkies, and also good bug hunters. These skills, combined with our obsessive natures, allowed us to flush out and squash a lot of stupidity built into the engine, and create new solutions for problems as they arose, or more commonly, when the playerbase began to exploit loopholes.
Cool Functions. As an outgrowth of the previous point, Three Towns managed to include a bunch of nifty systems nobody else had used before. This was an outgrowth of the "Code from Design" philosophy: "What if we could do this? But the engine doesn’t allow this. So beat it up until it does." Things that came out of this ideal were the pickpocket code (before NWN allowed flagging of stolen items), various outgrowths of the murder system, random overland encounters, massive changes to the pathetic monster AI, etc. These systems went way beyond other cool features like scrap, head tax, and one-time per character quest systems, and were commensurately more Byzantine and headache-inducing to code and test.
Trim Resources. Very quickly we figured out what things caused NWN to run badly (that were within our control), and set out to eliminate as many of them as possible. For example, heartbeat scripts are a HUGE drain on server resources. You need to use them for certain things regardless, but it’s incredible how many cute carrot feature scripts that are publicly available depend wholly on a whole slew of heartbeat events. We got rid of as many of these as we possibly could.
No Goddamn Hakpaks. Forcing players to download additional mods for the privilege of playing your goofy module running out of your apartment is insane, and I didn’t want to screw with that from day one. I feel this decision was justified in spades several patches after we published, when Bioware began incomprehensibly to break hakpaks, forcing people to mod the override directory on their clients, which caused another huge slew of problems.
Small Team. Three Towns was really me and Kynn, and nobody else as far as code/content went. (Bean did some stuff that I had to fix a lot; I mention this so he won’t whine at me on the phone. :P) Coding a project like this with one person would have been impossible in any sort of practical cycle, but the more people you add into the mix (especially when you can’t pay them) adds to the control checking and management that has to happen to avoid the too many cooks syndrome. Basically, we figured out early what we were each good at, and did those things, and then beat each other up a bit about the results until they were finished. I get the feeling that any more people involved in development would have meant a lot of inconsistencies and code conflicts.
Kynn on What Went Right: I think we created a platform with a good story and good script support. I liked the theory behind the platform and developing it was interesting even given Bioware’s near constant stupidity.
What Went Wrong
We Used Neverwinter Nights. NWN is absolutely not designed to make a PW. The fact that we had to resort to an external system to track data between restarts makes this obvious, as is the inability to do things that a PW might require like track damage over time and any sort of "aggressor flag" system. No events at all can be attached to player characters, which makes a lot of things impossible, requiring huge kludgey workarounds that ate up innumerable hours and system resources. Add to this the inefficiency of the server engine insofar as memory usage and CPU load, the amazing number of bugs we had to discover and deal with at each new patch, and the fact that a lot of scripting functions failed to work as they should have (or at all), and it was a huge headache. Not to mention the restrictiveness of the AD&D system.
High Back-End Maintenance Requirements. Although we had the best (IMHO) system to work around the persistent data problem, it required a lot of time and effort to maintain, and had to be fiddled with every module restart. The NWN server is notoriously unstable, and so every time it would die for no good reason, I had to recompile all of the data, look for flow errors, delete retarded-named characters that would break the system, etc. The bizarre popularity of Three Towns also meant that we had a HUGE amount of player variable data to deal with, and when this got too vast it would overwhelm the server’s paltry non-multithreaded brain, requiring me to periodically trim the player vault and all associated data, which took an enormous amount of time. The fact that the server couldn’t be auto-restarted meant that I was more or less tied to the server box, which was incredibly annoying.
People Played It. I had an axiom that went something like, "All (or the vast majority of) players suck," when I was commenting on commercial MMOG’s, and Three Towns did little to move me from my stance. It got to the point where most of my time as a developer was spent invisibly logging in a DM, following players around, noting the cheap trick they were pulling, then going to the toolkit and creating a fix for it. Add to this the vast number of complaints about absurd things regarding the module (most of which boiled down to, "I’m too damn lazy to make a module the way I want it, so you should, and here’s how, do it now") and the griefer/anti-griefer whining, and dealing with the playerbase became by and large a wholly unpleasant experience. Several players specifically destroyed the whole experience for not only their grief/exploit victims, but for Kynn and myself as well, as we would periodically be forced to listen to their bullshit justifications that have been used since time immemorial by morons in every nonconsensual multiplayer game setting. I had on occasion considered making the module so thoroughly unenjoyable that nobody would want to play on it and I would have an excuse to take it down forever, but it would have been simpler to just take it down with no explanation. I was too lazy to do either.
Early Publication. In hindsight we should have never gone "live" with the module until it was actually completed to our satisfaction, so that development wouldn’t be a concern during live play. We had more than enough to do just with fixing bugs and exploits and playing cop once the server was fully populated, which happened very very quickly. As a result, it was totally impossible to focus on module development, and after a couple months of dealing with players the idea of working on further expansion seemed somewhat less desirable that shoving bits of red-hot rock salt into our temples.
Small Team. Going live on a multiplayer server usually means (in the commercial sector, at least) adding additional staff to do the red robe jobs like being a cop, running lame events, etc. With only the two of us doing everything, we were overtaxed to provide a lot of in-game support. The problem with getting additional people in as DM’s in Three Towns is that it’s very easy to introduce items that shouldn’t exist in Three Towns with the DM client, thanks to the stupidity of not being able to delete base items from the palette. We did, however, have a lot of automated systems that took care of a lot of the problems that go with a PW and abusive players (things that other servers simply list as bannable offenses, which requires a lot of DM judgment calls), but still it was just too much.
Kynn on What Went Wrong: Idiotic playerbase sapped my will to live, much less develop code for them. I also think that needing to continuously design content for players because they were too stupid to make their own was another issue. I think that taking any player suggestions at all was a mistake, and I also think that not creating a pvp based world was a drawback. It was too easy to get bored in 3t, and too easy to not interact with other players. We had a huge turnaround rate where people could ‘finish’ the game. In the end, that coupled with the idiocy of most of the players on the server turned us into cops who only really logged in out of duty occasionally.
Ultimately, Three Towns was a rewarding (though not totally enjoyable) experience to create, and something of a migraine to administer. The complexity of Three Towns is fairly amazing, and it’s more amazing still that someone else would want to try and figure it out. God bless ‘em.
At the time I gave the code away, Kynn had removed NWN from his PC for several months, and I hadn’t touched it very often except for the toolkit. The headaches of dealing with the combined stupidity of the toolkit, server engine, and problematic elements of the playerbase had just been too much to deal with, and I have not loaded NWN since. However, Kynn is currently on AIM making meandering comments about doing another module with even crazier code solutions to stupid engine limitations, so who knows? We may yet again rise to produce something else, and hate the playing public even more than before.