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

Hello fellow AGSers,
us AGS source developers would like to hear your opinion about what the common user thinks AGS goal should be...

Should "Adventure Game Studio" be a tool primarily aimed for making games?
Or should AGS primary goal be to run older games and having the whole "making games" as a secondary feature?

Why are we asking this?
Because if we decide to focus new features and development on a new branch without retro compatiblity, we don't want people to start shouting about how we hijacked the project and make everyone angry.
Even if we went forth with this plan, AGS3 would still continue existing, just not receiving new features but only bugfixes.

There's much we would like to try, unfortunately it's not easy to improve AGS as long as we have to keep it backward compatible.
This choice is meant to give legitimacy to whatever path the development should be focused upon.
So, choose wisely.

- Alan

Cassiebsg

I only use AGS to make games, so guess what I choose.  ;)
There are those who believe that life here began out there...

Snarky

Make games that can be played on a variety of platforms.

Supporting older games should be expressly excluded as a priority, and perhaps even considered a positive harm.

CaesarCub

#3
From those choices I'd say focus on features and keep AGS3 bug fixing legacy support for a few years.

I'd say don't be afraid to demolish as much as you have from the old code (or even start from scratch taking advantage of newer technologies) and focus on easy of portability to newer platforms.

It's been a while since I used AGS, but I noticed that most of my user base plays my games on mobile.
And every now and then I talk to fellow developers talking about picking engines and a lot of the time they skip over AGS because of this same reason.

Edit:
As for the legacy AGS engine, I'd say to wrap it around some ScummVM-like UI to help people that use it to run older games to have a tool just for that.


Danvzare

#4
Using the newer AGS engines to keep the older games functional is nice, but I've only ever ran into compatibility issues with AGS games that are so old that the new AGS engine no longer supports it. Besides, I'd just find an alternative way to get the game running. There's plenty of ways. Dosbox and virtual machines spring to mind.

But of course there's the brilliant fact that the newer editors, still support importing your old games. Allowing you to update your game and continue working on it. This is brilliant if you're taking a long time, took a huge break, or just want to update an old game you made. But to what extent should that be supported? How many versions back do we really need to be able to import our old projects and expect them to still work?

My vote is for making games. Although a little bit of backwards compatibility will always be appreciated.

