OK, so here's some suggestions for AGS:
It would be nice if each of the inbuilt arrays like character, object, etc all had one or two extra members per item that were read/writeable and available for the use to use as they wished. Ideally, the user could control the number/type and names of these, but even if there were 1, called userdef1, then that would be great. I suppose these are like read/writeable propertty schemas, so it could be doen through that. Or through a way of getting OO extends to work on those builtins
As well as having inventory items, it would be nice if AGS had (at least one) another general purpose item list, which could be used for spells, icon-based dialog options, etc. It would be in the editor like the inv item list where you could set a sprite, cursor hotspot and property schema for each item. Ideally, there would be a generalised tree system where "Item lists" was the top level, with Inv items being a special case and default on the list, but the user could add other lists themselves.
If the user could define their own things to go on the "General settings" page, someone could write a super-template that the let the user change a combo box on the front page from "SCUMM FOA" to "Sierra classic" to "Broken Sword" to get various default game styles.
OO stuff makes include files or some kind of script module import/export easier to organise and more obviously a gap. At least the single-GUI import/export that I already mentioned.
Character editor should show view NAMES when choosing default, idle, talking views, etc.
Also be nice if characters, like GUIs, could have a named handler function
Be good if you could specify whether the dialog GUI goes away after an option is selected, or if it stays. Alternativley, specify a function to be called before and after any dialog
A GUI could have its own on_key_press and repeatedly execute handlers, and it would be nice if a GUI could have a click handler rather than just GUI controls, because lots of GUIs have a regularity to them that means that individual handlers would mean lots of cut-and-paste
It would be nice if each of the inbuilt arrays like character, object, etc all had one or two extra members per item that were read/writeable and available for the use to use as they wished. Ideally, the user could control the number/type and names of these, but even if there were 1, called userdef1, then that would be great. I suppose these are like read/writeable propertty schemas, so it could be doen through that. Or through a way of getting OO extends to work on those builtins
As well as having inventory items, it would be nice if AGS had (at least one) another general purpose item list, which could be used for spells, icon-based dialog options, etc. It would be in the editor like the inv item list where you could set a sprite, cursor hotspot and property schema for each item. Ideally, there would be a generalised tree system where "Item lists" was the top level, with Inv items being a special case and default on the list, but the user could add other lists themselves.
If the user could define their own things to go on the "General settings" page, someone could write a super-template that the let the user change a combo box on the front page from "SCUMM FOA" to "Sierra classic" to "Broken Sword" to get various default game styles.
OO stuff makes include files or some kind of script module import/export easier to organise and more obviously a gap. At least the single-GUI import/export that I already mentioned.
Character editor should show view NAMES when choosing default, idle, talking views, etc.
Also be nice if characters, like GUIs, could have a named handler function
Be good if you could specify whether the dialog GUI goes away after an option is selected, or if it stays. Alternativley, specify a function to be called before and after any dialog
A GUI could have its own on_key_press and repeatedly execute handlers, and it would be nice if a GUI could have a click handler rather than just GUI controls, because lots of GUIs have a regularity to them that means that individual handlers would mean lots of cut-and-paste