I'm going to bring up an old discussion now. I don't think there's been much discussion in forums (but if so, maybe someone can dig up some posts). But there has been much over the past couple of years in IRC.
This has to do with integrating RPG with the Drupal node system. The current RPG module is its own entity, entirely unattached to nodes. This is a reversal of earlier versions of the module. Originally, I'd planned to fully integrate it with CCK and Views, and if you look at the first few dozen commits, you'll see that RPG objects were actually node types, and the attributes were fields.
Eventually, I ran into several problems. Some issues were merely difficult, while others seemed nearly insurmountable. Thus, I rewrote the engine, making RPG objects an entirely separate entity in the database.
Now I'm writing graphical support for RPG, and am finding myself duplicating code, and questioning (yet again) my original decision to detach RPG from nodes. Here are some Pro's and Con's of using node types & fields for RPG objects:
Pros
- Views
- CCK
- leverage other related development
Cons
- have to resolve node access grants
- difficult to create node types/fields programatically (nearly impossible in d5)
- harder to allow types to inherit from other types
- difficult to make sure a specific custom function is called when invoking an action
And here for using an independent system as the module uses right now:
Pros
- types inherit cleanly, allowing overriding of attributes & actions
- easy to link functions to actions/attributes/events
Con
- lose existing node functionality
- bar of entry is raised for developers more familiar with nodes
- duplication/replication of code, such as for imagefields (although that may be of limited use for node object types anyway)
So I have some ideas to bridge this gap, or even redo the engine entirely. I would like to run them by you, to see if I'm missing anything, or if there's a better way, or if this is spot on.
1) I have an existing plan for an RPG Node module. Not the same thing -- this would simply create a node field that would be associated with RPG object types. Certain RPG types could be set to automatically create node objects (such as for player characters). The field would display a themeable function from the RPG object, so it could, for instance, display character data, and be used for views and such.
2) The engine could be rewritten, so that the core would depend on CCK fields. A checkbox would appear when creating a new node type, that would set the type as an RPG object type. Node access tables would then control access for such types. Fields would be created for attributes, actions and events. Widget types for the attribute classes. The rpg_get/set functions would simply access the node field values instead of calling the db, and would still allow custom functions to override those values. (That means it might not be able to fully access all of Views features.)
I'm really leaning towards option 1. I don't believe at this point that much would be accomplished by switching back to nodes. And nodes are a heavy-handed approach to many RPG objects, with the possible exception of characters. Morbus, in fact, at one point suggested that a hybrid version might be the way to go.
Well, anyway, that's enough for now. I'm really only whining because of having to replicate some image handling code. Other than that, I think the engine's working out to be fairly solid, and hopefully easy enough to work with. I'd love to hear any feedback you guys have!
Thanks,
Aaron Winborn

Comments
here's a pro with using 100%
here's a pro with using 100% node system: your realistate appreciates with time.
more specificaly: using views (predefined or programaticaly created) you can fetch the exact fields that you need, thus avoiding the heaviness of nodes.
also future (d7+) db schema API will allow for remote keys, which as far as i can tell will allow you to programaticaly create complex query joints which will further reduce node heaviness.
to solve the access issues, you will need to create your own access verification module, my assumption is you could do that inside hook_nodeapi, however i think this will be easier to do than duplicating all other node functionality.
------------------
Sometimes interesting things appears on http://litwol.com