AGVS

Started by goodohman, Fri 05/11/2010 03:15:38

Previous topic - Next topic

goodohman

Hello to everybody and CJ in particular!
Since my question involves many aspects, I decided to start a new thread.
How about if instead of squeezing more and more functionality out of AGS scripting, we could go the other way around, i.e. have the AGS as a .NET plugin that can be incorporated in VS for example (that's why AGVS). This way, every room can be some sort of a "Form" (or other GUI container) and all the power of C# and .NET for example can be available immediately.
Is it possible, and what, actually prevents you from doing so?

TIA!

Calin Leafshade

It's an interesting idea, and perfectly possible.

since VSExpress is freely available it would actually be excellent.

However it would essentially mean rewriting *a lot* of stuff.

I do like the idea though.

RickJ

Hmmm, so you are suggesting to use VS IDE  to write C# instead of using the AGS IDE to write AGS script and the resulting code would then be executed by the .NET runtime instead of the the AGS runtime.  Am I missing something?

Calin Leafshade

no the idea is to use VS to compile AGS script.

VS supports a multitude of languages as essentially plugins

Although now i think about it i'm not 100% sure if the express version supports that functionality.


RickJ

I understood the OP to say that C# could be used to overcome the limitations of AGS script.  Since the AGS runtime  doesn't execute C# then it can only be assumed that .net and/or mono would serve as the runtime.

Calin Leafshade

On re-reading I think you are right... dunno why I thought otherwise.

OP: So essentially what you are suggesting is XNA?

GarageGothic

Qt support C# scripting, doesn't it? Though I'm not sure how well it supports 3D (which, let's face it, will be a part of future AGS eventually).

RickJ

QT has cross platform 2D, 3D, Multimedia, plug-in, network, etc.  I think it would make a good candidate for the basis of an eventual open source runtime.  It would also deserve consideration if the editor is ever recast in C++.  There is also C# bindings  for QT which may also be useful.

http://sourceforge.net/projects/qt-sharp/
http://qt.nokia.com/products/

cat

The problem is that everyone will need a VS license and plugin support is only available from Standard Edition upwards (afaik, not sure if it's still true for the last version)

goodohman


Wow,
Thanks for all the replies and interest.
Well, I was originally thinking of C# (.NET) as the runtime, but "only" using VS as the editor is a superb idea as well.
As to runtime, it can be mono as well, if we don't want to be limited to "evil microsoft".
The editor then can be one of the free popular editors used with mono, I don't know, eclipse maybe? I think it freely supports plugins or so.
But again, yes, it's also the power of existing ultra sophisticated predefined classes in the .NET (or mono) libs, something which being without, seems like almost reinventing the wheel in so many ways with every new AGS extension and plugin out there.
I guess that a comparison to XNA is fair enough, although as I see it XNA puts a lot of stress on being a multiplayer RPG while AGS is basically A.G. - but the borders of course can blur quite easily.

So.. what's the verdict of the 12 monkeys?

Sslaxx

Stuart "Sslaxx" Moore.

tzachs


Clarvalon

Very interesting thread.  I'd had plans for something similar for XAGE, to allow scripting at a much lower level (i.e. let people wire in their own C# code rather than be limited to XAGE's Script/Action system).

I'd assumed that it likely wasn't possible on the xbox or any platforms relying on the compact framework, due to a lack of System.Reflection, but it appears I was wrong.

Quote from: goodohman on Fri 05/11/2010 22:15:57
Well, I was originally thinking of C# (.NET) as the runtime, but "only" using VS as the editor is a superb idea as well.

If you used Visual Studio alone then you'd lose all the carefully packaged benefits of AGS Editor.  Creating a walking animation without a GUI is not a lot of fun.

QuoteI guess that a comparison to XNA is fair enough, although as I see it XNA puts a lot of stress on being a multiplayer RPG while AGS is basically A.G. - but the borders of course can blur quite easily.

... huh?  XNA isn't a dedicated RPG maker.  You can make pretty much anything*.

* As long as it has zombies, avatars and some sort of massage functionality.
XAGE - Cross-Platform Adventure Game Engine (alpha)

monkey0506

Unless I'm mistaken, isn't everything in XBLA made with XNA? And I have to agree with clarvalon that porting AGS entirely to VS would essentially either rid us of the basic features that make AGS what it is, or otherwise they would have to be manually rewritten from scratch, and it wouldn't be AGS anymore anyway.

Calin Leafshade

No only the things in the indie section are made with XNA.

The rest of the XBLA stuff is made with much more low-level tools although I'm sure its possible for some of the titles there to be XNA (Super meat boy and the like)

monkey0506

Well there's a lot, a lot, a lot of titles there (in the Indie section) that aren't RPGs..so I don't really get that. But, I've never looked at XNA, so it's possible that the framework just easily lends itself to such.

Clarvalon

I've spent some time with this today and have a working design that integrates C# Scripting with XAGE Editor.  Obviously the below is specific to my engine but it should be possible to do something similar with AGS, should anyone want to.

Note that this solution is quite basic at the moment, and the the project build stuff isn't yet implemented.  However I've coded a quick manual mockup and it seems to work a treat.




1)  Editor Application

