Skip to Content
 

Randomizers, they are all the same

13 replies [Last post]
Mon, 10/04/2004 - 14:12
Anonymous

All forms of randomization: Cards, Dice, Spinners, whatever are functionally the same. The simple solution is to treat all of these as decks of cards with a number of available values in the proportions you desire.

Thus: 1d6 is a 6 card deck with a card for each value from 1 to 6. A spinner with a 2/3 chance of Option 1 and a 1/3 chance of Option 2 is a deck of cards with 2 Option 1s for each Option 2.

It might be a good idea to have an option for card drawing that functionally Draws, Reveals, Replaces, and Reshuffles.

For Public vs. Private information it would probably be a good idea to simply have a switch for each player. "Known to Player X" for every player. These on-off switches can be examined at any time and changed at any time. A "Hide from all" option that changes the status to "Off" for all players and a "Show to all" option that changes the status to "On' for all players is probably a good idea.

You will also want to set up some objects as "Static" which can not be changed (the board, the pawns, that sort of thing). You will also want a default value, the three most common i can think of would be: "Hide from all", "Show to all", and "Show to current player".

More as i think of it...

Thomas

Top
Mon, 10/04/2004 - 14:48
#1
jwarrend
Offline
Joined: 08/03/2008
Randomizers, they are all the same

To consider a d6 a deck of six cards, you have to reshuffle the deck every time you draw a card. If a player has to remember this for every "die roll", it will be a pain. If the computer does it for you, then just call it a "die roll" and make it easy.

I don't disagree with the general premise that randomizers can be handled with similar logic. But it's important that the game handle probability distributions correctly for the various kinds of randomness.

-J

Top
Mon, 10/04/2004 - 14:51
#2
Anonymous
Randomizers, they are all the same

Agreed on both points. What we call it in game does not really matter. My point was one of implementation. We only need to implement a single randomizer system: the one for a deck of cards, as opposed to one for Dice, one for Spinners, etc.

Thomas

Top
Mon, 10/04/2004 - 14:59
#3
ensor
Offline
Joined: 08/23/2008
Randomizers, they are all the same

I think it would be good to have two definite types for users, both dice and cards. Underneath, you could have a Randomizer class with upper and lower bounds, different types of distribution, a "sampling with or without replacement" option, but to make a die-like object they shouldn't have to make a deck of cards and then remember to reinsert the card drawn and reshuffle every time, it should come as a package deal.

Top
Mon, 10/04/2004 - 15:06
#4
Anonymous
Randomizers, they are all the same

Again i agree. But i would argue for an implementation that is a deck of cards that automatically replaces the card drawn and reshuffles. This is not difficult and it saves the time of creating a whole new Object. It also allows more flexibility (customized dice become easy when they are simply cards).

It seems to me that a simple option to Draw, Reveal, Replace, Reshuffle for a given Deck of cards would be far more effecient and flexible than implementing seperate Object types for all variations of randomization (and there are quite a number of them).

Thomas

Top
Mon, 10/04/2004 - 15:08
#5
Oracle
Offline
Joined: 06/22/2010
Randomizers, they are all the same

ensor wrote:
I think it would be good to have two definite types for users, both dice and cards. Underneath, you could have a Randomizer class with upper and lower bounds, different types of distribution, a "sampling with or without replacement" option, but to make a die-like object they shouldn't have to make a deck of cards and then remember to reinsert the card drawn and reshuffle every time, it should come as a package deal.

If the Randomizer class is "underneath" the classes for with and without replacement, how is the Randomizer class supposed to know what has already been drawn. It would be the responsibility of the without replacement class to keep track of that information.

What you can do is have the Randomizer class being the without-replacement class so it always works without replacement and then the with-replacement class is a sub-class that will tell it to reshuffle before each randomization. I don't really like that way though because the computer is doing a lot of extra work in the without-replacement case.

Top
Mon, 10/04/2004 - 15:13
#6
Anonymous
Randomizers, they are all the same

Interesting take on things. I was considering them to be a single class: DeckOfCards, which will need Replace Card function anyway (for if you run out of cards, or for games where cards are drawn and replaced anyway). Then you simply implement a function that automatically replaces the card drawn. You can set up a daughter class to DeckOfCards known as Randomizer which automatically implements replace at the end of the turn (or whenever).

Thomas

Top
Mon, 10/04/2004 - 15:40
#7
Oracle
Offline
Joined: 06/22/2010
Randomizers, they are all the same

