Messages

Did somebody water the plant after the murder took place? (if that's true, then I'm guessing the detective somehow knew that, and then figured out the murderer dragged the victim after the plant watering, otherwise the person who came to water the plant would have seen the body and called earlier).

If not, then some more questions:
Was there something in the pot that shouldn't have been there?
Did the detective have knowledge about sunflowers and how to care for them?
Was there more than one murderer?
Is the scene the victim's apartment?

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.

AGS gets character movement and animation right. Other engines I've used move a character at 60 FPS regardless of the speed of the animation. I think this is mostly due to laziness and lack of consideration at the point of design.

I made the same "crime" at the beginning with my engine, until somebody on the chat enlightened me on this feature in AGS. It wasn't due to laziness, it was due to artistic blindness, I didn't notice the difference myself.

Also, I think it might be more flexible to have a generic object hierarchy for rooms (and scripts attach to any object). So the room is just another object and a child of a game object - potentially you can get a reference from parent to set global properties or properties in another room. I think it would be pretty easy to disguise this as the current setup (global script is on the game object, room script is on a pre-built room object with no children) so people can stick with what they know if they prefer to.

Can you expand on this? I'm not sure I completely got what you're aiming for here. Can you also explain which use-cases are you hoping to solve (or make better) with this?

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?

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.

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.

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.

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.

[OpenTK:]

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.

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

Sorry for not reading everything, but did you take a look at https://github.com/ocornut/imgui
I'm using in my project, it's a immediate mode gui that works with opengl and it's in constant update.

I did look at it. I ruled it out mainly because I'm not sure how "immediate mode" integrates well with my design. Also I remember reading about it and people were talking about it more as a "GUI prototyping tool". And finally, the sample picture on the c# binding front page didn't look appealing. On the plus side the images on the original imgui project look better, and the c# binding is actively maintained, so I will keep it in mind.

You have the several .csproj in VS and when you build, it builds them all and you trust that is the MacOS project got built successflly, then it's OK?

