Hmmm... maybe a better way to go about all this would be to do the following:

- Have all data stored in the XML file, but ONLY data; no AS function calls. All game entities are given a unique ID
- Have an AS file that holds all my scripting stuff -- classes, functions, etc.
- In the AS file, there is an "OnEnter" function for rooms that takes an ID for a parameter. It will hold a long switch() block, in which I can define whatever behaviors I wish for certain rooms when a user enters (perhaps it would also take parameters such as the user's ID, but let's keep things simple for the explanation)
- Whenever a player enters a room, the C++ code calls the AS function "OnEnter", sending in the room ID in question

I could have a number of event functions defined for numerous game entities. This design makes it such that calls don't have to be constructed in the XML, which means I don't have to use ExecuteString(). This also seems to be organized better.

Any thoughts?

Long switch blocks are usually a warning sign. You probably don't want to define an object's behavior outside where you define other traits about an object.

I believe that if I were to implement an engine like what you're describing I would choose something similar to your last approach.

The data files (XML) can define the event handlers that should be called by the application when events are triggered. All event handlers have a predefined function signature, e.g. 'void function(event& e)', where the event type is a class that holds the necessary information, for example the id of the object fo which the event was triggered.

The event handlers can be defined in a separate script file, named by the XML file, or may even be defined inside the XML. If defined inside the XML the application should extract all the script pieces and compile them as one script as it is loading the XML file.

Example:

-- XML file<room id="1">   <name>Grassy field</name>   <description>You find yourself in a vast field of tall grass.</description>   <exits>      <exit hotkey="n" description="North" roomid="2" />   </exits>   <events>      <event name="onEnter" handler="EnterRoom1" />      <event name="onExit" hanlder="ExitRoom1" />   </events></room>-- Script codevoid EnterRoom1(event &e){  RoomObject @obj = @GetRoomObject(e.id);  if( obj.hasVisited )  {     // The player has already visited this room          ...  }  else  {     // This is the first time the player visits the room     obj.hasVisited = true;     ...  }}

Quote: Original post by SiCrane
Long switch blocks are usually a warning sign. You probably don't want to define an object's behavior outside where you define other traits about an object.

But I'm not trying to define behaviors of an entire class, but rather of different objects of a class. Basically, I would need Room1 to have a different onEnter() implementation than Room2, because they do different things when one enters; they are both Room objects, however.

Exactly my point. If Room1 and Room2 have different behaviors, why define them in the same place? That's what you would be doing with a switch statement.

Quote: Original post by SiCrane
Exactly my point. If Room1 and Room2 have different behaviors, why define them in the same place? That's what you would be doing with a switch statement.

But then, how else could I define different behaviors in objects of the same class? I don't want to have to make a separate subclass for each object that differs; that seems like overkill, as there'd likely only be one instance of each said subclass.

Quote:
But then, how else could I define different behaviors in objects of the same class? I don't want to have to make a separate subclass for each object that differs; that seems like overkill, as there'd likely only be one instance of each said subclass.

See my previous post. That's how you should do it. You would already be defining different behaviours for each object by registering different event handlers, there won't be a need for a switch case.