Sign in with
Sign up | Sign in
Your question

Item events ?

Last response: in Video Games
Share
Anonymous
July 12, 2005 7:07:45 AM

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

Hi, I got different problem this time.
Any suggestions on item events (what
should happen to them). So far we've:

OnActivated - item is being used
OnAccepted - item is being given to owner
OnBoiled - item is changing from fluid to gas
OnBorrowed - item is being borrowed to owner
OnBought - item is being bought by owner
OnBroken - item is changing from normal to broken
OnCondensed - item is changing from gas to fluid
OnDropped - item is being dropped by owner
OnDrunk - item is being drunk by owner
OnEaten - item is being eaten by owner
OnWielded - item is being equipped to owner's hand slot
OnWorn - item is being equipped to owner's non-hand slot
OnExploded - item is flammable and it was fired-up
OnGiven - item was given from owner to somebody
OnMelted - item is changing from solid to fluid
OnLent - item is being lent by user to somebody
OnPicked - item is being picked-up by owner
OnRusted - item is changing from unrusted to rusted
OnShot - item is being shot by user's missile weapon
OnSold - item is being sold by owner
OnSolidified - item is changing from fluid to solid
OnStealed - item is being stealed from owner
OnTakenOff - item is being taken-off from owner's non-hand slot
OnThrown - item is being thrown by owner
OnUnwielded - item is being unwielded from owner's hand slot

best regards,
Jan

More about : item events

Anonymous
July 12, 2005 7:38:36 AM

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

Hi, think OnActivated even should be used in this case..for weapons
this is called before attack..so it'll be much like:

AxeOfKings.OnActivated {
// your code to bypass the armour
}

regards,
Jan
Anonymous
July 12, 2005 7:42:56 AM

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

Oh, now I got it..ofcourse..this should be added:

OnAttack - direct (active) use
OnActivated - special powers used

thanks a lot,
Jan
Related resources
Anonymous
July 12, 2005 8:25:06 AM

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

Chris Morris wrote:
> "Jan Drahokoupil" <drahokoupil@telpro.cz> writes:
> > Oh, now I got it..ofcourse..this should be added:
> >
> > OnAttack - direct (active) use
>
> Don't forget that with (e.g.) a vampiric weapon OnAttack is both an
> effect on the target (-HP, -energy) and on the wielder (+HP, +energy).

Surely, the event should have it as a parameter

function OnAttack(Item,Owner,Target,GlobalData):Boolean;

> > OnActivated - special powers used
>
> Similarly OnAttacked for armour or other items with special powers, then.
>
> How would you handle an Amulet of Resist Cold and a Ring of Resist
> Cold. Both grant cold resistance when worn. If you use OnWorn to set
> -cold and OnUnworn to unset -cold, then there's the possibility of
> bugs when someone:
> 1) Equips the AoRC
> 2) Equips the RoRC
> 3) Unequips the AoRC to use the amulet slot for something non-redundant
> and is inadvertantly without cold resistance. Depending on complexity
> there's a chance for several subtle bugs there.
>
> Perhaps you do just need an OnCold trigger for this, but it would seem
> excessive to have OnCold, OnHeat, OnAcid, OnLightning, OnCabbage,
> OnPurple, etc.
>
> Possibly OnEffect[n] and the Icy Sword causes Effect[3] as its
> OnAttack. Then the Cold Caves can also cause Effect[3] once every five
> turns.
>
> --
> Chris

Well this is could always happen (bugs) :) )
We solved this by on equipping with an item this sequence is called:

Item.OnWorn(parameters) {
// user script
}

Owner.OnWear(parameters) {
// user script
}

so when you try to wear the AoRC it would be like:

Boolean AoRC.OnWorn(PItem,POwner,PGlobal) {
// item is allowed to be worn
Result=True;
}

Boolean Player.OnWear(POwner,PSlot,PItem,PGlobal) {
// effect is applied to the player here
POwner.AddEffect(PItem.FEffect);
// message is emitted here
PGlobal.Info(
PGlobal.Evaluate('{0} is wearing {1} now!',[POwner,PItem])
);
// the item is allowed to be worn after all
Result=True;
}

Boolean Player.OnTakeOff(POwner,PSlot,PItem,PGlobal) {
// effect is removed here
POwner.RemoveEffect(PItem.FEffect);
// message is emitted here
PGlobal.Info(
PGlobal.Evaluate('{0} is wearing {1} no more!',[POwner,PItem])
// the item is allowed to be take-off if not cursed :) 
Result=PItem.CheckState(stateCURSED);
}

Note: CSharp,VB and Java is currently supported as a "scripting
language" because of M$'s CodeDom capabilities (those languages can be
combined freely)

regards,
Jan
Anonymous
July 12, 2005 9:59:23 AM

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

Jan Drahokoupil wrote:
> Hi, I got different problem this time.
> Any suggestions on item events (what
> should happen to them). So far we've:

I'll comment on groups of events.

> OnBoiled - item is changing from fluid to gas
> OnCondensed - item is changing from gas to fluid
> OnMelted - item is changing from solid to fluid
> OnSolidified - item is changing from fluid to solid

are all phase transitions between solid, fluid and gas. You can add the
old and new phase as parameters of an OnPhaseChange generic event,
allowing custom phases for some objects (e.g. solution vs precipitate,
colour changes, diamond vs graphite vs fullerenes).
Melting, boiling etc. are violent changes: isn't the item destroyed?

> OnExploded - item is flammable and it was fired-up
> OnBroken - item is changing from normal to broken
> OnRusted - item is changing from unrusted to rusted

are other kinds of state change. Can you generalize them, in a similar
way, to arbitrary item states and a single event method?

> OnAccepted - item is being given to owner
> OnBorrowed - item is being borrowed to owner
> OnBought - item is being bought by owner
> OnDropped - item is being dropped by owner
> OnGiven - item was given from owner to somebody
> OnLent - item is being lent by user to somebody
> OnPicked - item is being picked-up by owner
> OnSold - item is being sold by owner
> OnStealed - item is being stealed from owner


are five ways of transferring items between characters, with active and
passive forms (you missed active stealing). What if there are others?
Do you think there are many differences between the various ways to get
or lose an item?
I'd leave only a generic OnGet and a generic OnLose, taking care of
special aspects (like money for selling or experience and detection for
stealing) separately.

> OnWielded - item is being equipped to owner's hand slot
> OnWorn - item is being equipped to owner's non-hand slot
> OnTakenOff - item is being taken-off from owner's non-hand slot
> OnUnwielded - item is being unwielded from owner's hand slot

should be generalized to arbitrary slots: non-hand include the second
hand if any, rings, armour, shields, second weapon, clotes, hat,
shoes... They should be mostly different.

> OnActivated - item is being used
> OnDrunk - item is being drunk by owner
> OnShot - item is being shot by user's missile weapon
> OnThrown - item is being thrown by owner
> OnEaten - item is being eaten by owner

are instantaneous usage events (the previous group is continuous
usage). Shouldn't you, again, consolidate them to an OnUse event with
the type of usage as a parameter? I suppose you already have flags,
enumerations or the like to list how can you use each item.

I'd like to hear more about how these events are triggered: they are
facts, not commands, so there is a significant amount of item-specific
logic to decide, for example, when an iron weapon in water suffers an
OnRusted(). How is it organized?

Lorenzo Gatti
Anonymous
July 12, 2005 10:54:29 AM

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

gatti@dsdata.it wrote:
> Jan Drahokoupil wrote:
> > Hi, I got different problem this time.
> > Any suggestions on item events (what
> > should happen to them). So far we've:
>
> I'll comment on groups of events.
>
> > OnBoiled - item is changing from fluid to gas
> > OnCondensed - item is changing from gas to fluid
> > OnMelted - item is changing from solid to fluid
> > OnSolidified - item is changing from fluid to solid
>
> are all phase transitions between solid, fluid and gas. You can add the
> old and new phase as parameters of an OnPhaseChange generic event,
> allowing custom phases for some objects (e.g. solution vs precipitate,
> colour changes, diamond vs graphite vs fullerenes).

