Any plans on a stand alone compiler? Here is what I was hoping for...

[Joseph DiPerla]

This has been discussed as a desired feature in the past by many in the community, where AGS is split into three applications, 1) The Editor 2)The compiler 3)The engine runtime.

Now I am not sure if anything has been discussed on this end, or if anyone is even willing to work on this at all. I would love to try and port this myself, however, though I am a very good vb programmer, a decent Java programmer and am learning c++ and even if c# seems to incorporate a little each along with its own thing... I cant seem to understand a lick of anything in C#. Its sad, I know, particularly because many rave about it. So, I was wondering if there was anyone who was thinking about undertaking such a project? Of course, that might mean also re-doing how the editor writes its output of the sources. So, I was thinking, why not leave the original editor with a native compiler, but at the same time, write a new compiler that is standalone that can compile sources into an AGS Game file? I know this doesn't make much sense, I am just trying to throw options out there. I guess the work on the AGS Editor to make it perform those functions can come later, once the compiler is done. In any case, I had some idea's on how to incorporate this if it should occur. This would allow custom editors and ports to other operating systems for editing.

Step 1: The folder arrangements.

Much how AGS has a project pane with various categories, the folders would be split up into those categories. So for instance, a tree for a simple AGS Project might look something like this im a game folder:

â"œâ"€â"€â"€Audio
â"œâ"€â"€â"€Characters
â",   â"œâ"€â"€â"€cEgo
â",   â"œâ"€â"€â"€cPumaman
â",   â""â"€â"€â"€cRoger
â"œâ"€â"€â"€EnginePlugins
â"œâ"€â"€â"€Fonts
â",   â"œâ"€â"€â"€Font0
â",   â""â"€â"€â"€Font1
â"œâ"€â"€â"€GeneralSettings
â"œâ"€â"€â"€GlobalScripts
â",   â"œâ"€â"€â"€GlobalScript
â",   â",   â"œâ"€â"€â"€Headers
â",   â",   â""â"€â"€â"€Source
â",   â""â"€â"€â"€RainScript
â",       â"œâ"€â"€â"€Headers
â",       â""â"€â"€â"€Script
â"œâ"€â"€â"€GUIs
â",   â""â"€â"€â"€gGui1
â"œâ"€â"€â"€InventoryItems
â",   â"œâ"€â"€â"€iCrap
â",   â"œâ"€â"€â"€iKey
â",   â""â"€â"€â"€iPod
â"œâ"€â"€â"€MouseCursors
â",   â"œâ"€â"€â"€Look at
â",   â""â"€â"€â"€Walk to
â"œâ"€â"€â"€Rooms
â",   â"œâ"€â"€â"€Room1
â",   â"œâ"€â"€â"€Room2
â",   â""â"€â"€â"€Room301
â"œâ"€â"€â"€Sprites
â",   â"œâ"€â"€â"€Jane Sprites
â",   â""â"€â"€â"€John Sprites
â"œâ"€â"€â"€Translations
â",   â"œâ"€â"€â"€English
â",   â"œâ"€â"€â"€German
â",   â""â"€â"€â"€Italian
â"œâ"€â"€â"€Video
â""â"€â"€â"€Views
    â"œâ"€â"€â"€View1
    â""â"€â"€â"€View2

As you can see, each category has sub folders depending on what each item in it is supposed to have. For instance, under the "View" Folder, you will see View1 and View2 and so on. Those are sub folders for each view you create in the editor. So thats the basic Folder Structure. There is only one Folder that does not appear in the in the original Editor Pane, and that is the Video Folder which you can include video's in. The General Settings Folder will put all the other pane categories in there. We will discuss more on that later.


Step 2: The Makefile

The make file should be in the root directory of the game folder and could be either a text file or XML. Personally, since I develop for Android, I noticed that XML is a very effective way of putting projects together. So, I was thinking that maybe the makefile could be Makefile.xml which would look something like this:

<?xml version="1.0"?>
      <Game>
            <General Settings Folder>
                   Folder:Include="GeneralSettings"
            </General Settings Folder>
            <Gui Folders>
                   Folder:Include="Gui1"
                   Folder:Include="Gui2"
                   Folder:Include="Gui2"
             </Gui Folders>
             <Room Folders>
                   Folder:Include="Room1"
             </Room Folders>
       </Game>     

