REPLY TO COMMENT


SuperBob
Wintermute's scripting language is based on JavaScript, and like JavaScript, it is dynamically-typed.  All variables must be first declared with the "var" keyword, and type is determined by assignment.  You can write code quicker and with fewer lines, but may not be able to prove what something does until run-time.  Adopt a naming convention (Hungarian or whatever) and stick to it.  It can be a real source of frustration.  All things considered, I find it mostly a joy to work with.

In Wintermute, everything is an object (including variables).  The engine creates a Game object.  The Game object has an attribute called Scene (i.e. Game.Scene) that stores the currently-loaded Scene object.  Scenes are comprised of Actors, Entities, Items, Regions, etc. and UI objects like Windows and Buttons.  These are created using plain-text "definition" files.  Wintermute comes with tools that create these automatically for you, but it is possible to make templates/snippets in your favorite text editor and generate them that way.  To change the scene, you simply use the Game.ChangeScene method and pass it the location of one of your scene files (e.g. "../../scummbar.scene") and some other parameters like how the scene is supposed to fade in and out.  In Adventure Game Studio, the engine is wedded to the editor and is the only way to create new scenes and other objects.  You can't copy a folder to a new destination (e.g. cp -r room1 room2) and this is a huge limitation.  To my knowledge, it is impossible for developers to work on different scenes at the same time and merge their work.  One must save and close the project, and re-open it in another location.  In Wintermute, however, everything is stored openly in a directory structure and any work will immediately be accessible across a local network.  You can use git or whatever it is you prefer for source control.  It comes with a debugger that allows you to view all the global and script variables at run-time.  You can create watches, set breakpoints, step through code, etc.  In fact, it's the best debugger I've seen in an adventure game engine, but that's not saying much.  You attach scripts to the characters and items in your game, and code is executed when an event occurs.  There's a "this" keyword which stores the object currently running the script.  Dialog is created using nested if/else or switch/case statements.  For example, if the Storekeeper's TalkTo event is triggered, a function named StorekeeperDialog is called.  Inside the function body is an infinite loop that displays the dialog choices and waits for the user's input.  You store the selected response and process it.  Lastly, there's parallax scrolling, particle effects, plugins can be written in C/C++, and more.  Audio and video is license-free OGG and Theora.  All the graphical elements are sprites including the UI and fonts, but there is TrueType font support.  You can dump the string table for localization and talkies.

For hobbyists, AGS is a great way to learn how to make an adventure game, but I would not recommend using it outside of that scope.  Nevertheless, it's been used to make commercial games.  As for OpenSLUDGE, the language is poorly-designed, has poorly-chosen keywords and built-in function names, and the included tools and documentation are really lacking.  It's not object-oriented, but pretends to be.