We've discussed this before and we've decided that this is definitelly
better approach (at least from programmer's view) but we wanted to keep
mod-maker from writing "switch" everytime he wants just simple code. I
agree that otherwise (when programming) I would do it this way as it's
common practice.

> Melting, boiling etc. are violent changes: isn't the item destroyed?

That depends on what mod-maker will decide in user-script :)  He could
implement the factual chemic realism or just destroy the item.

> > OnExploded - item is flammable and it was fired-up
> > OnBroken - item is changing from normal to broken
> > OnRusted - item is changing from unrusted to rusted
>
> are other kinds of state change. Can you generalize them, in a similar
> way, to arbitrary item states and a single event method?

As I said..to keep the scripting code clearer there aren't so many
changes so we've decided to keep them separately. The player is not
pushed to write:

case Old of
stateUNEXPLODED:
case New of
...
end;
stateUNBROKEN:
case New of
..
end;
stateUNRUSTED:
case New of
..
end;
end;

but he simply knows that item has broken and will write whatever the
effect is :) 

> > OnAccepted - item is being given to owner
> > OnBorrowed - item is being borrowed to owner
> > OnBought - item is being bought by owner
> > OnDropped - item is being dropped by owner
> > OnGiven - item was given from owner to somebody
> > OnLent - item is being lent by user to somebody
> > OnPicked - item is being picked-up by owner
> > OnSold - item is being sold by owner
> > OnStealed - item is being stealed from owner
>
> are five ways of transferring items between characters, with active and
> passive forms (you missed active stealing). What if there are others?
> Do you think there are many differences between the various ways to get
> or lose an item?
> I'd leave only a generic OnGet and a generic OnLose, taking care of
> special aspects (like money for selling or experience and detection for
> stealing) separately.

Note: First I've noticed that "Stealed" has to be "Stolen" :) 

Accept - Give
Lent - Borrow
Drop - Pick
Sell - Buy
Steal - Slip?

This is for generality..somebody should like to implement the item
which has effect on selling or maybe calls up some chatting session
with shopkeeper and so on..you can have many examples how to use these
events separately. Surely there will be different effect dropping armed
grenade then picking up unarmed one.

>
> > OnWielded - item is being equipped to owner's hand slot
> > OnWorn - item is being equipped to owner's non-hand slot
> > OnTakenOff - item is being taken-off from owner's non-hand slot
> > OnUnwielded - item is being unwielded from owner's hand slot
>
> should be generalized to arbitrary slots: non-hand include the second
> hand if any, rings, armour, shields, second weapon, clotes, hat,
> shoes... They should be mostly different.
>
> > OnActivated - item is being used
> > OnDrunk - item is being drunk by owner
> > OnShot - item is being shot by user's missile weapon
> > OnThrown - item is being thrown by owner
> > OnEaten - item is being eaten by owner
>
> are instantaneous usage events (the previous group is continuous
> usage). Shouldn't you, again, consolidate them to an OnUse event with
> the type of usage as a parameter? I suppose you already have flags,
> enumerations or the like to list how can you use each item.

The same problem as I mentioned before..

> I'd like to hear more about how these events are triggered: they are
> facts, not commands, so there is a significant amount of item-specific
> logic to decide, for example, when an iron weapon in water suffers an
> OnRusted(). How is it organized?

It's kept on user's decision whether the item is being rusted on some
occasions..in fact the routine is:

function
TcITEM.OnRusted(PItem:TcITEM;POwner:TcBEING;PGlobal:TcGLOBAL):Boolean;

where:

TcITEM : item-form class

PItem : actual item exposed to situation when it may rust
POwner : the owner of the item (if any)
PGlobal : reference to data of whole game

Result : if actually the item will rust (actually you can choose False
and rust it manually using PItem in the script)

The situation (OnRusted event) is called whenever the item is in the
contact with water generally.

> Lorenzo Gatti

regards,
Jan
Anonymous
July 12, 2005 11:10:22 AM

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

MSCHAEF.COM wrote:
> In article <1121162865.172821.279210@f14g2000cwb.googlegroups.com>,
> Jan Drahokoupil <drahokoupil@telpro.cz> wrote:
> >Hi, I got different problem this time.
> >Any suggestions on item events (what
> >should happen to them). So far we've:
>
> This looks like a nice list of events, but they suffer the same weakness
> as member functions in C++: they only key off of one object, not multiple.
> Where in this event model would you put code that triggers when two
> objects are combined or one object is used upon another?

Meanwhile there was some events added:

OnSlipped - item is being slipped from owner to somebody
OnAttached - item is being detached to item
OnDetached - item is being detached from other item

> I could see a message like OnGiven having radically
> different behavior depending on to
> whom or what the item was given to.

Message system is controlled from within the script via:

PGlobal.Message(PMessage:&String); >> Screen - message
PGlobal.Info(PMessage:&String); >> Screen - informative msg
PGlobal.Sensual(PMessage:&String); >> Screen - sensual msg
PGlobal.Warning(PMessage:&String); >> Game.debug as warning
PGlobal.Debug(PMessage:&String); >> Game.debug as error
PGlobal.Log(PMessage:&String); >> Game.log

Our engine itself generally doesn't contain any fixed data from the
game, only the basic game-logic which is generalized to absorb wide
(and wild) ideas from mod-makers.

> The natural solution isn't bad:
>
> RedPotion.OnGiven(toWhom)
> {
> if (toWhom == EVIL_SORCERER) end_Game();
> else if (toWhom == SLEEPING_PRINCESS) awakenPrincess();
> else...
> }
>
> But this reduces you to one place for adding new toWhom's for the
> RedPotion.

No, the beings have also the events that are triggered so when you give
an item to somebody it goes like:

TcBEING.OnGive(Player,RedPotion,EvilSorcerer,Global);
TcITEM.OnAccepted(EvilSorcerer,RedPotion,Player,Global);
TcITEM.OnGiven(Player,RedPotion,EvilSorcerer,Global);
TcBEING.OnAccept(EvilSorcerer,RedPotion,Player,Global);

You have plenty time to implemented whatever you want :) 

> I guess what I'm getting at is if you've considered some kind of
> multi-dispatch (like CLOS or Cecil) for your events?

There's no need for this because everything you need in the script is
passed by parameters (mainly the PGlobal) using which you can change
whole entire game (you've access to actual state of the game).

> -Mike
> --
> http://www.mschaef.com

regards,
Jan
Anonymous
July 12, 2005 11:47:27 AM

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

Two more notes:

Note: I meant 01.06.2006 ofcourse :) 

Note: Those events are written in C# because actually they're
compilable at runtime thru Microsoft.CSharp and CodeDom :) )

Otherwise the engine itself is written in Delphi 2005 :) 

Btw: On of my friends is writting the graphics wrapper based on Pixel
Shader (crazy ?!) in OpenGL..

regards,
Jan
Anonymous
July 12, 2005 12:16:20 PM

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

In article <1121162865.172821.279210@f14g2000cwb.googlegroups.com>,
Jan Drahokoupil <drahokoupil@telpro.cz> wrote:
>Hi, I got different problem this time.
>Any suggestions on item events (what
>should happen to them). So far we've:

This looks like a nice list of events, but they suffer the same weakness
as member functions in C++: they only key off of one object, not multiple.
Where in this event model would you put code that triggers when two
objects are combined or one object is used upon another? I could see a
message like OnGiven having radically different behavior depending on to
whom or what the item was given to.

The natural solution isn't bad:

RedPotion.OnGiven(toWhom)
{
if (toWhom == EVIL_SORCERER) end_Game();
else if (toWhom == SLEEPING_PRINCESS) awakenPrincess();
else...
}

But this reduces you to one place for adding new toWhom's for the
RedPotion.

