Topic: Discussion on Bladecoder,MonoAGS,Adore,Escoria + MonoAGS audit

[Clarvalon]

I personally prefer VS Code to MonoDevelop, but VS Code looks to be much harder to do in practice.

As a quick proof of concept I hooked up VS Code (running in 'Zen Mode' to hide some of the UI elements) to the main panel and was able to debug my C# game solution directly within my editor.



I can absolutely see the appeal of this approach, preventing the need to switch between applications (in my case, XAGE Editor and Visual Studio) as well as reducing the initial download size.  However it's only really useful if:

• VS Code can be customised and bundled without limit.  EDIT:  Looks like it's MIT license if you build it yourself.
• It's possible to better hide the VS Code UI (i.e. suppress shortcuts) so it feels like one application rather than two glued together.
• Some of the VS Code limitations can be worked around - for instance, it doesn't seem to be performing incremental builds for some reason, so it's a bit slower than Visual Studio to start the debugger.

A better, but far more complex approach, would be to rip out the code editor and debugger and integrate it properly.  Sounds like a lot of work though.

[tzachs]

Oooh, very interesting! I haven't considered hosting VS Code inside my own editor (I thought of doing the opposite), but that might be a viable alternative as well.

[Monsieur OUXX]

The more "external" code/tools/graphical elements you can embed in the game, the more development tools you can have for making games -- things you potentially wouldn't have thought about (graphic programming, dialogs editor, script debugger, etc.). This sounds perfect.

[ChamberOfFear]

It's possible to better hide the VS Code UI (i.e. suppress shortcuts) so it feels like one application rather than two glued together

Yeah, it's possible. We don't even have to modify any source code as far as I can tell, just provide our own keybindings.json to suppress conflicts.

[Clarvalon]

Had another quick play with this - confirmed it's possible to override and suppress key bindings as stated, and I've been able to get it to maximize and resize nicely within the parent panel.  A dozen or so user/workspace settings can simplify the UI to a point where it all feels pretty coherent.  It's not perfect though - the main remaining issues for me are:

• I'll need a way of capturing certain keypresses from the code.exe process and handling them within the parent editor program.  For example, F5 in VS Code will launch the build task to recompile the code, when in reality we'd actually want F5 from within the Editor to make sure the assets are all up to date first (spritesheets built et al).
• Edit & Continue is not yet supported in the VS Code C# Plugin.  This is unfortunate as being able to make runtime changes, as with Visual Studio, is a big productivity gain.
• It is currently only really suitable for the desktop platform - Xamarin & UWP are not supported so you'll need to use Visual Studio anyway for those.  So it may be simpler just to stick with the existing paradigm rather than forcing the user to learn two.

I'm going to stick with Visual Studio for the time being and take a look at VS Code again once it matures further.  It's been a fun experiment at least, but I can't afford the feature creep right now

[Monsieur OUXX]

Leadership decision to take :

AGS 5 based on this? Last call?

[ChamberOfFear]

You mean AGS 4?

I support it.

[Monsieur OUXX]

You mean AGS 4?

I support it.

I said AGS 5 to avoid creating confusion with the "AGS 4" cleanup branch, but it doesn't really matter.

[morganw]

I think from all the engines in the table, MonoAGS is the only one which could function as a direct replacement (without re-scoping the whole project).

[Monsieur OUXX]

Keep them coming guys. Now is the time to take a strong decision, after the initial shock.

My own vote, on a par contributing to BladeCoder OR MonoAGS. There's a billion reasons why they're equally good from my perspective. In a nutshell: I think BladeCoder is better, but handling the Java bits (packaged distribution of the JDK) make it a pain in the neck, PLUS it doesn't have a strong impulse in the AGS community, unlike MonoAGS which is carried by tzachs and others.

Name	Vote	Reason
ChamberOfFear	MonoAGS	-
morgangw	MonoAGS	"the only one which could function as a direct replacement (without re-scoping the whole project)."
Monsieur OUXX	MonoAGS or BladeCoder (on a par)	I think BladeCoder is better, but handling the Java bits (packaged distribution of the JDK) make it a pain in the neck. MonoAGS has a strong impulse in the AGS community.

[tzachs]

- replication of known AGS functions (character.Say, etc.) -- to which extent?

I created a "cheat sheet" which compares AGS functions to MonoAGS functions: https://tzachshabtay.github.io/MonoAGS/articles/ags-cheat-sheet.html

The "cheat sheet" has 2 sections, the first compares AGS script to c#, and the second section compares the APIs (functions and properties).

I plan on maintaining this document as we add more missing APIs (or change existing APIs to make them friendlier).
Any feedback (like missing functions that you think are important to add) will be appreciated.

[Crimson Wizard]

I am not sure what this voting meant for... after all contribution is a voluntary action.

Looking at the "voting" chart Monsieur OUXX has posted, frankly neither reasons mentioned are clear enough to me.

I don't know if I can or should vote, barely being acquianted with any of the mentioned alternative engines.

I think from all the engines in the table, MonoAGS is the only one which could function as a direct replacement (without re-scoping the whole project).

TBH I think it is XAGE that rather looks like a direct replacement, even though it is not in the table.
What I mean is that scripting API stays almost the same, from the looks of it. MonoAGS, on other hand is pretty different both in terms of scripting API and optimal coding approach.


Anyway, I am currently doing experiment by porting my recent racing AGS game into MonoAGS. I specifically chose a game that does not have any adventure elements as a first step. After that I plan to try making a simple adventure game for a test.
Then I will be able to give more actual user feedback (as opposed to theoretical thoughts from programmer's perspective).

[Clarvalon]

I created a "cheat sheet" which compares AGS functions to MonoAGS functions: https://tzachshabtay.github.io/MonoAGS/articles/ags-cheat-sheet.html

This is good.  I need to do something similar and annotate my documentation which is mostly automatically generated.

One thing worth mentioning is that AGS structs support inheritance whereas C# structs do not, so classes may be a better fit if you're looking to perform automatic code conversions (although then you have to worry about things like instantiation).

A main pain point for me is AGS's somewhat lax approach to typing compared to C#'s strictness.  Things like allowing return values from functions despite not having a defined return type, and using integers to drive if statements. 

TBH I think it is XAGE that rather looks like a direct replacement, even though it is not in the table.

I think it's excluded on the basis it is not open source, which I agree is desirable if you're already working from an open source engine.

[Crimson Wizard]

A main pain point for me is AGS's somewhat lax approach to typing compared to C#'s strictness.  Things like allowing return values from functions despite not having a defined return type

That is probably done for backwards compatibility, AGS does not check for missing return operator either. The "function" keyword actually works as an alias to "int" in contemporary versions, because that is what it returns IIRC.

[morganw]

What I mean is that scripting API stays almost the same, from the looks of it. MonoAGS, on other hand is pretty different both in terms of scripting API and optimal coding approach.

I'm wondering if the workflow is similar enough that, even if the scripting API is not a directly comparable, the editing tools could be shared (or just modular enough so both sets work in the same environment). The benefits would be, easier migration to MonoAGS from AGS, a newer editor for AGS in the short term, a boost for MonoAGS in the long term.

[tzachs]

I don't think differences in workflow is the big problem here, but rather the sheer amount of work involved to have the editor speak in an additional engine format. And also, a lot of the editor features will need to be disabled/hidden as they will not be supported by current AGS (or a lot of effort will be required to modify the engine), making me doubt how useful it would be in practice, and if the perceived benefits will be worth the effort.
That said, I will be making an effort to make the editor relatively modular (separating the editing experience from the output generators, for example), so that if somebody wants to go for it, she/he will be able to do that.