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.

Comments

Boris Mann’s picture

A long time ago, in a galaxy far away, I programmed some crazy Java and some crazy XML. ADI, or "Ad Infinitum", was the result.

It had some of the same concepts of extensibility, in that I conceived of it as a base game system or rules environement which would be combined with an environment that defined everything in the system, stored in XML files.

In my crazy idea, each local environment would be a server, and people could load their own configs, and then characters could roam from server to server (ah, agent based technology...how very 1999). Since each server defined the local environment, you might have interesting things like having a swords & sorcery character end up in a far future. I didn't quite get as far as figuring out what happens, but even that is something that could be possible between Drupal servers...(I smell a "character" node type in the future).

If you really want to go with a proven game system, you might want to consider Open Gaming Foundation, which is a pseudo nod to the WotC d20 system.

Awesome post, and I'll follow it with interest in my large amounts of free time.

P.S. I'm a level 52 Drupal Evangelist. I hereby bequeath this Sword of Fiery Newbie Slaying to killes. Hmmm...or perhaps Steven needs to draw a picture of this killes thing that I've heard tell haunts these very forums?

eaton’s picture

Interestingly enough, Drupal provides the sort of flexible system necessary to document an RPG gaming world AND provide a community for the gamers that regularly play it.

For those who've never seen a successful browser-based game like the ones Morbus describes, http://www.kingdomofloathing.com and http://www.urbandead.com are good examples.

I'd second the nomination of core D20 rules (http://www.wizards.com/default.asp?x=d20/welcome) as a basis. It meshes well with Drupal's code philosophy, and also provides a widely recognized standard set of core rules. It's designed to be theme-independent and has been used as the basis for a pretty diverse set of games... There are always ideological battles over how to best manage game mechanics, but the system has momentum.

Very interested in this project. Once I manage to get some of the stuff I'm working on now hammered out, I'd love to help.

--
Jeff Eaton | I heart Drupal.

Thox’s picture

Excuse me for mostly posting this just so it will show up on my tracker. I'd like to keep up to date on how this idea progresses.

Note: I'm also in favour of your section 8 - playable ASAP. I find that a much friendlier way to develop.

Morbus Iff’s picture

I'm familiar with the OGF and the d20 SRD - I remember looking forward to it with interest when it was created. However, the OGF and SRD are ultimately there to sell more D&D game books: the licenses restrict you, for example, from including instructions for how to create a character - you're supposed to run out and pick up the Player's Handbook. This same restriction applies to coding: automation of any of the processes of d20 (combat, character creation, etc.) isn't possible without entirely different licenses and "official" product designations, etc.

http://disobey.com/
http://gamegrene.com/

Boris Mann’s picture

But, wouldn't the program *itself* tell you how to "create a character" -- e.g. node/add/character just walks you through the process.

Wait, wait...I just looked: here's all of the "system reference document" on the WotC site: http://www.wizards.com/default.asp?x=d20/article/srd35

And here are the d20 message boards (vbulletin...boo! :P), with separate forums for each genre...fantasy, modern, etc.: http://boards1.wizards.com/forumdisplay.php?s=&forumid=259

Morbus Iff’s picture

Ultimately, it's whether we want to be d20 certified (no character creation), or just OGL certified, if at all (I personally prefer neither). See the software FAQ. Personally, I'd much rather just utilize a dumbed down version of the d20 rules (dumbed down enough so that they're most assuredly NOT the d20 rules) than use them verbatim - they are, in my opinion, too complicated (legally and comprehensively) for what I'd like to acheive here. There is a lot of stigma around d20, the OGL, and WotC in general (largely in the camp of "d20 sucks!", which I can't say I disagree with), and I'd hate to bring those discussions into this project (either in the design phase, or in the development phase).

http://disobey.com/
http://gamegrene.com/

eaton’s picture

...Is something streamlined enough to be easy to work with, but close enough that adapting D20 based material for a game concept would be easy. Your idea of a 'dumbed down' version of the rules is a good one, I think.

--
Jeff Eaton | I heart Drupal.

merlinofchaos’s picture

I'm with Morbus on this one. There'd be a lot to implement with a proper D20 setup and a lot of it may well be superfluous. I think a project like this would be much better served with a well-thought custom version.

Perhaps something that appeared to be D20 to the user, but was more interesting beneath the hood.

In online games, you generally want wider ranges. D&D3e, to be honest, is only good from about levels 3-11.

-- Merlin

[Point the finger: Assign Blame!]
[Read my writing: ehalseymiles.com]

-- Merlin

[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]

Morbus Iff’s picture

Rightfully so, there have been some comments about exactly what sort of rules system I'm planning here. I've really only talked about the module design, not the rules of the actual game. Here is an quick draft of a combat round. The two assumptions are that a) characters have $num_attacks per round, b) skills are measured on a 100%.

  1. Increment round number and give back $num_attacks.
  2. Find out who's going to attack.
  3. Find out who the attacker is attacking.
  4. Randomly choose an attack for the attacker.
  5. Determine all modifiers and modify skill roll.
  6. Roll against skill roll and remember degree of success.
  7. Calculate damage of attack and add modifier.
  8. Opponent rolls against degree of success on a 1d50.
  9. If roll is higher, opponent has a chance to defend.
    1. Randomly choose a defense.
    2. Do a skill roll for success or failure.
  10. Calculate benefits of defense and add defense modifier.
  11. Apply damage.