I guess what I'm getting at is if you've considered some kind of
multi-dispatch (like CLOS or Cecil) for your events?

-Mike
--
http://www.mschaef.com
Anonymous
July 12, 2005 2:07:17 PM

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

All those item events look C#-ish. I'm also writing a roguelike in C# and am
getting to the point that I need to figure out a general system for how
items are going to work. It looks like your plan is to have an abstract item
class and then subclass for each item in your game. Is this the case?

I'm resisting this approach as I would rather only have a class the defines
how a given item type works (potions, money, melee weapons, ect) and then
have the behavior be data-driven. For instance, in my potions class, I have
an enumeration for each of the potion effects and I do a switch on the
potion ID when the player drinks. This is fine for now, but I can see it
getting messy if I want to do things like having cold attacks shatter
potions, except for certain ones like potions of firebreathing or whatever.
Anything that requires special logic. In which case your approach begins to
look very attractive indeed. Care to comment on any of that?

I'd love to read more about your dev efforts if your roguelike has a
website.

Regards,
John

--
Blog:
Shedletsky's Bits: A Random Walk Through Manifold Space
http://www.stanford.edu/~jjshed/blog
Anonymous
July 12, 2005 3:12:13 PM

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

If I got it right, you're suggesting to have the events:

OnLost
OnGained

where first one is called whenever:

OnAccepted
OnPicked
OnSlipped
...

and the latter when:

OnGiven
OnDropped
OnStolen
...

Am I right ?

regards,
Jan
Anonymous
July 12, 2005 3:32:23 PM

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

"Jan Drahokoupil" <drahokoupil@telpro.cz> writes:
> Hi, I got different problem this time.
> Any suggestions on item events (what
> should happen to them). So far we've:
>
> OnActivated - item is being used

It might be worth distinguishing between active use and passive use here.

For example, the Axe of Kings can be used as a weapon, and always
bypasses armour when it hits. So, passive use of the special powers.

On the other hand, it can also be used, once a day, to summon the
King's Legion. Active use of the special powers.

I suppose you could use OnWielded to set an armour-bypassing flag on
the player's attacks, and OnUnwielded to unset it, but that seems to
be the wrong place to set the flag, to me.

--
Chris
Anonymous
July 12, 2005 3:48:40 PM

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

// Yes, I think it would be convenient.
// Other events could also benefit from a similar hierarchy.

// The eating/drinking/attacking could be kinds of activating.

// The rusting/burning/dissolving/breaking/repairing -- kind of item's
status
change, etc.

That sounds pretty reasonable..

// I'd also add an event called when you're hit with something
thrown...

I guess this is handled by

ITEM.OnAttack
BEING.OnAttacked

events :) )

regards,
Jan
Anonymous
July 12, 2005 3:59:01 PM

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

"Jan Drahokoupil" <drahokoupil@telpro.cz> writes:
> Oh, now I got it..ofcourse..this should be added:
>
> OnAttack - direct (active) use

Don't forget that with (e.g.) a vampiric weapon OnAttack is both an
effect on the target (-HP, -energy) and on the wielder (+HP, +energy).

> OnActivated - special powers used

Similarly OnAttacked for armour or other items with special powers, then.

How would you handle an Amulet of Resist Cold and a Ring of Resist
Cold. Both grant cold resistance when worn. If you use OnWorn to set
-cold and OnUnworn to unset -cold, then there's the possibility of
bugs when someone:
1) Equips the AoRC
2) Equips the RoRC
3) Unequips the AoRC to use the amulet slot for something non-redundant
and is inadvertantly without cold resistance. Depending on complexity
there's a chance for several subtle bugs there.

Perhaps you do just need an OnCold trigger for this, but it would seem
excessive to have OnCold, OnHeat, OnAcid, OnLightning, OnCabbage,
OnPurple, etc.

Possibly OnEffect[n] and the Icy Sword causes Effect[3] as its
OnAttack. Then the Cold Caves can also cause Effect[3] once every five
turns.

--
Chris
Anonymous
July 12, 2005 4:21:50 PM

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

Still covered by ITEM.OnAttack..because Target can be anything (because
walls are also items). And this event is also called after the thrown
item ends it's flight. Those are valid targets:

Ground - basic level
Item - items, buildings, walls, etc.
Being - player,npcs,animals, etc.
Environment - lava, water, etc.

Thanks for testing because this is exactly what I need now, before I'll
implement them to be fixed part of game-system..testing of
possibilities. Try even the crazy ways if I should be able to fit them
satisfactorily.

regards,
Jan
Anonymous
July 12, 2005 4:57:07 PM

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

So..I grouped the events by their interest :)  This is how the
complexity appears :p 

OnChanged
- OnBoiled
- OnCondensed
- OnExploded
- OnMelted
- OnSolidified
OnEquipped
- OnTakenOff
- OnUnwielded
- OnWielded
- OnWorn
OnGained
- OnAccepted
- OnBorrowed
- OnBought
- OnCaught
- OnPicked
- OnSlipped
OnLost
- OnDropped
- OnGiven
- OnLent
- OnShot
- OnSold
- OnStolen
- OnThrown
OnProcessed
- OnBroken
- OnDrunk
- OnEaten
- OnRusted
OnStructured
- OnAttached
- OnCreated
- OnDestroyed
- OnDetached
OnUsed
- OnActivated
- OnAttacked

pfuff..that's the current state

regards,
Jan
Anonymous
July 12, 2005 5:18:26 PM

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

The Sheep wrote:
> At 12 Jul 2005 12:21:50 -0700,
> Jan Drahokoupil wrote:
>
> > Thanks for testing because this is exactly what I need now, before I'll
> > implement them to be fixed part of game-system..testing of
> > possibilities. Try even the crazy ways if I should be able to fit them
> > satisfactorily.
>
> It still seems a little backwards to me.
> Shoudn't it be added when it's needed?
> Shoudn't it be written in the way that allows you to add a new event
> easily when you notice it's absolutely necessary?

Well..I'm adding all those events to the engine as you see almost in
real-time so there's not much problem to implement it..because all I
essentially did was adding lines:

TcITEM.OnEvent(..)

The events cannot be added in real-time, not because it's not possible
to do it but because they won't be called on the right places by
engine. Consider the analogy of item events to component events..You
can simply add them (events) to your component but you have to
implement them in your program. This is simply impossible to achieve
:) )

I know that I can't bundle all final events into the engine now but I'm
trying to bundle at least as much as I can (with help of others).
Because events are in-fact virtual user calls which I don't have to
implement (it's their job) it's easy to add them even many and even
structured in groups.

> Anyways, consider what things you could do with the items.
> When wall is an item too, then how about OnDigging? OnStumbleUpon?
> Doors? OnCLose, OnOpen, OnLock, OnUnlock, OnSpike...
> Traps? OnDisarm
> Containers? OnPutInto, OnGetFrom, OnOverflow

OnDigging = PickAxe.OnActivate + Wall.OnAttacked
OnStumbleUpon = Being.OnStepOver (depends on parameters)
OnClose/OnOpen/OnLock/OnUnlock = Doors.OnActivated + Doors.Effect
OnDisarm = Being.UseSkill (depends on parameters)
OnPutInto = Item.OnDrop (depends on parameters)
OnGetFrom = Item.OnPickup (depends on parameters)
OnOverflow = checked by mod-maker's script when Item.OnDrop

but essentially no problem to implement them alone :) 

> Maybe you could also play some roguelikes and take notes what things
> happen with items around you (not necessarily handled by the game).

I played many RLs (in fact I got ~40 of them on my HD) but believe me
this more time consuming than just asking everybody else because
there're authors and players present on this thread.

> --
> Radomir `The Sheep' Dopieralski @**@_
> (`') 3 Grrr!
> . . . ..v.vVvVVvVvv.v.. .

regards,
Jan
Anonymous
July 12, 2005 5:24:14 PM

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

Excellent :) )