We have a small game, MyTestGame that is structured as follows:



We have big ideas for the DoSomething script (read: function) and want to implement it in C#.  For this we get the editor to invisibly create, compile and delete a C# library project using MSBuild, in order to produce MyTestGame.dll.

The base class in MyTestGame.dll is as follows:

Code: ags
// Automatically generated class based on game content
// Created & compiled within XAGE Editor using MSBUILD to produce MyTestGame.dll
namespace MyTestGame
{    
    public class AutogenGame
    {
        // Passed in by engine - our actual game runtime data
        public static GameContent GC;

        // Create links to each room/scripts for our engine
        public Room_GLOBAL room_GLOBAL;
        public Room_Shop room_Shop;

        // Constructors - instantiated dynamically by the engine
        public AutogenGame() { }
        public AutogenGame(GameContent gameContent)
        {
            GC = gameContent;
        }

        // Called once Rooms have been instantiated by our custom script
        // So now we can populate each room's objects
        public void SetupAllRooms()
        {
            room_GLOBAL.Setup(GC);
            room_Shop.Setup(GC);
        }
    }
}


And each individual room in the game gets its own class generated, e.g.:

Code: ags
namespace MyTestGame
{
    /// Automatically generated class based on given room
    public class Room_GLOBAL
    {
        // Create individual refs for all our room items (for direct access in our custom c# scripts)
        public GObject Hero;
        public GObject Monkey;

        // Once room has been instantiated we can initialise the room's items
        public void Setup(GameContent gc)
        {
            // populate our refs from our actual runtime gamecontent
            Hero = gc.GETObjCharFAST("GLOBAL", "Hero");
            Monkey = gc.GETObjCharFAST("GLOBAL", "Monkey");
        }

        // Create virtual methods for each function we want to implement in our custom C# project
        public virtual string DoSomething()  { return null; }
    }
}



2)  Custom C# Script Project

We can then create our own C# project to house our scripts.  This project references MyTestGame.dll so that we can override the methods we want to implement, and directly reference the room items by name.  For example, our base class would inherit from AutogenGame:

Code: ags
namespace MyTestGame.CustomScript
{
    public class CSharpScript : MyTestGame.AutogenGame
    {
        // Takes the ACTUAL runtime game structure as a constructor
        public CSharpScript(GameContent GameContent) : base(GameContent)
        {
            // We need to instantiate each room here
            room_GLOBAL = new Room_GLOBAL();
            room_Shop = new Room_Shop();

            // Now finish initialisation (Autogen)
            SetupAllRooms();
        }
    }
}


And likewise we'd create new room classes to inherit from each generated room class:

Code: ags
namespace MyTestGame.CustomScript
{
    public class Room_GLOBAL : MyTestGame.Room_GLOBAL // Could instead use an interface to ensure all room scripts are implemented
    {
        public override string DoSomething()
        {
            return "This is from my custom C# scripting project!  My name is " + Hero.id;
        }
    }
}


This project creates MyTestGame.CustomScript.dll, which we dynamically load in our engine during runtime.


3)  Game Engine

