Shareable game content

The shortest answer, and philosophy, is:

* I don't see game objects as numbers or data only.
* Games need personality, not collections of numbers.

It's hard to see this philosophy because the game engine just isn't ready for it (I'll start working on that area when I finish the targeting system, which is what I'm doing now). To get an idea of where mobs, for example, are heading, please download any of these Skirmisk PDFs. That's where the mob design is coming from (and you can see two of them, incomplete, from the Starter Set). As you browse through these PDFs, I hope you can see how complex a UI toolkit would become, and that even assumes that the engine can provide happy selections for every possibility you want to map.

Mobs, for me, along with any other game object, need to have personality. They don't get two attacks only. They don't only do damage to a single opposing player. Their attacks don't always work under every circumstance. They should have no limits enforced by the game engine. This is where the philosophy is unviewable in the current codebase: the current mobs do, in fact, look like regular old collections of numbers. That is simply not what I want - future revisions will include per-action/ability callbacks, and more hooks to allow crazier attacks.

Certainly, yes, some abilities CAN be coded into the engine - if you grabbed the Starter Set PDF, you'll notice that the Human Sellsword's Killing Blow is a one charge action (symbolized by the white box next to it). They'll be a concept in the game engine of "charges", where an attack can only fire X number of times (and, potentially, be recharged based on another circumstance [see the Young Green Dragon's Poison Breath for an example]). That's where the targeting code I'm working on is preparing - it's a two stage process (1: find all valid attacks, 2: foreach valid attack, find all valid targets). The "charge" functionality would listen for the first stage of the process and remove any attacks that are expended. Anyways, I digress.

To create a mob, as I see it, in the database, would require a healthy number of tables and PHP code being stored within. I'm not hugely fond of storing PHP code in a database (and, naturally, there's core's concern of allowing PHP to be entered via the browser anyways), and I'm not hugely fond of the idea of having a zillion tables. I'm also unconvinced that it makes the "export a bugfixed version to update on other sites" easier to solve: if there's a happy-go-lucky editor built into Drupal, how would you reconcile changes that *I* have made to *my* version of the mob, which you now want to overwrite with your changes?

Everything goes back to personality: if a mob is a set of numbers only, capable of easily and cleanly being stored in a database, then it loses personality. It becomes yet-another beast where it doesn't really matter /what/ you're fighting. If, alternatively, a mob can become a set of code, listening on its own hooks, responding with its own custom callback, there's a lot greater chance for a) personality, and b) creativity that the engine doesn't support. The engine shouldn't restrict a mob's capability (and that's why every hook always receives the entire game $state, not just the most relevant object; loose coupling is another design principle of Game's approach).

If you look at most any other game engine nowadays, be it for MMORPGs or FPSs or RTSs, you'll see that most of their addons use an interpreted language too, usually Lua, but occasionally something in-house. There's been no shortage of development for those systems. If forcing PHP knowledge means that a user can't create, and ship, a poorly made "green dragon" or "vampire" that is JUST a set of numbers with no personality or creativity, then that's great! A barrier to entry here means better, more inventive, content.

Incidentally, to go back on the "loosely coupled" ideal above, there's no concept of "Weapons" in the game engine. The Exotic Weapons Pack could still be created, but it'd be a set of "attack" actions, that one could attach to a particular mob. Non-actionable items, like rings and armor, etc., would be considered merely attachable always-on "abilities". Of course, because the entire game $state is shared with every hook, one could certainly invent the concept of "Equipment" or tradeskills or pretty much anything else.

Oh, and stop by #drupal-games sometime, eh?

I'm not adverse to a Drupal toolkit to build .module files. I'm adverse to the implications it creates: less creative and more crunchy mobs. If the toolkit involved to be so masterful as to accept every possibility the engine supports (and there'll be a number of pre-shipped abilities, like "charges", "bloodied", "poison", etc., etc.), with a set of conditions ("[only do this] action if [one] of [my party] members is [dead]", "[do this] action [everytime] [an opponent's] mob damages [my party's] [Naga Swiftscale]", then it'd be absolutely incredible. Am I going to spend my time on that? Not for a lOong while.

Currently, that Longsword is unique solely to the Swiftscale (not Sellsword). If you wanted to re-use it elsewhere, you'd have to manually add it as an action to another mob. With that said, note that I don't believe that's exactly a good idea: the actions that a mob is defined with are tweaked to that mob's cost and difficulty - adding that Longsword to another mob would almost always require a change in modifier and damage, based on the new mob's capabilities. Knowing the source material, you probably recall that no other mob has the concept, specifically, of a "weapon" called "Longsword".

One can add the concept of Equipment easily enough, however - if you kept an equipment list somewhere, you could attach it to the current_party's mob action list during hook_game_battle_init_alter() (though, as I look at it, this would fail for AI users...). In my head, however, equipment would primarily consist of magical items, armor, or magical attacks (attached spells, etc.) - most of the attack actions that the source material come with are already stronger than a "normal" sword swing, making a "normal" sword swing undesirable to use.

I would probably explore Equipment when I start working on the idea of a "City" - another module which gives a place for the player and his mobs to wander around in and shop for stuff, find quests, blah blah blah. I'll start working on that once the battle engine is more powerful (months from now). Alternatively, you could do that! ;)