OnSeen
OnNear
OnPresent

OnOwnAction is determined by equip placement:

Head
...
Body
...
[Environment based]
[Inventory based]

While every equip position has it's own properties and effect (script)

So there can be different script runned when equipped on Hands or being
present in inventory..

Thanks, wonderfull events..possibly the ones I'll never thought about..

regards,
Jan
Anonymous
July 12, 2005 6:38:46 PM

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

The Sheep wrote:
> At 12 Jul 2005 13:18:26 -0700,
> Jan Drahokoupil wrote:
>
> > The Sheep wrote:
> >> At 12 Jul 2005 12:21:50 -0700,
> >> Jan Drahokoupil wrote:
>
> >> Shoudn't it be written in the way that allows you to add a new event
> >> easily when you notice it's absolutely necessary?
>
> > Well..I'm adding all those events to the engine as you see almost in
> > real-time so there's not much problem to implement it..because all I
> > essentially did was adding lines:
> >
> > TcITEM.OnEvent(..)
> >
> > The events cannot be added in real-time, not because it's not possible
> > to do it but because they won't be called on the right places by
> > engine. Consider the analogy of item events to component events..You
> > can simply add them (events) to your component but you have to
> > implement them in your program. This is simply impossible to achieve
> > :) )
>
> I think you need some kind of simple testing game at some stage anyways.

For sure :)  There're many scripts already predefined (opening doors as
the first one :p ) and K8 is actually fighting with testing. We do
implement them because it's almost impossible to write an engine
without actually seeing it alive :)  But surely we'll need some
feedback.

> Once your projects enters beta stage you can, hopefully, get some feedback
> from the mod-makers.

I hope so..

> > I know that I can't bundle all final events into the engine now but I'm
> > trying to bundle at least as much as I can (with help of others).
> > Because events are in-fact virtual user calls which I don't have to
> > implement (it's their job) it's easy to add them even many and even
> > structured in groups.
>
> Too many hooks make it worse -- every piece of interface (with the
> modules, not with the player) you add to your engine highers the entrance
> theresold a little bit and makes the learning curve worse.

That's sadly true..the manual (a nightmare of programmers) will be a
must. We're trying to keep it intuitive but when it reaches certain
level of complexity the intuition doesn't always help.

> Structure helps here, OO-aproach to the data files helps too, but there
> are limits. It's sometimes better to have one generalized hook that's
> obvious, than to have lots of them, but requiring lookup.

I guess many things regarding the quest control will be solved by our
MQN (Modular Quest Network) this should solve some problems to open
ends and possibilities..

> It's especially dangerous when there are several ways to do certain
> specific thing, but some of them are better than others.

I'm not getting out of responsibility but I hope that this should be
mainly the mod-makers concern. We're trying to make it easier to him as
we can. Using straight-forward approach.

> The interface problems need much more to solve than a discussion on
> a newsgroup. And you need a good intrfave for the modules if you want
> games for your engine.
>
> > OnDisarm = Being.UseSkill (depends on parameters)
> But shudn't there be an event connected with the trap, not the being?

When a skill fails then OnActivate of trap should be called and it's
effect unleashed but when successful I guess there's no reason for
having event on trap itself. All necessary should be handled by
Being.OnSkillUsed (called by UseSkill) because the trap (instance) is
available there. So if there're some reasons to do something with that
trap when it was successfully disarmed (don't have idea what actually
?) you can do it there (in Being.OnSkillUsed event).

> > OnPutInto = Item.OnDrop (depends on parameters)
> > OnGetFrom = Item.OnPickup (depends on parameters)
> They seem a little unintuitive. I mean you're not dropping the items, you
> just reorder your bags. I'd assume the OnDrop event is called when the
> item is dropped on the ground.
> Also, no even for the container itself (I suppose the
> increasing/decreasing weight is handled by the engine, but there might be
> other similar attributes programmed by the mod-maker).

Ok..I guess you're right they're a bit user unfriendly so I added them:

OnInserted
OnTakenOut

> > OnOverflow = checked by mod-maker's script when Item.OnDrop
> >
> > but essentially no problem to implement them alone :) 
>
> You must be aware that it's the trade-off -- either it's simple to learn
> or it has lots of hooks.

Again.. MQN should be helpful in controlling the storyline-flow and
monitor all the open ends.

> >> Maybe you could also play some roguelikes and take notes what things
> >> happen with items around you (not necessarily handled by the game).
> >
> > I played many RLs (in fact I got ~40 of them on my HD) but believe me
> > this more time consuming than just asking everybody else because
> > there're authors and players present on this thread.
>
> Just a suggestion on where you could get more ideas.
> It may be irrelevant for your engine, but in my game I have a separate
> action for aiming and for shooting, so you'd need events for creatures:
> OnAimedAt, OnShotAt (OnAttacked?), OnSpotted, OnHidden, etc.

OnThrown and OnShot should handle these.. Because they're proceeded
when returning true as a result..
OnSpotted was already suggested by Andreas and added so as these:

OnSeen - when in sight of somebody (probably will be left as a
Being.Event)
OnNear - when near somebody (now I think this should be solved
differently)
OnPresent - when on a specific level check (place?)

>
> --
> Radomir `The Sheep' Dopieralski @**@_
> (: ) 3 Snap!
> . . . ..v.vVvVVvVvv.v.. .

regards,
Jan
Anonymous
July 12, 2005 6:42:10 PM

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

At 12 Jul 2005 06:54:29 -0700,
Jan Drahokoupil wrote:

> This is for generality..somebody should like to implement the item
> which has effect on selling or maybe calls up some chatting session
> with shopkeeper and so on..you can have many examples how to use these
> events separately. Surely there will be different effect dropping armed
> grenade then picking up unarmed one.

Ok, so if I write a game for your engine, and there that quest item, say,
a key, and I want to change some game behavior depending on whether the PC
has it in his inventory or not, then I have to write hooks for all ways to
lose the item, and I am in trouble if I forget about any of them.

I think it's wise to have the general hooks. You could have the more
specific ones as an addition, but I doubt they will be so helpful, since
you've got to look up their names in themanual first ;) 

--
Radomir `The Sheep' Dopieralski @**@_
(..) 3 Bee!
. . . ..v.vVvVVvVvv.v.. .
Anonymous
July 12, 2005 10:33:48 PM

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

At 12 Jul 2005 11:12:13 -0700,
Jan Drahokoupil wrote:

> If I got it right, you're suggesting to have the events:
>
> OnLost
> OnGained
>
> where first one is called whenever:
>
> OnAccepted
> OnPicked
> OnSlipped
> ..
>
> and the latter when:
>
> OnGiven
> OnDropped
> OnStolen
> ..
>
> Am I right ?

Yes, I think it would be convenient.
Other events could also benefit from a similar hierarchy.

The eating/drinking/attacking could be kinds of activating.

The rusting/burning/dissolving/breaking/repairing -- kind of item's status
change, etc.

I'd also add an event called when you're hit with something thrown...

--
Radomir `The Sheep' Dopieralski @**@_
(nn) 3 Grin
. . . ..v.vVvVVvVvv.v.. .
Anonymous
July 12, 2005 11:10:58 PM

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

At 12 Jul 2005 11:48:40 -0700,
Jan Drahokoupil wrote:

> // I'd also add an event called when you're hit with something
> thrown...
>
> I guess this is handled by
>
> ITEM.OnAttack
> BEING.OnAttacked
>
> events :) )

And what if you want potions to break when they hit a wall?

--
Radomir `The Sheep' Dopieralski @**@_
(--) 3 ..zzZZ
. . . ..v.vVvVVvVvv.v.. .
Anonymous
July 12, 2005 11:38:43 PM

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

At 12 Jul 2005 12:21:50 -0700,
Jan Drahokoupil wrote:

> Thanks for testing because this is exactly what I need now, before I'll
> implement them to be fixed part of game-system..testing of
> possibilities. Try even the crazy ways if I should be able to fit them
> satisfactorily.