First of all, when I develop I rotate between developing from Mac and developing from Windows (and I'll add Linux to my rotations when support is added for that) to see that things are working well on both platforms. When I compile locally, I only compile the projects for the platform I'm testing, so I'm not compiling mobile if I don't test mobile. Once I submit a PR, the automated build kicks in which compiles for all platforms and runs the tests.

The pain usually comes later, after seveal years, when you need to let users use a different IDE/Compiler or a newer version of the original IDE. You get entangled in the many versions of VS -- well not you specifically because you know how to upgrade your csproj, but there's always someone who asks about a version that you don't own -- and you cry.
I mentionned VS but I'm perfectly aware that nowadays the VC++ restributable bullshit is gone, so don't hit back on VS. My concern can be applied to trying to compile a .csproj with any "unforeseen" IDE/compiler. That's when the automated project generation becomes a magical tool.

I don't think that's currently a problem in c# world. There are multiple IDEs, but only a single compiler (Roslyn) which everybody uses. If it will become a problem, I will re-evaluate.

the statement "you could virtually make your game in Notepad" is not acceptable, but it's always something that's very hard to hear for developers. I could virtually make my AGS game in Notepad just by writing XML.

Perhaps notepad was a bad example, but the point here is that while you can write your AGS game with XML on notepad, you can't debug it without the AGS editor, you don't have intellisense, code navigation, etc, without the AGS editor. With MonoAGS you can do all that without the editor, and you'll be able to do that no matter which flavor of the editor you install. Now, this wasn't meant as an answer to your specific concerns, this is obviously not a solution to a lot of people who want something built in. But it is very important to a lot of people who already have their favorite IDEs/tools and want to stick with it.

The fact that the game designer can carry around his CLI tools is not an answer either. He/she wants to press "play", not type command line commands to run compilation.

Sorry for not being clear, you'll have a "play" button in the standalone version which will run the cli tools.

For now, MonoDevelop addresses these criteria, I believe, but is available from source only (!) and is apparently complex to turn into a portable installation. I'm not surprised that the Unity guys managed to do it, and make it seem easy, but they have way more time and money to achieve miracles

If MonoDevelop doesn't pan out, then I'll search for alternatives, or worst case (don't want to go there, but it's always an option) build my own.
Btw, apparently unity are now shipping with Visual Studio instead of MonoDevelop. So maybe it is possible to bundle with Visual Studio (or maybe Unity and Microsoft made a deal, I don't know).

qptain_Nemo told me that MonoAGS most likely will run on Arch Linux ARM too.

I hope? I saw that dotnet core supports Arch Linux, don't know about Arch Linux ARM.

@tzachs Any reason why you don't use Monogame as the "middleware" that other point-n-click engines use? (see initial table). It has recently switched to .Net Core and it has the most permissive Microsoft license. I know it was mentionned before but we never elaborated. It might not be too late.

When I first started development, MonoAGS was a very strong candidate for a backend. I started installing the framework, but I remember the instructions were very confusing for me, and I don't remember if ever got it to work. I remember thinking "yeah, it's not going to fly with non-programmers". Also MonoGame (or any complete game engine) brings with it a lot of baggage, dependencies, opinions and quirks that restrict my own design. Not using it gives me more freedom. However, I'm not ruling out looking into integrating with MonoGame as an optional backend (same goes for Unity, btw).

The fact of mentionning SharpDevelop as an option for the IDE suggests that not being really up to date with the .NET eco system.

@ChamberOfFear Can you explain how? Which specific point do I misunderstand? Is it only compatible with "traditional" .Net Framework? Is it compatible with Mono? Is it compatible with .Net Core? Is it out of support? Etc. It's free, portable, lightweight, under MIT license, and specfically targetted at C#, so it makes it a very appealing candidate.

From what I can gather from their Github page, SharpDevelop is Windows only.

Other question : do you use tools such as mkbundle or Monokickstart to bundle Mono in the current version of MonoAGS?

No work was done regarding deployment yet, so no. Also, as I plan on removing Mono, most likely I will not use those.

This is aimed at explaining once and for all what I mean every time I try to express some concerns regarding what I sometimes call "vector abilities", sometimes "3D geometry", sometimes "subpixel transformations", etc.

Ah, great explanation, thanks!
Yes, it's a valid concern against OpenGL which I was not really aware of. I'll need to study it more.

By game production pipeline I meant that the work of the project leader, game designer, artists and scripter don't overlap.
Here is how they sometimes overlap in AGS :
- Every time you add a sprite or a room, it modifies game.agf or some other central set of files. Conflicts cannot be resolved easily.

So that's another reason for me to switch to dotnet core, their csproj supports globbing patterns so you don't have to specify specific files that are included in the project (it's possible that mono supports the new csproj too now, btw, not sure). Besides the csproj there's nothing else so there would be no conflict here.

- If a sprite changes on the file system, you have to reimport it --> you have addressed that. (by the way, make sure that room backgrounds are not managed separately -- AGS keeps them in a black box, unlike sprites)

Room background is not separate. All assets are treated the same (at least when developing): files in the file system.

- if you add or remove a sound, it creates its corresponding name in the script. It breaks compilation if you remove the sound. (the sound artist's work conflicts with the scripter's work)

Hmmmm, that's a touchy subject. I understand your concern, but on the other hand named assets are also important for intellisense and avoiding typos. It's currently not a problem but it might be when I develop the editor- I'll think about how to address that when I get there.

About the GUI : I strongly recommend that you use a thirs-party library, and that you don't implement GUIs yourself! Home-made GUIs are the plague of many game frameworks. There's always a moment when scripters want to extend the behaviour or aspect of a GUI control, and then they can't because they can't hook on the controler events or graphical containers, or can't make sense of the rendering flow. And then you will have to carry that weight. Have you ought about GTK?

Yes, I thought about GTK# among others. I have two problems with that:
1. I want to be able to have the GUIs as part of the world, meaning I need to control when and where to render it with OpenGL. So that pretty much rules out all GUI libraries that are not OpenGL based. The best GUI framework I found for OpenGL is nanogui, which I still consider my fallback plan if my current plan doesn't work as I want. The problem with that is nanogui's c# binding looks abandoned which means that I'll need to maintain the binding myself, plus get a deep understanding of nanogui workings and I tend to believe that the weight this will carry on me is not smaller then have my own framework in place. And also, this doesn't solve my second problem...
2. So, what Crimson Wizard said here:

Now, at any point in time you add CanBeOnGUI behavior, and boom, character becomes a GUI element, while retaining everything else, walks among the buttons and talks to labels.

I'll basically lose this ability for GUIs if I follow that route. The fact that GUIs in the engine are treated the same as all other objects and can be manipulated the same, I feel that's a great power for the engine to have.

Therefore, be careful with "anonymous" fields used by Protobufs/Protocontract.

Just to be clear here, protobuf is just used for the saved games file format, that's it.

I suggest even more than previously the use of automatic solution generation, since I saw that you have one .sln file per target platform.

mmm, no? I only have one sln file. Are you talking perhaps about the csproj files? I have a csproj file per platform, not a sln file per platform. I'll have to read about cmake for c# more, I'm kind of hesitant because I didn't see any c# project actually using it yet (but maybe it's because it's new, based on your link). There's a known solution for the multiple projects per platform in the c# world: Protobuild- it's used by both MonoGame and Xage, so I'm more inclined to use it. However I'm still not convinced that the added dependency (be it protobuild or cmake or something else) and the cost that goes with it is worth the multiple projects "pain", maybe it's because I haven't experienced that pain yet, currently I kind of like that clean separation between projects. Also protobuild does not currently support dotnet core as far as I know- I did want to play with it at some point to gain a better understanding of the benefits, but I don't consider this a priority. If another contributor will come and want to add something like that, I'll probably not going to stop her/him though (except for the dotnet core issue...).

- I'm kinda worried that there are platform-dependent wrappers for every core feature, such as drawing, input, etc. Isn't that managed by OpenTK? Or is it only some "transparent" wrapping meant for some basic C# trick (make advantage of interfaces or whatnot)?

For graphics rendering, OpenTK supplies OpenGL bindings and OpenGL ES bindings. Those are not the same unfortunately. So I have 2 implementations of "IGraphicsBackend", the OpenGL one is used by desktop (Windows, Mac and Linux), and the OpenGLES one is used by Android & IOS. And I'll probably need yet another implementation when I add UWP (xbox and windows store) which will either be DirectX or Angle. For input, OpenTK handles it cross-platform for desktops but not for mobile: I use the xamarin APIs which are native representations of the android and ios APIs, but they are not the same. I might switch in the future if I find something.
For bitmap and text rendering, I also currently have 3 implementations (desktop, android and ios) but I want to switch to SkiaSharp which is completely cross platform (and also gives a lot of other benefits like hardware accelerated text rendering). Currently stuck on this, btw: if somebody knows/figures out how to solve this, let me know.

- I would suggest taking the opportunity of this engine rewrite to put some distance between the absolute core point n' click engine (rooms, inventories, etc.) and the things that might be custom. Two examples from the top of my head : the hard-coded fade-in/fade out as seen in RoomEvents.cs, and the player's behaviour on Verb events as seen in Player/Approach. I'm not saying you should kill all that, I'm just suggesting that you imagine what could be this "less hard-coded layer of code", and that you move those things there after creating the required event hooks in the core.

Yes, I'm discussing solutions with Crimson Wizard. However... rooms are not adventure game specific? Room = Scene, and every game engine on the planet (I think) have this concept. The "OnBeforeFadeIn/OnAfterFadeIn" events for moving in/out between scenes is also generic and not adventure game specific.

- event hooks! event hooks everywhere! E.g. OnNewItemInInventory

MonoAGS has event hooks a-plenty. All lists that are marked as "IAGSBindingList" have an "OnListChanged" event which gives all the items that were added/removed from that list. Good call on the inventory items though, as I didn't change it from "IList" to "IAGSBindingList" yet, will fix.
Also, all components implement "INotifyPropertyChanged", which you can subscribe to and get events whenever any property in the component changes (this is how the inspector refreshes itself to show you whenever something changes in the game).

- Have you considered an importer for an existing AGS 3.4 project?

I suspect it's going to be crazy amount of work. If somebody else wants to work on it, that would be great. I'm not going to, though, not in the foreseeable future.

- You have re-implemented all the usual classes such as lists, dictionaries, events, trees (you're literally using C#!), point, rectangle (you're literally using OpenTK!), etc. I won't complain because everyone does it (ScummVM, etc.), but... what is it with you people?

lol, yeah, it looks bad...
My core engine library targets dotnet standard which means I can target both dotnet framework, mono or dotnet core.
OpenTK is still not officially supported with dotnet core (it's in progress), meaning that the core engine can't reference OpenTK, only the desktop engine project can reference it. So I had to copy a bunch of their classes to make it work. Once they support dotnet core I'll be able to remove those.
For drawing bitmaps, I used stuff from System.Drawing which is also not part of the dotnet standard so I had to take dotnet framework code. Once I switch to SkiaSharp I'll be able to remove those.
And finally, my binding list is not taken from c#, it's my implementation that's there for adding those hooks you mentioned earlier which don't exist in the original list implementation. And tree is also my implementation, there's no tree data structure in c#.

@tzachs, a question for you : why did you put emphass on functional languages in the docs? did you have some advantage on mind regarding the making of a game with your engine?

I don't think I did? I just listed F# as potentially the best candidate if you want to code your game using something not c#, because I know it's a dotnet implementation that is actively supported by Microsoft, and I'm not sure how actively maintained and complete other dotnet implementations are (everything else afaik is developed by the community and not sponsored by major players, I might be wrong about that).

- One big big concern: the IDE as it is now, and even if you intgrate an "editor" as an in-game GUI, the game development workflow would be to run and debug the game from within Visual Studio. Even if it's a free Visual Studio, we can't redistribute it, which means that we must tell the users to download two separate things: 1) MonoAGS, and 2) Visual Studio. For me that's a no go. Any solution would be better than that -- like swapping to SharpDevelop or MonoDevelop. An answer that comes to mind is : "no, you misunderstood, first you compile the game in visual studio but then you can distribute the unfinished game to develop it 'from within itself', as some sort of standalone Editor" --> that doesn't sound like a good solution, because then you can't change (and recompile) any custom script inside it as long as it travels outside of visual Studio.

Ok, so I guess it's time to talk about my plans for the editor (important note - everything here is subject to change and might not actually happen).
First, regarding your concern: 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). The MonoDevelop addin can be packaged together with MonoDevelop and distributed. For the visual studio flavor, yeah, you'll want to download VS first and then download the AGS extension.

Regarding what you said earlier about hard-coded verbs: the plan is for the editor to have somewhere a place to edit your list of verbs (or you'll use a game template which has the verbs pre-set). The editor will auto-generate a "Verbs.cs" file with your verbs, and the core engine itself will not have knowledge about specific verbs.

You'll also be able to edit your outfits and choose which animations are part of that outfit, those animation names will also be auto-generated to a cs file.
As for the animation editor, I plan to have a basic layout like AGS has with individual frames and live preview, but also will have a "switch to timeline" button: this will place your frames on the timeline, and you'll be able to add tweening for properties (shown on separate tracks in addition to the frames), and possibly set various blendings. And one last thing for the animation editor would be to allow for composition animations -> show the entire object tree so that you'll be able to have separate animations for the head and body (for example) and see how they work together.

For the room/scene designer, I plan the canvas to have a similar interface that InkScape has for moving/rotating/scaling objects (with grid lines/snapping for alignments etc) and for editing areas something similar to InkScape vector tools as well. In the tree view of the scene you'll be able to show/hide/lock/unlock layers or individual objects, and selecting an object will show the inspector (called "Properties Window" in AGS but the same principle, pretty much exists in all editors). From the inspector you'll be able to set values and add/remove components. You should be able to switch between "playing the room" to "editing the room" immediately (I hope), or maybe even editing while playing. You'll be able to see and edit the GUIs from the scene designer (they might not "belong" to the scene, but it's just that more convenient to see how the game will actually look from the editor). When adding a new object to the canvas you'll be able to select from various presets (object, character, button, etc): each preset is basically an entity with a specific set of components and defaults. The presets that are available for you to use will be dictated by the game template you choose, or you'll be able to create your own presets (or import from modules, etc). This is kind-of similar to prefabs in unity (but not as powerful- will probably extend this to be as powerful eventually). For each of those presets a friendly interface will be auto-generated for your coding pleasure (so you'll be able to write "character.Walk" instead of "character.GetComponent<IWalkComponent>().Walk").

For events/interactions- my observation here is that for most adventure games, most of the interactions are basically the player character says something in response for looking/interacting with an object in the room. Really, I don't think I'm exaggerating if I say that's 75% of interactions in a typical game is just that. That's why, I want first to make this as painless as possible. If you type on a object/verb combo line in the editor, it would automatically translate into player.Say(..whatever you typed..). Otherwise you'll have either the current AGS option of going straight to code, or you'll have the option to open the interaction editor. The interaction editor might be similar in some ways to what Blade Coder has. At least for the first phase, I'm not planning to have graphs with nodes a-la articy/draft, but a list of interactions with if/else branching as indented, we'll see how it goes and maybe I'll re-evaluate. The functions in the interaction editor (like the properties from the inspector, btw) will have help links directly in the editor (it will be extracted directly from the api documentation for built in functions/properties, and extracted from code attributes for external modules). You should be able to run code from the interaction editor and to run saved editor interactions from the code. Also, the interactions themselves will not be hidden, code will be generated for you so this can also be seen as a learning tool. And finally, I plan to have async/await support directly in the interaction editor. Hard to explain without a picture, but basically if you add a "Walk", for example, it will add an "await" with "walk" on the same line, but then you'll be able to drag the "await" section to its own line and put other actions between the "walk" and the "await" so you can have the character walk in parallel to other things going on in this cutscene.

Another interaction related feature I want to have is a "matrix" window. This aims to be a productivity enhancer for writing interactions in bulks and also to solve the problem of a lot of games (that drives me crazy) where the developer forgets to code all of the interactions. The matrix window will have all interactable objects + inventory items as both rows and columns. Each cell is an interaction that has to be filled. You'll have a nice "you're 64% there!" label showing you how much of the interactions are done. And you'll be able to click on each cell to edit the interaction (with any of the methods I talked about for interactions), you'll also be able to mark specific cells as "default" (which will activate that whatever "I can't do that" default interaction you configured) or as "bug: not supposed to happen" (which will also activate the default interaction but might do something else like crashing you if you debug, or send an email from a tester or whatever you set it to do on "bug"). You'll have some controls for filtering the matrix to specific rooms/only inventory/etc if it's getting too big and/or you want to focus on something specific. And finally, you'll have a "start marathon" button which will rotate between "unfilled cells" with easy shortcut keys to pass to the next interaction.

As for speech, this is also a big pain-point for me with current AGS. I still want to support the current workflow, but also have a speech control window (maybe somewhat similar to the speech center plugin), and you won't be forced to number your speech lines in the code yourself, the string itself will be the id and map to a numbered filename (or filenames for multiple localilizations), though you'll be able to override with a number for specific lines (like if you have multiple lines with the same string but need to be said differently). You'll be able to write director notes in the speech window for specific lines, and create nice looking scripts for voice actors. Also, there will be a "start marathon" button here too, you'll select a character and it will run over all of the script lines for that character and open the speech line editor. From the speech line editor you'll be able to record the voice and do basic editing. When recording you'll have keyboard shortcuts to stop this take and start a new take, and a shortcut to move to the next line. For editing you'll be able to trim beginning/end of takes, change volume/pitch/reverb. You'll be able to delete takes, and keep multiple takes (for repeating sentence where you might want some variation in how a character says a line). I still painfully remember the amount of time it took to get the independently recorded lines from the voice actor, open a big-ass audio software where all I want to do basically is select the good takes, and then do some trimming and volume adjustments, then manually exporting to files, figure out the correct filename and then needing to test it in the game to see that I completely screwed it up... This whole process took ages. Hopefully doing it all in-editor will save huge amounts of time.
Another interesting possibility here that I want to explore, is being able to open the speech line editor directly as you're playing the game. So, for editing, the game developer will be able to edit lines while playing the game which gives better context. For recording, if the voice actor is recording remotely, the game developer might prepare a few saves where the character speaks, and either instruct the voice actor what to do to get to her/his lines, or even code to directly cut to the dialogs. If the voice actor is recording with the developer in a studio, then hopefully the game developer could bring her/his laptop and hook it up to recording hardware, and switch to the saves/coded dialogs while showing the monitor to the voice actor. The goal here is that the context of the actions will be much clearer to the voice actor as the dialogs are played.

I'm going to skip various other things the editor needs (editing settings, deployments, fonts, cursors, and I maybe forgot lot of important points), but one last point I want to touch on is customizability.
There are obvious customizations you can expect, like authoring your own components and being able to edit their properties in the designer.
But more than that, as the editor will be using the same framework as the engine, it will use the same mechanisms for customizations the engine uses: meaning, almost everything should be able to be replaced if you want. You'll be able to code your own inspector if you so choose and replace the existing inspector (and then share it as a module for other developers), etc.

Overall I would like to congratulate you for how compact is your code.
Also, kudos for using async/await.

Thanks

The Editor is not part of the initial vision. It's envisionned as some sort of tool "external" to the engine, that can come after. It means there's no vision on assets management and game-creation pipeline.

The editor is a critical part of why I started my project in the first place, it's definitely part of the initial vision. My AGS development background is exclusively the editor, and I had a much clearer idea on what I wanted to do with the editor than the engine when I started.
The engine comes first because it's the core, and because I wanted it to be independent from the editor in the sense that at any time during the development you can ignore the editor completely and just stick with the engine.

Like Crimson Wizard said, I currently work on the editor as an overlay in the engine, as I want you to be able to edit rooms as you play them (i.e to remove the “edit room -> debug -> edit room -> debug” annoying loop). I don't want to talk too much about the editor currently -> I can probably go on and on about features I plan for the editor if you'll push me, but because it's very early stages and things will change greatly, I don't want to over-promise. Anyway, if you have ideas for stuff you want to see in the editor, now is a very good time, so let me know.

Regarding assets management -> That's kind of vague and can be interpreted in many different ways:
In the context of the editor the idea is to have an “explorer” view with the assets folder which will bind to the assets in the actual folders, so just by copying to the folder on your computer should automatically update the assets (though of course it will also have dedicated context menu and drag&drop support). It should also support hot-reloading the assets during the game (when debugging). 
In the context of asset bundles, packing textures, compressions, etc, that's all stuff I want to add in the future, though it's true I don't have a clear vision for this, I don't have the experience, but I definitely want to tackle that. Crimson Wizard gave me a detailed proposal that I'm going to implement in terms of making the engine easily extensible for loading different bundles from different locations. Any other feedback on this (or anything else) is welcome.
I might have completely missed your point here, because, as I said, it's vague, so let me know if you meant something else.

Regarding game-creation pipeline -> This is even more vague than assets management, so it would help if you expand on that.

It's focusing a lot on basic graphics rendering (SDL), with no vision regarding the other components, such as sound engine, controllers input, GUI, timing, etc. That's my biggest concern with many wannabe game engines: they lose steam after they manage to render the graphics of the game, but that's only 25% of the whole picture.

So first to clear the confusion a little bit, I'm currently not using SDL, but OpenTK. OpenTK has the option of taking SDL as a backend to override OpenTK's own native handling of windows, input and graphics. In theory this should give better stability and better controllers handling- so far I didn't add controller support and didn't see any stability issues related to OpenTK so I'm not using SDL, but I have the option to if the need arises.

Regarding sound engine, here's what I currently have:
- The ability to play/loop/stop/pause/resume/rewind (or seek to a specific position) sounds.
- The ability to change a sound's volume/pitch/panning (you can set it for the audio clip itself or for individual sounds played by the audio clip), including tweening.
- The ability to query a sound's state and to get all currently playing sounds for an audio clip
- The ability to asynchronously wait for a sound to finish playing
- Automatic cross-fading for music clips when switching rooms with the ability to configure fade-in/fade-out time and tween.
- A sound emitter which can be attached to a moving entity and automatically adjust the panning based on its position in the scene (i.e positional sound), and also volume changing areas, that changes the volume automatically when the emitter moves across the areas (lower volume for far away entities, etc). The sound emitter can also be configured to easily play sounds on specific animation frames (useful for footsteps).

Here's what I don't currently have but want to add (and I have a tracking issue on Github for each one of those):
- Automatically reduce volume for playing sounds when speech is playing (but allow overriding it per sound)
- Allow adding effects to sounds (like reverb) at runtime
- Support envelopes
- Support for Opus format (and other audio formats)
- Support runtime synth of sounds (midi)
- Support audio streaming

If there's more stuff you think a sound engine needs which I am not aware of please let me know.

Regarding GUIs, here's what I currently have:
- Various controls: labels, buttons, checkboxes, comboboxes (drop-downs), inventory windows, listboxes, scrolling panels, sliders, textboxes
- Layouts: stack layout and tree-view layout.
- All GUIs are basically extensions of existing entities, meaning that they can be treated just like all other entities, so you can have GUIs as part of your world, they don't have to be on top. They can also be parents of non-GUI entities and vice versa (so you can, for example, have a character walking inside a scrolling panel if you want) and you can also tween GUIs and change their position, scale, rotation and pivot points.
- Dialogs like yes/no, with the concept of focus so that dialogs can take input focus from the game.
- A proof-of-concept skinning (theming) engine for GUIs.

As to what I don't currently have, there's a ton of stuff missing, from various controls (tabs and menus come to mind immediately), responsive grid layouts, pretty built-in skins, and the existing controls themselves also might miss functionality. This is all very much in progress. The kicker here is that as I'm building the editor based on this GUI framework, assuming I'm successful you can expect that eventually I'll have a very complete GUI framework that can be easily integrated into the game world (not a lot of engines can claim that, I believe).

Again, let me know if there's more stuff you think it's missing.

Regarding timing, I'm not sure what you mean by that, please expand if you can.
Regarding controllers, yes, I currently don't support those, but plan to add eventually (though it's not a top priority currently as people can use libraries to work-around that).

It doesn't do vectors, even only just by wrapping some basic directX primitives/data structures. There are many vectors usages that you might not think about until they're missing and it's too late (graphics scaling, walkable areas, perspective, camera control, tweens, parallax, etc.).

Like Crimson Wizard, I was also confused. I originally thought you meant vector art (svg), which is currently indeed not supported (but it's actually a high priority for me). Vector areas is another thing completely which is also currently not supported (but planned). Lastly, based on the gamasutra article you linked to, I think the only thing missing to do something like that is perspective camera support, as everything automatically uses ortho cameras currently (MonoAGS already support parallax layers, btw). This is something I can probably add.

Is the build automated? Like, do you maintain a solution made with something such as cmake to generate the .sln file and all? That's one of the weaknesses that CW pointed out in AGS. Those tools are real magic to generate soluions for any IDE/compiler/Visual Studio version in one click

The build is automated (and there are automated tests as well- though the tests are not as comprehensive as I would like them to be). Also, a big fantasy for me would be to have UI tests (i.e use docker to open up an OpenGL context, and automatically run the demo game or some other test game with video recording if something goes wrong).
I don't use cmake nor do I understand what you mean by "generate the .sln file and all”. I'm not familiar with any c# project that uses cmake? I don't have any experience with c++, but in c# you almost never update the sln file manually, the IDE handles it for you, and the IDE itself rarely touches it as well (just when adding/removing projects).

Apart from that,I have no opinion on the switch from Mono to .net Core.

.net core should be faster and more stable than mono, but the really big appeal is that it can be self-contained, meaning you can bundle the runtime with the game so it's not needed for the user to have the runtime installed on her/his machine.

Good manual + community + tutorials: yes

I would not say that's true: I consider the current documentation to be miles off from where I want to be: I have reference API docs and some explanation articles but zero tutorials, samples and recipes.

Subpixel management / maths / vectors: to be binded

I don't understand the category and the “to be binded”. MonoAGS supports subpixel positioning. Not sure what you mean by “maths”, but c# has built in math in the standard library, and already mentioned my misunderstanding of what you mean by vectors.

Multithreading inside the game:
to be implemented by the game designer

MonoAGS currently uses 2 threads, one for the render loop and one for the update loop. And other than that, yes, developer can create threads if she/he wants. I talk more about the threading model here.

Data structures / serialization / database-like processing

c# (the standard library and existing libraries) probably has everything you want and more.

1) relying on a cross-platform tech? If yes which one?
2) which is the licensing Of that underlying tech ?
3) Is that underlying tech  only a graphics renderer or a full multimedia engine? In other words: does the graphics rendering come bundle with the audio and potentially 3D or GUI rendering, or are these separate libraries?
4) Is that underlying tech  only a game engine or an Editor too?
5) How old is each of the few central underlying tech or lib (name them) and the main project itself ?
6) What third-party libraries is it using (full list)? How old/robust/well maintained/too restrictive are they?
@tzachs not accurate enough!  could you please have a look at the bits I added in italics in the quote above?

