AGS Project Goal

Started by Alan v.Drake, Sat 25/04/2020 19:45:46

Previous topic - Next topic

What should AGS purpose be?

AGS main purpose should be to make games
39 (95.1%)
AGS best feature is that it can run older games
2 (4.9%)

Total Members Voted: 41

Alan v.Drake

Quote from: Crimson Wizard on Tue 28/04/2020 02:02:52
This is a case of manipulation of public opinion [...]

* rubs hands with an evil grin *

But really, that is what it means in practical terms. Backward compat and innovation are anathema to each other, at least until we can cleanly separate them so we no longer cause butterfly effects because we added one feature or improved something.
Besides trying to keep adding features to AGS3 only makes it harder and more complex to mantain, doesn't it?

- Alan


Hobo

I don't think I've ever used the engine to run older games and to be honest, I didn't even know it was considered to be a prominent or important feature.
So, obviously I'm completely fine with dropping the backwards compatibility and I'd probably be fine with any other change or cut, no matter how drastic.
I mean, you're working voluntarily on an open source engine, so from my perspective you can go wherever you want with it.

Crimson Wizard

#22
Quote from: Clarvalon on Sun 17/05/2020 10:33:26
To clarify, I don't see XAGE as a successor to AGS.  The model AGS uses - an all-in-one program that handles everything for you - is compelling

This is what causes a lot of inconvenice in practice, and other developers plan to move away from towards separated tools.

Clarvalon

Still, the AGS download is less than 30MB.  Compare that to however many GB the Visual Studio installation is.  AGS is self-contained and simple to use and that puts it in a good position, particularly for less technically-minded people who may otherwise be intimidated by using Visual Studio. 
XAGE - Cross-Platform Adventure Game Engine (alpha)

Snarky

Quote from: Crimson Wizard on Sun 17/05/2020 12:26:38
This is what causes a lot of inconvenice in practice, and other developers plan to move away from towards separated tools.

Really? I think that's a very bad idea. (Sorry to derail your thread, Clarvalon. I'm not sure this is discussed elsewhere.)

Crimson Wizard

#25
Quote from: Snarky on Sun 17/05/2020 15:22:06
Quote from: Crimson Wizard on Sun 17/05/2020 12:26:38
This is what causes a lot of inconvenice in practice, and other developers plan to move away from towards separated tools.

Really? I think that's a very bad idea.

This is a good idea, as currently you cannot modify anything or even compile a game without launching IDE, which makes AGS games impossible to edit on non-Windows systems. This closeness of AGS editor, in coupling with closed binary formats used to store parts of the game project - all this was a big concern for years.
Therefore the goal is to split out at least compiler and few other processes into separate tools with cross-platform code, that could be run on their own from a batch script.


UPDATE: I think this comment summs up it pretty much: https://www.adventuregamestudio.co.uk/forums/index.php?topic=57990.msg636620565#msg636620565

doimus

#26
Not only should the new tech be prioritised over backwards compatibility, but IMO, the whole concept of a "studio" app should be dropped as well.

GUI toolkits and the whole concept of GUI apps in in a such sad state of affairs right now. Proffesional GUI apps I mean. It seems everybody and their mother is reinventing their own custom GUI toolkits. The old ones are getting bloated into oblivion... It. Just. Makes. No. Sense. Anymore. Whatever one does today in whatever GUI toolkit, it will be hopelessly outdated 20 minutes in the future. And in the same time, it will severely limit the cross platform support.

There's really no need to waste resources on editor apps in this day and age. There are countless level editors, image, text editors out there that can be used instead.
I'd argue thet the best way of maintaining future-proof backwards compatibility (...I know Doc, but I'm back, I'm back from the future! :-D) is to have exactly zero binary code in an author's game project folder. Apart from obvious image and audio assets, that is.
It should be possible, maybe not desirable, but possible, to create a game in plain text editor, with nothing more than project script files, config files, binary assets and a command line compiler. The "unix way" of doing things. Visual editor should be an optional part of the toolkit, not it's foundation.