It still seems a little backwards to me.
Shoudn't it be added when it's needed?
Shoudn't it be written in the way that allows you to add a new event
easily when you notice it's absolutely necessary?

Anyways, consider what things you could do with the items.
When wall is an item too, then how about OnDigging? OnStumbleUpon?
Doors? OnCLose, OnOpen, OnLock, OnUnlock, OnSpike...
Traps? OnDisarm
Containers? OnPutInto, OnGetFrom, OnOverflow

Maybe you could also play some roguelikes and take notes what things
happen with items around you (not necessarily handled by the game).

--
Radomir `The Sheep' Dopieralski @**@_
(`') 3 Grrr!
. . . ..v.vVvVVvVvv.v.. .
Anonymous
July 13, 2005 12:48:46 AM

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

At 12 Jul 2005 13:18:26 -0700,
Jan Drahokoupil wrote:

> The Sheep wrote:
>> At 12 Jul 2005 12:21:50 -0700,
>> Jan Drahokoupil wrote:

>> Shoudn't it be written in the way that allows you to add a new event
>> easily when you notice it's absolutely necessary?

> Well..I'm adding all those events to the engine as you see almost in
> real-time so there's not much problem to implement it..because all I
> essentially did was adding lines:
>
> TcITEM.OnEvent(..)
>
> The events cannot be added in real-time, not because it's not possible
> to do it but because they won't be called on the right places by
> engine. Consider the analogy of item events to component events..You
> can simply add them (events) to your component but you have to
> implement them in your program. This is simply impossible to achieve
> :) )

I think you need some kind of simple testing game at some stage anyways.
Once your projects enters beta stage you can, hopefully, get some feedback
from the mod-makers.

> I know that I can't bundle all final events into the engine now but I'm
> trying to bundle at least as much as I can (with help of others).
> Because events are in-fact virtual user calls which I don't have to
> implement (it's their job) it's easy to add them even many and even
> structured in groups.

Too many hooks make it worse -- every piece of interface (with the
modules, not with the player) you add to your engine highers the entrance
theresold a little bit and makes the learning curve worse.

Structure helps here, OO-aproach to the data files helps too, but there
are limits. It's sometimes better to have one generalized hook that's
obvious, than to have lots of them, but requiring lookup.

It's especially dangerous when there are several ways to do certain
specific thing, but some of them are better than others.

The interface problems need much more to solve than a discussion on
a newsgroup. And you need a good intrfave for the modules if you want
games for your engine.

> OnDisarm = Being.UseSkill (depends on parameters)
But shudn't there be an event connected with the trap, not the being?

> OnPutInto = Item.OnDrop (depends on parameters)
> OnGetFrom = Item.OnPickup (depends on parameters)
They seem a little unintuitive. I mean you're not dropping the items, you
just reorder your bags. I'd assume the OnDrop event is called when the
item is dropped on the ground.
Also, no even for the container itself (I suppose the
increasing/decreasing weight is handled by the engine, but there might be
other similar attributes programmed by the mod-maker).

> OnOverflow = checked by mod-maker's script when Item.OnDrop
>
> but essentially no problem to implement them alone :) 

You must be aware that it's the trade-off -- either it's simple to learn
or it has lots of hooks.

>> Maybe you could also play some roguelikes and take notes what things
>> happen with items around you (not necessarily handled by the game).
>
> I played many RLs (in fact I got ~40 of them on my HD) but believe me
> this more time consuming than just asking everybody else because
> there're authors and players present on this thread.

Just a suggestion on where you could get more ideas.
It may be irrelevant for your engine, but in my game I have a separate
action for aiming and for shooting, so you'd need events for creatures:
OnAimedAt, OnShotAt (OnAttacked?), OnSpotted, OnHidden, etc.

--
Radomir `The Sheep' Dopieralski @**@_
(: ) 3 Snap!
. . . ..v.vVvVVvVvv.v.. .
Anonymous
July 13, 2005 1:13:42 AM

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

Jan Drahokoupil wrote:
> Hi, I got different problem this time.
> Any suggestions on item events (what
> should happen to them). So far we've:
>
> OnActivated - item is being used
> OnAccepted - item is being given to owner
> OnBoiled - item is changing from fluid to gas
> OnBorrowed - item is being borrowed to owner
> OnBought - item is being bought by owner
> OnBroken - item is changing from normal to broken
> OnCondensed - item is changing from gas to fluid
> OnDropped - item is being dropped by owner
> OnDrunk - item is being drunk by owner
> OnEaten - item is being eaten by owner
> OnWielded - item is being equipped to owner's hand slot
> OnWorn - item is being equipped to owner's non-hand slot
> OnExploded - item is flammable and it was fired-up
> OnGiven - item was given from owner to somebody
> OnMelted - item is changing from solid to fluid
> OnLent - item is being lent by user to somebody
> OnPicked - item is being picked-up by owner
> OnRusted - item is changing from unrusted to rusted
> OnShot - item is being shot by user's missile weapon
> OnSold - item is being sold by owner
> OnSolidified - item is changing from fluid to solid
> OnStealed - item is being stealed from owner
> OnTakenOff - item is being taken-off from owner's non-hand slot
> OnThrown - item is being thrown by owner
> OnUnwielded - item is being unwielded from owner's hand slot

OnSeenBy - is that vampire in LoS to the holy cross you are wearing?
OnNear - did you put that two subcritical uranium masses near
each other?
OnLevelEnter - did you bring the zombie head on the astral plane?
OnOwnAction - your sentinent sword wants to do something
Anonymous
July 13, 2005 8:07:48 AM

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

The Sheep wrote:
> At 12 Jul 2005 14:38:46 -0700,
> Jan Drahokoupil wrote:
>
> > The Sheep wrote:
> >> At 12 Jul 2005 13:18:26 -0700,
> >> Jan Drahokoupil wrote:
> >> > OnDisarm = Being.UseSkill (depends on parameters)
> >> But shudn't there be an event connected with the trap, not the being?
> >
> > When a skill fails then OnActivate of trap should be called and it's
> > effect unleashed but when successful I guess there's no reason for
> > having event on trap itself. All necessary should be handled by
> > Being.OnSkillUsed (called by UseSkill) because the trap (instance) is
> > available there. So if there're some reasons to do something with that
> > trap when it was successfully disarmed (don't have idea what actually
> > ?) you can do it there (in Being.OnSkillUsed event).
>
> For example, in NetHack you can pick up bear traps you disarmed.
> Other traps could allow to take some parts of them (magical gems?).
> etc.

I don't fully understand.. When trap is disarmed it's effect is only
deactivated but it still can be activated and behaves like normal item
(you can pick it up).

> When the code is in UseSkill, you can't easily add a new trap with effects
> like this, without diving in the (probably already complicted) code of
> OnUseSkill.

Effects are defined separately and then assigned to item's equip
positions. So first you'll build the library of effects ("of Cold
Restistance","of Fire") then you'll create item (e.g.) Ring and you'll
setup parameters for equip position "Finger" and assign the effect "of
Fire" to it. Which is then available from "Item.Effect" so it can be
reproduced/modified freely. OnUseSkill is event fired by
Being.UseSkill..so you'll decide what will happen (what the skill is
about).

> --
> Radomir `The Sheep' Dopieralski @**@_
> (Uu) 3 Sigh!
> . . . ..v.vVvVVvVvv.v.. .

regards,
Jan
Anonymous
July 13, 2005 8:44:39 AM

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