Ok, expanding on the “italics” parts:

1. All the techs I list here are cross-platform (and by cross-platform, I mean, at the very minimum: Windows 7 and above, Mac, Linux, Android, IOS.
2. Dotnet framework, OpenTK, SDL, OpenAL Soft, Protobuf.net,NVorbis, FFmpeg, everything else is MIT.
3. The underlying tech is low-level multimedia bindings (you see it as useless, I thought the opposite: I didn't want to get the burden of an existing complete engine, as it gives more freedom).
4. …
5. Very hard to answer about the underlying tech age, it's not something usually published on the front page: dotnet core is probably the youngest one (2 years?). I originally started working on MonoAGS on Aug 7, 2015 (on the flight to Mittens New-Orleans). Everything else has been around longer than that.

@tzachs, could you clarify the points below:

Ok, you added this as I was typing, so parts I haven't touched on yet:

- implementation of usual point n click entities yes/no (rooms, characters, inventories, objects…)

yes to all (I think).

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

So I went over the API back in the day, and I think I have most of it in some form or other. I probably missed a bunch of stuff though.
Things that I know I don't currently have are: Object.Solid, tint areas, text parser and drawing surface. I'll go over it soon and make a more exhaustive list.

- editor (explain your plan)

Ok, so you are pushing me . It will be a long post on its own, and will take me some time to write, so I'll get back to you on that.

- you're really not using any game-oriented  middleware for assets loading, sound management (apart from basic OpenAL), controllers input, animation, camera control, etc.?

Not that I know of.

Hmm, well, there is a lot I can say, but I am a bit hesistant sometimes, because many things look too much "integrated" into the engine already.

Oh, there's more stuff you hasn't shared? Please do. I keep refactoring things and changing approaches, so even if something looks too much "integrated" now, it might not be in the future (and even if I disagree with something now, it still gets stuck in my head for later re-evaluations).

Just because the scripting language is JavaScript, that doesn't necessarily mean the games will be browser-based, does it?

True, you can target desktop with Electron for example, and I believe there are also solutions for mobile (and also, for mobile, you can have a web page appear as a native application, this is something Construct does, for example)

1) relying on a cross-platform tech? (yes/no)
2) which licensing?
3) Is it only a graphics renderer or a full multimedia engine? In other words: does the graphics rendering come bundle with the audio and potentially 3D or GUI rendering, or are these separate libraries?
4) Is it only a game engine or an Editor too?
5) How old is the tech?
6) What third-party libraries is it using (full list)? How old/robust/well maintained/too restrictive are they?

