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.

SMF spam blocked by CleanTalk