The Sheep wrote:
> At 12 Jul 2005 14:38:46 -0700,
> Jan Drahokoupil wrote:
>
> > The Sheep wrote:
> >> At 12 Jul 2005 13:18:26 -0700,
> >> Jan Drahokoupil wrote:
> >> > OnDisarm = Being.UseSkill (depends on parameters)
> >> But shudn't there be an event connected with the trap, not the being?
> >
> > When a skill fails then OnActivate of trap should be called and it's
> > effect unleashed but when successful I guess there's no reason for
> > having event on trap itself. All necessary should be handled by
> > Being.OnSkillUsed (called by UseSkill) because the trap (instance) is
> > available there. So if there're some reasons to do something with that
> > trap when it was successfully disarmed (don't have idea what actually
> > ?) you can do it there (in Being.OnSkillUsed event).
>
> For example, in NetHack you can pick up bear traps you disarmed.
> Other traps could allow to take some parts of them (magical gems?).
> etc.

I don't fully understand.. When trap is disarmed it's effect is only
deactivated but it still can be activated and behaves like normal item
(you can pick it up).

> When the code is in UseSkill, you can't easily add a new trap with effects
> like this, without diving in the (probably already complicted) code of
> OnUseSkill.

Effects are defined separately and then assigned to item's equip
positions. So first you'll build the library of effects ("of Cold
Restistance","of Fire") then you'll create item (e.g.) Ring and you'll
setup parameters for equip position "Finger" and assign the effect "of
Fire" to it. Which is then available from "Item.Effect" so it can be
reproduced/modified freely. OnUseSkill is event fired by
Being.UseSkill..so you'll decide what will happen (what the skill is
about).

> --
> Radomir `The Sheep' Dopieralski @**@_
> (Uu) 3 Sigh!
> . . . ..v.vVvVVvVvv.v.. .

regards,
Jan
Anonymous
July 13, 2005 8:49:10 AM

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

The Sheep wrote:
> At 12 Jul 2005 14:38:46 -0700,
> Jan Drahokoupil wrote:
>
> > The Sheep wrote:
> >> At 12 Jul 2005 13:18:26 -0700,
> >> Jan Drahokoupil wrote:
> >> > OnDisarm = Being.UseSkill (depends on parameters)
> >> But shudn't there be an event connected with the trap, not the being?
> >
> > When a skill fails then OnActivate of trap should be called and it's
> > effect unleashed but when successful I guess there's no reason for
> > having event on trap itself. All necessary should be handled by
> > Being.OnSkillUsed (called by UseSkill) because the trap (instance) is
> > available there. So if there're some reasons to do something with that
> > trap when it was successfully disarmed (don't have idea what actually
> > ?) you can do it there (in Being.OnSkillUsed event).
>
> For example, in NetHack you can pick up bear traps you disarmed.
> Other traps could allow to take some parts of them (magical gems?).
> etc.

I don't fully understand.. When trap is disarmed it's effect is only
deactivated but it still can be activated and behaves like normal item
(you can pick it up).

> When the code is in UseSkill, you can't easily add a new trap with effects
> like this, without diving in the (probably already complicted) code of
> OnUseSkill.

Effects are defined separately and then assigned to item's equip
positions. So first you'll build the library of effects ("of Cold
Restistance","of Fire") then you'll create item (e.g.) Ring and you'll
setup parameters for equip position "Finger" and assign the effect "of
Fire" to it. Which is then available from "Item.Effect" so it can be
reproduced/modified freely. OnUseSkill is event fired by
Being.UseSkill..so you'll decide what will happen (what the skill is
about).

> --
> Radomir `The Sheep' Dopieralski @**@_
> (Uu) 3 Sigh!
> . . . ..v.vVvVVvVvv.v.. .

regards,
Jan
Anonymous
July 13, 2005 9:57:43 AM

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

At 12 Jul 2005 14:38:46 -0700,
Jan Drahokoupil wrote:

> The Sheep wrote:
>> At 12 Jul 2005 13:18:26 -0700,
>> Jan Drahokoupil wrote:
>> > OnDisarm = Being.UseSkill (depends on parameters)
>> But shudn't there be an event connected with the trap, not the being?
>
> When a skill fails then OnActivate of trap should be called and it's
> effect unleashed but when successful I guess there's no reason for
> having event on trap itself. All necessary should be handled by
> Being.OnSkillUsed (called by UseSkill) because the trap (instance) is
> available there. So if there're some reasons to do something with that
> trap when it was successfully disarmed (don't have idea what actually
> ?) you can do it there (in Being.OnSkillUsed event).

For example, in NetHack you can pick up bear traps you disarmed.
Other traps could allow to take some parts of them (magical gems?).
etc.

When the code is in UseSkill, you can't easily add a new trap with effects
like this, without diving in the (probably already complicted) code of
OnUseSkill.

--
Radomir `The Sheep' Dopieralski @**@_
(Uu) 3 Sigh!
. . . ..v.vVvVVvVvv.v.. .
Anonymous
July 13, 2005 4:49:54 PM

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

At 13 Jul 2005 04:07:48 -0700,
Jan Drahokoupil wrote:

> The Sheep wrote:
>> At 12 Jul 2005 14:38:46 -0700,
>> Jan Drahokoupil wrote:
>>
>> > The Sheep wrote:
>> >> At 12 Jul 2005 13:18:26 -0700,
>> >> Jan Drahokoupil wrote:
>> >> > OnDisarm = Being.UseSkill (depends on parameters)
>> >> But shudn't there be an event connected with the trap, not the being?
>> >
>> > When a skill fails then OnActivate of trap should be called and it's
>> > effect unleashed but when successful I guess there's no reason for
>> > having event on trap itself. All necessary should be handled by
>> > Being.OnSkillUsed (called by UseSkill) because the trap (instance) is
>> > available there. So if there're some reasons to do something with that
>> > trap when it was successfully disarmed (don't have idea what actually
>> > ?) you can do it there (in Being.OnSkillUsed event).
>>
>> For example, in NetHack you can pick up bear traps you disarmed.
>> Other traps could allow to take some parts of them (magical gems?).
>> etc.

That's really convenient! I'll remeber to always have a bunch of disarmed
pit traps and trapdoors in my pack, just in case I wanted to go down
a level.

> I don't fully understand.. When trap is disarmed it's effect is only
> deactivated but it still can be activated and behaves like normal item
> (you can pick it up).
>
>> When the code is in UseSkill, you can't easily add a new trap with effects
>> like this, without diving in the (probably already complicted) code of
>> OnUseSkill.
>
> Effects are defined separately and then assigned to item's equip
> positions. So first you'll build the library of effects ("of Cold
> Restistance","of Fire") then you'll create item (e.g.) Ring and you'll
> setup parameters for equip position "Finger" and assign the effect "of
> Fire" to it. Which is then available from "Item.Effect" so it can be
> reproduced/modified freely. OnUseSkill is event fired by
> Being.UseSkill..so you'll decide what will happen (what the skill is
> about).

I was obviusly talking about what happends when you disarm the trap, not
related to anything you called 'effect' in your engine.

Consider a bear trap, a fire trap, a spike trap and a pit trap.

The bear trap can be disarmed and picked up as an item, which you can
later use to set it up again.

The pit trap cannot be taken with you -- at most you can take parts of it,
like the twigs and leaves that cover it.

A fire trap is also probably built into the dungeon floor or wall -- the
best you can do is to break the mechanism.

The spike trap is similar to the fire trap, but maybe you can gain some
spikes (used later to jam doors, etc.) when you disarm it.


--
Radomir `The Sheep' Dopieralski @**@_
<..> ] 0110110?
. . . ..v.vVvVVvVvv.v.. .
Anonymous
July 14, 2005 5:19:12 AM

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