Answering for MonoAGS:
1. Yes
2. Kept the same license AGS uses.
3. 2D graphics, GUI and audio (no 3D planned in the near future).
4. Working on an editor.
5. New.
6. I list all the current dependencies here. They are all actively maintained. I do plan to do some changes to that in the not too distant future (switching from Mono & DotNet framework to Dotnet Core, and using FFMPeg for both audio and video are the 2 big changes I want to make).

In AGS you have 3 type of people

I couldn't agree more, that's why in MonoAGS the scripting language is c#, the engine is in c# and the editor will be in c# (and the editor will use the same GUI framework the engine provides), so really if you know how to script games, it gets you closer to understand the tools.

Have something basic that does nothing

So this is a philosophy that while I definitely see where you're coming from (and I think you and Crimson Wizard are on the same page here), I think is not as fitting to AGS. The main advantage that AGS has over an engine like Unity in my view is that the adventure stuff is built in, ready to be used. Stuff that's not going to be used by a lot of people should be in separate packages but stuff that's considered core to the genre, I want it built in and maintained as part of the engine.

MonoAGS by tzachs (which has a lot in it already, but seemed overcomplicated to me, which I kept telling to tzachs, probably annoying him greatly; also its way of creating games may be quite different from AGS).

Annoying maybe in the sense that you're giving me more stuff to think about (and more work), but definitely want more of that, it's great help. And I'm claiming "in progress" for the complexity and AGS-ey workflow stuff, hopefully it would get much better.