The above is a slightly modified version of an old game engine I built, where the goal was to support *fair* fights between say, a Smurf and a Godzilla. Here is a sample of the debug log from that app (note that some of the debug doesn't mesh with the above, but I assume you can mentally modify to fit):

Round 1
. Smurf will now attack - 7 moves remaining.
. Attack chosen was named 'punch'.
. Failure is 25% [1 (attack skill) / 4 (player skill) * 100].
. Difference in size (attacker - opponent): -27.
. Adding size modifier to Botch Roll: (25 + -27)
. Attack will be successful if 1d100 is greater than 0.
. Rolling 1d100: Virgin: 57 / Final: 57
. Success by 57. Rolling damage...
. Rolling 1d2: Virgin: 1 / Final: 1
. Adding strength modifier [1 (damage) + -4 (modifier)].
. Choosing a random description...
. Chosing the only aka: The Tiny Blue Creature
. Chosing a random aka: The Big Green Lizard
The Tiny Blue Creature winds back and clobbers The Big Green Lizard!
Godzilla's hit points drop to 64!

...

. Godzilla will now attack - 2 moves remaining.
. Attack chosen was named 'punch'.
. Failure is 33% [1 (attack skill) / 3 (player skill) * 100].
. Difference in size (attacker - opponent): 27.
. Adding size modifier to Botch Roll: (33 + 27)
. Attack will be successful if 1d100 is greater than 60.
. Rolling 1d100: Virgin: 86 / Final: 86
. Success by 26. Rolling damage...
. Rolling 1d8-1: Virgin: 6 / Final: 5
. Adding strength modifier [5 (damage) + +3 (modifier)].
. Smurf needs higher than 26 to defend.
. Rolling 1d50: Virgin: 29 / Final: 29
. Defense chosen was named 'cower'.
. Failure is 75% [3 (defense skill) / 4 (player skill) * 100].
. Defense will be successful if 1d100 is greater than 75.
. Rolling 1d100: Virgin: 96 / Final: 96
. Total damage after defense is: 4.
. Choosing a random description...
. Chosing the original name: Smurf
. Chosing a random aka: The Big Green Lizard
A huge, fisted claw slams into you! 4 points o... wait!
Smurf cowers in the corner and stops the brunt of The Big Green Lizard's attack!
Smurf's hit points drop to 4!

The old system also had support for counter attacks, fatalities, and combos.

http://disobey.com/
http://gamegrene.com/

merlinofchaos’s picture

# Randomly choose an attack for the attacker.

Not so fond of this idea.

What if my character has one really weak attack, but a few other really strong ones. Why would he ever use that attack?

-- Merlin

[Point the finger: Assign Blame!]
[Read my writing: ehalseymiles.com]

-- Merlin

[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]

Morbus Iff’s picture

Well, in my opinion, that would be possible. The goal with the randomness was speed: if it takes me twenty attacks to kill a monster, then I'm eventually going to want to click "attack for five rounds" or "attack until i'm nearly dead" buttons. Those buttons would do the randomization. If, however, you really did want to manually pick your twenty attacks, and do twenty page loads in a combat round, you'd have that ability to (either from the very beginning, or after clicking any of the other buttons). Random attacks would be necessary for flavor in monsters and so forth: I really wanted the combat text to be remotely interesting to read, as opposed to all numbers.

http://disobey.com/
http://gamegrene.com/

Boris Mann’s picture

Random makes sense for the NPCs, not so much for characters.

A count down timer in AJAX and some sort of radio button/toggle system which allows players to select attacks/special moves (think a cooldown period for some specials) might be interesting.

You can set the toggle and just sit back and wait (choose/set the countdown time and/or select a checkbox that says "Finish combat" that just uses that choice all the way through or until events are met...eg. low hp warning).

I've been playing some WoW, and the mechanics there might be interesting to look at. It's actual similar to the way I modelled different "power sources" for abilities in ADI.

Morbus, do we maybe want to set up a wiki somewhere to start capturing these ideas? Feel free to use either the trac-based dev wiki or the Drupal-based one. The dev one might be better since I can set up SVN accounts there. I started a GameApe page that you're free to use or ignore.

Morbus Iff’s picture

I'm a big fan of the way WoW does things (in fact, we're doing a raid into the Molten Core tonight [g]), and that is definitely a direction I want to go in (stat/skill/item-wise). As for the wiki, I don't think we really need an off-site SVN for this - I was thinking of just starting in my Drupal sandbox, and letting anyone else commit into that too. I'm fine with using the trac wiki though - I've been wanting to get more familiar with how trac works anyways. As for the page names, any particular reason for "Game Ape"? While I didn't give it a load of thought, I was thinking just "game" for the module name and "gameapi" for the API.

