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. :-)
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
| |
For: |
|
Use: |
| & | | & |
| < | | < |
| > | | > |
| [ | | [ |
| ] | | ] |
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.