This is about the most misguided thing I've ever read. Sure, let people use other editors if they want/need to, but Adventure Games Studio as a complete, single-installation, "works-out-of-the-box," pretty well documented IDE is probably the second most important factor to its success as an engine (the first being that it's completely free). Give up on that and we might as well shut down now.
AGS works out of the box. On certain version of Microsoft Windows, with certain version of GUI toolkit installed. Once you're out of that ecosystem, you're screwed. Which makes AGS a lot less free and certainly a lot less portable than it could be. That's the whole point I was trying to make.
Add to that the fact that there just isn't a single GUI paradigm that works on all platforms or all devices for all users. The concept of a productivity app is in a state of flux at the moment and is changing on a daily basis. Just look at all the IDEs, Music DAWs, 3D Apps, Game engines. Almost all of them have unique proprietary GUIs built in-house. Conceptually, we're right back where we were back in late 80s gui-wise. It's everyone for themselves, and the concept of an unified interface on an unified platform on unified hardware is pretty much dead.
The other point was that writing usable GUIs occupies a whole lot of valuable resources. It is certainly nice to whip out own cross-platform widget rendering engine, text buffer and code parser. But then users start asking for syntax highlighting, window resizing, code auto completion, dark modes, etc. The list goes on and on, and sooner than later, you're writing a GUI library instead of adventure engine. And then someone comes up and says you're an old dinosaur who prefers puffy 90s icons, or a clueless material flat icon hipster.
And based on all that, the sensible conclusion is to completely decouple the presentation aspect from the creation aspect. If someone prefers classic desktop interface, let them have it. If someone prefers web-like touch-friendly "material" look, let them have it. If someone prefers coding it all by hand in Emacs, let them have it, but at the same time let the compiler programmers worry not about it, at all. They get the configs and scripts and act on them. How and where those scripts were created should be the least of their concern.
This, divide-and-conquer approach has an additional benefit that it might attract GUI programmers who would otherwise be scared away from contributing to the project. This way a GUI "studio app" could be written in languages different from the core, from python to javascript to C, whatever someone prefers. They don't need to fork the main project to do it and they just need to output text files standardized with the compiler. The gui room/view editor could be written as a plugin for GIMP, Krita, Photoshop, Tiled, whatever, and let their programmers worry about dark modes and window resizing. Artists familiar with Photoshop would likely prefer to edit/preview rooms while working on art, without the need to import to the main app.
This way the 'adventure compiler' could be written in bare standard languages that'll compile on bare standard compilers, regardless whether particular GUI toolkit runs on a particular platform. As long as it reads script and asset files and outputs bytecode.
And then only the runner is tied to a particular platform. So a Windows/Linux runner could be written in C++, web runner could be written in javascript, iOS and Mac runners could be written in Swift. Sh!t, an Amiga runner could be written in assembly, as long as it gets the adequate bytecode and assets. Or it all together could be done as a ScummVM plugin and be readily available wherever and whenever ScummVM is available.
I mean, Java VM couldn't care less if the programmer used Netbeans or Eclipse to do their work. Unity couldn't care less if artists used 3dsMax or Maya for 3d models. AGS now doesn't give a rat's ass whether images were made in Photoshop or the GIMP. It's just standardized data...
Poll