On initialisation we load our new custom script dll (I'm not exactly sure how this would be implemented in C++, though I understand the AGS runtime has robust plugin support):

Code: ags
Assembly dynamicScript = Assembly.Load("MyTestGame.CustomScript");
Object dynamicScriptObject = dynamicScript.CreateInstance("MyTestGame.CustomScript.CSharpScript", false, BindingFlags.Default, null, new object[] { GC }, System.Globalization.CultureInfo.CurrentCulture, null);
Type dynamicScriptType = dynamicScriptObject.GetType();


Which we can use to fire off our C# scripts as follows:

Code: ags
public Object InvokeRoomScript(string roomID, string scriptID)
{
    // Get the Room Instance from our custom C# Script
    FieldInfo roomField = dynamicScriptType.GetField("room_" + roomID);
    Object roomInstance = roomField.GetValue(dynamicScriptObject);
    Type roomType = roomInstance.GetType();
            
    // Invoke the Custom Script (overriden method)
    Object returnValue = (string)roomType.InvokeMember(scriptID, bindingFlags.InvokeMethod, System.Type.DefaultBinder, roomInstance, new object[] { });
    return returnValue;
}
 
e.g.:






It's still unclear at the moment whether this can ever be supported on all platforms due to limitations with mono and the compact net framework, but potentially this technique can offer more advanced coders the option to do the bulk of their scripting in C#.

The idea is that there'd be a 'refresh dll' button on the Editor that will rebuild the auto-generated code.  Visual Studio should pickup the changes to the dll, and that way one can flick between the Editor and VS and get the benefits of both. 

I hope that is of some use to somebody!
XAGE - Cross-Platform Adventure Game Engine (alpha)

goodohman

#17
Hello to all my new friends.

I am very excited from all the unexpected positive and lively response in this thread.
First some delayed response,
Monkey/Clarvalon: using a different (VS, eclipse) editor won’t rob us of AGS, and it’s not limited to text only. We can actually have all the graphics, control, etc… reproduced. In VS for example, you can have custom forms in design mode, which will actually help in a better WYSIWYG experience.

In continuum to Tzachs’s and Clarvalon’s initiatives (and to what other folks do with other languages), please let me introduce you to a cute plugin called Cesium.
It's seems like a preliminary effort to start moving things in the direction of what’s started cooking here :)
This is basically a plugin which has only one command string ret = CSDo(string cmd)
It accepts a string which includes the name of a C# script file(s), and some other optional parameters and arguments which needs to be passed to the script. It executes the script immediately, and returns anything the script returns converted to string, so you can also serialize structures, etc…
It is automatically good for .NET ver > 2, and does not need any additional SDK’s (it seems).
You DON’T have to redistribute the PluginAPIWrapper.dll with it (it’s internally embedded and extracts itself to a temporary directory when needed)
The plugin itself includes a static CSAux class with some helper functions that can be used in the C# scripts as well (I hope that future versions will also expose all of them automatically to AGS scripts).
The scripts are normal C# scripts that can be written, tested and executed in VS or any other tool you have, and so you can also continue testing the AGS game (even only the .EXE) and debug/change the scripts concurrently.
The life cycle of the C# is only until it finishes execution, but I hope future versions should also have the option to retain or even switch to different contexts. As to “production”, I believe that all scripts can be compiled into one .dll and be called from there.

Attached is an example AGS game and Aloha.CSX C# script (just click the key)

The plugin would like to say thanks to Smiley’s AGS Plugin API for C#, and to Delay’s CSI code.

The plugin would also like to ask CJ to expose the game’s members or at least the managed members to complete a true C# capability, and to ask whoever deals with the editor to maybe allow embedded keywords to use in editor c# scripting, maybe something on the lines of:
#Cesium [param1, param2, …, switches.. etc…]
   Cs_func(param1,…
#End

Parameters for the cmd argument:
(CodeFile)+ (-d DEFINE)* (are Reference)* (-R)? (-q)? (-c)? (-a Arguments)?
(CodeFile)+      One or more C# source code files to execute (*.cs)
(-d DEFINE)*     Zero or more symbols to #define
(are Reference)*  Zero or more assembly files to reference (*.dll)
(-R)?            Optional 'references' switch to include common references
(-q)?            Optional 'quiet' switch to suppress unnecessary output
(-c)?            Optional 'colorless' switch to suppress output coloring
(-a Arguments)?  Zero or more optional arguments for the executing script

The list of common references included by the -R switch (depending on the used .NET ver) is:
System.dll, System.Data.dll, System.Drawing.dll, System.Windows.Forms.dll, System.Xml.dll, PresentationCore.dll, PresentationFramework.dll, WindowsBase.dll, System.Core.dll, System.Xml.Linq.dll and (independently) AGSCesium.dll itself.
Cesium’s return code is (null if it failed to execute the program or whatever value the executed program returned if it executed successfully).ToString()

Examples:
MyCSProgram.csx
ProgWithArgs.csx are System.Xml.dll -a ArgA ArgB -SomeSwitch
ProgUsingDlls.csx -d DEBUG -d TESTING â€"R
String.Format("Aloha.csx -R -a %s", name)
(the last one is the one used in the example AGS game)

I think the .csx extension because future versions can include other special directives and AGS commands.

(p.s. Cesium, I guess because the chemical sign is Cs)



tzachs

@goodohman: your plugin seems interesting, and I will take a look later on. From first impression, it kinda looks it does the same as C# Runner (functionality wise).

@clarvalon: That's a huge addition to XAGE which will definitely make me consider using it in the future. I wonder, do you support (or intend to support) creating user controls in c# and flawlessly integrate it in the game's GUI?

SMF spam blocked by CleanTalk