AGS Awards votes close at 13:59 BST on Wednesday 07 March 2018. You've already voted, so you've got 14 days and 21 hours left to wait before voting closes!

Author Topic: Discussion on Bladecoder,MonoAGS,Adore,Escoria + MonoAGS audit  (Read 2486 times)

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.
« Last Edit: 15 Jan 2018, 21:17 by Clarvalon »
XAGE - Cross-Platform Adventure Game Engine (alpha)

tzachs

  • AGS Baker
  • Mittens Vassal
  • Parking Goat- games that goats like!
    • I can help with translating
    •  
    • tzachs worked on a game that was nominated for an AGS Award!
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

  • Cavefish
  • Mittens Vassal
  • Mittens Half Initiate
    • I can help with proof reading
    •  
    • I can help with translating
    •  
    • I can help with voice acting
    •  
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.
 

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.

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 :)
XAGE - Cross-Platform Adventure Game Engine (alpha)

Monsieur OUXX

  • Cavefish
  • Mittens Vassal
  • Mittens Half Initiate
    • I can help with proof reading
    •  
    • I can help with translating
    •  
    • I can help with voice acting
    •  
Leadership decision to take :

AGS 5 based on this? Last call?
 

You mean AGS 4?

I support it.

Monsieur OUXX

  • Cavefish
  • Mittens Vassal
  • Mittens Half Initiate
    • I can help with proof reading
    •  
    • I can help with translating
    •  
    • I can help with voice acting
    •  
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.
 

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

  • Cavefish
  • Mittens Vassal
  • Mittens Half Initiate
    • I can help with proof reading
    •  
    • I can help with translating
    •  
    • I can help with voice acting
    •  

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.
       
« Last Edit: 25 Jan 2018, 16:47 by Monsieur OUXX »
 

tzachs

  • AGS Baker
  • Mittens Vassal
  • Parking Goat- games that goats like!
    • I can help with translating
    •  
    • tzachs worked on a game that was nominated for an AGS Award!
- 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

  • Local Moderator
  • AGS Project Tracker Admins
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    •  
    • Lifetime Achievement Award Winner
    •  
    • Crimson Wizard worked on a game that was nominated for an AGS Award!
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).
« Last Edit: 06 Feb 2018, 15:07 by Crimson Wizard »

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.
XAGE - Cross-Platform Adventure Game Engine (alpha)

Crimson Wizard

  • Local Moderator
  • AGS Project Tracker Admins
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    •  
    • Lifetime Achievement Award Winner
    •  
    • Crimson Wizard worked on a game that was nominated for an AGS Award!
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.
« Last Edit: 07 Feb 2018, 14:26 by Crimson Wizard »