Regarding other engines, here are a few you haven't mentioned:
Blade Coder is an open source one that looks impressive.
There's the commercial Visionaire studio.
The framework for Godot is called Escoria.
Calin's engine Adore. And there's also Sludge.

I think the only way it could work is if the parents stayed somewhere else (hotel / own rental), and met up during the day with the main group.

Right, I guess this is what we might do then (and we'll come just for the weekend probably).

Ooh, we're definitely interested, but I'm guessing it's going to be problematic coming with a (very demanding) 2 year old? Was there ever a precedent of somebody bringing a kid? And how did it go? If not, maybe we'll do a weekend there and come visit.

There was some complaint last year that the font was difficult to read. If anyone has any suggestion for fonts to use for the chat window or above characters' heads (or other things), let me know. (We should be able to do proper rendering and outlining of antialiased text now, so don't feel limited to pixel fonts.)

This might be a good resource for selecting a readable font for small text: https://ux.stackexchange.com/questions/3330/how-do-you-choose-a-font-for-extremely-limited-space-i-e-will-fit-the-most-rea

With AGS integrated, that would necessarily expand the goals of the project to include supporting our needs, right?

Maybe, though that would require a big commitment (and mind shift) from their side.

(Do you mean a custom shader as e.g. for a scaling filter, as part of the engine, or for a particular game, to achieve some special effect?)

For a particular game.

When I started working on my MonoAGS rewrite, I considered basing it on ScummVM (among other options).
The biggest turn-off for me was that the goal of ScummVM is to support old games, so newer functionality is not getting developed, and the existing architecture might be limiting in terms of what you can do with it.
Is it possible to give the game developer the ability to write custom shaders, for example?