Well, to elaborate....Take some of the music libraries out there, like FMOD. FMOD handles all the heavy lifting (ie, all the code to import a music file, load a music file, and stream a music file are done for you). All you basically have to do is import the library and make some function calls to load and play a tune.
This same approach could be done with an adventure game library, except it would likely benefit from a GUI BUILDER app to accompany it that would export the finished gui designs in a format the adventure game library can import and understand. So basically you'd use this GUI BUILDER, which is an app made to design all your adventure game guis (verbcoin, verb bar, cursor states, inventory) and then you'd export that as a file much like a music file. Then the library would interpret this file and allow you to do things like DISPLAY the main gui, seize control over the mouse for point and click, and other things. The library could be as simple as just displaying a gui on the screen or as complicated as doing all the heavy lifting an adventure game would require APART from what a typical engine offers (rendering, objects, music, etc). Basically you'd have a very specific library for a very specific type of game that provides only the bits not typically offered in a generic engine like Ogre.
Specific things I could see the GUIBUILDER doing:
1. Allow you to import graphics for cursors and establish their properties (what each one does) and save/load them in an encrypted .csr file (or whatever).
2. Allow you to import graphics for inventory items and establish their properties (what they do when used, looked at, etc) and save/load them in an encrypted .inv file (or whatever).
3. Allow you to import graphics for images, buttons, and so on for the main gui, design them, and then save the entire gui (graphics and all) as a separate .gui file (or whatever). The editor would allow you to do basic pushbutton states that the library would understand (like if you assign a button to randomly change the player cursor, when you load the gui up in the game and click on the button it will do so).
Obviously you could expand the functionality if you were designing this, but the goal of the GUIBUILDER would be to allow you to create content that is adventure game centric and not as easily done through direct coding means.
Oh, by the way, nobody replied to that but it's very interesting. That's my quest with existing engines. ProgZmax, you baffle me: Sometimes you're on the side of : "do everything yourself, GUIs are for sissies", and there you're on the opposite side
I loved that post.
The editor would allow you to do basic pushbutton states that the library would understand (like if you assign a button to randomly change the player cursor, when you load the gui up in the game and click on the button it will do so)
In my opinion this is the one thing that is constantly overlooked and underestimated in engines and libraries: The
state machines, and the handling of their related
events.
However that's extremly important because
that's where the said library would meet the underlying graphic engine.
Each engine (let's say Source, the UDK, Blender, etc.) has
its own set of events and ways to manage them. Defining events that are universal enough (e.g. "mouse click", to give a simple example) is essential.
