I wrote this some time ago, but was reluctant to post it. Probably because my thoughts are in chaos, and I cannot come to single decision.

I will leave it here under a spoiler, but before that: my biggest concern with starting a new version of the engine is whether it is really needed. In the light of existing and upcoming projects. There is XAGE by Clarvalon (I do not know much about it, except that it can create games by converting from AGS project), 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). There is announced Javascript engine by Scotch, which I also do not know anything about, nor its progress (And although I personally like javascript for the ease of coding, I do not know how much game developers, including those who develop commercial games, will like games to primarily run in browser). There is Unity on its own, and Adventure Creator for Unity (which supposedly is easier to use, but not free). There is Godot engine (which I am not familiar with yet), and someone mentioned that few AGSsers were trying to create an adventure game framework in it.There is even Wintermute still (one of the recent games made on it, or at least so I heard).Maybe others that I am not aware of.

Unfortunately, I am not familiar with the whole "market" situation very well, with demands and expectations of game developers. For instance, I start coding something today, and year later find out that another group of game developers have switched to Unity, or anything else. This concern was among the reasons that stopped me from actually trying anything new all these years.

1. Keep old AGS in mind but do not rely on it. We may use ideas and even code as a reference, but not trying to perfectly match its behavior. Even in terms of copying something, only modern stuff is applied. If someone would like to achieve full compatibility, that could later be done in a form of a engine "mod", or plugin. There are options here, but the point is to just not think about it during this starting stage.

2. As simple as possible. We do not have much people who may work, and less who know programming well (not meaning to be rude here :p), and the future is uncertain. The first version of the engine should be as bare as possible with minimum functionality enough to make an "adventure game". In regards to game objects only obligatory basic stuff is coded, assuming the rest will be filled in by script modules and/or future contributions.Objects API need to be very simple and flexible, so that scripters did not have to make hacks trying to remove unwanted behavior.

3. As simple as possible #2. Use most simple solutions for a problem for starters. If someone wants anything more sophisticated, they may add it later, after engine is working.For example, what may be the most simple way to package game files? ZIP archive? Then ZIP archive it is. Would be that technically convenient to write game data and savegames in key-value text format (like JSON or XML)? If so then do that.If game creators would require something less "hackable", that may be added later at demand (there may even be an engine mod with closed-source package format reader for paranoic commercial game creators).For the same reason as above, prioritize use of existing libraries to do the "dirty work" when possible, and when they actual suit the needs, instead of creating our own solutions.

4. Made of replaceable/switchable stuff. Engine program must be divided into components that work more or less as "black boxes". For example, "resource manager" that gives a game data by demand from any of the available locations without need to specify actual location. Resources are read by "resource reader", which may read from simple file, from ZIP archive, from old AGS-like data blob attached to exe, or whatnot. Pathfinding has its own manager and associated data component present in the room. Engine just sais "Pathfinder, give me path from X1,Y1 to X2,Y2", and manager does that all alike, regardless of whether there is a bitmap mask for walkable areas, or polygon-based solution, or node graph.Scripting works same way. There is a script manager that may be told to load script from file X, execute certain function with predefined name there, and able to translate script calls to the engine API. But scripting language itself is not bound to the engine. That may be AGS script for starters, but also any other script language like Lua or Python, or even Mono-based C# may be supported as plugin or engine "mod".

5. We use AGS Editor as a IDE. Making IDE is not easy, and even though it may not be perfect, but we already have a GUI workspace, which may be relatively easily adjusted to compile with new engine following new rules.

(Of course, all this assumes that I won't be working alone, because for instance the Editor would need some overhaul too)

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.

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.

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.

although I personally like javascript for the ease of coding, I do not know how much game developers, including those who develop commercial games, will like games to primarily run in browser

Just because the scripting language is JavaScript, that doesn't necessarily mean the games will be browser-based, does it? You can embed a JavaScript engine in a standalone native application, like Unity has been doing with its UnityScript/JavaScript (though they're apparently deprecating it).

imho I think that we should rationalize this.Firstly, only my two cents: I think that only people who know about IT (at least) and programming (at best) should jump in.Secondly, I think we should avoid the usual neverending thread of "opinions". We should have a neat, proper table of all the pros and cons of each project and/or underlying tech, with boxes to tick: The following quesitons come to mind immediately: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?