The Sheep wrote:
> At 13 Jul 2005 04:07:48 -0700,
> Jan Drahokoupil wrote:
>
> > The Sheep wrote:
> >> At 12 Jul 2005 14:38:46 -0700,
> >> Jan Drahokoupil wrote:
> >>
> >> > The Sheep wrote:
> >> >> At 12 Jul 2005 13:18:26 -0700,
> >> >> Jan Drahokoupil wrote:
> >> >> > OnDisarm = Being.UseSkill (depends on parameters)
> >> >> But shudn't there be an event connected with the trap, not the being?
> >> >
> >> > When a skill fails then OnActivate of trap should be called and it's
> >> > effect unleashed but when successful I guess there's no reason for
> >> > having event on trap itself. All necessary should be handled by
> >> > Being.OnSkillUsed (called by UseSkill) because the trap (instance) is
> >> > available there. So if there're some reasons to do something with that
> >> > trap when it was successfully disarmed (don't have idea what actually
> >> > ?) you can do it there (in Being.OnSkillUsed event).
> >>
> >> For example, in NetHack you can pick up bear traps you disarmed.
> >> Other traps could allow to take some parts of them (magical gems?).
> >> etc.
>
> That's really convenient! I'll remeber to always have a bunch of disarmed
> pit traps and trapdoors in my pack, just in case I wanted to go down
> a level.
>
> > I don't fully understand.. When trap is disarmed it's effect is only
> > deactivated but it still can be activated and behaves like normal item
> > (you can pick it up).
> >
> >> When the code is in UseSkill, you can't easily add a new trap with effects
> >> like this, without diving in the (probably already complicted) code of
> >> OnUseSkill.
> >
> > Effects are defined separately and then assigned to item's equip
> > positions. So first you'll build the library of effects ("of Cold
> > Restistance","of Fire") then you'll create item (e.g.) Ring and you'll
> > setup parameters for equip position "Finger" and assign the effect "of
> > Fire" to it. Which is then available from "Item.Effect" so it can be
> > reproduced/modified freely. OnUseSkill is event fired by
> > Being.UseSkill..so you'll decide what will happen (what the skill is
> > about).
>
> I was obviusly talking about what happends when you disarm the trap, not
> related to anything you called 'effect' in your engine.
>
> Consider a bear trap, a fire trap, a spike trap and a pit trap.
>
> The bear trap can be disarmed and picked up as an item, which you can
> later use to set it up again.

Sure..let's call it standard (item) trap behaviour..

> The pit trap cannot be taken with you -- at most you can take parts of it,
> like the twigs and leaves that cover it.

Trap pits are made by decreasing height of ground (or eventually
skipping it at all so the player..will drop level down, because of
voxel structure) and setting the flag "Fake floor" coz we're not able
to solve it otherwise (if you'll step on the floor the fake floor will
disappear and you'll drop down on real land where spikes (or acid or
whatever) should be laying. Any suggestions on this ?

> A fire trap is also probably built into the dungeon floor or wall -- the
> best you can do is to break the mechanism.

We'll we're forced to implement nasty list of flags to cover some
aspects. This one is covered by "Land trap" which makes the item built
in the floor. There also "Invisible" and "Unpickable" which seems to be
(when combined) able to get the same effect but "Invisible" can be
overriden by some spells or abilities. Here's the (actual) list of
flags:

Artifact
Barrier
Broken
Burried
Container
Corpse
Deflector
Emitter
Fake_floor
Immovable
Indestructible
Invisible
Jailing
Land_trap
Moving
Passable
Racial
Rusty
Teleport
Transmuter
Transparent
Unnatural
Unpickable

> The spike trap is similar to the fire trap, but maybe you can gain some
> spikes (used later to jam doors, etc.) when you disarm it.

