I have recently finished two large projects that are totally non-game related and have found the urge to get back into online gaming from the development side. Enthusiastically, I jumped into the entertainment section of the module listing and was surprised to see how many arcade style games were now available. I also took a peak at the game module, it's rationale and think and hope that goes forward. My initial thoughts were that it seemed to be rebuilding the wheel in many aspects. "An API much like nodeapi". I guess I don't understand why you need an entire new API? Just sitting here, with my scratch pad and pen, I jotted down a geographical system whereby players moved around "rooms". Rooms are simply nodes, and using nodeapi $op view, we know exactly where the player is. Anyway, I did a ton of programming using MOO way back on Xerox's MOO code. Loved it. It reminds me a lot of php in many ways. One thing I loved about MOO code was that it provided a framework to make ANYTHING. Fantasy, future, etc. If you wanted dice, you make it dice based. Since the MOO I was running around on was Steve Jackson Games', I just recreated their famous "Hacker" card game as a text based version on the computer, only instead of staring a bunch cards on the table, there was a simulated XTerminal complete with unix prompts, (which of course changed to root when you hacked that account). It was a lot of fun to do, and play. Amazingly, 1 month after completing my generic network, and generic computer which the game ran on, Steve Jackson Games took down the MOO, and my code was lost forever!! :( Maybe it had something to do with the fact that they actually created the game??
Anyway.. I'm rambling. My point is that what is really needed is a generic (I love that term) framwork for a few simple operations.
1)Geography - Where is the player?
2)Real time updates - you really don't want to find out you have been hacked or shot at 10 times after you do one page refresh.
3)Combat - This should be turnbased.
4)Multiplayer - this is the internet.. You must allow people to fight each other, and partner. If you're worried about PvP the easiest way to deal with that is to make the game lethal. You die, and you die. You lose everything and start over at square 1. You give weak characters the option to run and hide. It's an aspect of online gaming that has been completely mismanaged.
Most everything can be done with drupal already.. geography, storage and security. The one aspect that needs work is live updating. From there, combat isn't that big of a deal.
I am going to move forward with this as I have an idea for something really different gamewise, but as I said, I'd like the framework to be generic and expansible. I'm going to look at the live update module to see if there is anyway to incorporate it. Then do geography. My thought is node references connect rooms, and nodeapi keeps track of what room you're in. Store player->location somewhere, maybe the data array, maybe as a field on the character which would be a node, with user reference back to $user.
My weakness is AJAX and Jquery.. I just have not done a lot with it. I'll be happy to provide anyone with code or post as I go along. I have never hosted a project on Drupal, but would be okay with doing it that way.
Why don't I dive into game and contribute? I looked at the code and basic framework and it's not going to fit my special project, that's all.
Comments
Sounds like you looked at the
Sounds like you looked at the 6.x release of the Game module. That's nearly two years old. I wouldn't say much about it.
Anyways, using nodes as game objects has a lot of pros and cons. Various designs have approached game objects in multiple ways. Given the fact that Field API is in Drupal 7.x, I would reconsider all previous arguments for and against nodes (though, I would argue that it makes upgrading and customization even harder). Even with Field API, it still doesn't solve my primary conceit for node based game objects: you can't easily share them. Similar to LPMud, every game design I've ever made has had game objects in a file (be it a PHP or XML or JSON file). The ability to create and share game objects, with versioning capabilities and being able to diff changes between previous/new versions, is crucially important to me. That has always been the death knell for using the node system for me.
Anyways, after working on game.module 6.x (or was it 5.x? I can't even remember), I left it for a long time, then came back and started a new approach in game.module, based on recreating the D&D Miniatures ruleset, again with units as external PHP .inc files (versus nodes). It worked well enough, had a decent API to it to support all manner of additional conditions (http://groups.drupal.org/node/17069), and had AI as literal Drupal users (http://groups.drupal.org/node/17203). Ideally, I never finished that one either. Then I started working on a card-based combat engine, and got a prototype of that up and working, with an API, yadda yadda. I tend to lose interest in coding games really fast though. I talk more about that at http://www.disobey.com/node/1822 and http://www.disobey.com/node/1856.
The saddest part of it all is that I've yet to find a really good browser based game that tells a story. None of my existing attempts have, and the game engine you describe above doesn't make a mention of it either (potentially because, like MOOs and MUDs, there isn't really strong support for such a thing there either - the story is in the hands of the players RP, based on the environment they've been given). As I sit down to the boring task of writing code, all I can think about is the story or world I'd like to make underneath them. And the ability for others to share that world (via shared libraries/game objects) and contribute to it.
Which isn't to say I stop thinking about game engines or rulesets. I've dreamt up about three or four since the last time I've worked on code, and they've all been gravitating toward the casual game genre - stuff that folks can play in fifteen minutes, or through Facebook. No Facebook game tells a story either (the only one I would really count was VPN Wars, and the developer totally decided to remove all traces of it from Facebook and their corporate website).
Anyways, my 2 cents.
I never heard of VPN Wars.
I never heard of VPN Wars. Was it good?
Anyway, I have a Flash-powered game in the works. It is being designed to work with the Drupal database (save data to the user's account), but I'm not 100% sure how to make Drupal interact with the new data. A new module needs to be developed specifically for said game, so I wonder why I should bother to use Drupal for it.
Visit my under-construction site. Let me know what you think. Thanks.
VPN Wars was "eh". The VPN
VPN Wars was "eh". The VPN stood for "Vikings, Pirates, Ninja", so you can just imagine from there what it was about: it was a Mafia Wars-like game where you could pick one of three primary classes to advance in. There was more to it then that - there was more collection and hidden questy things, and some attempt to tell a story (primarily through the progressive mission descriptions). It was pretty well done. No idea why Meteor Games decided to just dump it (I think there was some database crash, then they said "eh, it was just a passing interest until we got our REAL game up", and then they removed all mention of it, and called Island Paradise their "flagship" title. It's just another Farmville. BoOoOoriIing.
Oh, and incidentally, yeah, I
Oh, and incidentally, yeah, I don't really think that a Flash game that uses Drupal as a datastore is a "Drupal game". A Drupal game, in my opinion, can not functionally operate, or be easily ported away from, without Drupal. Flash games, AJAX games, etc., don't count.
Oh, there's story.. big story.
I have a very unique story. It just needs something to live in! :) I wrote screenplays for about 7 years, never sold one, but won a big contest once..so, I completely agree, it has to have a story.. Look at the great games over the years, deep good story: Wasteland, Metal Gear Solid, GTA, Fallout 3, and of course all the infocom games. A good game HAS to have a story or it loses me.. I don't care how good the graphics are. Give me fair graphics, and I can love the game if it has a good back story..Wasteland is a case in point.. I replayed it about a year ago for kicks, although, I'll say the combat almost bored me to death the second time around.
Back to node based games. I think the combination you're looking for a portable game that has a great story isn't possible. The great story can't be ported, only the framework it sits in. By creating mobs, or weapons that are ported, the new game they are ported too automatically becomes unoriginal. Think Aliens I, II, III, IV etc. I lost my interest after II.. I loved II only because it went from horror genre to suspense. Blah blah.. My point that I am not making very well is that the great thing about MOO code was that it started with User 1.. That was it. No other generics (unless you ported them) but who wanted to? You wanted it all original and it had to be because everyone had already started the game by "Comes out of the closet, literally" once already. It had to be different.
So, I don't really care about portability. I don't really care about sharing either EXCEPT that I have used a lot of peoples code and thoughts in my drupal projects and I thought, this time, I need to make it a format that can be shared, be it good or bad, let the user decide and if they like it, so be it.
Nodes can be shared though. A node module is the way to go. Yes CCK is easier but most modules that need specialized nodes make them (Ubercart, etc). It's just not practical to expect the user to replicate a CCK node. Mysql is better than files. It's existence is proof and lastly, one can always dump the database for others to use.
"Nodes can be shared". I'd
"Nodes can be shared". I'd love to hear how you plan to handle versioning (when someone changes their version of Animal ABC), structural changes (when someone adds, or modifies, the fields assigned to a node structure), or similar clashes (how you know ID "vampire" is the same ID "vampire" you're exporting/importing). Exporting and importing (more accurately, merging) MySQL exports, based on your statement, is clearly something you've never actually done before. It's just not as simple as you're trying to make it.
Note that I'm not advocating that you create Awesome Great Story and then you export it and someone else suddenly has their own copy of Awesome Great Story. I'm advocating that someone may want "Medieval Monsters from D&D" in their cyberpunk world, they want to start from version 3.2 of your build, add their own, tweak some of the descriptions you've made, and be able to upgrade to version 3.3 when and if it comes out (which wouldn't blindly overwrite their revised editions, but WOULD overright playtested or nerfed/improved statistics).
So.
"I'd love to hear how you plan to handle versioning (when someone changes their version of Animal ABC), structural changes (when someone adds, or modifies, the fields assigned to a node structure)"
You wouldn't EVER EVER do this in drupal, you override it.
It sounds to me that you are wanting to create something that someone can change, modify with a text editor. Then you're absolutely right, don't use nodes. In fact, why even use drupal?? Just write the whole thing from scratch if you're going to throw out all the great advantages of drupal.
When you want to add an attribute to a monster, you do it with a module. Just like it's always been done with drupal. In ubercart, when you want to change product attributes, or create a new product altogether, you don't go alter the source code or create a new data file somewhere.
Also, due to the beauty of all of this, migrating data from one ecommerce site ie (product nodes) to another is very simple and if I want to change the product attributes, it's also very simple and in fact it's simple for the end user because some considerate programmer has made it so.
And no, I try to stay away from merging mysql databases, Instead I do everything possible to avoid that and thankfully it's really quite simple if the framework promotes this.
Let's agree to disagree. My point, drupal saves a ton of time and everything you describe above can be done with modules and overrides. If you want to do it old school and require a user to put data into a file using wordpad, that's okay, just not my cup of beans and I don't think anything is wrong with it. I just can't imagine using the same technique to modify anything else in drupal, so I'm not sure why a game is so different. It's all just information that interacts, be it product nodes, or monster nodes.
Sure, I see your point that in the beginning it's easier to allow someone to make a text file than a module but Drupallers are abundant and I have yet to see a good module have lack of contributions, and who doesn't like games??
/me rolls eyes.
/me rolls eyes.
Update
Well. I have a lot of fun coding on this. Thus far, I have designed things based on a class system. So, you have a room class that has the basic properties of length, width, height. From this class you can create a child class that inherits the dimension properties. I really wish I could just go on and on with inherited properties (think MOO) but without using true objects it would quickly go above my head. Anyway, from here, you can create different classes of room such as Underwater, Space Sector, whatever. The process is borrowed from Ubercart's use of a product class as a parent for all the sub products. Eventually, I'll add the ability to add attributes to a parent class and these will be properties for example, $room->oxygen_level, $room->temperature, etc. So if you like a room type someone has built, you can import the class as easily as migrating a product class from one ubercart site to another. The API will take care of exactly what a certain property does. Say, zero oxygen, translates to 'death in minutes'. I'll use this concept and translate it to objects also, such as a weapons classes (projectile, melee, etc). So far, I have a character migrating from room to room without any problems. The rooms are connected via a portal object that will also be a class as well eventually. Right now, it's just a plain object for testing. You can create any number of characters and then control (mount) them (don't laugh, mount just fits the bill right now) and move them around, change characters and when doing so , you teleport to their location. I am using hook_access to determine if a player can enter a room and the requirements are that a portal connects the desired room to the current room the character is located in. This way, I can use a "player can teleport" value in my hook_perm. This is mainly for admins of course.
I had gone around and around on how to get lots of variables in and out quickly without using variable_set/get and I found queryable Variable module. It is perfect. So it's a requirement. It saved me writing my own query module so that's nice.
Next, will be looking at the live update module's API to try and get real time chat, updates to the node page to announce player arrival, chat, etc.
Nifty stuff
I had a fun idea for a game but pondering how to get it really going. Is this kind of inheritable class framework you've got available anywhere (or based on something else?) Looking @ the RPG module for 5.x too. It would be great to have code to look at, as well as how hook_access and actions, triggers can be used to make a full game environment.
Just reading your post again. Answered this before but.
All of the inheritance and class work was taken from Ubercart. Their process for creating different product classes that all shared similar functions, you can buy them, yet different fields, ie clothing with sizes vs electronics that don't looked perfect. So a good place to start would be the product module code from Ubercart.
Hey.
Hi, I still am using 'classes' for rooms. this way, one can create a different type of room that has different CCK fields, but still shares the basic requirements for a room such as dimension. Drupal limits me there however. I cannot create subclasses. I have been doing A LOT of reading with regard to inheritance and object oriented programing and the bottom line is that drupal simply puts limits on this. large amounts of posts and grumblings can be found on the boards with this regard.
My main stumbling block was last week, objects and how to structure them. I am used to Object Oriented Multi-user dungeons, specifically, Xerox's LamdaMOO Code. I wanted a way to create objects that were generics, and had inheritable properties. For instance, the generic object is the super parent. It has properties of weight, and size. All objects have these two properties. A child of the object object is the Generic Container, it has weight, size AND volume AND can be the location of other objects ('think of this as a backpack, or sack'). Then the hierarchy grows. Perhaps a boat can be a child of 'container' with extra properties.
The problem is, this just isn't possible with drupal. There is the inherit module, but it's two years old and broken. My best solution was to use CCK and to have shared fields.
I personally LOVE to just create node types using node modules, but this would require a new module for every node type!! What if there were 30 different types of objects.. That's just not feasible.
So instead of using custom node modules, I use one module that makes sense of 'objects' based on their CCK fields! If a node has the $node->field_weight[0]['value'] field then it IS an object.
CCK allows the reuse of fields so the generic field of field_weight can be reused on every subclass of 'object' and therefore we now have a sort of pseudo object inheritance model.
Creating new content types requires two things.
1)Build the CCK content type. First use all the same fields as the parent objects and then add your new fields that further characterize the object. Something really nifty is that we get multiple inheritance. We can take fields from different parents. So maybe we can create a 'gun boat' by combining the 'boat' object with the 'weapon' object!
2)Next we add a specific function to our object module that defines the object.
is_object() defines the base generic object by simple testing for the presence of the field_weight field.
then each progressive function tests for further differentiation. is_gun() might check for a unique property only found in guns.
So, now we have CCK objects as in game objects. developers can easily tell what fields are needed to classify something as a certain object, plus we can use views and all the fields that CCK provides. Very cool.
More stuff
Well. I have come a long way. Still going strong on this and working 3-4 hours a day. It has transformed from a do anything module to a website that uses 6 custom modules. I have done in 6 months, what it would have taken Pavil Curtis years to do, thanks to Drupal. The great thing is that my game documentation is being written at the same time my game is. Everything is 'node'ized' (thats a new word I just made up). For example, I have a skill called 'Bar fighting' which is a skill. It has tactics such as 'Tackle', 'Wild Swinging', and 'Cue Fighting' which are nodes as well. Not only do the nodes describe the skill for documentation, but they also hold all the information I need about the skill. So, all messages, damage, tohit, etc. If I want to transfer a skill or tactic from my game to another, I just export the node.
No you cannot add crucial fields then export. Not possible and I am not sure how that would be possible with any format. You could however add extra cck fields..
Every node has an associated function that is called with call_user_func() as a helper function.
It is all easily expansible for the user or 'administrator'. You can create new rooms, objects, skills, and tactics as easily as 'Create Content'. Really, anyone can add to the game.
It's like MOO code on steroids. Multimedia too.
My only concern is server load. The very nature of the game requires a lot of database work, and it is loaded with Jquery so there is a lot of server polling. It will likely need a dedicated server and limits to the number of users. That said, the hardware is what ALWAYS seems to limit me. No matter what I am doing.
I am hoping to get an alpha test up by Jan 1 and when I do I will post up the site location. I think this is going to turn some heads with regard to Drupal as a gaming platform.