Requirement types ?

Archived from groups: rec.games.roguelike.development (More info?)

Hi, this time I'll be glad to hear your suggestions about requirement
types. Those are requirements whether you're able to use
skill/spell/item.

First question is: Event vs Parametric requirements ?
Second one is: What type of parameters ?

I would like (for mod-makers easier) to implement parametric
ones..Respectively melting down all posibilities of Event requirements
which are wider for sure but it should be bothering to implement for
every skill (etc.) So having something like:

REQUIREMENTS
|-Type:SKILL "RequiredSkill"
|-Type:LEVEL "RequiredLevel"
|-Type:QUALITY-BEING "BeingAttribute" "RequiredValue"
|-Type:QUALITY-ITEM "ItemAttribute" "RequiredValue"
|-Type:BODYPART "Bodypart" "TestIfBeingHasBodypart"
..

any suggestions on other types of requirements ?

regards,
Jan
5 answers Last reply
More about requirement types
  1. Archived from groups: rec.games.roguelike.development (More info?)

    |-Type:TERRAIN "IsOnRequiredTerrain"
    |-Type:ALIGNMENT "HasRequiredAlignment"
    |-Type:TIME "IsRequiredHour"

    T.
  2. Archived from groups: rec.games.roguelike.development (More info?)

    Nice ones :)

    Inspired I'll add these:

    |-Type: ITEM "RequiredItem"
    |-Type: MONEY "RequiredAmount"

    regards,
    Jan
  3. Archived from groups: rec.games.roguelike.development (More info?)

    "Jan Drahokoupil" <drahokoupil@telpro.cz> schrieb im Newsbeitrag
    news:1121691248.925726.320140@g43g2000cwa.googlegroups.com...
    > Hi, this time I'll be glad to hear your suggestions about requirement
    > types. Those are requirements whether you're able to use
    > skill/spell/item.
    >
    > First question is: Event vs Parametric requirements ?
    > Second one is: What type of parameters ?
    >
    > I would like (for mod-makers easier) to implement parametric
    > ones..Respectively melting down all posibilities of Event requirements
    > which are wider for sure but it should be bothering to implement for
    > every skill (etc.) So having something like:
    >
    > REQUIREMENTS
    > |-Type:SKILL "RequiredSkill"
    > |-Type:LEVEL "RequiredLevel"
    > |-Type:QUALITY-BEING "BeingAttribute" "RequiredValue"
    > |-Type:QUALITY-ITEM "ItemAttribute" "RequiredValue"
    > |-Type:BODYPART "Bodypart" "TestIfBeingHasBodypart"
    > ..
    >
    > any suggestions on other types of requirements ?

    I would add a parameter to define if the value must be higher or lower and
    i would add quantity to Item ,to produce something like a 20-Shot bow that
    needs 20 arrows,before it can be used.

    |-OwnerStatus : Item "lend,buyed,stolen"
    | A magic sword that only works when it is stolen
    |-Trigger: "Is_This_flag_set"
    | Spell that only works after the crystal ball of the Green Wizzard is
    destroyed
    |-Quality-Target
    | A dagger that set enemys with under 30 HP on fire
    |-Bodypart-Target
    | A skill that allows to cut of the head of enemys that have one
  4. Archived from groups: rec.games.roguelike.development (More info?)

    "Jan Drahokoupil" <drahokoupil@telpro.cz> wrote:

    > Hi, this time I'll be glad to hear your suggestions about
    > requirement types. Those are requirements whether you're able to
    > use skill/spell/item.
    >
    > First question is: Event vs Parametric requirements ?
    > Second one is: What type of parameters ?
    >
    > I would like (for mod-makers easier) to implement parametric
    > ones..Respectively melting down all posibilities of Event
    > requirements which are wider for sure but it should be bothering
    > to implement for every skill (etc.) So having something like:
    >
    > REQUIREMENTS
    > |-Type:SKILL "RequiredSkill"
    > |-Type:LEVEL "RequiredLevel"
    > |-Type:QUALITY-BEING "BeingAttribute" "RequiredValue"
    > |-Type:QUALITY-ITEM "ItemAttribute" "RequiredValue"
    > |-Type:BODYPART "Bodypart" "TestIfBeingHasBodypart"
    > ..
    >
    > any suggestions on other types of requirements ?

    Just use a callback function which returns true if it can be used, or
    false if it can't (and returns a message to indicate why not). If all
    you have is pre-made conditions then you are going to miss things like
    'has X in inventory' (spell component/focus), 'used Y the turn before'
    (part of a group of items that must be used in series), 'no mailreader
    configured' (for a scroll of mail), and so on.

    I said this in the previous thread about item events, and I'll say it
    again. If you have to list all the possibilities that someone might
    want, then (a) there is a 100% probability you missed some
    possibilities, no matter how many you come up with; (b) your design is
    therefore broken; and (c) you are, on some unconscious level, using the
    task of listing possibilities as a procrastination tool to avoid
    working on things that actually matter.

    --
    CalcRogue: TI-89, TI-92+, PalmOS, Windows and Linux.
    http://calcrogue.jimrandomh.org/
  5. Archived from groups: rec.games.roguelike.development (More info?)

    jimrandomh wrote:
    > "Jan Drahokoupil" <drahokoupil@telpro.cz> wrote:
    >
    > > Hi, this time I'll be glad to hear your suggestions about
    > > requirement types. Those are requirements whether you're able to
    > > use skill/spell/item.
    > >
    > > First question is: Event vs Parametric requirements ?
    > > Second one is: What type of parameters ?
    > >
    > > I would like (for mod-makers easier) to implement parametric
    > > ones..Respectively melting down all posibilities of Event
    > > requirements which are wider for sure but it should be bothering
    > > to implement for every skill (etc.) So having something like:
    > >
    > > REQUIREMENTS
    > > |-Type:SKILL "RequiredSkill"
    > > |-Type:LEVEL "RequiredLevel"
    > > |-Type:QUALITY-BEING "BeingAttribute" "RequiredValue"
    > > |-Type:QUALITY-ITEM "ItemAttribute" "RequiredValue"
    > > |-Type:BODYPART "Bodypart" "TestIfBeingHasBodypart"
    > > ..
    > >
    > > any suggestions on other types of requirements ?
    >
    > Just use a callback function which returns true if it can be used, or
    > false if it can't (and returns a message to indicate why not).

    Actually that's the case now..but we've found that this is really
    unbearably annoying. Sometimes you just want simple requirements and
    you still have to write your own scripting on that. Almost every item
    has it's requirements and we're trying to simplify this but I'm just
    testing if it's possible to do so. Because otherwise I'll leave on the
    scripting. Also I'm considering having both options available. When
    it'll be possible to describe the requirements by rules it will be done
    this way otherwise the scripting will be needed.

    > If all you have is pre-made conditions then you are going to miss things like
    > 'has X in inventory' (spell component/focus), 'used Y the turn before'
    > (part of a group of items that must be used in series), 'no mailreader
    > configured' (for a scroll of mail), and so on.

    Sure..as I said I'm trying to put some rules together to determine
    whether it is possible to have sane number of rules while covering wide
    area of possibilities.

    > I said this in the previous thread about item events, and I'll say it
    > again. If you have to list all the possibilities that someone might
    > want, then (a) there is a 100% probability you missed some
    > possibilities, no matter how many you come up with; (b) your design is
    > therefore broken; and (c) you are, on some unconscious level, using the
    > task of listing possibilities as a procrastination tool to avoid
    > working on things that actually matter.

    You're right in some software I do literally hate it (mostly M$ one)
    When it's suggesting that those are all rules (for example Outlook)
    you'll ever find usefull. So let's say I want to combine rules and
    scripting. But I need as many rules as possible to choose which are
    reasonable and which are not.

    > --
    > CalcRogue: TI-89, TI-92+, PalmOS, Windows and Linux.
    > http://calcrogue.jimrandomh.org/

    regards,
    Jan
Ask a new question

Read More

Development Games Video Games