LordSmerf wrote:
Interesting take on things. I was considering them to be a single class: DeckOfCards, which will need Replace Card function anyway (for if you run out of cards, or for games where cards are drawn and replaced anyway). Then you simply implement a function that automatically replaces the card drawn. You can set up a daughter class to DeckOfCards known as Randomizer which automatically implements replace at the end of the turn (or whenever).

There's two philosophies in OOP, one is to make as many different classes as possible, so they do exactly what it's supposed to (ie the coder shouldn't worry about reshuffling the deck each time. They should say they're using something with replacment, and then let the class take care of it for tuem). The idea there is it reduces the chances of a bug; the coder might forget to tell it to reshuffle. The main code also looks cleaner because more is abstracted away.

The other way is to have as few more generalized classes as possible, and use extra code to adjust them to fit the application. The advantage there is there's fewer classes for the programmer to be dealing with, so they can learn to use them better and be more sure they have the right one for the job.

I usually prefer the second way of looking at it, so I'm kind of surprised that my earlier suggestion fits the first way.

Jason

Top
Mon, 10/04/2004 - 15:54
#8
sedjtroll
sedjtroll's picture
Offline
Joined: 07/21/2008
Randomizers, they are all the same

Wouldn't/Couldn't a 'deck of dice' simply be another deck of cards, and in order to "roll" you simply put the top card of that deck into that decks discard pile? If you're drawing a card then shuffling it back into the deck each time then that's kinda silly- computers are good at generating random numbers between whatever range you want.

- Seth

Top
Mon, 10/04/2004 - 15:56
#9
FastLearner
Offline
Joined: 12/31/1969
Randomizers, they are all the same

(Not to get into the programming side, but let me say that the fact that decks of cards have "memory" is very important to many designs, and random pulls followed by automatic reshuffles will ruin a lot of games.)

Top
Mon, 10/04/2004 - 16:09
#10
Oracle
Offline
Joined: 06/22/2010
Randomizers, they are all the same

sedjtroll wrote:
Wouldn't/Couldn't a 'deck of dice' simply be another deck of cards, and in order to "roll" you simply put the top card of that deck into that decks discard pile? If you're drawing a card then shuffling it back into the deck each time then that's kinda silly- computers are good at generating random numbers between whatever range you want.
- Seth

That's the way we're talking about doing it. On the one hand, it is pretty simple to tell the computer to generate a random number in a certain range so it seems like a waste of processing time to have the deck class go to all that trouble. On the other hand, it's nice to present a consistant interface to the programmer rather than automatically handling the deck and leaving them on their own for the dice.

BTW, computers are good at generating pseudo random numbers, but true random numbers are much harder. It makes no difference for this project, but if we needed true random numbers (like for encryption), the random number generator in the programming language wouldn't be suitable. One of the more interesting ways of generating random numbers is www.lavarand.com . They point a digital camera at a row of lava lamps, then then perform a hash algorithm on the random image to get a real random number.

Jason

Top
Mon, 10/04/2004 - 17:26
#11
Anonymous
Randomizers, they are all the same

The reason i suggest using a unified "deck" mechanic for all forms of randomization is that it is significantly more flexible and also quite a bit less work.

For example, let us assume that my game uses d6s with customized faces. I can just make a 6 card "DiceDeck" that has those faces. Also, programming a single randomization system is easier, and for designers it means that they only have to learn how to manipulate a single aspect of code for whatever randomizers they want.

It should also be highlighted that the automatic Replace, Reshuffle code would be optional. In the same way that memory is important with many card based games, absence of memory is important in most randomizers.

Thomas

Top
Mon, 10/04/2004 - 17:38
#12
phpbbadmin
Offline
Joined: 04/23/2013
Well

I hate to do a 'Hey, look at what I said' post, but did anyone bother to read my reply to RookieDesign's Object Definitions post? In that reply, I layed out a very logical method for implementing objects, including randomization. Someone please read it and tell me what they think. I think my reply got 'buried' by LordSmerf's, either that or it was not understood, because I think it's spot on for what we need.

-Darke

Top
Tue, 10/05/2004 - 19:40
#13
Trickydicky
Offline
Joined: 12/31/1969
Randomizers, they are all the same

Darke

I'm not a programmer. So take this for what its worth, but your above mentioned post was the only one that really made any sense to me. If it is simple enough for a complete non-programmer to understand then it gets my vote.

Top
Syndicate content


forum | by Dr. Radut