Spike traps depends on mod-maker because they could lay down a "Land
trap" and when you'll step on them their effect (script) is triggered.
So mod-maker has to implement where from the spike will attack and send
the spike (setting it's velocity vector).

>
> --
> Radomir `The Sheep' Dopieralski @**@_
> <..> ] 0110110?
> . . . ..v.vVvVVvVvv.v.. .

regards,
Jan
Anonymous
July 14, 2005 6:40:28 AM

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

The Sheep wrote:
> At 14 Jul 2005 01:19:12 -0700,
> Jan Drahokoupil wrote:
>
> > The Sheep wrote:
> >> At 13 Jul 2005 04:07:48 -0700,
> >> Jan Drahokoupil wrote:
>
> >> The pit trap cannot be taken with you -- at most you can take parts of it,
> >> like the twigs and leaves that cover it.
>
> > Trap pits are made by decreasing height of ground (or eventually
> > skipping it at all so the player..will drop level down, because of
> > voxel structure) and setting the flag "Fake floor" coz we're not able
> > to solve it otherwise (if you'll step on the floor the fake floor will
> > disappear and you'll drop down on real land where spikes (or acid or
> > whatever) should be laying. Any suggestions on this ?
>
> How do I mark it as a trap then? How do I use my DetectTrap and DisarmTrap
> skills? I need special code to handle this.
> I think it's somewhat wrong when I need special code for something, that's
> similar from the player's perspective.

You'll simply enable your trap's flag "Land trap" and whenever the
player steps on that [X,Y,Z] the Trap.OnActivate is
triggered..Otherwise DetectTrap (if mod-maker will implement this
skill) will have to be called from Trap.OnSeen event just like:

item was seen by being (handled by engine) -> run Trap.OnSeen

in Trap.OnSeen(..) {
Result=PBeing.OnSkillUsed(PBeing,PTrap,'DetectTrap'..);
if (Result) {
// disarm trap's effect (Trap.Effect=nil);
// set visible (Trap.Invisible=false);
} else {
// keep it hidden
}
}

while DisarmTrap should be used actively by Player (thus
Being.OnSkillUsed is triggered)

> Why can't you have a trap (item), that cannot be picked up, is invisible
> without DetectTrap check, and makes a hole in the ground whenever someone
> activates it. And, ofcourse, will make this hole also when disarmed.

If you'll set flag "Unpickable" and "Invisible" it won't be visible and
unpickable :)  unless you'll change it in user-script. It's on
mod-maker's decision where (if ever) he changes that flag. So if he
decides to change it just like you said in Trap.OnSeen event no problem
then..he also can create the hole afterwards the trap is trigged or
detected but he run into the problem of 3D map..He will be forced to
check whether the desired depth of hole isn't bigger then thickness of
the land bellow him (thus making it a hole to lower level).But
essentially this is also easy for him to be done.

> >> A fire trap is also probably built into the dungeon floor or wall -- the
> >> best you can do is to break the mechanism.
> >
> > We'll we're forced to implement nasty list of flags to cover some
> > aspects. This one is covered by "Land trap" which makes the item built
> > in the floor. There also "Invisible" and "Unpickable" which seems to be
> > (when combined) able to get the same effect but "Invisible" can be
> > overriden by some spells or abilities.
>
> Seems ok, altrough some of those flags could be implemented in the event
> handlers.

Don't understand you fully..How did you mean it ?

> >> The spike trap is similar to the fire trap, but maybe you can gain some
> >> spikes (used later to jam doors, etc.) when you disarm it.
> >
> > Spike traps depends on mod-maker because they could lay down a "Land
> > trap" and when you'll step on them their effect (script) is triggered.
> > So mod-maker has to implement where from the spike will attack and send
> > the spike (setting it's velocity vector).
>
> You're talking about dart trap -- the one that shoots darts at the player.
> I mean a spike trap -- there are lots of them in the old Prince of Persia
> game. When you step on it, a bunch of sharp spikes grows from the floor.

I described a pit trap in a previous post..you'll just place spikes on
the lowered floor and their OnActivate event will be triggered when
you'll fall on them (effect depends on mod-maker but impalement is a
custom :) .

> If you had the OnDisarm event, you could create a bunch of spikes (or
> darts, in case of dart trap) in place of the trap.

OnDisarm is too specific for a general item class I guess.

> --
> Radomir `The Sheep' Dopieralski @**@_
> (nn) 3 Grin
> . . . ..v.vVvVVvVvv.v.. .

regards,
Jan
Anonymous
July 14, 2005 12:59:06 PM

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

At 14 Jul 2005 01:19:12 -0700,
Jan Drahokoupil wrote:

> The Sheep wrote:
>> At 13 Jul 2005 04:07:48 -0700,
>> Jan Drahokoupil wrote:

>> The pit trap cannot be taken with you -- at most you can take parts of it,
>> like the twigs and leaves that cover it.

> Trap pits are made by decreasing height of ground (or eventually
> skipping it at all so the player..will drop level down, because of
> voxel structure) and setting the flag "Fake floor" coz we're not able
> to solve it otherwise (if you'll step on the floor the fake floor will
> disappear and you'll drop down on real land where spikes (or acid or
> whatever) should be laying. Any suggestions on this ?

How do I mark it as a trap then? How do I use my DetectTrap and DisarmTrap
skills? I need special code to handle this.
I think it's somewhat wrong when I need special code for something, that's
similar from the player's perspective.

Why can't you have a trap (item), that cannot be picked up, is invisible
without DetectTrap check, and makes a hole in the ground whenever someone
activates it. And, ofcourse, will make this hole also when disarmed.

>> A fire trap is also probably built into the dungeon floor or wall -- the
>> best you can do is to break the mechanism.
>
> We'll we're forced to implement nasty list of flags to cover some
> aspects. This one is covered by "Land trap" which makes the item built
> in the floor. There also "Invisible" and "Unpickable" which seems to be
> (when combined) able to get the same effect but "Invisible" can be
> overriden by some spells or abilities.

Seems ok, altrough some of those flags could be implemented in the event
handlers.

>> The spike trap is similar to the fire trap, but maybe you can gain some
>> spikes (used later to jam doors, etc.) when you disarm it.
>
> Spike traps depends on mod-maker because they could lay down a "Land
> trap" and when you'll step on them their effect (script) is triggered.
> So mod-maker has to implement where from the spike will attack and send
> the spike (setting it's velocity vector).

You're talking about dart trap -- the one that shoots darts at the player.
I mean a spike trap -- there are lots of them in the old Prince of Persia
game. When you step on it, a bunch of sharp spikes grows from the floor.

If you had the OnDisarm event, you could create a bunch of spikes (or
darts, in case of dart trap) in place of the trap.

--
Radomir `The Sheep' Dopieralski @**@_
(nn) 3 Grin
. . . ..v.vVvVVvVvv.v.. .
Anonymous
July 15, 2005 11:04:04 AM

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

I'd be interested in hearing more about MQN, if you could explain a bit
more of how it's structured?
Anonymous
July 18, 2005 2:44:09 AM

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

"Jan Drahokoupil" <drahokoupil@telpro.cz> wrote:
> Hi, I got different problem this time.
> Any suggestions on item events (what
> should happen to them). So far we've:
>
> OnActivated - item is being used
> OnDrunk - item is being drunk by owner
> OnEaten - item is being eaten by owner
> OnWielded - item is being equipped to owner's hand slot
> OnWorn - item is being equipped to owner's non-hand slot
> OnShot - item is being shot by user's missile weapon
> OnTakenOff - item is being taken-off from owner's non-hand slot
> OnThrown - item is being thrown by owner
> OnUnwielded - item is being unwielded from owner's hand slot

> OnBoiled - item is changing from fluid to gas
> OnBroken - item is changing from normal to broken
> OnCondensed - item is changing from gas to fluid
> OnExploded - item is flammable and it was fired-up
> OnMelted - item is changing from solid to fluid
> OnRusted - item is changing from unrusted to rusted
> OnSolidified - item is changing from fluid to solid

And just how would an outsider know whether to call OnBoiled or
OnMelted? And why should it care? You can drop all seven of these and
replace it with one OnDamage(damageType), and not have to worry about
the relationship between flammable, meltable, and boilable objects
all the time.

> OnAccepted - item is being given to owner
> OnBorrowed - item is being borrowed to owner
> OnBought - item is being bought by owner
> OnDropped - item is being dropped by owner
> OnGiven - item was given from owner to somebody
> OnLent - item is being lent by user to somebody
> OnPicked - item is being picked-up by owner
> OnSold - item is being sold by owner
> OnStealed - item is being stealed from owner

Same problem as before: a long list of rediculously specific methods
for what should just be OnAcquire(), OnLose(). If I want to implement
an item with an effect when it enters inventory and an effect when it
leaves inventory, I don't want to implement *nine* methods.

You're falling into the most common roguelike developer trap there
is: over engineering. Stop planning for unlikely possibilities and
start making real features. By the time you're ready to add the Phase
Changer of Yendor to the game, it will be obvious what's the best way
to do so.

--
CalcRogue: TI-89, TI-92+, PalmOS, Windows and Linux.
http://calcrogue.jimrandomh.org/
Anonymous
July 18, 2005 2:56:25 AM

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

jimrandomh wrote:
> "Jan Drahokoupil" <drahokoupil@telpro.cz> wrote:
> > Hi, I got different problem this time.
> > Any suggestions on item events (what
> > should happen to them). So far we've:
> >
> > OnActivated - item is being used
> > OnDrunk - item is being drunk by owner
> > OnEaten - item is being eaten by owner
> > OnWielded - item is being equipped to owner's hand slot
> > OnWorn - item is being equipped to owner's non-hand slot
> > OnShot - item is being shot by user's missile weapon
> > OnTakenOff - item is being taken-off from owner's non-hand slot
> > OnThrown - item is being thrown by owner
> > OnUnwielded - item is being unwielded from owner's hand slot
>
> > OnBoiled - item is changing from fluid to gas
> > OnBroken - item is changing from normal to broken
> > OnCondensed - item is changing from gas to fluid
> > OnExploded - item is flammable and it was fired-up
> > OnMelted - item is changing from solid to fluid
> > OnRusted - item is changing from unrusted to rusted
> > OnSolidified - item is changing from fluid to solid
>
> And just how would an outsider know whether to call OnBoiled or
> OnMelted? And why should it care? You can drop all seven of these and
> replace it with one OnDamage(damageType), and not have to worry about
> the relationship between flammable, meltable, and boilable objects
> all the time.

He don't have to know when to call those events..because they're fired
by engine itself when needed. Mod-maker only has the chance to
implement his own effect when this occures (but not necessarily).

> > OnAccepted - item is being given to owner
> > OnBorrowed - item is being borrowed to owner
> > OnBought - item is being bought by owner
> > OnDropped - item is being dropped by owner
> > OnGiven - item was given from owner to somebody
> > OnLent - item is being lent by user to somebody
> > OnPicked - item is being picked-up by owner
> > OnSold - item is being sold by owner
> > OnStealed - item is being stealed from owner
>
> Same problem as before: a long list of rediculously specific methods
> for what should just be OnAcquire(), OnLose(). If I want to implement
> an item with an effect when it enters inventory and an effect when it
> leaves inventory, I don't want to implement *nine* methods.

We've solved this (with help of Sheep and others)

OnChanged - grouped event called when any of subitem is called
- OnBoiled
- OnCondensed
- OnExploded
- OnMelted
- OnSolidified
OnEquipped
- OnTakenOff
- OnUnwielded
- OnWielded
- OnWorn
OnGained
- OnAccepted
- OnBorrowed
- OnBought
- OnCaught
- OnPicked
- OnSlipped
OnLost
- OnDropped
- OnGiven
- OnLent
- OnShot
- OnSold
- OnStolen
- OnThrown
OnProcessed
- OnBroken
- OnDrunk
- OnEaten
- OnRusted
OnStructured
- OnAttached
- OnCreated
- OnDestroyed
- OnDetached
OnUsed
- OnActivated
- OnAttacked

> You're falling into the most common roguelike developer trap there
> is: over engineering. Stop planning for unlikely possibilities and
> start making real features. By the time you're ready to add the Phase
> Changer of Yendor to the game, it will be obvious what's the best way
> to do so.
>
> --
> CalcRogue: TI-89, TI-92+, PalmOS, Windows and Linux.
> http://calcrogue.jimrandomh.org/

This is just engine..we don't know what mod-maker will try to implement
and we're just widening the possibilities.

regards,
Jan
!