http://disobey.com/
http://gamegrene.com/

Boris Mann’s picture

I was rolling around the sound of "gameapi" and realizing that, of course, the system needs a name of some sort.

So....Game Ape? The .org is available, and some Google searches don't show any obvious collisions.

As I said, feel free to use or ignore as needed...I'll take my pencil and paper along with me over my offline holidays and think up a few more things and dig out any other rules system stuff that I had laying around.

Morbus Iff’s picture

I'm not sure it really needs a name besides "game" - the goal, ultimately, is to create a framework for other people to make their own magick with (with their own names), not to create a brand.

http://disobey.com/
http://gamegrene.com/

Morbus Iff’s picture

In hindsight, I suspect you're looking for a community site where game makers can go to and share their creations, play the "master" game, or otherwise wax poetic for help. WIth that said, I'd say we can just use my gamegrene.com - it's got an active community of roleplayers already. I can go ahead and set up a developer forum on there now, with an initial post pointing here - lemme know.

http://disobey.com/
http://gamegrene.com/

Boris Mann’s picture

I was thinking of the rules system, at least some of which has to have a defined framework -- like character and creature attributes, for one.

merlinofchaos’s picture

I also was never fond of percentile systems, because they don't particularly scale well. I've always preferred the D20 style skill vs target, except the roll should be more on a bell-curve.

-- Merlin

[Point the finger: Assign Blame!]
[Read my writing: ehalseymiles.com]

-- Merlin

[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]

merlinofchaos’s picture

Summary of an IRC discussion on the topic.

My personal feeling is that using a bell curve to control attacking rather than pure percentile gives more interesting results.

In this kind of system, a given character has an Attack score, and another character has a Defense score.

The system uses a die roll that is a bunch of dice. A simple version (and I don't suggest using this but throw it out for example purposes) is a postive d6 and a negative d6, ala the Feng Shui/Nexus system. That gives a result of -5 - +5 clustered around 0. The attacker rolls, adds that the attack score, and if the score is higher than the Defense score, it is a hit.

The difference between attack and defense can optionally be used as a damage modifier -- rewarding really good rolls with extra damage.

In a system such as this, the actual roll would probably be something that gave a range in hundreds of points, making very high attack scores possible but requiring a very large difference between attack/defense for hits to be automatic.

-- Merlin

[Point the finger: Assign Blame!]
[Read my writing: ehalseymiles.com]

-- Merlin

[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]

eaton’s picture

And voice support for these statistical checks being 'success vs failure' calculations, rather than pure attack. Not all actions are combat. 'Attack and defense' can be considered 'Attempt and resist', I think.

--
Jeff Eaton | I heart Drupal.

Cvbge’s picture

Wow girl, you really got us all. Hiding your gender for all this time...

Anyway, have a happy pregnancy and good luck with your delivery!
;)

skor’s picture

Don't tell your little one about your domain name.

stevryn’s picture

Hmm the profile says male? Did I miss some modern medicine miracle? I have always said men need to experience pregnancy and childbirth personally....how much more understanding and sympathetic they would be!!!

congrats on your good news!

Geary’s picture

This dude is pregnant?

Or maybe the better half? :-)

aaron’s picture

This is an excellent project idea, one I'd love to put some spare time into. I'm looking forward to a forum where we can start tackling some rules ideas. I'd personally actually want to go the way of FUDGE, at least as far as having really simple stats/skills, thus allowing the gameapi's to plug in and do their magic with. Though it sounds like you plan to go another route, and I'm fine with that.

I think that whatever happens, it's important to keep it simple, as far as the framework. That's the power of Drupal, and I'd love to see that power implemented in the Game module and API.

