views:

158

answers:

5

I'm working on a RPG using django and am considering different options for implementing part of the skill system.

Say I have a base skill class ie, something like:

class Skill (models.Model):
      name = models.CharField()
      cost = models.PositiveIntegerField()
      blah blah blah

What would be some approaches to implementing specific skills? The first option that comes to mind is:

1) Each skill extends Skill class and overrides specific functions:

Not sure how this would work in django. Seems like having a db table for each skill would be overkill. Could the child class be abstract while the Skill class have an entry? Doesn't sound right. How about using a proxy class?

What are some other options. I'd like to avoid a scripted approach for a pure django approach.

+1  A: 

I'm kind of tired (late here in Sweden), so I am sorry if i misunderstood, but the first thing that popped into my head was extra fields on many-to-many relationships.

Baresi
This is a great suggestion, but I'm having a hard time thinking of how to avoid having extra models for each skill using this method.
jathanism
+1  A: 

I would set up some inheritance.

class BaseSkill(models.Model):
    name = models.CharField()
    cost = models.PositiveIntegerField()
    type = models.CharField()
    ....

class FireSkill(BaseSkill):
    burn_time = models.PositiveIntegerField()

    def save():
        self.type = 'fire_skill'
        return super(FireSkill, self).save()

class IceSkill(BaseSkill):
    freeze_time = models.PositiveIntegerField()

    def save():
        self.type = 'ice_skill'
        return super(IceSkill, self).save()

The advantages of this are when you just want to list a player skills you all need to work with the BaseSkill class. If a vendor is selling skills you only need to list prices from the BaseSkill class. When you need more detailed attributes of a skill it is easy to take the type to access it. E.g. If you have: skill = BaseSkill.objects().get(pk=1) you can access ice skill by doing *skill.ice_skill.freeze_time* or more generally *get_attribute(skill, skill.type).field_name*

Jason Christa
+1  A: 

When I've seen this, there have been two classes: one for the Skill as an abstract instance (e.g. a skill in speaking Swedish, a skill in Excel development) and then the actual skills possessed by a person with a foreign key to the Skill.

hughdbrown
+5  A: 

Perhaps you might consider separating a skill and it's associated effect. More that likely, skills will end up having one or more effect associated with them, and that effect could potentially be used by multiple skills.

For example, an effect could be "Does N frost damage to current target". That effect could be used by the skills "Blizzard Bolt", "Frost Blast", and "Icy Nova".

models.py

class Skill(models.Model):
    name = models.CharField()
    cost = models.PositiveIntegerField()
    effects = models.ManyToManyField(Effect)

class Effect(models.Model):
    description = models.CharField()
    action = models.CharField()

    # Each Django model has a ContentType.  So you could store the contenttypes of
    # the Player, Enemy, and Breakable model for example
    objects_usable_on = models.ManyToManyField(ContentType)

    def do_effect(self, **kwargs):
        // self.action contains the python module to execute
        // for example self.action = 'effects.spells.frost_damage'
        // So when called it would look like this:
        // Effect.do_effect(damage=50, target=target)
        // 'damage=50' gets passed to actions.spells.frost_damage as
        // a keyword argument    

        action = __import__(self.action)
        action(**kwargs)

effects\spells.py

def frost_damage(**kwargs):
    if 'damage' in kwargs:
        target.life -= kwargs['damage']

        if target.left <= 0:
            # etc. etc.
T. Stone
In the games I've worked on, you wouldn't have a separate sub-class for each skill. You'd have something like this with a generic 'Skill' class holding the universal information and associate different effects and actions with the skill as needed.
Kylotan
(That was meant to be an 'I agree with this answer' comment.)
Kylotan
Thanks for the good response. I knew I'd end up doing a bunch of inheritance for other skill types, ie passive vs active skills etc. Having the separate field as part of the base skill that points to module/class/function that defines the skill/effect specific actions gets to the heart of what I was trying to figure out.
awithrow
A: 

You could also use single table and save inner model based off object in a pickled field.

kibitzer