Re: [Jopenrpg-devel] Dice roller parser question

[Ted B. <te...@us...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 07 June 2002 10:59 am, David Hudson wrote:
> Hi Ted,
>
> I noticed that the openRPG syntax for dicerolling hasn't been fully
> implemented (notably the .each() function which would have been useful for
> FUDGE dice). Would you mind if I took a look at that code? I am interested
> in working with javaCC.
>
> Thanks
> Dave

My preference would be to have you make a new parser, actually.  I've been 
wanting to have jOpenRPG use different dice parsers for the different game 
systems, I just haven't gotten around to implementing it yet.

The current parser 'OriginalParser' is something of a major kitbash.  I 
originally had a ton of modifiers for it, actually before OpenRPG got them 
implemented.  I pulled them though, I think because there was an error in 
them somewhere.  <shrugs>

We should probably come up with some sort of Interface for all of the dice 
parsers to implement so that we can just reference the Interface in the code.  
That would allow us to swap out parsers on the fly.

At a minimum, I think dice parsers should return a double, so that users can 
use them for math instead of just dice rolling, and should also build some 
sort of 'description string' that shows the actual rolls.

I would also like to, eventually, have all of the dice parsers to value 
substitution.  We'd then be able to pass the parser a Hashtable along with 
the dice code.  The Hashtable would contain mappings like "$RANGE" maps to 
"12" or something.  Then the dice parser would replace $RANGE with 12 when 
tearing apart the roll.  If it found a variable that had no value in the map, 
it would ask the user.

*Additionally* I want to come up with a good way to allow the dice parser to 
query the user, under certain circumstances, for the value of the roll.  That 
would allow GMs to fudge dice rolls and have them look authentic. :)  
Obviously there'd have to be some way to toggle this ability, and the client 
should announce the fact that this 'mode' is enabled to discourage cheating.

I was also thinking that, perhaps, the parser should return a RollResult class 
instead of a double.  The RollResult could have a double member and String 
member.  That would remove the need to have 2 different methods to get the 
data.

<shrugs>

Not trying to say you should *do* all of this, just brain-dumping what I've 
been pondering WRT the dice parser.  Obviously the current parser would have 
to be seriously overhauled, or just scrapped.  That's why I suggested you 
write a new parser :)

Oh!  I'd suggest you make the parser a 'static' parser.  That way we can reuse 
a single instance.  Currently the Core maintains a reference to the single 
dice parser in use, and everyone else just asks Core to do the rolling.  
You'll probably want to make a new package for your parser so that the 
generated classes don't overwrite OriginalParser's.  That was my plan, 
anyway: 1 parser per package.

Heh, have fun!  If you run into any trouble, feel free to ask.  As I recall 
there were a few sticky points in writing a static parser.  OriginalParser 
should have all the info you need to puzzle it out, but I won't make any 
promises as to legibility. :)

- -- 
Ted Berg                jOpenRPG Project [http://jopenrpg.sourceforge.net/]
PGP ID 219A86B2          F4A0 410E 4E37 F3D5 DA33  1FBC 3A38 028D 219A 86B2
Unauthorized use of this .sig may constitute violation of US law.
echo Qba\'g gernq ba zr\!             |tr 'a-zA-Z' 'n-za-mN-ZA-M'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9APyDOjgCjSGahrIRAgpxAJ9pwDoPgWDAI3evKeyWqy8ogqtRSwCgtSLM
Jps6Agp+oEvpPK6jARRY7mM=
=O9Im
-----END PGP SIGNATURE-----