- Aaron

Digital Folk Art (my blog)

Drupal Multimedia (my book)
AaronWinborn.com (my blog)
Advomatic (Web Tools for Progressive Advocacy)

aaron’s picture

Oh, and congrats on your pregnancy. Will this be your first? Our daughter just turned two, and that's been a beautiful path in our lives.

- Aaron
Digital Folk Art (my blog)

Drupal Multimedia (my book)
AaronWinborn.com (my blog)
Advomatic (Web Tools for Progressive Advocacy)

Morbus Iff’s picture

Yes, it'll be our first. We'll know the sex in a few weeks.

Regarding FUDGE, I did give it a lot of thought on using that as the system. Unfortunately, as you know, the rules system is largely catered to easier face-to-face play and, because there's no true system "out of the box", there is no "traditional" FUDGE system that I think a large portion of gamers would be immediately familiar with (nor any popular systems of escalating wound charts). At the moment, I'm personally leaning toward a World of Warcraft-like system (the computer game, not the actual paper RPG), which is pretty immediate to pick up, and was built for the same environment we're focusing on (online play). If you know nothing about WoW, you can pretty much get an idea of everything by staring at my character sheet (no login required).

As for forums, I'll probably be setting up something on my gamegrene.com, which has a healthy audience of RPGers (which is good, as they are exactly the people that the data files need to be understandable by). This'll help create a healthy amount of bleed/mixing of the communities too. However, I probably won't set those forums up until next week sometime, after I've written a bit more documentation on the simplistic rules system I have in mind.

http://www.disobey.com/
http://www.gamegrene.com/

Fool2’s picture

I was also thinking about the possibility of making a strategy-type text game rather than an RPG.

Something like Utopia, Starkingdoms, Star-Fury, or maybe even Nation States (I don't even know if these are around anymore) but it pretty much involves you having land which create resources and attacking other people and stealing their land etc.

I think drupal would be perfect for this because these game systems are cron based. If I ever find myself bored I will definitely be interested in programming a game.

Count me interested

deanypop’s picture

Not to mention that a lot of fun things could be done in drupal around a CCG (collectible card game)... Many of which might promote drupalisms more directly (give user card after X logins/posts, or after visiting a specific node, allow for trading, track 'values' of cards, whatever). Also, unless I'm mistaken, CCGs tend to require better/more rigid rulesets - both to allow for easy pickup/play, as well as expansion of cards without completely destroying the game itself (though, I can imagine a few CCGs where this eventually happens due to successive rules additions trying to address game imbalances that arise). I can even picture allowing the specific rules to change based on the taxonomy of the "playfield" node... Perhaps allowing for a hybrid card/web-RPG that uses cards for conflict resolution but still allows for navigation/interaction in the same "standard" RPG ways?

Anyway, just a thought. I guess I just see the drupal + game as needing "more" drupal - otherwise, why not just embed a php/html game engine that already does what you want?

Morbus Iff’s picture

As mentioned in the original post, I'm sticking strictly to a "traditional" HTML based browser RPG at the moment - making a gameapi that is everything to everyone is delicious, but has been tried, and failed, many times. That certainly doesn't mean it isn't possible to do parts of what you'd like - the API in my head would let plugins create and control their own attributes (such as "Land Resources: 50"), and use them as they see fit ("If resources spent are 50, build new house.").

As for CCGs, games I absolutely adore too, I spent a good three or four months working on that (and, in fact, have some Drupal code that creates a UI for card and set creation, listings, etc., as well as integrates with a Flash widget to display cards all purdy-like) but, for various reasons, put it on the back burner and returned to RPGs. The most difficult part of a browser based CCG is creating fast and visual gameplay: it's very difficult to do M:TG-like "instants". What happens, visually, after you play a card is cumbersome too (if you play "heal +20", then refresh the page and discover half your creatures gone, where do you look to see that your opponent played a "-10 to all creatures" card, besides a lackluster log file onscreen? I'd like to do CCGs, but not today; we could certainly make card items in this API though, with their own actions.

http://www.disobey.com/
http://www.gamegrene.com/

Morbus Iff’s picture

Incidentally, the exact reason I'm not porting another game to Drupal is because I want as many Drupalisms as possible (and, honestly, none of the web based open source game engines I've seen do much of anything that I actually want). The race-related API I'm working on (a "proof of concept" demo next week, hopefully) will allow a race-creator to decide if a) his race is always visible to everyone, b) his race is visible, but selectable only to those who meet some requirements ("a Drupal user of this site for more than six months"), c) his race is invisible, and only visible and selectable by certain conditions ("has this user written more than 100 comments?", "does any character of this user have a certain item?", etc.). And so on.

