• defining the AD&D rule set using XML (example below)
• understanding how to use Perl/Gtk2, since the documentation is sorely in need of... well... existing
• monster/NPC AI for battles

<spell class="mage">
  <name>Sleep</name>
  <level>1</level>
  <message>%t is put to sleep</message>
  <sounds>
    <cast>DEFAULT</cast>
    <hit>enchanted.midi</cast>
  </sounds>
  <images>
    <cast>DEFAULT</cast>
    <hit>DEFAULT</hit>
  </images>
  <friendlyfire>0</friendlyfire>
  <combatonly>1</combatonly>
  <cumulative>1</cumulative>
  <castbyparty>1</castbyparty>
  <canscribe>1</canscribe>
  <autoscribe>0</autoscribe>
  <candispel>1</candispel>
  <throwvs>spell</throwvs>
  <throwresult></throwresult>
  <target type="square">
    <count dice="" sides="" bonus="" perlevel=""/>
    <range dice="" sides="" bonus="" perlevel=""/>
  </target>
  <duration units="">
    <length dice="" sides="" bonus="" perlevel=""/>
  </duration>
  <casttime></casttime>
  <abilities>
    <ability>sleep</ability>
  </abilities>
  <effect>
    <attr>ASLEEP</attr>
    <amount>1</amount>
    <units>absolute</units>
    <targeting>target</targeting>
    <cumul>1</cumul>
    <worksif>
      <true>$TARGET->hit_dice() < 5</true>
      <false>$TARGET->is_undead()</false>
    </worksif>
  </effect>
</spell>
[download]

My biggest stumbling block when it comes to XML is determining what should be an attribute of an element (like the "class" type in the spell element) and what should be the data of an element (like the name of the spell in the name element).

First, do you really want to use XML? ;-) On one hand, it's great in that it's entirely cross-platform (and here I refer to languages more than hardware). On the other hand, it's overly verbose, and uses up way too much memory.

If you're doing this in perl anyway, YAML may be a better/smaller/faster choice. It'll mostly limit you to perl - should you want to reimplement in another language, you'll need to reimplement something (either YAML in that other language, or convert everything to XML for perl).

As for your stumbling block ... yes, that is always something that has confused me, too. Especially when <spell name="sleep>...</spell> is so much shorter than <spell><name>sleep</name>...</spell>. Good luck :-)

My biggest stumbling block when it comes to XML is determining what should be an attribute of an element (like the "class" type in the spell element) and what should be the data of an element (like the name of the spell in the name element).

My rules of thumb are as follows. Note: I am sooo not an XML purist. In fact, most XML'ers are probably going to puke when they read my ideas. You have been warned.

1. Every primary node is a thing. In this case, you have a spell.
2. If you can, you should use attributes. Not for any storage issue, but becaues it makes more sense.
3. Most attributes can be redefined as containing nodes that propagate their attributes to their children. For example, I would have a node called <spelltype> that has an attribute called "value". So, you could have something like:

   <spelltype value="mage">
     <spell name="sleep">
       ....
     </spell>
     <spell name="fireball">
       ....
     </spell>
   </spelltype>
   
   <spell name="lightning bolt" spelltype="mage">
     ....
   </spell>
   [download]

   I use this in Excel::Template for formatting and other attributes that might work across a group of similar nodes.

4. If an attribute is a thing, it belongs as a child node. For example, <effect>.
5. If an attribute is complex, it belongs as a child node. For example, <sounds>.
6. If an attribute can be repeated, it belongs as a child node. For example, <effect>.

So, I would rewrite your spell as follows:

<spell spelltype="mage" name="sleep"
  level="1" friendlyfire="0"
  combatonly="1" cumulative="1"
  castbyparty="1" canscribe="1"
  autoscribe="0" candispel="1"
  throw_vs="spell"
>
  <message to="can_see_target">%t is put to sleep</message>
  <message to="target">You have fallen asleep</message>
  <sounds>
    <cast>DEFAULT</cast>
    <hit>enchanted.midi</cast>
  </sounds>
  <school>enchantment</school>
  <images>
    <cast>DEFAULT</cast>
    <hit>DEFAULT</hit>
  </images>
  <target type="square">
    <count dice="" sides="" bonus="" perlevel=""/>
    <range dice="" sides="" bonus="" perlevel=""/>
  </target>
  <duration units="">
    <length dice="" sides="" bonus="" perlevel=""/>
  </duration>
  <casttime></casttime>
  <throwresult></throwresult>
  <component type="somatic" />
  <component type="verbal" />
  <component type="material" consumed="1">
    <item name="sand" amount="1" units="pinch" />
  </component>
  <abilities>
    <ability>sleep</ability>
  </abilities>
  <effect>
    <attr>ASLEEP</attr>
    <amount>1</amount>
    <units>absolute</units>
    <targeting>target</targeting>
    <cumul>1</cumul>
    <worksif>
      <true>$TARGET->hit_dice() < 5</true>
      <false>$TARGET->is_undead()</false>
    </worksif>
  </effect>
</spell>
[download]

The problem is that you're going to start developing a mini-language. For example, some spells allow for more than one material component. And, some spells allow for an either-or with material components. You're starting to discover this in your <:worksif> node. The components is just another example of htis.

It's almost better to embed a database that to use flatfiles. That way, you can link directly to the record for sand instead of having to look it up in some large file. This will reduce the amount of RAM needed, probably by a factor of 10.

And, you're not really going to be using the fact that XML is human-readable. You're still going to have a data-entry interface to manage these. Might as well use an RDBMS instead.

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

There are also documented GUI toolkits around. Tk is one, but it is probably too weak for what you're planning.

Perlqt and Wxperl are others - while themselves not perfectly documented, they're just wrappers of popular C++ frameworks - Qt and WxWindows, both of which have terrific documentation.

My personal experience with WxPerl was quite good.

I wish I could say the same about WxPerl. I've had a great deal of difficulty getting it to compile. I've never had it compile and run perfectly (I've only tried on two different systems, though), but when I had it partially working on one system, the results were beautiful. I say "partially" because it passed most tests. I just learned to not use any functions in the part that did not pass.

It is is nice toolkit, but I'm concerned that it would be a huge stumbling block for many inexperienced people.

Cheers,
Ovid

New address of my CGI Course.

Yes, I was just introduced to WxPerl yesterday. After comparing screenshots and running the sample programs, I think WxPerl has a better look and feel to it, and I think I'd be able to use it faster.
_____________________________________________________
Jeff japhy Pinyan, P.L., P.M., P.O.D, X.S.: Perl, regex, and perl hacker
How can we ever be the sold short or the cheated, we who for every service have long ago been overpaid? ~~ Meister Eckhart