Quote from: CaesarCub on Sat 25/04/2020 21:00:15
As for the legacy AGS engine, I'd say to wrap it around some ScummVM-like UI to help people that use it to run older games to have a tool just for that.
It'd be nice if ScummVM implemented support for old AGS games. It'd fit in better than Might and Magic. (A game series I adore by the way, but they're hardly point and click adventure games.)

blur

I think you should not mix up the editor and the engine. Of course the editor is for making games, while the engine is for playing games.
Also I have a hunch that this question has been discussed some time ago already.

Slasher

#6
Both answers of course can be right.... But how can you vote?

For developers it's about being able to use AGS as the engine for game creation. As AGS evolves it become a bigger tool through technology for the needs of the developers and players.

Being able to import earlier AGS version games is a good feature, but only when the developer wants to change, edit the game or upgrade, otherwise just playing games makes no difference to the AGS version standalone. Unless you want to change or upgrade your game there is little reason to support compatibility as older versions of AGS are still available..

So it all depends... What is the best feature of modern AGS?  Probably being able to create what you want with better tools and implementation...

I still wish the menu icons were bigger for those of us with difficulty clicking the right button icon..

Slasher


Moresco

Maybe I don't understand, but why do we need backward compatibility?  If I'm making a game with version 3.5, and version 4 does not support the code written in 3.5, then tough, I will either have to finish my game in 3.5 or upgrade.  I can accept this reality.  I prefer the engine/editor to continually improve, and I don't care if that means I can't upgrade from 3.5 to 4 without updating the code or the way I approached something.  Trying to keep bad code or bad practices in the engine/editor while also attempting to improve it has got to be exhausting. 

That's just my 2 cents, and 2 cents never made us rich.  :grin:
::: Mastodon :::

cat

I favor innovation over backwards compatibility. However, there are two caveats:

Development of a single game can span multiple years, or people want to do fixes and improvements for old games. There has to be an option to upgrade old games to the newest version. However, this does not necessarily have to be done in the latest editor only. For example, when you have a very old game, you already have to upgrade it to AGS 2.72 before upgrading to 3.x. This could be a viable solution: Just call a new version 4.x and require the game to be upgraded to the latest 3.x before importing it to 4.x. Migration between different 4.x versions could be done via scripts that are run during import.

Is there actually anyone playing games with different engines? Since AGS games come as precompiled exe (and now also for other platforms), just run the game. Maybe it would be nice to provide downloads of older engines so people can have them in parallel on their PCs and choose the one they need, if really necessary.
Another topic is the Android build. Is it possible to have multiple installations of the AGS engine installed on one device? If not, I suggest making a different package for 4.x so it is possible to have them run next to each other.

morganw

Quote from: cat on Mon 27/04/2020 11:01:18
Development of a single game can span multiple years, or people want to do fixes and improvements for old games. There has to be an option to upgrade old games to the newest version. However, this does not necessarily have to be done in the latest editor only. For example, when you have a very old game, you already have to upgrade it to AGS 2.72 before upgrading to 3.x. This could be a viable solution: Just call a new version 4.x and require the game to be upgraded to the latest 3.x before importing it to 4.x. Migration between different 4.x versions could be done via scripts that are run during import.
To clarify, 'backwards compatibility' is only talking about the engine that runs games, and this doesn't necessarily have any impact on being able to upgrade your game's source project to the next AGS version within the Editor. What we are talking about removing is the ability to take an older compiled game and have it run on future AGS engines, and hopefully this gives the opportunity to make upgrading the AGS version less of a problem for game developers.

Quote from: cat on Mon 27/04/2020 11:01:18
Is there actually anyone playing games with different engines? Since AGS games come as precompiled exe (and now also for other platforms), just run the game. Maybe it would be nice to provide downloads of older engines so people can have them in parallel on their PCs and choose the one they need, if really necessary.
It is being used in this capacity, which is why this poll is here.

Quote from: cat on Mon 27/04/2020 11:01:18
Another topic is the Android build. Is it possible to have multiple installations of the AGS engine installed on one device? If not, I suggest making a different package for 4.x so it is possible to have them run next to each other.
How the Android port is used at the moment (take game.exe and try to play it on your phone) is a good example the of backwards compatibility being used. If the goal is to build games, we build games for specific platforms and would not build generic launchers, so multiple installations are not an issue. Removing backwards compatibility would mean there is no longer the concept of having AGS on your phone, in the same way that you don't install Unity onto your phone to play a Unity game, you build an installable package for the game itself.

Crimson Wizard

#10
Quote from: morganw on Mon 27/04/2020 14:58:42
How the Android port is used at the moment (take game.exe and try to play it on your phone) is a good example the of backwards compatibility being used. If the goal is to build games, we build games for specific platforms and would not build generic launchers, so multiple installations are not an issue. Removing backwards compatibility would mean there is no longer the concept of having AGS on your phone, in the same way that you don't install Unity onto your phone to play a Unity game, you build an installable package for the game itself.

I guess it will be still technically possible to have a new launcher that runs games made in a range of contemporary versions of AGS.

LimpingFish

Quote from: Alan v.Drake on Sat 25/04/2020 19:45:46
Should "Adventure Game Studio" be a tool primarily aimed for making games?
Or should AGS primary goal be to run older games and having the whole "making games" as a secondary feature?

Why would AGS primary goal be to run older games? In fact, similar to Snarky's point, why should older games be a priority at all?

Personally, I would like to see AGS used as a means to create a platform-agnostic game, which could then be read by a host of platform-specific interpreters.

Or have I misunderstood the question?
Steam: LimpingFish
PSN: LFishRoller
XB: TheActualLimpingFish
Spotify: LimpingFish

Crimson Wizard

#12
Quote from: LimpingFish on Tue 28/04/2020 01:00:45
Quote from: Alan v.Drake on Sat 25/04/2020 19:45:46
Should "Adventure Game Studio" be a tool primarily aimed for making games?
Or should AGS primary goal be to run older games and having the whole "making games" as a secondary feature?

Why would AGS primary goal be to run older games? In fact, similar to Snarky's point, why should older games be a priority at all?

This is a case of manipulation of public opinion, because the question was never put how Alan worded it.
"Making games" was never suggested as a "secondary feature".

Running old games was suggested as one of the integral features of the engine in the past, since JJS started making official ports in order to run AGS games on other systems, because prior to that it was near to impossible to reliably run them on other systems than Windows, and even run games compiled many years ago on contemporary Windows, - that also was becoming more difficult (old executables did not have support for modern graphic modes, for example). AGS database had many hungreds of games at that point, and most of them were running only Windows. Users on Linux and Mac desired to be able to play them natively without virtual machines and such.
EDIT: In case someone wonders how much used this feature is; this may be not seen on this forums, but in all these years I was receiving support requests from dozens of people, who wanted to run pretty old games on modern devices. There are still people who add translations for old games too, and being able to run them with new engine for them is a big deal.

The question was not whether this should be primary feature or not, the question in a nutshell is whether it may be discontinued for the benefit of a major redevelopment.

From the start of the current open source project it is based on JJS's works, which included layers of backwards compatibility (some of that was not a part of 3.2.1, last version by CJ). Unfortunately, the engine code was never cleaned up enough to untangle this compatibility support and make it an optional module, for instance. Because of that it was always difficult to make bigger changes, while I was reluctant to drop it thinking that we are now responsible of carrying this support, at least until there are better alternatives.
Personally, I believe that was a big mistake, and would've things done differently, AGS probably will be pretty more advanced than it is now. Of course that would be achieved at the cost of people not being able to run old games with this engine, but perhaps same functionality could've been implemented in another, parallel, project, or even in ScummVM.

And yes, it's true that this was all discussed many times before.

Snarky

It's cool that it's been possible to bring back compatibility for games made in older versions of the engine, but there should be a clean break. There is no good reason why the next AGS version should have to carry the weight of getting games from ten, fifteen, twenty years ago to run.

cat

What about a middle ground there? Breaking changes are necessary, but should not happen all the time. There could be a list of engines available in the download section of the AGS page with exact numbers which AGS versions are supported by each engine. If I now have an old game that would neither run with DOS-Box nor with my current OS, I can look at the list and try to find an engine version that supports the game and my OS. It requires a bit of administrative effort, but is probably worth it.

I also like CW's idea about the launcher app. I think this would also be useful for other OS (even Windows maybe?) - just download one (probably big) engine package and run it. The launcher then decides which engine to start up to play the game. This would allow for playing old games easily and the newest engine could get rid of legacy support.

Snarky

Isn't that essentially what 3.5 is? A best attempt to run games made with almost all versions of the engine? You could certainly have a separate development track that just kept improving compatibility and fixing bugs on that branch without adding more functionality to the engine.

Also, there already is a list of older versions on the AGS download page (though it hasn't been updated and is very incomplete).

Quote from: cat on Tue 28/04/2020 08:20:41
What about a middle ground there? Breaking changes are necessary, but should not happen all the time.

I don't think anyone is suggesting it should happen all the time. If there is a new "generation" of the AGS engine that discards this kind of backwards compatibility with legacy games (while offering developers some kind of upgrade track for projects in progress), going forward it probably makes sense for subsequent versions to maintain compatibility with older versions, for the same reasons it has had value for AGS in the past (bugfixes and support for newer systems). It just wouldn't support games from before the break.

But the developer discussion also indicates that they're planning to refactor and architect the whole system better, cleanly separating the engine layer from the system backends (which they call "frameworks", for some reason). That should make it easier to extend with new system ports and platform support in the future, so that you could run the game with the engine it was originally built in on a newer platform.

Crimson Wizard

#16
Quote from: cat on Tue 28/04/2020 08:20:41
I also like CW's idea about the launcher app. I think this would also be useful for other OS (even Windows maybe?) - just download one (probably big) engine package and run it. The launcher then decides which engine to start up to play the game. This would allow for playing old games easily and the newest engine could get rid of legacy support.

Hm, this was never my idea, I was speaking about Android launcher.

UPD: Seriously, though, the idea is fine, but I think a point is missed here. In regards to the old game support, the main concern is that we do not have a proper modular system in the engine that would let easily upgrade platform support for all branches. If engine was split into two parts (for example, similar to how ScummVM is split on backend modules and game engine modules), then the decision would be much simplier, as upgrading platform support would automatically apply to both new and old versions of AGS.

Snarky

Quote from: Crimson Wizard on Tue 28/04/2020 10:09:54
UPD: Seriously, though, the idea is fine, but I think a point is missed here. In regards to the old game support, the main concern is that we do not have a proper modular system in the engine that would let easily upgrade platform support for all branches. If engine was split into two parts (for example, similar to how ScummVM is split on backend modules and game engine modules), then the decision would be much simplier, as upgrading platform support would automatically apply to both new and old versions of AGS.

But is it also correct to say that insisting on backwards compatibility is one of the big things standing in the way of moving to that sort of architecture, because it makes it much more complicated to make significant changes to the code?

If so, does that not argue for making a break now, so that future games can have improved forward compatibility and platform support?

Crimson Wizard

Quote from: Snarky on Tue 28/04/2020 14:58:17
But is it also correct to say that insisting on backwards compatibility is one of the big things standing in the way of moving to that sort of architecture, because it makes it much more complicated to make significant changes to the code?

If so, does that not argue for making a break now, so that future games can have improved forward compatibility and platform support?

Yes, I believe so. But of course above assumes that we reach that point in foreseeable future.

cat

Quote from: Crimson Wizard on Tue 28/04/2020 10:09:54
Hm, this was never my idea, I was speaking about Android launcher.
I know, I was just trying to expand on it.

@Snarky: Yes, I was referring to this list and that it should maybe be more extensive and complete in case backwards compatibility is dropped.

I think if a new 4.x version drops support for anything 3.x, but the latest 3.x is still available for download (i.e. people who need it to run old games can find and use it), this is perfectly fine. I think the important part is to clearly document the breaking change and where to find appropriate versions.

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