• entries
    109
  • comments
    175
  • views
    116606

Again, a small update

Sign in to follow this  
Emmanuel Deloget

94 views

I'm going to do a lot of small updates every time I need it (to speak about the progress I make everyday). I hadn't much time to work on the source code today, so I only did one important class: the CreatureGroup - believe it or not, it handles a group of creature. The class is meant to be used in teh combat system, but since it has a visit() method it can be used for various purpose.

There are a few things I'd want to say about this class. First, it is heavily commented - very heavily. For example, this is the code of the visit() method:

// visit all the creatures; this is again a use of the
// visitor pattern, but this one is slightly different since
// there is only one creature type (ie we don't have any
// difference between a human player and a dragon NPC).

bool CreatureGroup::visit(CreatureVisitor& visitor)
{
for (size_t i=0; i if (!visitor.visit(mCreatures)) {
return false;
}
}
return true;
}

As you can see, while I just taled about the visit() method and despite the name of the CreatureVisitor class, I make clear that I don't apply the real visitor pattern here - mostly because I don't really need it (and remember that I target simplicity).

Second, in this class I decided to introduce the notion of functor and template method. For example, the creatures in the CreatureGroup can be ordered - I provided a sort() method that takes a ORDERER template paramater:

// order creatures depending on a parameter functor
// ORDERER must overload operator(); you can pass
// one of the ordering functor defined before

template <class ORDERER> void sort(ORDERER orderer)
{
// since it is a template function, I have to define it as an
// inline function

std::sort(mCreatures.begin(), mCreatures.end(), orderer);
}

The notion of template is loosely introduced (I should rewrite the comments) and the notion of functor is explained in detail in the header file.

I'd also like to talk about the visitor pattern. Yesterday (I believe it was yesterday), I told you that the visitor pattern breaks the OCP rather violently. It also introduces another problem in terms of OO design: a cyclic dependency.

The visitor have to know the concrete class it must visit, and the concrete class have to know the visitor. This is what I'd call tight coupling.

It seems that the visitor patter, while solving a very difficult problem, exhibits some specific difficulties itself.

This is the primary reason why I implemented a pseudo-visitor in the CreatureGroup class (the other was: I don't really need a full blown visitor).

Next to do: the combat system and the action resolution system. The combat system is pretty evolved. I must handle the player and the AI controlled creatures (both the friendish ones and the other ones). I must let the player decide what he is going to do (rather simple: attack, defend, launch a spell, use an object or flee) and I must choose the actions of the different AI-controlled creatures (their behavior is given by the creature race or by a specific behavior object, I don't know yet) I must also decide who gains the initiative and who attack who. Then I must process everything, roll the attacks, compute the damages and so on (I found a job for the InventoryVisitor: find what is the current creature weapons and armors).

Of course, the combat system itself is very simple (I throw a dice to attack, you throw a dice to defend, if mine is greater than yours then I hit you); there are some little quirks but most of them are already implemented.

Now that I explain it, it seems rather complex [smile]

See you later, dudz !
Sign in to follow this  


0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now