Editor(visual or not) + scripting language + assets + compiler + runner = game.

All components are interchangeable as long as the interface between them is common.

In that spirit, maybe the S in future AGS should stand for STANDARD?

Crimson Wizard

#27
I'd like to ammend the above comment, noting that the scene (room) editor does not have to be it's own application. This proved to be a difficult task to keep editor and engine in sync, especially if they are written in different languages and thus based on different graphical etc libraries.
Engine can already display the room and everything else, so why not let it run in "edit" mode (even if the editing controls are handled by a plugin or script module in order to keep the base engine smaller)? I think this concept was implemented in almost every mature engine today.

Hypothetically, an Editor app could be a sort of GUI wrapper around an engine window, that runs it and provides settings and paths to resources.

Snarky

Quote from: Crimson Wizard on Sun 17/05/2020 15:47:50
This is a good idea, as currently you cannot modify anything or even compile a game without launching IDE, which makes AGS games impossible to edit on non-Windows systems. This closeness of AGS editor, in coupling with closed binary formats used to store parts of the game project - all this was a big concern for years.

Therefore the goal is to split out at least compiler and few other processes into separate tools with cross-platform code, that could be run on their own from a batch script.

One doesn't follow from the other, though. Having an integrated IDE is not in conflict with the compiler being a separate executable, or require that the project files are these big binary blobs or in a closed/custom format.

Quote from: Crimson Wizard on Sun 17/05/2020 15:47:50
I think this comment summs up it pretty much:

Quote from: doimus on Sun 17/05/2020 17:01:29
Not only should the new tech be prioritised over backwards compatibility, but IMO, the whole concept of a "studio" app should be dropped as well.

There's really no need to waste resources on editor apps in this day and age. There are countless level editors, image, text editors out there that can be used instead.

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.

Crimson Wizard

#29
Quote from: Crimson Wizard on Sun 17/05/2020 15:47:50
I think this comment summs up it pretty much:

Quote from: doimus on Sun 17/05/2020 17:01:29
Not only should the new tech be prioritised over backwards compatibility, but IMO, the whole concept of a "studio" app should be dropped as well.

There's really no need to waste resources on editor apps in this day and age. There are countless level editors, image, text editors out there that can be used instead.

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.


The key point in above post is this:

Quote from: doimus on Sun 17/05/2020 17:01:29Visual editor should be an optional part of the toolkit, not it's foundation.

Editor(visual or not) + scripting language + assets + compiler + runner = game.

All components are interchangeable as long as the interface between them is common.

The data and rules should be a foundation and dictate GUI, not other way around.

First comes the data, and the way engine runs it, only then the necessary tools to work with it, only then the user UI for convenience. This is perspective from basic things upwards.
This way it's flexible, easy to update, easy to create custom tools for.



Quote from: Snarky on Sun 17/05/2020 18:03:08
One doesn't follow from the other, though. Having an integrated IDE is not in conflict with the compiler being a separate executable, or require that the project files are these big binary blobs or in a closed/custom format.

My point was that currently it's too monolithic, and much of the project data format was designed in a way meant to be read by particular editor program. You cannot use one part (e.g. compiler) without running editor. IDE could be a monolithic program or it could be a UI wrapper which uses standalone tools underneath.

Cassiebsg

Just as long as it's as easy to use as AGS currently is for the end user, then I'm fine with whatever route you guys decide to move towards.

As in, I only need to download a full pack and still run the AGS editor to create my games and compile the game, with no extra steeps to install UI, script language, manual, compiler, runner, etc.
There are those who believe that life here began out there...

morganw

Quote from: Snarky on Sun 17/05/2020 18:03:08
Having an integrated IDE is not in conflict with the compiler being a separate executable, or require that the project files are these big binary blobs or in a closed/custom format.

