It is my hope that as object oriented programming increases in use and scope, front ends/clients will be developed independently from the "logical" game engines themselves. This would let graphics oriented programmers and artists work on the GUIs, and logic/rules oriented programmers work on the game engines, with neither team needing to interface with the other except to specify a standard set of "messages" that will be passed back and forth between their objects.
Once that messaging standard is defined (much like HTML was specified), it could be used by multiple games, and not just games created by the same company or group of developers. To work best, the messaging standards would be have to be public. What you'd end up with is a bunch of commercial and freeware modules which you, as a player, would get to assemble to your own liking. Yes, that's right: a la carte game playing!
This concept is already being explored in Multi User Dungeons (MUDs), where multiple MUD clients can access multiple MUD servers. Players pick their favorite client and their favorite server, which allows them to maximize their enjoyment. Wouldn't it be nice if more genres of games were like that?
It doesn't just have to be games, either. Database interfaces, command shells, all those application GUIs, should all be independent of the database, operating system, and application modules themselves. Taking a cue from MUDs' client/server remoteness, the modules should be distributed as well. But that's getting beyond the scope of this particular topic.
Anyway, back to Roguelike Games, someone could play the NetHack Brains Module with the SuperTrav FrontEnd Module, then play the Angband Brains Module using the same front end, and then a few weeks later try both games with a new front end, without ever having to download new NetHack or Angband Brain Modules.
Or, breaking it down further, someone could play with the NetHack Dungeon Module, the Angband Items Module, the Omega Monsters Module, the ADOM Wilderness Module and the SuperTrav FrontEnd Module.
These thoughts lead us to the next topic (MetaHack).
I wrote the above topic article back in 1996, when I was all hyper about object oriented programming, modularity, and essentially what is now being consider the component-based paradigm. Personally, I think the article is naive and boring. As a player, I don't feel any desire to continue that train of thought. As a potential developer... well, I don't really feel any desire to continue that train of thought either.
Okay, fine. For the sake of finishing what I started, I'll make myself talk about it...
Right now I'm not so sure that increased modularity is the key to Roguelike gaming happiness. It takes time to learn how to use interfaces, even when implementations are hidden. The more general and flexible a component is, the more inefficient it is [due to overhead], the longer it takes to develop [and debug], the longer it takes to learn to use [since so many features are supported that you will never use but must wade through], and the more likely it is to cost money [due to the high costs of development]. This is counter to the spirit of Roguelike game development.
Okay, enough about that. If I feel like delving into this topic further, I might come back to it. Also, if you have your own thoughts you'd like me to add, you can send them to me.
Nowadays, mods (not MUDs) are very popular. Most of the commercial games I've played in the last 5 years have mods. If we don't like the units, spells, or terrain in a game, we can change them (or download someone else's changes). There are even "total conversions" which alter the game's basic interface.
Modularity in games is so popular now that there's no need to evangelize it anymore.