There's really no need for me to wait until RAGE is released to share the core structures behind the engine. The key to building an interactive scene is constructing scripts based on conditions, and those scripts are comprised of three main parts:
Results
The fork in the road. The path that is executed depends on whether a previous test returned Pass or Fail.
Events
Actions that are performed by the engine, like playing a sound or running a storyboard. Not to be confused with events in programming languages.
Tests
The evaluation of conditions which result in True (Pass) or False (Fail).
Result nodes process any child events and tests they have. The recursive structure is a bit verbose but also very flexible. The trick is to account for all the relevant scenarios. The more scenarios you cover the more intelligent your game will seem to the player.
Sample Scenario
Let's say the player enters a scene called "bowlingalley". Pictured left is a simplified example of what the startup script might look like (click for larger image). At the top of the script tree you'll see a node marked
Root. This is a special type of script Result that is automatically executed, i.e. there is no True/False evaluated beforehand. Any Events and Tests that belong to Root will automatically be executed when the script is invoked. The text
You've entered the bowling alley will always be displayed.
The events I've added to Root are pretty self-explanatory. An ambient sound is queued up while text is displayed. When it's time for you build your own script you'll find this to be pretty intuitive (I promise!). Upon clicking the Events node you'll have the option to add a new event, upon which you'll be presented with a list of various event types such as AddAmbientSound and AddCharacterToScene. Once you select an Event type you'll be prompted for the relevant parameters, i.e. sound name, output text, character ID, and so forth.
The Tests node is slightly more confusing at first glance. There are a handful of different types of Tests you can perform within the engine: ActiveSceneID, ActiveCharacterID, CharacterFlagExists, ItemFlagExists, and a few others. Flags are a big part of tracking the state of your game, so most of your tests will likely hinge on the existence (or lack thereof) of flags.
For simplicity's sake, the test I've added performs a check on whether the ActiveSceneID is "bowlingalley". I've added two Results to the test, one for Pass and one for Fail. Obviously the Fail branch is never going to execute in this case, but many flag-based scenarios will need to account for both possibilities. In the Pass result I've added a simple output of Yes, you're in the bowling alley, and no child tests.
You may have noticed the (Exit = False) label next to the Pass Result. This tells the engine whether to bail out of the entire script once the current test (ActiveSceneID = bowlingalley) has been processed, or whether it should "fall through" and continue processing tests below it. This is handy in scenarios where you want a catch-all scenario, something that should happen if none of the tests return True.
Scripts are triggered at various times, not just when a scene first loads. They're also executed as a result of point-and-click scenarios. Once a player enters the bowling alley they can generate the Examine shoe rack scenario. The RAGE engine checks the scripts for a match on the verb/target combination; if no match exists it reverts to a generic script associated with the Examine verb. The generic script is where you specify a failure response (or multiple responses if you want to randomize it a bit) such as "I don't see anything special about it."
That's all for now. Hopefully this sheds some light on how independent, granular scripts will make an adventure game come to life.