What about this.
We design a very simple engine based on the following concepts:
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.
