NetHack is OSS. It's developed and maintained by the NetHack Consortium. That's a volunteer group that, like the Apache group, votes on changes to the basic code, one of the most common and most successful OSS development methodologies. It's cool. Download it now.

But it's also a mature product. The last major upgrade was v3.2.2, released in December 1996. The kinks have been worked out. There's not a lot of reason to add more to the game; it's already incredibly deep.

But you know--it is an old-style product. It looked cool back in the early '80s, but modern games ought to have GUI interfaces and stylish graphics....

Is there any way to update NetHack for the modern world?

Will artists work for egoboo?

Maybe.

The problem is this: modern game development is not mainly a programming task. Typically, 80 percent of a game's budget goes on media assets--all the graphics, animations, cut scenes, sounds, music, and so on. The other 20 percent gets shared among programming, game design, and project management. Of those three, programming is the largest bit, but it's still a small fraction of the game development project.

It's easy enough to say "Hey, kids, let's update NetHack for the multimedia world," but a big problem arises immediately. OSS development harnesses the desire of programmers to gain egoboo and streetcred. But programming is a tiny bit of the pie....

To update NetHack, you need somehow to inculcate artists with the open-source, potluck, give-and-get ethos. You need to get animators and graphic designers and sound people to say, "Cool, I want a piece of this, here's 40 frames of animation for a zorn" (one of NetHack's monsters). You need to get them to work for free--just like a hacker.

Is that possible?

I don't know. But let's think about it. Suppose we design--let's call it VisualHack--so that the user at any time can get info about a particular graphic or sound. Right-click on the zorn, say, and among the items that shows up on the pop-up menu is "Artist"--and if you select that, you get "Zorn animations by Igor Renderman."

So our buddy Igor gets his name out there, gets it seen by thousands, maybe millions of players. And when he puts together his portfolio to show to game developers, he can say "I did the animations for 16 critters in VisualHack."

In other words, design the product from the inception to cater to the egoboo of artists and designers. Design it specifically to inculcate the mindset we need.

Would that work? Who knows? Maybe it would, maybe it wouldn't. But there are some clear advantages for graphic guys, particularly ones who don't currently have many game development credentials. This is a good credential to stick on your resume, a good set of images for your portfolio. It's a way to say, look, I haven't done a lot of work in the industry, but I've contributed to an actual, released product that's reached a large number of players. I've shown I can carry something to completion. I've done something cool.

It's a cheap way to showcase your work.

Structuring the project
Let's think a little bit about what we'd need to do to make VisualHack work.

The purpose shouldn't be to change the game qua game much, or at all. The purpose should be to provide cool animations and images along with an intuitive interface that doesn't require players to memorize the function of each keystroke. To make it, in short, a game with the graphical qualities and appeal of a full-featured, commercial game, but without many of the wholly unnecessary, marketing-driven features like animated cut scenes and real-time 3D.

Room for improvement, visually.

A lot of the basic code in NetHack can be borrowed, but we need support for a GUI interface and graphics and sound display. All of that stuff has to be funnelled through an abstraction layer; that is, the code shouldn't make DirectX or Windows calls, but should call abstracted windowing objects. Those objects would then be compiled differently for different platforms--one set for Linux boxes, another for Windows or DOS machines. That's necessary to preserve code transportability across OSes.

The short-term objective should be to ensure functional versions for Linux and Wintel machines; if it runs on Linux, it should run reasonably well on other Unix variants as well. Mac, BeOS, and other support would depend on programmers willing to code the platform-specific routines necessary for those OSes. The development team should be open to people willing to do that work, but that shouldn't be considered key functionality.

We'd need a graphical, point-and-click interface; ideally, the game should never require a keypress. Inventory should show up in a panel that remains onscreen. We probably want an oblique overhead view with prerendered 3D images; there seems no compelling reason to use real-time 3D, since we don't have to sell the buyer from CompUSA on the project.

Next page: then there's the art...