Here we are in the last lecture for module
four about classes and objects. And as a reminder here are the module
learning objectives. And we've finally gotten to the one we're go, we're going to design a new class
together. So at this point in the module, we've discussed the foundational ideas
behind the object oriented paradigm here and we've discussed
how to use those ideas in a C-sharp program. Now were going to step back from the programming and do a higher level design
activity. To design a class. Before we actually do that, you should
take this in-lecture quiz. So, before we can design our rubber chicken class, we have to think deeply
about our game design, and really decide what
role does the rubber chicken play in our game. Now you might think That the player avatar
would be an awesome thing to use the rubber
chicken for. Sadly, not this time. This time we're going to design the rubber
chicken as a weapon. So it won't be a very limited weapon, of
course, because rubber chickens are pretty flexible now I
hope you got that. rubber chickens can be either melee
weapons as you can might, as you might be able to imagine and they can be
ranged weapons as well. So, the way we're going to approach this
is first we're going to think about the
state. What kind of information do we need to store to capture the characteristics of
the rubber chicken? And then we'll move on to behavior. Now it's important for you to realize that
as we design real classes for real games we end up iterating between
state and behavior as we go along. We might discover we need some new
behavior as we're developing our game. At which point we probably need to go back
and add some more state as well. So this is sort of a a-typical small
example well we'll cover state and then we'll
cover behavior. So you should now go to the in lecture
quiz, which really has you pause and think about the state of the
rubber chicken for a while. And then come back and we'll talk about
it. Okay, so there is some reasonable state
information that we might store for a rubber chicken that we''re going to use
as a weapon in our game. First of all, we're going to need location
we need to know where the rubber chicken is, so that we
can do collision detection. Especially if you're good at using your
rubber chicken weapon, you're going to actually collide that rubber
chicken with other stuff and the way we actually figure out that that's
happened is by using the location of the rubber
chicken. Rubber chickens also have velocity,
especilly when they're used as a ranged weapon. So if were to throw the rubber chicken, it
has a particular velocity. And so we're going to need that velocity
so that we can change the rubber chicken's
location over time. We also have a range for the rubber chicken.
How far can you throw it, for example. And so, you know, you get upgrades, you
get rubber chicken upgrades as you work your way through this Fictional game
that hopefully no one will ever build. So you get these upgrades to your rubber
chicken and so you can fling your rubber chicken further if you
increase the range through those upgrades. Accuracy, you also have accuracy with your
rubber chicken, you can't just fling it in any
direction and then expect it to hit stuff, you need
to actually be good at aiming your rubber
chicken, wow there are some weird things I'm saying today but
that's okay. You have to be able to aim your rubber
chicken with some level of accuracy and again you might be
able to upgrade that stuff. Rubber chickens, when we do get that collision with something, rubber chickens
inflict damage. Now that damage could be variable right,
it could be based on how far away the rubber
chicken was. Its velocity when it strikes whatever it
hits, because if you use it as a range weapon towards
something close, it will probably do more damage than if
you use it as a range weapon and you throw it far
away. So, there's some damage that's probably
variable, unless we stuff our rubber chicken with
C4. In which case it probably always inflicts about the same amount of damage when it hits something and
explodes. The last thing we probably want to store
which you may not of thought of is who is the owner of this
rubber chicken. And it's not because we need you know somebody to feed and care for this rubber
chicken. It's because usually what happens,
especially in games with weapons, especially in games with ranged weapons,
is if you inflict damage by throwing your rubber chicken towards
something and the rubber chicken hits and destroys, oh, I don't know,
something, imagine something, hits and destroys something usually the owner
of that particular projectile, in this case, will end up getting points or
upgrades or something. Right so you actually need to keep track
of who is the owner of the rubber chicken, so
that we could allocate to those benefits to whoever
damaged something with the rubber chicken. Okay, so if that hasn't been disturbing
enough to you. That's great.
Hang with me. We'll see how much more damage we can do. So you should now go do another in lecture
quiz. We really think about what kind of
behaviors should this rubber chicken have. And then click continue, and we'll move on
together. Okay. So there are a number of reasonable behaviors that this rubber chicken could
have. For example, we're going to want to update
this rubber chicken. Remember we talked, sorry, we haven't
talked yet, but we will talk soon about a game loop where we
update to the game world so that we sort of update
the status of everything in our game world and then
we draw it. So we will want to update the rubber
chicken periodically. Every frame in our game, in general. So that the location changes based on the
velocity. So we definitely want to the rubber
chicken to expose an update behavior. So that we can change its location as we
go along. We might also want our rubber chicken to
exhibit an explode behavior, so we could call a
method telling the. Rubber chicken to explode. That really only applies if we're using
the whole C4 rubber chicken approach.
But, you know, it's worth thinking about. We also may, if we have a more interesting game, we may have the rubber chicken play
an animation. It can play one animation as it flies through the air Another animation right
before it realizes it is going to explode because rubber
chickens are pretty self aware and they know that's
going to happen. and a variety of other animations just for humor. If you're building a game with rubber
chicken weapons, you probably are keying into the
humor idea. So playing some animations might be
interesting. I have in fact done this class design
exercise in a sort of normal. Well not a normal classroom, a classroom
of my game development students, let's put it
that way. And so I felt compelled to tell you that
there is one unreasonable behavior, at least for the rubber chicken. And most rubber chickens are not going to
in fact turn into a live chicken. Sometime in the game. That would just be wrong. This is not Pinocchio with rubber
chickens, so we we're probably not going to convert our rubber chicken
into a live chicken. Okay, so that was sort of a short and
sweet what thought process do we go through to actually design the
classes in our game. And that's probably enough for sort of the
informal figuring out what you need as you build classes in
your games. More advanced object-oriented analysis and
design has, uses much more formal tools to actually
figure out state and behavior and so on, and so
in later classes that I teach at UCCS, we actually cover those kinds of
things. But this sort of informal thinking about
it kind of process, including understanding
that you're probably going to iterate in practice, is, is a
reasonable first taste towards how we actually design
stuff. So, that's the end of module four. Next time, we'll actually move on to
talking about the XNA framework.