So then the Compiler would start to grab all those folders and search for their XML file settings and compile what the game needs compiled. The only difference is that the Script folders will not contain any XML file settings, therefore the folders need to be included and the compiler would just automatically iterate through the headers and source sub folders and include all the script files found in there.

Step 3: XML File Settings.

Each Category in a pane, has its own properties. For instance, Lets take a look at the Inventory Item Properties for, lets say, a key. This is how it would look:

<?xml version="1.0"?>
          <Inventory Item id="iKey">
                   <Appearance>
                       <CursorImage>0</CursorImage>
                       <Description>New Inventory Item</Description>
                       <Image>0</image>
                   </Appearance>
                   <Design>
                       <HotspotX>0</HotspotX>
                       <HotspotY>0</HotspotY>
                       <ID>1</ID>
                       <Name>iKey</Name>
                   </Design>
                   <Properties>
                       <Property>Some Property</Property>
                   </Properties>
                   <Events>
                        <Interact>Script</Interact>
                        <Look>Script</Look>
                        <Talk>None</Talk>
                        <Other>None</Other>
                        <Use>Script</Use>
                    </Events>
        </Inventory Item>

Notice a few things in there: Properties and Events. Of course, the properties will be described somewhere else, however you have to specify here to what property the item has in it. You can add more than one property in that bracket of course. Also, look at the events. You have each event listed, but it either has a Script or None in the field. If it has none, that event does nothing. If it has a script in it, it will correspond to the appropriate script function. No need to specify what it is here.

Step 4: General Settings

The GeneralSettings folder will contain a few XML Files to work with:

Settings.XML which will contain all the information on the General Settings pane option in the editor.
TextParser.XML will contain the list of Text Parser items within it.
I think you get the idea, but for completions sake:
LipSync.xml
Dialogs.xml
GlobalVariables.xml

Again, these files will be iterated through when the game is compiled.

Step 5: Rooms

Room scripts will be found in the scripts folder. Each room Script will have its own subfolder called Room# corresponding to the appropriate room Number.

Again, there will be an XML file in the room directory though, that will contain all the room properties and such. However, each room folder will also contain the following sub-folders:

BGScenes  - For all the Background animations it will have.
WalkBehinds - With all the Walk behinds images in it.
Regions  -  Ditto
Hotspots  - Ditto

And each of those folders will also contain XML Files describing the details of those items, for example: Description, name and event procedures.


This is just a preliminary organization for a stand alone compiler. Again, there are some great benefits to this as it would allow an easy interaction editor implementation if we wanted to add one. It would offer a way to edit the game source via a text editor and our own apps. It can allow any of us to create our editors, even ones that are supported on other Operating systems other than Windows. Its just a thought. What are yours?

[BigMc]

I'd think a better strategy would be to make the Editor cross-platform first. Then making sure the GUI is sufficiently separated from the rest shouldn't be difficult. If sonneveld is right, making the Editor cross-platform is mostly a matter of splitting up ags.native into its C# and C++ parts (see http://www.adventuregamestudio.co.uk/yabb/index.php?topic=45990.0). He says he made some progress with that, but he didn't make that code public yet.

EDIT: After looking at your text some more it seems like what you want is to change the AGS project format rather than having a compiler. I agree that this is desirable.

[Joseph DiPerla]

Yes and no to your edited comment. What I was looking more to do was what Calin said in that post:

I would argue against P/Invoke since it tends to be hacky at best in a cross-platform environment.

A better model would be to have the AGS editor as an IDE for an AGS source tree. Then the IDE just saves the source tree to disk and then invokes the compiler as a separate binary exactly how something like Eclipse + gcc might work.

This is infinitely more portable and allows us to deal with each element of the AGS source independently (IDE, Compiler, Runtime)

And to achieve what you also mentioned:

In the moment I'm mainly interested in a command line compiler for Linux to make it possible to add open source AGS games to Linux distributions

In fact, when you look at IDE projects like Dev C++ or Eclipse, they use GCC, or the visual c++ or other compilers to compile their projects. Doing so (Seperating the IDE and the compiler) allows them to port their ide's to other platforms.