: It is, probably, not my place to point out, but if you are trying to mimic the usual dialog boxes - why don't just use the dialog boxes? For every sutuation you can create a separate dialog box - it will be easier then to write scripts and add controls dynamically. If the case is that you do not now at all the contents of your dialog then you should implement it as you desire. However, can you bring an example of where you may be needing this functionality - when controls on a dialog box cannot be predicted in any way?
Hey, well that's a nice question. Have you ever heard of the game 'VGA Planets'? Or 'Romance of the Three Kingdoms'? Or, as another example, imagine a turn-based / play-by-email variant of Warcraft (assuming you know Warcraft). All of these would be examples of a turn-based strategy game, that take place on some world or universe (or for that matter it might as well be an island or an asteroid) where players have some types of units roaming around, building settlements at various locations on the map, intending to (most likely) expand their kindom/empire/whatever and rule over all of the in-game world, using instruments such as the military, diplomacy, trading, alliances, even contraband, etc.
Take all those games and they probably have more in common than would seem at first. That is, if you exclude the game graphics, and the game interface (which is largely dependent on the functionality specifics of any and all elements in the game).
A friend of mine and I, have the intention of writing some sort of game engine specifically for turn-based pbm games, but one where third parties can completely design their own game elements and mechanics. A hierarchical object structure, in an xml-like format, will define game data like what types of entities (such as army units, or trading alliances) can exist in the game, and what actions they can perform, and also what instances of these entities exist at any given turn, what they are doing, and their relations to other entities. All the while, a script (or several scripts) define the game mechanics, which specify exactly what happens, what does it mean for some entity to perform some actions, what is the result of it, etc.
Now, there are (asside from lack of code right now ;) two major gaps in the plan, which you might have guessed already from reading the second paragraph:
(1) What about the interface?
(2) What about the game-specific graphics?
So, number two is to far away yet to worry about it, by the way, don't we all know some kick-ass cg. artist, or a good royalty-free download site that can help out on this front? :)
And number one has just been solved. Of course it is possible to auto-generate an interface given the game-specific entity and action types (which, by the way, will be impossible to know in advance or be prepared for in any other way than throwing in the hype of Mr. 'dynamic' and Mrs. 'on-the-fly'). But it would be much nicer if game designers could specify for themselves what screens are available, and what will be on those screens, and where the automap should be placed. And so, we decided that the game interface design (and then, is there any other way, really?) should be part of the design for one specific game.
So, in a nutshell (chuckle), there is the answer to your inquiry. Was any of this making sense? By the way, ask me anything except 'when will this very cool game engine be finished', because probably it will never be finished, and if it will be then, who knows, maybe it's not so cool afterall... :P