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

[Monsieur OUXX]

Right, Clarvalon has released an exporter to Xage (with source, apparently) which might be a good place to start.

True! I forgot about that. Brilliant! Damn, at the moment I work at a very restrictive company (and I have very very long days of work so I have almost zero free time once I'm at home). I can absolutely not toy around with any of that. #frustration

I would strongly suggest to start orienting the amount of energy spent on MonoAGS onto the packaging part, so that a non-hardcore developers community has a chance to slowly emerge.

[Clarvalon]

Bit late to this thread but there's a frightening amount in it that's directly related to what I've been working on, especially in the last six months.  It seems like there's a lot of common ground between MonoAGS and XAGE, so thought I'd chip in.  I tend to neglect my development blog, so apologies for linking to so many individual tweets:

OpenTK:  Not sure I'd recommend this as the back end.  MonoGame previously used it but instead switched to SDL2, at least for the desktop platforms (following in FNA's footsteps) as it is better supported and more actively developed.  That's my layman understanding anyway.

ProtoBuild:  I stopped using this due to lack of .NET core support.  It's planned but I didn't want to wait.  Besides, the new .csproj options, where items are included by default, somewhat negates the need for protobuild as it's fairly trivial to automatically create the .sln and .csproj files you need.

C#:  XAGE automatically creates and updates a bunch of back end base classes - some are static wrappers to the engine via an interface and the rest are dynamically created based on the game project.  The Editor can then automatically create or jump to the C# methods that act as your game events.  I've illustrated this process via a clunky .gif here.  There are some workarounds under the hood as C# script is somewhat stricter than AGSScript, but from an end-user point of view it can feel pretty familiar to AGS depending on your engine API.

.NET Core:  The introduction of .NET Standard 2.0 massively improved the core landscape.  Ethan Lee's MonoKickstart bundler for Linux & Mac seemed to work fine, but getting mono to play nicely with mkbundle, to create standalone executables, was a nightmare.  Eliminating Mono is nice and being able to use dotnet publish seems to work pretty well.

IDEs:  Seems strange for anyone to get hung up on Visual Studio, given the Community Edition is free for small teams and hobbyists.  As per above, you can create an interface between an editor and Visual Studio without too much work.  Maybe it's because the minimum download size is large.  There are also other IDEs that are compatible with .NET Core, as mentioned, Visual Studio Code which is also cross platform.

Protobuf:  Good choice - it is very good for engine game state serialization.  Much faster than everything else I've tried.  Here's an old comparison with XML.

Dear ImGui:  Second the vote for this - it's extremely easy to use.  I recently plugged this into the debug build of XAGE.  There's a nice C# wrapper here that is MonoGame and FNA friendly.

AGS.Plugin.ExportToXAGE.dll  Recently I was kindly given the source to an AGS game that uses runtime plugins, the first time I've encountered this.  As a result, I've been making some recent changes to this editor plugin.  The code in the original thread is quite old.  I could provide a more recent version, though it's a bit messy as it uses remote links to classes in other projects.

[tzachs]

It seems like there's a lot of common ground between MonoAGS and XAGE, so thought I'd chip in.

Hehe, yes, I remember reading your blog ages ago and thinking "wow, this is very close to what I wanted to do too". In fact, one of the reasons I didn't start working on MonoAGS sooner was because I was waiting for Xage (and one of the reasons I eventually started working on MonoAGS was because I thought that Xage was abandoned).
Judging from the recent tweets you linked here it looks pretty sweet.

OpenTK:  Not sure I'd recommend this as the back end.  MonoGame previously used it but instead switched to SDL2, at least for the desktop platforms (following in FNA's footsteps) as it is better supported and more actively developed.  That's my layman understanding anyway.

When MonoGame made the decision to drop OpenTK it was when there was a big drama in OpenTK- the main maintainer left the project and it seemed like OpenTK was going to die. As it turns out, it didn't, other people came and took over, and it's very actively maintained now. Btw, from what I remember reading at the time, they switched to SDL2 for window and input, but they stuck with OpenGL and OpenAL and just wrote their own bindings instead of OpenTK.

There are also other IDEs that are compatible with .NET Core, as mentioned, Visual Studio Code which is also cross platform.

I'm a big fan of VS Code, and yes, it supports dotnet core for development, the problem with it however is that it doesn't support c# for writing extensions, only Typescript/Javascript. So it doesn't look like I'll be able to bundle my editor with VS Code. Note: there's WebSharp that looked like it could be promising in terms of maybe compiling c# for Electron and then perhaps it is possible to write extensions for VS Code, but it hasn't been touched in a few months so I'm afraid it was abandoned.

Protobuf:  Good choice - it is very good for engine game state serialization.  Much faster than everything else I've tried.

Yes, I chose protobuf for both speed and good support for backwards compatibility. Btw, if speed is what your after, rumors has it that Cap'n Proto is even faster the protobuf.