The most straight-forward solution is likely to create the underlying tools to operate independently of anything else but then to take an existing editor that has a plug-in ecosystem and supply plug-ins that allow the editor to function as a complete IDE. I think the 'studio' part is pretty critical, just not how it is architected now.

doimus

Quote from: Snarky on Sun 17/05/2020 18:03:08

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

LimpingFish

It sounds like your describing an IDE more suited to a professional development environment, rather than what AGS is, and always has been, to a lot of it's users: a simple, all-in-one, hobbyist tool.

But I'm no software engineer.
Steam: LimpingFish
PSN: LFishRoller
XB: TheActualLimpingFish
Spotify: LimpingFish

Crimson Wizard

Quote from: LimpingFish on Mon 18/05/2020 01:00:12
It sounds like your describing an IDE more suited to a professional development environment, rather than what AGS is, and always has been, to a lot of it's users: a simple, all-in-one, hobbyist tool.

It may be both, but the issue here, IMO, is in different perspective on a program. You may look at this from "outside" seeing a final result, or from low-level to top, so to speak, seeing it as a set of parts. Because when it is a set of parts, it's easier to accomodate for more variants of use.

What I am trying to say here, consider for example there are two users. User A wants to have one program that does everything and runs out of the box, and user B wants to only have certain tools and create their custom enviroment to match preferred workflow.
If developers come at this from the end-result perspective they will make a monolithic application as a solid undividable program, thus resolving user A's needs, but not user B.
If, on other hand, developers will look from low-level perspective they'll create modular system where each operation is performed by a dedicated tool, and a sort of a wrapping GUI that works as the system overseer, they would resolve user A's needs (they will use main GUI app), as well as user B's needs (they will use selected tools from the set).
If done well, user A won't notice a difference between two solutions, as the end result seem same from the outside.

Danvzare

Quote from: LimpingFish on Mon 18/05/2020 01:00:12
It sounds like your describing an IDE more suited to a professional development environment, rather than what AGS is, and always has been, to a lot of it's users: a simple, all-in-one, hobbyist tool.

But I'm no software engineer.
It kind of sounds like that to me too.
I think first and foremost, AGS should cater to the hobbyist over the professional. Sure, it's preferable to cater to both whenever possible. But if one has to be chosen over the other, the hobbyist should come first.

doimus

Quote from: Crimson Wizard on Mon 18/05/2020 01:39:42

It may be both, but the issue here, IMO, is in different perspective on a program. You may look at this from "outside" seeing a final result, or from low-level to top, so to speak, seeing it as a set of parts. Because when it is a set of parts, it's easier to accomodate for more variants of use.
....

Exactly, and not only would it allow more variants of use, it would allow a decentralized development, and most importantly, quicker release circles, which is paramount in any software development, especially open source.

Quote from: Danvzare on Mon 18/05/2020 15:24:05
Quote from: LimpingFish on Mon 18/05/2020 01:00:12
It sounds like your describing an IDE more suited to a professional development environment, rather than what AGS is, and always has been, to a lot of it's users: a simple, all-in-one, hobbyist tool.

But I'm no software engineer.
It kind of sounds like that to me too.
I think first and foremost, AGS should cater to the hobbyist over the professional. Sure, it's preferable to cater to both whenever possible. But if one has to be chosen over the other, the hobbyist should come first.

The problem with that approach is that so called hobbyist tools require more, often waaaay more, professional-grade work hours to get them to a polished state. And that can be problematic in an environment where work is not honored in money.

Open source software must use other leverages than financial gain to draw in developers. Focused passion is one of them. Some people love making GUI apps in high level languages, some people love making compilers in low level languages, some love designing scripting languages. It's not sensible to make the GUI guy do it all in low level programming code, or to have the compiler developer wade through endless gui source listings etc. It kills the passion, and consequently the project.


SMF spam blocked by CleanTalk