![]() |
|
#1
|
||||
|
||||
Decks and DiceI have been playing with some of the randomizing posts here and thought this might be of interest. The code here will all become part of some classes for decks and dice. I just want to see if there are any problems that I should be aware of before moving on (or just a better way to do it).
CPP / C++ / C Code:
Anyhow, that's all there is to it. I thank the various posters that got me interested. I tried to adhere to the declare your variables if and only if you need them method as well as using the consts as I go so I could create the proper size array at runtime. Any and all sugestions for improvement are welcome! Mark __________________
"Opportunity is missed by most people because it comes dressed in overalls and looks like work." --Thomas Alva Edison "Those who would give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety." --Benjamin Franklin "A happy person is not a person in a certain set of circumstances, but rather a person with a certain set of attitudes." --Hugh Downs |
|
#2
|
|||
|
|||
|
nice coding!
there is just one exceedingly minor thing I noticed as I was reading. In function RndInit(): CPP / C++ / C Code:
|
|
#3
|
||||
|
||||
|
Quote:
Cool, I have seen it both ways and didn't notice any difference in the output. I appreciate the feedback U...G..., now to wrap everything up in some handy dandy easy to use classes and get to work on the dice games! Mark __________________
"Opportunity is missed by most people because it comes dressed in overalls and looks like work." --Thomas Alva Edison "Those who would give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety." --Benjamin Franklin "A happy person is not a person in a certain set of circumstances, but rather a person with a certain set of attitudes." --Hugh Downs |
|
#4
|
||||
|
||||
|
Some changes mainly some simple classes to practice isa inheritance it seems.
CPP / C++ / C Code:
CPP / C++ / C Code:
CPP / C++ / C Code:
compiled with: Code:
__________________
"Opportunity is missed by most people because it comes dressed in overalls and looks like work." --Thomas Alva Edison "Those who would give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety." --Benjamin Franklin "A happy person is not a person in a certain set of circumstances, but rather a person with a certain set of attitudes." --Hugh Downs |
|
#5
|
|||
|
|||
|
sweet! I think I am going to have to take advantage of that "free software" clause! I am thinking of making a console-based (at least, console to begin with) RPG-like adventure game. I'll let you know how I fare.
|
|
#6
|
|||
|
|||
Re: Decks and DiceQuote:
While it may be true that a die is a "1 through n-sides random number generator," it isn't usually thought of as one. In the case of your design, your RandomGen class provides no behavioral specification to the derived "Dice" class. Therefore, the relationship between RandomGen and Dice would better be handled through aggregation than inheritance. In fact, RandomGen's whole world is to init the random number seed and provide a "carefully guarded" interface to RndGen. When in reality, the utilitarian-ness of an RNG class would be fine as a standalone body of code, surely without the need to derive from it to gain that utility. We find an overlapping of "responsibilities" in RandomGen::RndGen( const int sides ); ...why would "sides" be used in a RNG operation? The "concept" of a "side" belongs to the "Dice" class. Sure, one can argue that it is just a name of an int than rand needs in order to produce something meaningful. I'd probably change the interface so that Dice::Roll() returns an int equal to what GetRoll() would return. Why make the user use 2 operations when you know that all they want is the next random number? Also, in a multi-threaded world, two calls are going to mean a lot of headaches should the user somehow never call GetRoll after Roll, if blocking is required to protect the data value made during Roll. I can see Dice having an instance of RNG in it and using it. I definitely do not understand the thinking behind a protected ctor that takes an int. What you're telling users is that they have to implement our own DiceN for every one that you decide not to support. For example, a D9 or D7, both common in D&D and similar "old fashioned" RPGs. And, to that extent, there is absolutely no reason why DNeg47 : public Dice { public: DNeg47() What's the use of a public GetSides operation if the user had to use Dice6 d6; during construction? Let's see, I forgot how many sides a D6 has? The idea behind a GetSides is important when that value can be changed at the time of the object construction. Generally, having to name a new type for every possible combination of integers is probably a bad design from the outset. Let's see: D2,3,4,5,6,7,8,9,10...D100 Okay, that's great right until someone needs/wants a 114 sided dice. Granted, it may be unlikely, but why limit your code such? When I take a look at the RNG class, I try to figure out what the benefit of the seeded bool is. It is always false on creation, so how is it ever going to be true without an instance of RNG? ...and won't every instance of RNG change it to true? RNG has no public ctors and only a protected no-args ctor, so only derived classes can even instantiate an RNG. This suggests all the "good inheritance" behavioral elements, but doesn't come through on any of them except by way of adding some "mechanics" to the code. In fact, it separates the concepts into dissimilar thinking patterns in a way that I don't think makes the code more useful, clearer or easier to understand/use. Consider: CPP / C++ / C Code:
...why is this not: CPP / C++ / C Code:
Does anyone other than the ctor use "seeded?" Is seeded ever anything but false when entering the ctor? Here are some changes you may want to consider: CPP / C++ / C Code:
CPP / C++ / C Code:
CPP / C++ / C Code:
Code:
...now there is no reasonable limit to the number of sides a D may have and you don't need to maintain a bunch of duplicate code for each Dn that you want to be able to offer. Of course, I may not have considered all of your design requirements, so let me know if this doesn't work for your needs. :davis: |
|
#7
|
|||
|
|||
Re: Decks and DiceNice to see I'm not the only one thinking on this problem. I've been working on this class file for awhile now. It is designed to make rolls on strings based on YdX format used for roleplaying.
dice.h CPP / C++ / C Code:
|
|
#8
|
||||
|
||||
Re: Decks and DiceMark,
One thing I noticed that is a minor point but you may find easier to deal with eventually is your deck setup/initialization. As a magician I'm hyper-aware of how cards work as a deck so I though I'd toss this at you. Your GenSeq() function both initializes and randomizes a deck. You might want to consider a more real world scenario and split the deck manipulation into 1) Initialization 2) Shuffle Assuming a normal deck of cards, initialization could simply be loading the new deck with sequential values. This closely simulates a brand new unopened deck to start. Your function could in fact be used to assume a used deck to start with. Call once, like srand(). Then implement a shuffle function which could mimic a riffle and/or overhand shuffle for more realistic manipulation. These two are probably the most used shuffles. Simply randomizing the deck as most programs seem to do does not take into account the dynamics that shuffling offers. Which is a moot point if you don't really care -- which is just as acceptable... __________________
Cow: You're a lawyer too? Mooseblood (mosquito): Ma'am, I was already a bloodsucking parasite. All I needed was a briefcase! |
|
#9
|
||||
|
||||
Re: Decks and DiceThanks for the feedback everyone.
Walt, when I did this last year it was because of a bunch of randomization posts that were going on at the time. IIRC you posted some links talking about what is a shuffle and discussed it a bit. I like your idea of "opening a new box" with the constructor and then going through the physical process. I'm going to have to revisit those and see what a year has done for my thought process. davis, when I was playing with this last year I was thinking along the lines of how I would use the class. I wasn't so much interested in the N-sided class, but the final concrete classes that would depict a particular object (in my case a 6 sided die) in a way I could wrap my brain around. I'll have to go through your reply a bit more to see if I have any questions based on that when I get a chance. Mark __________________
"Opportunity is missed by most people because it comes dressed in overalls and looks like work." --Thomas Alva Edison "Those who would give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety." --Benjamin Franklin "A happy person is not a person in a certain set of circumstances, but rather a person with a certain set of attitudes." --Hugh Downs |
|
#10
|
||||
|
||||
Re: Decks and DiceAnother idea building off of davis' code:
CPP / C++ / C Code:
CPP / C++ / C Code:
I couldn't help uncapitalizing the first letters of method names, would you believe I actually have a hard time reading it the other way? Just locked into familiar styles, I guess. I also added a const qualifier to the getSides method, as we wouldn't expect the Dice to change in any way after simply checking the number of sides (Heisenberg anyone? Matthew P.S. I forgot to mention, you might also find it convenient to add the following: CPP / C++ / C Code:
__________________
I was born not knowing and have only had a little time to change that here and there. -- Richard P. Feynman Boris Podolsky: James! How's the rat business? James Moreland: Well, actually it's mostly students I'm experimenting on now. Kurt Gödel: My God, the mazes must be enormous. |
Recent GIDBlog
Toyota - 2008 July Promotion by Nihal
| Thread Tools | Search this Thread |
| Rate This Thread | |
|
|
Network Sites: GIDNetwork · GIDWebHosts · GIDSearch · Learning Journal by J de Silva, The