addama

You've all given me the answer to the problem, and I thank you for that. Essentially, the goal was to maximize modularity in code so that, given enough effort by the player (and myself with front-end work) the end-result is a fairly complex game with many redeeming facets to keep the user's attention. For example, in addition to being an Orc and a Paladin, you might want to also be a Blacksmith. Blacksmiths can do things that only blacksmiths can do, and so that's added into your character's repertoire, and provides another avenue for play. In addition to those, you might want to join the local 501st Stormtrooper Garrison. Or commence your training as a Librarian, which would get tacked on alongside Paladin. In theory, every one of these additions could provide an entirely new layer to the game, whereby one feeds into the next; advancing in one that you may advance in others later. Orcs might have things only Orcs can do/make/get. Same with Paladins. Throw into the mix that every class falls into a category (Tank, Caster, Melee, etc) there's another level of "Hey you're X, come do Y" or "I notice you're X, if you beat the Z monster, I'll show you how to make Y." Maybe Librarians are the only ones that can access the Ninth Circle of Hell? You'd certainly want to put in all the work to become a Librarian to get all that phat underworld loot, especially if a rare Blacksmithing material you need is in abundance down there. Add on top of that weapon-use and gaining experience with weapons as you use them. You might learn a sword-only ability by using your sword a bunch, which you could then upgrade by spending money at a trainer. For killing a bunch of undead, you might get invited to the Island of the Dead where you can kill more undead until you're blue in the face, and when THAT happens, you get an ability like Exorcism that kills the Undead on the spot. Add in a Pokemon aspect where you collect things/pets, and level them up. Add in a collectible card catalog. Add in a gachapon collection. Take any part of any game, as long as it's definable in a non-animated way (unless AJAX is involved), and add it in. All you need is time and nimble fingers. I've digressed from the original point, but you catch my drift. Dropping a bunch of classes in a directory, defining how you get from one class to another, and BAM - a game you can conceivably play forever (at least until boredom sets in). I really like the idea presented earlier by Russell about having sub-objects... I think that best represents what I had in my head. Hopefully my idea as presented here doesn't sound too far-fetched Thanks for the help!

So that would be $player->Orc->berzerkerRage(); and $player->Paladin->prayForAbsolution(); to access each individual method. That wouldn't be bad, I guess, because the specific classes would still exist, AND I would only be instantiating the ones I needed. Makes sense. I had thought about this too - instantiating the attacks, which would then presumably be controlled by an interface to make sure it's got all of the appropriate methods (getViableTargets, getDamage, getDamageType, etc). That's probably a good idea in it's own right.

While I'm perfectly (and painfully) aware that PHP does not allow multiple inheritance of classes, I've run into a situation where that's what it looks like I need to do. I can't quite figure out how to do this without making a million subvariants of every class combination I'd want. Here's the problem (pseudo-code used here is just for example, not to be picked apart): You are playing a game. Your character is both an Orc and a Paladin. Orcs have special stats and abilities, as do Paladins. Your enemies can also be Orcs, Paladins, or both, using the same stats and methods that you'd be getting. I could easily "class OrcPaladin {}" or "class Player implements Orc, Paladin {}" but the former increases my class count exponentially for each race/class combination, and the latter only defines the CONTEXT of methods, but not specifics about them. The methods for Orc and Paladin are unique to those classes, and the content of those methods are always the same. ALL Paladins get the "public function prayForAbsolution(){}" function, and ALL of them implement it in the same way. ALL Orcs get the "public function berzerkerRage(){}" function, and ALL of them implement it in the same way. These are the only things (for the sake of this example) that make up the Orc and Paladin abstract classes. If I went with the interfaces method, I wouldn't be able to dynamically define the Player class within the bounds of Race and Class as defined by the USER without statically defining one or both. I could predefine: class Player { if ($this->class == 'Paladin') { $classAbility = 'prayForAbsolution'; } public function prayForAbsolution() {} public function berzerkerRage() {} public function otherClassAbility() {} public function otherRaceAbility() {} } // and then elsewhere... $you = new Player('Paladin'); $you->{$you->classAbility}(); ...but that's an awful lot to load up into one class when only 2 methods will ever be needed. Basically, I'd be throwing the whole slew of abilities into the Player class and lugging the whole catalog with it everywhere it went. And that's not mentioning making enemies that can be Orcs or Paladins or Orc Paladins. Am I missing something about interfaces that would negate this problem? Am I wrong to want a Player object to be both an Orc type object and a Paladin type object? What am I missing? [EDIT] Oh, and hello