Just s a couple of thoughts:
Game Specification Language
If this concept was expanded to included a directory structure containing all the resources, sprites, backgrounds, sounds, etc, their import properties/instructions and the scripts that comprise the game, the AGS editor then be able to read/write this file. The file could then be input to stand-alone compilers to port any given game to different game engine back-ends.
I believe this is similar to what Clavaron did with XAGE. It's also a way to work around the license incompatibilities between AGS and SummVM; there could simply be an AGS-ScummVM compiler and shazamo AGS games are able to run on ScummVM. Conceivably this could be done with older AGS games even without the source code?
With regard to format, the obvious first choice to come to mind is XML. Fell free to opine as to it's merits and/or alternatives.
Game Entity
I like the above discussions about "things' and "game entities" and agree with much of it. I believe all Game Entities or Entities ought to have some common characteristics:
Resources
Entities ought to be able to "own" resources such as sprites, sounds, music, etc. Two or more entities can own the same resources. If an entity is exported it's resources are also exported (this would also apply to it's other constituents as well). If an entity is imported all of it's constituents are also imported. From a user perspective it may look like the game contains multiple copies of the same resource but this does not have to be the case. The game files themselves would contain only one copy and multiple references as is the case now.
Views
Animation is perhaps a better word? Entities could have 0 or more views or animations consisting of an arbitrary number of loops. Different views could be set active by the script code. If a character entered the water the swimming view could be activated. Perhaps multiple views could be simultaneously set active to change clothes or hair-do for example. This suggests some sort of organizational hierarchy (i.e. folders, groups, or something). The concept of view should be general enough to include the playing sounds, music, and other resources synchronized to animation or without animation at all. In light of this perhaps a word like "Composition" may be a better choice?
Collections
The way to handle inventory is perhaps to just let inventory items be Entities and then allow Entities to contain collections of other entities. So if a character has a gun, then the gun can have bullets. If a character has chewed bubble gum and a paper clip in the inventory and then makes a key with those items he will end up with a key in his inventory but no bubble gum and paper clip. Why? Because the key now has the gum and paper clip. I suppose a generalized solution would allow entities to have multiple collections. You could then of course, as suggested earlier, have GUI components for displaying collections.
Scripts
Entities ought to have the ability to contain scripts. It could be something like modules are now in AGS and could work in exactly the same way. The would have the ability to respond to and/or capture events.
Events
Otherwise know as player interactions. Currently interactions are only defined in for rooms. Why should not other entities also have the ability to respond to such events/interactions. In addition it would be nice if there were the ability to handle user defined events where one script could post an event (possibly with data value) which would trigger interaction functions in other scripts.
Dialogs
Dialogs are held between one or more entities. Participants can be explicitly identified within the dialog or identified when the dialog is initiated, sort of like passing parameters. Dialogs are owned by entities. If a room owns the dialog it can only be initiated when the participants are in that room. If a character owns a dialog then the dialog can be initiated in any room where the participants are present. The owning entity does not necessarily have to be a participant.
Dialogs usually result in the player learning something or the game changing state (or both). Perhaps the latter consequence should be enshrined in a standard way. What if entities were able to have a collection of "Facts"? Each fact could be a string or unique id# and have a count and %confidence level. There could be a dialog command called reveal (reveal "fact string" [%confidence]). If confidence level not supplied then revealing entity's default confidence level is used. The entity(s) to whom the fact is revealed adds the fact to it's knowledge base it it doesn't exist. The count is then incremented and then used to calculated a weighted average of the confidence level. The game programmer can then use these properties however he wishes. "Conversation" is perhaps a better word than dialog?
Game Specification Language
If this concept was expanded to included a directory structure containing all the resources, sprites, backgrounds, sounds, etc, their import properties/instructions and the scripts that comprise the game, the AGS editor then be able to read/write this file. The file could then be input to stand-alone compilers to port any given game to different game engine back-ends.
I believe this is similar to what Clavaron did with XAGE. It's also a way to work around the license incompatibilities between AGS and SummVM; there could simply be an AGS-ScummVM compiler and shazamo AGS games are able to run on ScummVM. Conceivably this could be done with older AGS games even without the source code?
With regard to format, the obvious first choice to come to mind is XML. Fell free to opine as to it's merits and/or alternatives.
Game Entity
I like the above discussions about "things' and "game entities" and agree with much of it. I believe all Game Entities or Entities ought to have some common characteristics:
Resources
Entities ought to be able to "own" resources such as sprites, sounds, music, etc. Two or more entities can own the same resources. If an entity is exported it's resources are also exported (this would also apply to it's other constituents as well). If an entity is imported all of it's constituents are also imported. From a user perspective it may look like the game contains multiple copies of the same resource but this does not have to be the case. The game files themselves would contain only one copy and multiple references as is the case now.
Views
Animation is perhaps a better word? Entities could have 0 or more views or animations consisting of an arbitrary number of loops. Different views could be set active by the script code. If a character entered the water the swimming view could be activated. Perhaps multiple views could be simultaneously set active to change clothes or hair-do for example. This suggests some sort of organizational hierarchy (i.e. folders, groups, or something). The concept of view should be general enough to include the playing sounds, music, and other resources synchronized to animation or without animation at all. In light of this perhaps a word like "Composition" may be a better choice?
Collections
The way to handle inventory is perhaps to just let inventory items be Entities and then allow Entities to contain collections of other entities. So if a character has a gun, then the gun can have bullets. If a character has chewed bubble gum and a paper clip in the inventory and then makes a key with those items he will end up with a key in his inventory but no bubble gum and paper clip. Why? Because the key now has the gum and paper clip. I suppose a generalized solution would allow entities to have multiple collections. You could then of course, as suggested earlier, have GUI components for displaying collections.
Scripts
Entities ought to have the ability to contain scripts. It could be something like modules are now in AGS and could work in exactly the same way. The would have the ability to respond to and/or capture events.
Events
Otherwise know as player interactions. Currently interactions are only defined in for rooms. Why should not other entities also have the ability to respond to such events/interactions. In addition it would be nice if there were the ability to handle user defined events where one script could post an event (possibly with data value) which would trigger interaction functions in other scripts.
Dialogs
Dialogs are held between one or more entities. Participants can be explicitly identified within the dialog or identified when the dialog is initiated, sort of like passing parameters. Dialogs are owned by entities. If a room owns the dialog it can only be initiated when the participants are in that room. If a character owns a dialog then the dialog can be initiated in any room where the participants are present. The owning entity does not necessarily have to be a participant.
Dialogs usually result in the player learning something or the game changing state (or both). Perhaps the latter consequence should be enshrined in a standard way. What if entities were able to have a collection of "Facts"? Each fact could be a string or unique id# and have a count and %confidence level. There could be a dialog command called reveal (reveal "fact string" [%confidence]). If confidence level not supplied then revealing entity's default confidence level is used. The entity(s) to whom the fact is revealed adds the fact to it's knowledge base it it doesn't exist. The count is then incremented and then used to calculated a weighted average of the confidence level. The game programmer can then use these properties however he wishes. "Conversation" is perhaps a better word than dialog?
.
... and perhaps pigs can learn how to fly