This is our last lecture in this module
developing a Console Application class. So next time we will move on to doing XNA
stuff, but we have a little bit more work to do
here first. As a reminder here are the module learning
objectives for the entire module. So you should recall that last time we
added the two constructors to the die class.
One, that built a die with the standard 6 sides and one that built a die with a
consumer specified to number of sides. So there was a parameter in the
constructor and there was an argument when we called the constructor to tell it
how many sides we needed. This time, we're going to implement the single roll
method that we need in our die class. So I have the project available to us. We already have, recall, fields,
constructors, and properties in our class. So now we can add methods. [SOUND]. And we needed a single method.
We need the roll method. And we're going to learn something new as
we develop this method and the rest of it we've
already seen before. So methods have an Access Modifier and
because we want a consumer of the class to be able to roll the die, we're
going to make this method public [NOISE]. The next thing that happens, the next
thing that we put as we build this method, is the return
type for the method. So, the deck take top card method, had a
return type, I'm going to type it here, it's not
going to work. Had a return type of card, because it
returned a card from the method when you took it. Other methods in the deck class, had to
return typo void. They didn't return anything at all, they
just did their job and then were done with it. And so, we need to think about should the
roll method have a return type, should it
return anything or not. And this is actually a trade off for this
method because the way I'm implementing it, it's going to have a void return type
which means it doesn't return anything, and then it's much more like what actually
do with dice, right. You roll a die and then you look at what
number's on top. So standard usage would be somebody rolls
the die by calling the roll method and then accesses the top side property to
see which side is on top. There is an alternative certainly we could
return an int from here, so that we rolled the die and then
generated the sorry, then accessed the topSide
property an returned that. We could do that, but we're going to do it
this other way instead. So, [NOISE] Access Modifier, return type, method name, well, not exactly that way [NOISE]. Method name parentheses, even if there are
no parameters, parentheses [NOISE], open brace, curly brace, and we'll put in
the comment momentarily. So, the next question is, is there any
information that we need from the consumer of this method
to say something about the role? And the answer is no, in this particular
case the answer is no. They're just going to roll the die.
So I put the three slashes in, and I say
rolls the die. So, how do we roll the die?
Well rolling a die means that we are randomly picking some number, right, from
the set of sides, of the die. We are randomly picking which side should
be on top. So we're definetly changing topside. And we can. Well, gee, I said we need to have a random
number, so I'm going to create [NOISE] a new random number generator [NOISE] right here, and this new random number
generator will use, we will use this new random number generator to
generate a random number for the top side. And we'll actually use the overload of
rand.Next that lets us specify both the lower bound and the upper bound,
because we are numbering the sides on our die starting at 1.
We will put a 1 here as the first one. And so for a six sided die for example, we
want a random number between 1 and 20. So, ha, ha, that's crazy. Here I am thinking DND again.
for a six-sided die, we need a random number between 1 and 6.
And so we need to say numSides plus 1 because remember the upper bound for
our, for this argument to the next method. This gives an upper bound, an exclusive
upper bound. So if we pass in 7, it will give us, for this call, a number, a random number
between 1 and 6. So let's actually go back to our, well,
I'll save it. And we'll go back to our testing code [NOISE]. And we will roll the die [NOISE]. We'll roll and print the results. [NOISE] So we tell the die, the standard die, in this case, to roll itself [NOISE], and then we will display the top side
again. So I'll just grab these two lines of code,
and put them here instead. Put them here also. So if I Ctrl F5, we see that we roll and
we get a topside of 3. And just so that you see that this rolling
also works, for the D20. We'll do it here as well. Although of course we'll need to change a
little bit. We'll need to roll the D, we'll need to
tell the D20 to roll itself, and we will then
tell the D20. We'll then access the topSide property of
the D20. Okay.
So I'll control f5. So, so far, this looks pretty good, right? It looks like we're getting a random
number. And by the way, let me just add the right
line that we're missing here. [SOUND]. By the way, I had to be careful over here
in the roll method to not just say between 1 and 6 right, because we could have an arbitrary number of sides on the dice, on
the die. So that's why I used numSides here to make
sure that it would still work for the D20 as
well. Unfortunately, even though there is all
looks great. Let's roll a few times in a row. [NOISE] Ctrll F5, and you will see that for the
standard die we rolled a 2, and then a 2 and then a 2.
So this is actually an issue with random number
generators when we create a new random number
generator, what happens is, it takes the system clock
time from our computer in general, and uses it as something
called a Seed, and that seed is the start of generating a sequence of
numbers using an algorithm, a set of mathematical
steps to figure out the next number. So in computers these aren't actually
random. They're what are called pseudo-random, because they are
not actually random, if you know the Seed and you know the algorithm you can perfectly
predict the sequence of numbers that would be
generated. The problem is that if you start with the same Seed and you are going to be using
the same algorithm because that's just
expressed in code, then you're going to get the same sequence of
numbers all the time.
And so the issue is that because computers are really, really fast, we end up with three calls to roll in quick succession
such that the system clock is close enough to the same that
each random number generator gets the same seed.
So I am going to take this random out of there, and I am going to move it up here
as a field instead, that was crazy.
I will just take it in now [COUGH], I guess I just you know, [UNKNOWN] instead of seeded.
So new random [NOISE] up here in the class. So, this will get created when the object
is constructed. And so each call to roll down here isn't
creating a new random number generator anymore, is in fact just using the one
that we created inside the object. And I'll Ctrl F5 again, and you can see,
yes, we did get two 4's in a row, but that was not the problem I was talking about. As you can see we are getting essentially,
random rolls. Now, I've solved part of the problem here. and the different dice look different
because one is generating numbers between 1 and 6 and one is generating numbers
between 1 and 20. But, we would have the same exact problem
even with what I've done so far, if we created two 6 sided die in a row because we'd be creating the objects quickly enough
potentially anyway that they'd end up with the same Seed so both dice would end up with the same sequence
of numbers. Even though the numbers changed over the
sequence, the dice would always match. The optimal robust commercial quality
solution is to have a random number generator that you create for your
entire game, and every time anything in the game needs
a random number, it just goes to that one
single centralized random number generator and
gets a random number. We're not going to do that here because
we're focused on class design and implementation rather than sort
of the overall game design implementation. But, that you should know that because
this is an important issue for random numbers. So we have created everything that we
needed to create today. And in fact, we have finished off our die
class in implementation. So, over the course of 3 lectures, we designed it and we implemented state the
first time, and then identity last time, and now
behavior this time, so all done with the die class. Next time we're going to actually start developing a class. We'll design it and implement it for use
within an x and a game.