While everyone else has answered your question quite well, in terms of the technical Perl aspect, I would like to comment on the design of your application. (This is in no way meant to imply that I know everything that you're intending on doing, nor is it meant to imply that I have The Right Way. I merely wish to offer ideas, given my package experiences.)
You are looking to write a series of modules that will help you develop a comprehensive D&D application. The key word there is "application". I don't know what your background is in Perl or programming, but the first instinct I've seen in a lot of decent programmers has been to treat Perl with less respect than they would C, Java, or any other compiled language. If you're looking to write a stable app, you need to realize that's what you're doing and design this a bit. If you intend on using this over and over, and/or extending it, this week or two in the beginning where you define where stuff lives will be absolutely critical.
"Why?", you might ask. Well, you talk about a dice-rolling function called dice(). Then, you talk about a modifer() function. As someone who plays D&D, these, to me, instinctively seem as if they belong in the same place. This is because they both deal with ability scores.
Now, the immediate response would be that dice() also deals with combat. Ok. So, dice() may need to live elsewhere, and that's fine. The question would be "Where?"
modifier() seems to imply a character module. This would have things help you generate stats, choose skills, choose spells, and moderate when someone can cast a spell or not. Sounds like a lot? Well, it is ... and it isn't. Who says every bit of code has to be in RPG::D&D::Character?
A case could be made that the top level should not know how to roll dice. All the top level should know about is characters, spells, and combat. Why? Because it doesn't care how combat is resolved. All it cares about is that combat is resolved. All the details should be taken care of by RPG::D&D::Combat. No-one else wants to know, cares to know, or should know. Same goes with character generation, skill/spell adjudication, etc.
Creating a RPG::Randomize module is definitely appropriate. Within this module could be dice(), as well as other methods of randomization. coin_flip() could be here. (1d2 is different than flipping a coin, and you should code it that way, even if it would seem that, from the theory, it is the same.)
However, the high-level manager doesn't know about RPG::Randomize. It doesn't care about the mechanics of it. (If only I could draw a picture here!)
I hope this helps you understand a little of the deeper thinking behind sane package construction. Also, please use strict in everything you do. It will make your code much cleaner and clearer.
In reply to Re: Modules: Building blocks for the Daft Adventure