[Monsieur OUXX]

Guys, thanks for all the feedback above. Lots of accurate things to move the discussion forward.

However there's one point that seems to be continuously misunderstood, which is Visual Studio. I'll say it more time : it does not matter if it's free (money-wise) when it's not legally redistributable, it makes it unsuitable for a packaged AGS. VS Code is not brandable nor redistributable either.

recap one more time :  a potential IDE must be :

- free (money-wise = zero dollars)
- free (license = you can do a commercial use of the game you make, you can extend the source code, and you can add the AGS logo on the IDE)
- legally redistributable (you can host it ont he AGS website and you can allow to copy it around)
- OPTIONAL BUT HIGHLY WANTED : portable (as in "no installer required")
- OPTIONAL BUT HIGHLY WANTED : lightweight (less than 50MB all included, no separate download/install required beforehand -- in AGS you'd need the .Net Framework, but everyone usually already has it)

SharpDevelop is all of that, VS is not, VS Code is not -- that's is why I'd like someone to explain why ChamberOfFear said it's outdated.

[eri0o]

Monodevelop is redistributable, isn't?

[Monsieur OUXX]

Monodevelop is redistributable, isn't?

Yup, it's a mix of LGPL and MIT license. Alsoif I understand correctly it would still be c ompatible with .Net Core (if only using this http://lastexitcode.com/projects/MonoDevelopDnxAddin/ , or natively )

[tzachs]

VS Code is not brandable nor redistributable either.

Why not? It's open-source and released under the MIT license.

SharpDevelop is all of that, VS is not, VS Code is not -- that's is why I'd like someone to explain why ChamberOfFear said it's outdated.

I think you missed my earlier comment on this- it's Windows only which is a deal-breaker. And also, this.

[Monsieur OUXX]

VS Code is not brandable nor redistributable either.

Why not? It's open-source and released under the MIT license.

I don't think so; I think they made it misleading on purpose : https://github.com/Microsoft/vscode/issues/17996
It's written here and there on the Internet that the source code is MIT, but that the EULA states that the use of the software is still licensed, whatever that means.


If it turns out that VSCode is indeed free in every way, then it can become a good candidate. But some effort still needs to be put asap into packaging the thing with MonoAGS, which could be far from trivial.

[ChamberOfFear]

I don't think so; I think they made it misleading on purpose : https://github.com/Microsoft/vscode/issues/17996
It's written here and there on the Internet that the source code is MIT, but that the EULA states that the use of the software is still licensed, whatever that means.

If it turns out that VSCode is indeed free in every way, then it can become a good candidate. But some effort still needs to be put asap into packaging the thing with MonoAGS, which could be far from trivial.

I wish I had more time to engross myself in this, but I'm just going to comment this one thing. Doesn't the second post in the issue you linked to contradict your conclusion? In fact, it looks like VS Code meets most of your criterieas, even the one with rebranding (looks like it was designed to meet these criteria), as long as we build it ourselves, which we were going to have to do anyway if we want the blue cup. https://github.com/Microsoft/vscode/issues/17996#issuecomment-273994925

For it to be a viable candidate we'll still need to figure out how to bundle the C# plugin with it of course, and a compiler still has to be included.

Edit:
It looks like plugins can be bundled fairly easy assuming we're using an installer, we'd just have to install them to their designated paths https://code.visualstudio.com/docs/extensions/example-hello-world#_installing-your-extension-locally

[tzachs]

It looks like plugins can be bundled fairly easy assuming we're using an installer, we'd just have to install them to their designated paths https://code.visualstudio.com/docs/extensions/example-hello-world#_installing-your-extension-locally

That's cool, however I'm less concerned with how to bundle the plugin, I'm more concerned about how to write it. As VS Code only supports writing your extension in TS/JS it means we either need to figure out how to compile c# to js (there are some solutions but I'm very skeptic regarding their completeness) or do it IPC which I'm afraid will be too slow (unless maybe we duplicate the entire render loop in js which might be a big burden on maintenance). A third possibility might be to fork VS Code, and run c# from Electron directly, but I'm also a little bit skeptic about this.
Another problem is that apparently Electron doesn't work with OpenGL currently, so we'll also need to write a WebGL backend (which might not be too bad, considered doing it eventually anyway for supporting WebAssembly).
I personally prefer VS Code to MonoDevelop, but VS Code looks to be much harder to do in practice.

[ChamberOfFear]

I'm sorry but you completely lost me. Why does it matter that extensions are written in JS? Why do we need to compile C# to JS? I don't understand what use-case you're trying to solve.

[tzachs]

For example, I want to run the room designer in a tabbed document window in VS Code. The room designer itself will be written in c#, using components from the engine & API (both c#) and rendering the actual c# game code in the window.

[ChamberOfFear]

