I just went and looked at Dice::Dice. It _might_ do what I want it to, but:
1: I want to be able to parse a string and return the appropriate roll. This is the main thrust of the module in question. Dice::Dice has some ability to do this - however, there are situations (particularly in games like Warhammer) where large bucketfuls of dice are needed. Dice::Dice might well not be efficient here, as I don't want persistent objects - only answers.
2: Dice::Dice, by your own admission, requires a re-write because of the use of deprecated features - unless the re-write has already taken place and I missed the note that says so.
3: I don't _want_ well-behaved object dice. I want a function which takes appropriate input and brings back a number, by munging the input and totting up a bunch of rand() calls. Perhaps I need to clarify what I expect my own module to do.
Desirable calls:
stringdice() - a function to take a string like '3d4 + 2d6 +4d8 +9' and return a properly-distributed random number in the appropriate range.
listdice() - a function to take a couplet ($x, $y) and return the individual values of xdy as a list.
bestdice() - bestdice($x, $y, $z) returns the best $z values of listdice($x, $y).
topdice() - topdice($x, $y, $z) returns the values of listdice($x, $y) exceeding or equalling $z. (For World of Darkness, for example).
Looking at the documentation for Dice::Dice, it could probably be persuaded to do the above, but I'm not sure if it's the best way to proceed.
All this is not intended to suggest Dice::Dice is at all bad - far from it - but TMTOWTDI. Also, I'm interested in being able to develop this stuff myself, and Dice were not a feature of the implementation which screamed to be OO.
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------
| [reply]
[d/l] |
Thanks for the explanation, and yes the code was re-written, but I'm not completely sold on them either for performance reasons -- I'm just shamelessly trolling for opinions :)
Having coded many of the DnD charcter generation and battle tables in several languages over the years (It's my favorite way to learn and compare languages) separating the dice makes it easier to run the rolls against matrices as well as clearly delineating whose dice are being operated on.
Plus in the game design I've always pondered I've looked for ways to put the dice back in the hands of the players. In table top gaming picking and rolling your own dice is a part of the fun.
coreolyn
| [reply] |
Plus in the game design I've always pondered I've looked for ways to put the dice back in the hands of the players. In table top gaming picking and rolling your own dice is a part of the fun.
Ahh - differences of approach. My groups have almost invariably said 'all these dice are fiddly and boring. Can we use them as little as possible, please?' Consequently they find the idea of an implementation which does take the dice out of their hands appealing. The idea of 'SimDice' never occured to me.
I've learned languages by writing text adventures - the newly modular D&D 3e seemed a natural extension of that.
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------
| [reply]
[d/l] |
