Editor's Note: Any worthwhile Nethack variant eventually finds a home in Slash'EM. Tracking those variants and the main Nethack sources is quite a job though. Howard Wen recently interviewed Warren Cheung and J. Ali Harlowe, the lead developers of Slash'EM.
O'Reilly Network: Warren, technically, what went right the second time when you brought together Slash and the Wizard Patch to create Slash'EM? Were there other reasons besides your lack of programming knowledge during your first try?
Warren Cheung: I think it was mostly the little changes that made all the difference. The second time around I deciphered the results of the patch and basically worked out the errors through sheer force of will. I plowed through all the gcc errors, fixing things to the best of my knowledge, until about 3 A.M., when I finally ran out of errors to fix. As luck would have it, the whole thing compiled. So, on the whole, it would be a small amount of additional knowledge, a healthy portion of luck, and the rest supplied by simple stubbornness.
ORN: What were some of the coding issues (regarding game play and graphics, for example) that had to be resolved in merging Slash and the Wizard Patch together to make Slash'EM?
WC: Actually, there was very little that conflicted when merging Slash and Wizard Patch. The philosophy behind Slash (grossly simplified of course) was to add more of everything in NetHack: more objects, more monsters, etc. The Wizard Patch dealt mostly with the way spellcasting was handled, which was largely untouched by Slash. So the few coding issues that had to be dealt with mostly concerned changing the other spellcasters in Slash to the "Wizard Patch philosophy"—the NetHack Wizard class is joined by Fire Mages, Ice Mages and Necromancers in Slash—and doing the same with the new spells. The greatest stroke of luck here would be the fact that the Wizard Patch didn't touch any system-dependent elements like graphics, which would have been probably far beyond my capabilities at that point.
ORN: Besides Slash and the Wizard Patch, is there code from other NetHack variants or patches that have been incorporated into Slash'EM? What are the unique challenges (or problems) that have come with mixing together code from within the NetHack family?
Slash'EM: The Sum of All NetHacks -- Any worthwhile Nethack variant eventually finds a home in Slash'EM. It's the proving ground for all sorts of new and unique ideas. Far more than just a conglomeration of patches, Slash'EM is a fresh game in its own right. On the twilight of a new release, Howard Wen examines how a classic is kept alive and fresh.
WC: AllegroHack was probably the most significant patch/variant that I've merged. There have definitely been several other small patches that have been merged into Slash'EM over the years, adding new monsters like the Genetic Engineers and Frankenstein, the Dwarf Patch, the fishing pole, SHOW_WEIGHT, all the new and improved tiles.
Overall, I don't recall any large changes needing to be made to integrate patches with Slash'EM. Mostly it's due to the changes in line numbers and the differences in the tilesets. True conflicts only occur when two patches change the same aspect of the code; do we keep the original, one of the patches, or somehow make everyone "play ball"?
J. Ali Harlow: The very first integration that I was involved with was the QT interface. This was before it was integrated into vanilla NetHack in version 3.3. Because of NetHack's good modularity, this was relatively simple and just needed some work to support the extra tilesets that Slash'EM includes and the concept of a secondary weapon, which at the time was unique to Slash'EM.
In a fit of enthusiasm, I then integrated the GTK+ interface into Slash'EM Ranger [the current version]. I don't recall any problems with doing this, although over the years I have slowly rewritten the interface for various reasons until the current version is very different from [the author's] original. It still looks much the same, though.
ORN: Whenever there's a new version of NetHack released, what are the most apparent and immediate elements of its code that need to be altered in order to accommodate Slash'EM?
WC: Actually, the reverse is how traditionally this problem is approached. A difference between the last version of NetHack used as a base and the new version of NetHack is done, generating usually a gargantuan patch modifying almost all the files. Then it's a matter of going through this 5-10 MB patch file and integrating the changes. Most of it is an all-or-nothing deal; you either change everything or only change a very small part of the code. This made the upgrade to NetHack 3.3 fairly scary. There was a period of three months where Slash'EM was basically dead while I slowly whittled away at the patch file.
The massive effort (of which I was only a small part) that tackled the NetHack 3.4.0 upgrade impressed me to no end. That one focused, coordinated effort finished the entire merge in little more than a week.
JAH: I was involved with integrating NetHack 3.4 into Slash'EM Vampire as part of a large team effort including dev team members and others from the NetHack community. This really was a mammoth task made more difficult by the fact that NetHack 3.4 included many bug fixes that had either been contributed by the Slash'EM dev team or had been independently fixed by both dev teams, which meant that each change had to be considered carefully before incorporating into the Slash'EM source. I only did one small part of this and found it quite a chore. I'm very impressed that Warren did all this on his own for the integration of NetHack 3.3.
ORN: What are some of the interesting technical issues you've dealt with when adding your own original features to NetHack?
JAH: One of NetHack's main strengths is the huge range of interactions between objects and the consistency that is maintained while doing this. As soon as you change one thing, you need to think very carefully about what else needs changing to keep consistency. One example of the problems I had with this is my changes to lava handling. My motivation was to make lava pools more consistent with water pools. (There were a number of occasions where objects and monsters would not be damaged by lava pools, whereas in the equivalent situation with water pools, damage would have occurred.) Most of this was straightforward, but now that I had made objects damageable by lava, I had to consider what should happen to containers that were damaged in this way. I decided that all except ice boxes should be destroyed and their contents exposed to the lava and, therefore, also damaged.
Other Linux Interviews
Then there was the issue of objects which are capable of controlled burning (candles and the like). I decided that these should catch fire, but not be destroyed. However, the Candelabrum of Invocation cannot normally be lit if it is cursed. Should lava damage be an exception? I decided that it should, since it seemed to me that it was not unbalancing for a player to use lava to light the candelabrum in this way.
What I'm trying to say is that every change has knock-on consequences and the hardest thing is working through them all and making the right judgment call so that the end result makes a better game. Since this is not my greatest strength, I rely heavily on the slashem-devel mailing list for advice. Slashem-devel is a group of people who are interested in the development of Slash'EM, including the dev team, but also including many other developers and players. Slash'EM would not be the game that it is today without their help.
WC: As Ali said, the interaction of a new feature can have effects all throughout the NetHack world and has to make sense in that context. Nowadays, there's the worry of the interface. With most of the letters being taken on the keyboard, adding new actions isn't quite as simple as it used to be. Part of the challenge is trying to figure out a way to do what you want without overly changing the current interface.
ORN: Regarding the proxy window interface, what would be the complications in switching its protocol from synchronous to asynchronous?
JAH: One of the advantages of the simple arrangement possible when working with a synchronous protocol is that both the client and the server always know whether they should be reading or writing. Since NhExt packets contain a length field in the header, the proxy interface can issue a read call without worrying about the fact that it may block.
With an asynchronous protocol, this will no longer be the case and the proxy interface will have to be able to issue non-blocking read calls. In addition, there will need to be some kind of system for tracking packets so that replies can be associated with requests. Of course, none of these problems are new and have been solved in the X11 protocol, which I am hoping to use as a pattern.
ORN: What are the major difficulties that must be resolved so that window interface queries to the Slash'EM engine can remain flexible, without opening up the game to cheating?
JAH: In order to make the proxy windowing interface as flexible as possible, it needs to have mechanisms for external interfaces to be able to query as much of the internal state of the game as possible, without giving away information that the player should not have access to. The situation is much the same when it comes to modifying the game state, except that external interfaces should have much less need to do this and it's even more important to prevent unintended access.
What we need to do, then, is examine the state information that the game holds and decide which parts should be made available to external interfaces. Once this is established, new remote procedures can be designed to provide the information to prospective external interfaces.
Howard Wen is a freelance writer who has contributed frequently to O'Reilly Network and written for Salon.com, Playboy.com, and Wired, among others.
Return to the Linux DevCenter.
Copyright © 2009 O'Reilly Media, Inc.