so on and so on. Really, I think the table presentation would help a lot to assert the amount of "invisible tweaking" required. Everyone who's been a developer knows how huge can be the gap between something out-of-the-box and something that requires to integrate several technologies, study how to build it (on several platforms), study its limitations, clearly see the "little things" that are missing, study the maturity, etc.

Firstly, only my two cents: I think that only people who know about IT (at least) and programming (at best) should jump in.

I agree on the list below, although I'd argue about "only IT people", because before you make a tool you set up goals for this tool ,and that goal usually relates to needs of potential users. What I mean, the list of "things" also need to include something from gamedesign perspective as well.

Firstly, only my two cents: I think that only people who know about IT (at least) and programming (at best) should jump in.

I agree on the list below, although I'd argue about "only IT people", because before you make a tool you set up goals for this tool ,and that goal usually relates to needs of potential users. What I mean, the list of "things" also need to include something from gamedesign perspective as well.

OK, but then even that should be rationalized as a poll:

"sort the features below by order of importance: (each point receives a unique number going from 1=most important to n=number of questions=least important)- AGS games working on Windows- AGS games working on non-Windows Desktop OS'es- AGS games working on Mobile devices?- Same 3 questions for the Editor- AGS having primitive 3D abilities or at least abstract rendering surfaces (to make it clearer: useful for modules that manage walkable areas, downhill walkable areas, layers, parallaxes, cast shadows, rain/particle effects, and to a certain extent Tweening, etc.)- AGS being good at hi-res graphics and/or video-like animations (lots of frames and alpha), smooth sprite movements- AGS being good at pixel games (no blurry or artifact effects caused by window sizing or sprites alignments/scaling)- AGS being able to emulate 8-bit games- sound engine (ambiant loops, localized sounds, etc.)- talkie games (dialogs and sound assets management)- collaborative game-making (primitive versioning + file merge + maybe permissions)- etc."

In addition, my intuition is that the answers provided by people who have actually already released a game should have more weight. And the answers from people who made commercial games should have even more weight. (Obviously, not because they are "more important" but because we can assert that they had more pressure to make a game that actually works and appeals to the players)

I will try to shine some light on why I think Unity works... If any normal person opens Unity, you can't possibly say "this is great piece of software". BUT once you commit to learn all the rough things in Unity, the same language you used to build your very tiny, probably in a jam, C# game, well... You can use that same knowledge to build tools for it! The base can be a magic proprietary box that mostly does nothing, but you now can build your own tools to make games with the same knowledge you have for making games, and you can share those tools. And you can share assets too! In the end I see Unity as this thing that Has a store to share stuff, and build across multiple devices, but that when you just install, it does nothing.

In AGS you have 3 type of people:1 - people who can script, using AGS Script2 - people who can make plugins, using SOMETHING (I have no idea how to make plugins).3 - people who can mod and advance the engine, using C and C++....and a secret 4th type:4 - people who can draw Adventure Game Stuff.

Being good in 1 and 4 doesn't contribute much to becoming 2. And the majority is too distant from 3.

So to create Yet Another Game Engine, I think the idea that would work would be just like Unity. Have something basic that does nothing, a package manager for distributing assets, and start from there. I would strongly advice being 2D AND 3D, choose ONE and stick with it. Doing the 2 there is already GODOT.

Also AGS Script is typed, which allows very good prediction of things while typing. I would advise against bare javascript, python or other non typed languages. I like that AGS Script is very non-verbose when compared to C#, making easy to sketch commands in forum (without smart predictions of things).

I would ignore collaborative and just guarantee things to work with git.

Also I think such engine should have as priority having an asset for AGS like workflow of game making, but you know... Allow if someone want to one day add a Mario Maker asset or crazy RTS designer asset, SIM RPG MAKER asset.

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).

Quote from: Snarky

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)

Quote from: Monsieur OUXX

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. Yes2. 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).

Quote from: eri0o

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.

Quote from: eri0o

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.

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?

Answering for MonoAGS:1. Yes2. 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).

@tzachs not accurate enough! could you please have a look at the bits I added in italics in the quote above?