Requirement types ?

[Guest]

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

 

[Guest]

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

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

T.

 

[Guest]

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

Nice ones

Inspired I'll add these:

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

regards,
Jan

 

[Guest]

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

 

[Guest]

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/

 

[Guest]

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