posted 11 years ago
hi Hans,
I was asking about the structure, because I wanted to know the 'visability' of your Player class (or 'PlayerCharacter'
as you call it). The easiest way to let all of your classes know about the existence of the 'PlayerCharacter' class
is to put that class in a separate file inside your package, that is indeed the folder in which you have all
your classes. In that case you can define the interface 'Creature' safely with a reference to a 'PlayerCharacter'.
I understand this: you have a 'Play' class, and an 'Encounter' class, and by the look of it, it is an instance of the 'Encounter'
class that does the actual game:
and where 'spaces' is the actual board in use.
Please correct me if I'm wrong.
My idea was to define the board as:
And then populate this array in your initializer method, something like:
And what specific Creature this _XXX would be, well, that's up to you to decide that,
maybe based on some formula that picks a specific Creature at random from the
available Creatures that you have defined.
Now, the whole idea is that if your player lands on some space, say spaces[2, 3],
that this space, being some Creature, knows what to do! You do not need to know
what specific Creature that might be, the Creature itself knows it, and that's enough!
How does this work? Because each Creature, be it 'Creature_XXX' or 'Creature_YYY',
has a method 'doAction(PlayerCharacter player) {...}' that exactly defines what
should happen to the player in this method.
So, suppose we have two players, 'Hans' and 'Piet', playing your game in a turn based
fashion (yes, two players!). It's Hans'turn and he lands on spaces[2, 3].
Since spaces[2][3] is a Creature, it knows what to do, it has a method 'doAction', and
so we call:
and since Hans is lucky, he gets a sword. You, see, there is no need to retrieve what kind of
creature is located on spaces[2, 3].
Now it's Piets turn. The dice are cast, and he lands on spaces[4,5].
Here we go again:
You see, no long if's and else's.
Now look at your lines 09 and 10 of the 'Encouter' class.
The right hand part is okay, you call the 'doAction' methode of
whatever Creature populates that space. But there is no need to retrieve
that Creature.
Now, with this in mind, a possible set up of the game might be:
As said, this is just an example of what is possible. But I hope that the idea of using 'interfaced'
Creatures is clear, and how you could act the 'doAction' on this player.
Greetings,
Piet
There are three kinds of actuaries: those who can count, and those who can't.