It looks like a fairly good setup. I do have a few suggestions.

• I'm not sure the Combat object is needed right now; it's possible to convert Combat's methods to methods of "Peasant" (or better yet, a base class for Peasant). It depends a bit on how you mean to extend it.

• In the combat() method you have ($combatref, $self, $self2) = @_;. It's a good idea to have $self always be the current object, not another argument. I would probably write it as ($self, $combatant1, $combatant2) = @_;.

• I would move the item transfer code to the combat() method, and let the damage() method return the health of the combatant. This also implies you need inventory and/or gold accessors.

• You shouldn't access other object's internal state directly; make methods to access them. I.e. don't use $attacker->{_name}, use $attacker->name().

  This will allow you to change the implementation (as a silly example, you might want a creature that looks different each time you look at it - that's easy to implement if you get the name from a method, but it gets really messy if you try to pull the name out of the objects hash).

• You'll want to create a base class for characters/monsters. That will allow you to create new "creature classes" quickly. Just split out the reusable methods in a seperate class when you start adding creatures.

Cheers,
Joost.

update: I just noticed a fairly significant assumption in your code, namely that a Peasant is a (mostly) permanent classification. In other words, by making Peasant a class, you make it hard to "upgrade" a character from say a peasant to a merchant, warrior or whatever (assuming Merchant and Warrior are separate classes). That might not be a wise choice if the Peasant class is a player-character (NPCs don't usually change class, but players do sometimes upgrade in MUDs I know)

There are ways to work around that in perl - at the most basic level, you can just re-bless() an object into another class - but if you're working with additional libraries (say - Class::DBI to store your data) that could become cumbersome. Most libraries consider classes to be static, even though that's not a requirement in Perl.

If Peasant objects regularly change "class" you might want to consider storing the "class" in a field instead. I.e. make a PlayerCharacter class that has a "character_type" field or something similar. If your "classes" are really very different in behaviour, your original setup might be more useful, though. As in all software design, it depends. :-)