http://www.disobey.com/
http://www.gamegrene.com/

Boris Mann’s picture

So, to boil that down...the name for that function is "unlocking hidden characters", like in many console games. Very cool!

Morbus, I'd love to do some work on race/skill creation, but of course we need to nail down attributes first. Any thoughts there? Yeah, the forum is probably needed on gamegrene to kick around this stuff more...

Morbus Iff’s picture

The primary means of communications I've setup for the project: the forums at Gamegrene.com. The site is currently running Drupal 4.6 - the game.module will be developed under 4.7. Naturally, this means I'll be switching over to 4.7 sometime in the next few months (as well as moving gamegrene.com to a new host, something I did with my own disobey.com a few months ago).

http://www.disobey.com/
http://www.gamegrene.com/

adrian’s picture

Is a proper web 2.0 version of the game at urbandead.com

Basically, it's a post apocalyptic pseudo real time 'rpg' where you play either a zombie, or a human (with a certain class).

You walk around on a grid, going into shops and finding weapons .. and then run around killing zombies. When you die , you become a zombie, and there's a way to become human again from being a zombie.

My idea however is to tie it into google maps, and do an urban dead - los angeles, or new york .. and cordon off an area of the city and run around slaughtering each other in that, along with information from a9 .. you actually find guns in gun shops .. and bats in sporting good shops.

zombies are cool =)

--
The future is so Bryght, I have to wear shades.

NaX’s picture

I am looking for a browser based chess game that I can integrate into my site. It would be a lot less complicated than a RPG, but users should be able to create games and invite a user to that game, and track win/loss with ever user.

I just need a starting point of a working game that I can port and integrate. I am not a brilliant PHP dev but I am willing to give it a try.

aaron’s picture

Ok, here's an unofficial announcement of Spindowners, the game I'm designing, with plans to use the Game-API module for Drupal as/after it becomes developed. I know it sounds a little premature, but I've been working on the concept for awhile, and Morbus's decision to begin development of a Game-API for Drupal timely coincided with my plans. I plan to be active in the development of Game-API as well, of course.

Spindowners is a web-based role-playing game. It will be turn-based, in the tradition of LoRD and Urban Dead. It also has a layer of political intrigue and diplomacy thrown in for good measure. In fact, some may find this aspect of it more interesting and fun than the tactical play of day-to-day. Hopefully, most players will enjoy a healthy balance of both.

On the mundane level, each player controls a character. (Multiple characters may be allowed, but that will have to be tightly controlled, probably in a fashion that Urban Dead allows). These characters will be allowed a certain number of in-game actions per day.

The game takes place inside of a giant wheel-shaped satellite, host to millions in an intergalactic empire. Some of the people on the satellite call it home, and refer to themselves as Spindowners. The bulk of the rest are just passing through.

Or were, until war just struck, heralded by an explosion that disabled the satellite and stranded those millions. Factions and governments arise out of the ensuing anarchy, all vieing for control of the hub.

In the meta-game, taking place largely in forums and blogs, characters may negotiate and take part in the governments and societies running the hub. In the anarchy of war, many small and large governments may form or dissolve spontaneously. The forums will allow for many types, from democracies to oligarchies to dictatorships. They may take the form of national governments, corporations, mercenary groups, and neighborhood watch groups.

You can read more at Spindowners.com, and are welcome to become part of the development process. I'm planning to be active at Gamegrene as well, considering the nature of what's happening. The Game-API will be a great addition to the world of Drupal and Open Sourcing, and I am excited to be a part of it!

- Aaron

Spindowners
Digital Folk Art (my other blog)

Drupal Multimedia (my book)
AaronWinborn.com (my blog)
Advomatic (Web Tools for Progressive Advocacy)

aaron’s picture

People watching this thread might want to also read the post about GameAPI: Updates and Map Making that Morbus posted recently if they haven't already.

- Aaron

Spindowners (a text-based sci-fi mmorpg being developed with the upcoming Game module for Drupal)

Drupal Multimedia (my book)
AaronWinborn.com (my blog)
Advomatic (Web Tools for Progressive Advocacy)

aaron’s picture

New group at http://groups.drupal.org/games-and-game-apis for those watching...

Aaron Winborn
Spindowners (A web text-based sci-fi rpg in development...)
Advomatic (Web Design for Progressive Advocacy, Grassroots Movements, and Really Cool Causes)

Drupal Multimedia (my book)
AaronWinborn.com (my blog)
Advomatic (Web Tools for Progressive Advocacy)