However, I then said that both RPG::D&D::Character and RPG::Dice would be needed. That implies that dice() would be located in a non-D&D spot.

However, I don't want to start a flame-war. This project is obviously something dear to your heart and I apologize if you felt that I was insulting your intelligence or your design capabilities. I was merely attempting to humbly offer up some ideas of my own.

No offence intended or taken, dragonchild. I was agreeing with you! I just didn't express myself very well. I was endorsing your point about the need to separate the Dice and Character modules. Consequently, I presented my version of the arguments against your initial suggestion - which you yourself argue against further down the post. I apologise for the confusion - nothing could be further from my intentions that to start a flame war with you or anyone.

Now, onto the project!

The basic functionality you're probably going to need involves (at least) the following areas:

• Character/NPC/Monster Generation
• Skills
• Magic (both Arcane and Divine)
• Combat (both mudnane and magical)
• Items (both mundane and magical)
• Map Generation

Ok:

• Character, monster and NPC generation. In my original BASIC implementation, PCs were generated by manually writing a character into a .txt file. My present attempts at writing the character generator software are naturally designed to improve on that rather unfriendly method. Thus far, yea good. Monster generation was one of the better aspects of the BASIC version (at least first time through) - individual instances of monsters were created by reference to arrays of base statistics - a technique I would repeat in a non-OO Perl implementation. However, OO offers a more natural way to handle this - provided I can get my head around OO. NPC generation will be essentially like mosnter generation for generic NPCs - 'farmer' is much like 'orc' in most ways. Special NPCs will be hand-written, possibly with a text editor, perhaps using a 'DM mode' feature of the main engine.
• Skills are a side effect of PC generation, and have already been entered in a tabulated format. The table can be read into whatever data type takes our fancy/fits our purpose. Obviously, for RPG::Cthulhu::Character, a different, and differently-formatted list is required.
• I conceive of spells as consisting of their casting details, as data, plus specific referenced calls to procedures in RPG::DND:Magic to invoke the unique effects. Duration spells would create objects with timers, checked periodically to detect expiry.
• Combat will interrupt normal play. (As it happens so quickly, characters who are, say, shopping in the market, will have just about enough time to turn a corner while a group elsewhere fight and slay six orcs.) That will be a set fact about the game, no matter what engine is invoked, since the time-stamped actions are part of the text adventure interface, rather than the rules emulator. I had originally intended to fudge combat, but a curses-driven engine to produce roguelike floor plans does not seem impossible.
• Items should be handled by a method parallel to that used for monsters. If, as seems likely, we go OO, Perl objects' ability to inherit from more than one parent is useful: objects which are both weapons and clothes (such as gauntlets) should pose little problem.
• There is already a large map in a format friendly to the text-only BASIC implementation. An ideal Perl implementation would accept the data from this file, convert it to a 'vanilla' set for the Perl version, and leave me the ability to round the original data out to something more appropriate to the finished engine.

It makes your high level very instinctively obvious. Any new DM can, given a well-defined and documented API to your modules, create his/her own high-level programs.
It makes changing game systems very easy. You are creating RPG::D&D::* right now. However, by that very package nomenclature, RPG::Cthulhu::* is very possible. If you leave out all implementation details from the top level, switching systems is almost trivial.
It makes designing the system much easier. You don't have to remember that there is a 1% need to roll dice at the manager level. You'll know that all implementation details are hidden from the top level. You just need to have the appropriate module adjudicate itself.

But if we're employing modules that use RPG::Dice, won't we have the option, however undesirable its use may be, to access the dice rolls from the top level? I'm not saying we should - just trying to check that we could.

Now, we don't know exactly how these modules will go about doing their thing. In fact, we don't even know if they will be modules or classes. (RPG::D&D::Character may very well be a class - I find it easier to think of a PC or monster as an thing that knows how to do stuff versus a set of methods to be run on a data structure you have to maintain.) Each module will have an API (set of methods that other modules know about) and a mandate (what it takes care of for you). Once you have sketched this out, it becomes very simple to flesh out the skeleton.

Silly question: what does API stand for?

That aside, this re-emphasises to me the need to go OO. On the other hand, it leaves me scratching my head as to where to begin. Clearly the current create.pl will have to be re-written from the ground up. At the risk of picking other people's brains too much - how do people think I should start?

Suppose we have RPG::DND::Character. Would 'fighter' be best as a function or other form of data in that module, or as a separate module dependent on it? How can we produce a call to the appropriate 'new' (or whatever) function which creates the character with the statistics chosen by the player? Or should the character be created as a 'blank sheet' and then filled in?

I recognise that people will say 'It's your project: do it your way.', as well as 'TMTOWTDI'. But I'd be interested to know what (in broad terms) people think of my attempts to understand this new (to me) field of programming, and how they think I can avoid hamstringing my own project with bad implementation.

Thanks!

The grateful and apologetic Tiefling

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GAT d++ s:- a-- C++ UL P++ L++(+) E? W+(++) N+ o? K w+(--)
!O M- V? PS+ PE- Y PGP- t+ 5 X+ R+++ tv- b+++ DI++++ D+ G+ e++ h!(-) y
+?
------END GEEK CODE BLOCK------
[download]

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.