I see, that's interesting. In that case wouldn't a C# to JS transpiler be sufficient? Bridge.NET looks very professional and complete, I'm not sure if the license allows us to use it, don't feel like reading it from top to bottom.

• Homepage
• Source code
• License

[tzachs]

Right, Bridge.NET is one of the solutions I mentioned which I'm skeptic about. My concern with Bridge.NET is that it directly transpiles c# to JS, it doesn't compile the generated IL, meaning all the dependencies will need to be compiled as well, and some of them do IL injection, so not sure what the solution there would be.

Either JSIL or WebSharp look like a more appropriate solutions but both look abandoned. I suspect both are abandoned because WebAssembly makes it all obsolete. Both Mono and .Net Core have in progress ports to WebAssembly, and as Electron supports WebAssembly this might be a good solution for the future, but probably not viable for now.

[eri0o]

Just a reminder you can just do what Unity does and have the thing you write code separated from the rest - this is also how working with Chrome/Firefox developer tools with VSCode works, and I think with Unreal too. People seem to be OK with this - I know in the past we used to have IDEs but not doing it looks to me more maintainable. Also think about a package manager (you can use one that already exists) to share scripts.

[Monsieur OUXX]

Doesn't the second post in the issue you linked to contradict your conclusion?

Maybe. The thing is that I wrote this message in a work environment where I couldn't open the link that I linked; I could only read its summary in Google. But the day before I did read several posts in several websites on the Internet, stating that VS Code is a "fake" free software. Anyways that settles it. "Really" MIT = OK for our purposes. Carry on

Unity, Unreal engine

eri0o I fel like there is an ongoing misunderstanding about Unity and Unreal : I've stated several times that those are not suitable for our purposes for licensing reasons. But you keep posting about them. Unless we decide that AGS should be a Unity plugin and that AGS games will have forever the splash screen/watermark "made with free Unity".

I'm asking again : what's wrong with SharpDevelop?

[eri0o]

I think you are misunderstanding: those are good pieces of software, I am not saying to build AGS on top of any commercial engine, I am saying LOOK AT HOW THEY SOLVE THE EXACT SAME PROBLEMS, and take a note. Seriously.

I have absolutely no idea why you don't look commercial engines up considering considering they have history - not for building on top, taking inspiration, and they have open bits (or are completely open), either on github or bitbucket. I know that I will stay on AGS and migrate to a better maintained engine if the "replacement" is just New Mistakes Edition. It's completely not fun being in middle of development and have your engine swept away.

[tzachs]

Just a reminder you can just do what Unity does and have the thing you write code separated from the rest - this is also how working with Chrome/Firefox developer tools with VSCode works, and I think with Unreal too. People seem to be OK with this - I know in the past we used to have IDEs but not doing it looks to me more maintainable.

So, as I said earlier:

I'm hoping to distribute the editor in several flavors: the standalone version will come bundled with the dotnet cli but without any IDE. Like persn said, you'd be able to use pretty much any ide you want (you can program in notepad if that's what you want) with that. That's pretty much the equivalent for unity. Other flavors would be as IDE add-ins, and I'm planning to target Visual Studio and MonoDevelop (hopefully all flavors will share as much code as possible between them), though that's probably not going to happen for the first version (version 0.1 coming sometimes this decade to your home).

What you're saying here is basically what I planned for the first release.

However, for people who don't have a particular favorite IDE they want to work with I think that having everything built in the same product provides for a better seamless experience (especially if you're working from a single monitor- I wrote some unity games and switching between the applications on my laptop was super annoying). The fact that unity and a lot of other engines aren't doing something like this is indeed alarming and a cause of concern regarding how maintainable it is. I still want to try and see for myself if I can make this work, and then evaluate maintainability concerns.

Also think about a package manager (you can use one that already exists) to share scripts.

I'm using standard c#, so nuget or paket should both work fine.

I'm asking again : what's wrong with SharpDevelop?

Seriously? I've answered this (twice). Any reason for ignoring what I wrote there?

[morganw]

I'm asking again : what's wrong with SharpDevelop?

Supported operating systems: Windows Vista and later

Plus it looks like there are issues going past C# 5.
http://community.sharpdevelop.net/forums/t/22341.aspx
I wanted to use it at work to avoid Visual Studio licensing, but existing code was already using features of C# 6.

[Monsieur OUXX]

I'm asking again : what's wrong with SharpDevelop?

Seriously? I've answered this (twice). Any reason for ignoring what I wrote there?

I've missed it (twice). Now I see it.

@eri0o : it wasn't clear to me that you were just mentionning Unity for its features, not as a candidate for AGS 5 underlying tech. When I started this "comparison of engines" thread I should have been more specific : comparison of strengths and flaws of technologies that might become the underlying tech for AGS 5.

I know that Crimson Wizard is interested in a top-down approach (features first) -- aparently, so do you. I started this thread with a bottom-up approach on mind (tech first). Let's meet halfway.