I am pregnant (woohoo!). In six short months, I will be disappearing from active duty in the Drupal community for a good long time. I'd like to discuss a desire I've had for years and years, only reworked for our beloved codebase. In short: an HTML based browser role playing game, though ultimately an API.

My Assumptions of the Reader

• You're familiar with HTML based browser games.
• You're familiar with paper role playing games.
• You have a passing familiarity with MUDs and BBS door games.
• You've read my ancient battleplan from the link above.

The Desired Final Product

1. All game data stored in external files.
2. The default game data files are multi-genre.
3. A gamesapi is created, much like the nodeapi.
4. Races, classes, weapons, armors, items, rooms, quests.
5. Skills and similar "addons" (magic, psionics, bionics, etc.).
6. Not real-time (like BBS door game Legend of the Red Dragon).
7. "Traditional" combat/statistics systems for easy understanding.
8. Focus on "playable ASAP" as opposed to UltimateDoesEverything!

Approaches to our Final Product
1. All game data stored in external files.

This is the most crucial bit of my design: to mimick the extensibility of an LPMud (grab Dead Souls, extract it, look in the /lib directory). It is absolutely imperative that game data (the monsters, objects, NPCs, rooms, quests, etc., that collectively make up the game world) is easily shareable, easily modifiable, easily commented, and easily updated. I think the lack of this, where game data is primarily stored amongst dozens of relational databases, is why other HTML based browser games usually only have one "main" server and a few rare offshoot servers: it's just not easy to "roll your own". See also the next section.

Thus, individual bits become individual files: a troll would be stored in races/troll.inc, a sword in weapons/short_sword.inc, areas (being a collection of rooms) in areas/desert.inc, and so on. If someone wants to create a spankin' new race, they can just copy and rename troll.inc to fairy.inc, modify the innards, and load it via an admin interface. If someone wants to grab killes' awesome "angry german" NPC, they'd just download his file, plop it into the right place, and enable it. Updating objects follows the same procedure.

The immediate concern is "well if I had 500 monsters, that'd be 500 files, right?" which is quite true, and why we'd use .inc instead of .module - Drupal doesn't automatically load .inc files (so we don't have that overhead) and, when needed, we can specify which files we need at the right time (if you're only fighting one monster, we just load that particular .inc, not the other 499).

2. The default game data files are multi-genre.

The best, and worst, thing you can do with a game framework is to ship dummy game data with it. On one hand, the game is playable "outta the box". On the other, you've mentally constrained the person to a genre: if all the dummy data is fantasy-related, folks are gonna think it's that way for a reason. This then creates a glut of the same old boring games and settings on multiple servers, with a fight for "who has the most fantasy races". Boring, boring.

Any sample data shipped with the default game API should be multi-genre. Smurfs battle it out with Jean-Luc Picard. A swordsman locks horn with that guy from that movie that had that cool scene in it. Plate-mail blocks Cthulhu cajones. In other words: crazy reality that couldn't possibly happen. Why? To force people to mess with the data files: if I only want a fantasy world, I'm gonna wanna delete Jean-Luc Picard. If I see that it's as easy as disabling npcs/jean-luc_picard.inc, then I'm a lot closer to copying that file into, say, npcs/elfqueen_badname.inc. This bit of psychology has but one purpose: to encourage people to change things, in a way that is much easier than SQL edits.

3. A gamesapi is created, much like the nodeapi.

Along with the "modify the strings and numbers" approach of, say, creating a new race, there'd also be a gamesapi to faciliate the creation of advanced plugins. To go back to Legend of the Red Dragon, think of the default "explore forest": there were only a few random events that happened besides monster battles. IGMs, or inner game modules, changed this by adding new events to standard exploration. Add in 50 IGMs, and you could have fifty or more random forest events, locations, custom NPCs (innkeepers you could buy from, fortunetellers that granted boons, petshop keepers), etc.

Something similar needs to be possible herein. A weather plugin could hook into gamesapi_attack, reducing the skill of your attack in bad weather. Hooks into gamesapi_travel could generate dozens of new random events and gamesapi_location could allow you to create an inn or pub with buxom maids and custom favors. The API should be everywhere (these were hastily created examples and not final).

4, 5: Races, classes, weapons, armors, objects, rooms, quests, skills.

These are a few of my favorite things. They gotta be in there.

6: Not real-time (like BBS door game Legend of the Red Dragon).

If you've had visions of a browser MUD, with real time chatting and events and so forth, lose them. Whilst it'd be possible to do some occasional real time events (AJAX chat in an inn, etc.), the framework would be largely turn / page-reload based. PvP would be handled like LoRD: you state who you're attacking, your opponent becomes computer controlled (and always "do or die"; attempting the highest damage and the best heals), and you can't run. Scoreboards and history would be kept to keep gamers informed.

7. "Traditional" combat/statistics systems for easy understanding.

There are plenty of innovative rules systems out there; this is not the place to implement them. The fact that a game is being built inside Drupal, with a gamesapi, is innovative enough, for now. First, we need to gain critical mass, and that means the lowest common denominator regarding rules. Think strength, constitution, intelligence, dexterity, wisdom (maybe charisma), min/max damage (not in dice notation, but "10 to 24"), skill levels to provide bonuses, armor to reduce damage, hit points, mana points, blah blah blah.

8. Focus on "playable ASAP" as opposed to UltimateDoesEverything!

This framework would be built using iterative design principles: the sooner something works, the better. Thus, we'd first implement a UI for race selection. A race is selected and... game over. Then class selection. A class is selected and... game over. And so on. There are a zillion different ways games can be made: I have five months left to code, and I'd rather generate interest in working, and revisable, code, then design docs that cater to absolutely no one in particular and try to do too much. We shouldn't try to build in support for puzzle games. Or FUDGE rules. Or real time strategy. Lowest common denominator: a traditional RPG, web based, with external data files. Pique the curiosity of the game and Drupal communities; create enough sample data to entice worldbuilders; build enough sample plugins to arouse know-a-little developers; support theming; make lots of hooks you doubt will ever be useful; let folks surprise you.

Funding the Work

I have a healthy interest in seeing something happen in the next five months: I consider it my final "hurrah" before my life changes forever. With that said, and the particular cause of my inevitable disappearance, I wouldn't mind receiving some funding. Naturally, you'd be fully credited in the documentation ("wow, that benefactor really got it; a game within a CMS? who knew!") and I'd sing your praises. If you've any heart within that cold, cold bank vault of yours, don't hesitate to contact me with your intentions.

Be an Idol... My Idol...

Since I'll be focusing on iterative development, there's no guarentee they'll actually be a game available to play at the end of my available time - it could just be a bunch of data files and UI, with no clear interaction between any of them. Thus I'd love to see some healthy interest from other developers, who'll ride along with me and take the reins once I saunter off into the wailing sunset. After some meandering discussions within #drupal, there does seem to be valid interest in the idea, enough so that prompted this long writeup of my intentions.

The "add new comment" is there for a reason, bub. Wake me up.

Drupal version: Drupal 4.7.x