CRPGs, Perl, Gtk2, and my vision

[japhy]

In a world plagued by World of Warcraft, Baldur's Gate, Everquest, Neverwinter Nights, and countless other multiplayer computer RPGs that I don't know about, the "gold box" games of Strategic Simulations, Inc. have been lost in time.

The gold box games published by SSI were three series of games (4 in the Pool of Radiance set, 3 in the Dragonlance set, and 2 in the Savage Frontier set) based on the AD&D rule set. You created a party of up to six characters of varying races, classes, alignments, and genders. Then you went through cities, dungeons, and landscapes, completing quests by helping non-player characters (NPCs), killing monsters, and finding treasures.

I know there are at least two existing CRPG construction kits out there: Forgotten Realms' Unlimited Adventures and the Open Source project Dungeon Craft. I have a vision of creating a similar application in Perl, (currently) using Gtk2. It'll be fun, it'll take a while, but I'm going to enjoy it. It's back-burner for a while, though...

[dragonchild]

If you want some help, I'd love to be involved.

[japhy]

It'll be a long-term project, but the core areas I'll need help with are:
• 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
I've looked at how DungeonForge stores its data, and I think using XML is probably going to be easier than coming up with some special format. I'm not an XML purist -- I'm not a czar of the DTD -- but I figure the data would be stored like so:

<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>

Something like that.

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).

[Tanktalus]

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 :-)

[dragonchild]

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>
   

   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>

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.

[spurperl]

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.

[CloneArmyCommander]

Rock on :)! My perl skills are limited since I am still new to the language, but you can still count on me to be behind you 100%. I have wondered when somebody would step up and show some of these middle school kids how things are really done, the ones who play these MMORPGs, labeling themselves ultimate "HaXoR." To be honest, I have been sitting the online game world out until somebody could write something as exciting as Adventure or Hack, the good games ;).

[castaway]

It sounds like a fun idea, but also one that will take a year or three.. :)

From experience, I know that just coding an engine (no graphics, just the game logic) takes an extraordinary amount of time, and is hard to get right. (Though I guess if you're using an existing set of rules, you'll have less need to balance things). It sounds like a good idea for a community project though, people to keep each other going, give ideas and so on.

My first suggestion would be, make a community site for it, a wiki will do to start with. Add ideas as they occur to you, writing things down helps them become clearer, and others can ask pointed questions, or come up with their own ways of doing things, to be discussed.

(I say this because I'm currently also fiddling with a largish project, and writing things down certainly does make a difference.. Even more so if its somewhere that others can see)

C.

[japhy]

Voila: Dungeon Construction Kit wiki.

[Tanktalus]

japhy,

I highly discourage you from using the AD&D 3.5e rules. To do that will require licensing from Wizards of the Coast. Instead, check the WotC website looking for their Open Gaming system. Use that instead. It's almost identical to AD&D 3(.5)e, except that all trademarks have been removed. Of course, that means few prestige classes, and no defaults for Forgotten Realms or Dragonlance or Eberron, but that's ok. As long as you make it easy for the end-developer to add new spells, ignore existing spells, add prestige classes, set the map up however they want, etc., then they can go get the license for these things from WotC, allowing DCK to continue to be free (or not, but it can be free).

If you get that far, then you can look at creating a trademarked DCK, sort of like how the PCGen team formed Code Monkey Publishing to do exactly that - sell trademarked data sets to users of PCGen.

In my ideal world, DCK and PCGen would share data formats. Unfortunately, PCGen uses an abomination of a format which I would not want to implement a new parser for. PCGen does plan on going to XML one day, but by then you might be somewhat entrenched in your own XML format. The advantage to sharing, of course, is that you'd not have to type up all the open gaming content that WotC has released, and could get to work almost directly on the engine to use it.

Just my two cents (CDN). :-)

[Koosemose]

Wooo! I'd be more than willing to help with any aspect of this. However, I was curious as to which particular ruleset you intend on using, AD&D 1st ed., 2nd ed., or 3E (or the slightly updated 3.5). Personally I would suggest 3.5, as the rules are much more clear cut, making for an easier translation to programming logic. If you decide to go with 3.5, I could definitely help with converting any rules to programming logic. I could probably help some with the older editions though it's been a while since I've actively played either, I have PhB and DMGs for both hidden somewhere. Also if you go 3.5, I happen to have a database full of all of the spells from the PhB, though it's from the OGL reference docs, so it lacks certain copyrighted spellnames (i.e. Mordenkain's Lucubration is simply Mage's Lucubrations). But with a few tweaks it could be useful in at least easing the conversion of spells to in-game effects.

I've been looking for a fun project to participate in, but most of the ones I've come across are in a language I'm not familiar with (perl being the only one I'm at a skill level I'm comfortable with) or pertain to a subject I either have no interest in or no knowledge of. If nothing else I'm fairly confident that I could come up with some sample adventures to show off what it can do once it's to a useable point, I've got quite a few campaigns in the works that I just don't have the time (or consistent enough players) to actually run, which would be interesting to convert to CRPGs.