Personally I would have a base class of object and have events on them that request information from various objects, i.e.
Code: Select all
OBJECT
Id
Name
Type (item, npc, monster, static_item)
events[] (array of EVENT objects)
properties[] (array of PROPERTY objects)
EVENT
Id
Script[] (array of strings)
PROPERTY
Id
Type (int, char, bool)
Value
as a quick note an IS_CONTAINER property is something the engine could look for but does not have to be hard coded as part of the object type. It makes it more flexible (also covered later in the basic commands.)
Then break down the events per object type.
Have a basic floor_trigger that has the events (i.e.)
Code: Select all
ON_ENTER
( type = monster/party/item/anything else/
direction entered from = n/s/e/w
objectReference
)
ON_LEAVE (like above)
A wall trigger that should be positioned on a wall tile and have a facing (much like RTC) but with definable zones that can be interacted with.
Code: Select all
wall_trigger
x, y, level
zones[] (array of ZONES)
ZONE
x1,y1,x2,y2
sprite[] or pic[]
Events would be like
Code: Select all
ON_MOUSECLICK
(button 1=left 2=right 3=middle,
itemRef if an item is in the hand that clicked,
playerRef the player that "clicked" the wall,
zoneRef for the Zone
)
ON_MOUSEENTER (params as above)
ON_MOUSELEAVE (params as above)
As for the scripting engine, some basic commands could be
Code: Select all
MOVE_PARTY x, y, level, face
MOVE_ITEM itemRef, x, y, level, position
MOVE_ITEM_LIMBO itemRef
MOVE_ITEM_CONTAINER itemRef, containerItemRef
CHANGE_PROPERTY itemRef, propertyName, [newVal for anything but bool]
The property bit comes in so that people can have their own counters on objects and things and it can just add them on, but your engine can use internal properties stored the same way.
Im thinking to define objects you would do something like
Code: Select all
Item 001 "Alcove Wall" (x, y, level)
{
visible (bool) = false
visible2 (bool) = true
}
Now VISIBLE could be a property that your engine looks for when you are near that object and deal with it but VISIBLE2 is one of mine (as a dungeon author) and makes no ends. But it stores them in the same way
Now all you have to do is have a method that checks each of the engine assigned properties (like VISIBLE for instance to decide whether to draw them or not) and you have the basis for a quite flexible system.
Before I continue too much, is this what you were after? Or am I ranting for no reason
