Item events ?

[Guest]

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

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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

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

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

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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 ) 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

 

[Guest]

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.. .

 

[Guest]

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.. .

 

[Guest]

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.. .

 

[Guest]

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.. .

 

[Guest]

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.. .

 

[Guest]

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