Does it make any sense to develop AGS further?

Started by Crimson Wizard, Thu 13/04/2017 19:10:09

Previous topic - Next topic

Peder 🚀

#60
I'm also not sure making AGS commercial is the solution or even a good choice, there are many other ways of raising funds if it were needed for further development of AGS.
There could be "sponsors", that donate a set amount of money per month for having their logo placed on the website and so on.

I'd love to see AGS grow and become better and more modern without loosing it's "ease of developing adventure games", but whatever its fate, I'll be here archiving whatever games are made with it as long as I'm capable of typing and paying my server bills :=

Dave Gilbert

From what I can see, money was never the issue. We've offered to pay folks before to improve AGS, and the answer has always been no. It's a hobby for most people here. So there's no reason to make AGS a commercial engine.

RickJ

There seems to be two main developer pain points, neither of which would be alleviated with funding.

Legacy Code - Working on legacy code really sucks and there is no amount of money that can make it un-suck.  I've been there before.  Working on someone else's code is the most joyless experience anyone could ever have, especially code that has a long development history.  Having a root canal is a more pleasant activity.

Leadership - As mentioned earlier in the thread CW has inadvertently assumed CJ's role as our fearless leader.  CW believes he lacks knowledge and authority to make certain kinds of decisions and so is uncomfortable in that role. This is exasperated by the difficulties associated with the legacy code base. The irony here is that the community has great confidence in CW's leadership abilities and whole heatedly support his decisions (even the wrong ones ;) )

The solution has already been mentioned previously in this thread.  The current AGS version becomes Classic AGS with no future development except for bug fixes. We then begin an AGS 4.0 project from the ground up.  I can't think of anything that would do more to re-energize the community than engagement in the process of creating a brand new AGS.  The current AGS version could be used as a guide but we wouldn't have to lock ourselves into anything.

So to answer CW's original question ... NO it doesn't make sense to continue developing the legacy code base.  There are too many limitations and it's too difficult to make progress.  If there is a desire to start with a clean slate then we should go for it.  I think it's something everybody would willing to support and contribute to.

Mehrdad

Quote from: Dave Gilbert on Wed 19/04/2017 16:24:42
From what I can see, money was never the issue. We've offered to pay folks before to improve AGS, and the answer has always been no. It's a hobby for most people here. So there's no reason to make AGS a commercial engine.


Dave, Your wife help you for export to other platforms . Some people like me haven't  programming experience so we need to publish game on mobile and other platforms.Hire master programmers want much money and All of them not familiar with AGS too.
Commercial version at least is great idea for export to other platforms. 
My official site: http://www.pershaland.com/

Dave Gilbert

Quote from: Mehrdad on Wed 19/04/2017 16:53:19
Quote from: Dave Gilbert on Wed 19/04/2017 16:24:42
From what I can see, money was never the issue. We've offered to pay folks before to improve AGS, and the answer has always been no. It's a hobby for most people here. So there's no reason to make AGS a commercial engine.
Dave, Your wife help you for export to other platforms . Some people like me haven't  programming experience so we need to publish game on mobile and other platforms.Hire master programmers want much money and All of them not familiar with AGS too.
Commercial version at least is great idea for export to other platforms. 

Maybe I'm misunderstanding the discussion, but it seemed that the point of making AGS commercial was to further fund the creation of AGS? I.e., pay a developer like CW to do more work on it? That's not going to work if nobody actually wants to take the money.

Mehrdad

Quote from: Dave Gilbert on Wed 19/04/2017 17:57:04

Maybe I'm misunderstanding the discussion, but it seemed that the point of making AGS commercial was to further fund the creation of AGS? I.e., pay a developer like CW to do more work on it? That's not going to work if nobody actually wants to take the money.


I'm sure there is many people ready for pay to CW ,Gurok , ...for get best result from AGS as encourage and appreciate  .Because all versions after CJ was really great. But seems they don't want money .
CW want more colleague for investigate to engine.

Anyway my mean of pay was output to MAC,Android,iOS  not by CWa and his team.
My official site: http://www.pershaland.com/

CaesarCub

[Insert small introduction about how new I am to the forums and how I hesitate to contribute on this topic because I don't have knowledge/time to work on the AGS engine myself].

I like the idea of a committee, one that should be formed by people that has worked on the engine and people that has used the engine a lot.
Crimson is the one with the most engine knowledge, so even if he doesn't lead the committee he should definitely be the one that can estimate how costly any change is.
But that raises a different question, which is, what role he wants to be in.

A lot of people in this topic (including me) have showed no interest on keeping compatibility with previous versions.
CW: Would not having to care about compatibility with previous versions give you more room to breathe and make working on the engine something that wouldn't stress you as much as it is now? Or would it be the same?

I'm guessing that creating an AGS4 from scratch would be a huge task. How much of the AGS3.x code could be reused without falling into the issues AGS has in terms of intricate code?
CW: Would working on something like this still be a painful experience for you?


RickJ

QuoteHire master programmers want much money and All of them not familiar with AGS too
The going rate for contract programmers is about $10K per month, which, I imagine, is out of reach for most game projects and our little community.

QuoteI like the idea of a committee
Committees usually suck at whatever their mission is ;)

QuoteCrimson is the one with the most engine knowledge, so even if he doesn't lead the committee he should definitely be the one that can estimate how costly any change is.
Good point, Getting a handle on the amount of effort and time required is essential before undertaking such a project. There needs to be certainty about the amount of resources required and and the amount of committed resources available.



CaesarCub

Quote from: RickJ on Thu 20/04/2017 16:40:39
QuoteI like the idea of a committee
Committees usually suck at whatever their mission is ;)

Well, the idea is mostly to have a group of people decide which features make sense to push and which ones are really not that important and can wait.

Quote from: RickJ on Thu 20/04/2017 16:40:39
QuoteCrimson is the one with the most engine knowledge, so even if he doesn't lead the committee he should definitely be the one that can estimate how costly any change is.
Good point, Getting a handle on the amount of effort and time required is essential before undertaking such a project. There needs to be certainty about the amount of resources required and and the amount of committed resources available.

I'm not only talking about big changes, but even for new features. Some stuff can look easy but be impossible once you look under the hood.

Crimson Wizard

#69
The mentioning of this comittee idea was a part of retrospection. I was not planning to participate in one now, neither I have any wish to keep working on the engine even if its compatibility ties are broken. This is simply too late for me to do this.

Surely such move would make change easier. But in my opinion, the changes that AGS needs may only be solved by rewriting very large parts of it, which is comparable to writing an engine anew. Of course, that's just me, because other people seem to think that AGS is pretty good as it is now.

Dave Gilbert

#70
AGS is VERY good as it is now. Making games is a pleasure. That's the bit that everyone wants to keep.

The main issue with AGS is that the games are getting more and more difficult to run as computers change. On some computers, only Direct3D mode will work. On some others, only DirectDraw. There doesn't seem to be any rhyme or reason for this that I can see (especially since DirectDraw is so old it's not even supported anymore). That is the main issue that I am concerned with - enabling the end user to easily PLAY the games. Everything else is pure window dressing. As a commercial developer, this is the highest priority for me. I don't know how everyone else feels.

Crimson Wizard

Quote from: Dave Gilbert on Thu 20/04/2017 17:24:34
The main issue with AGS is that the games are getting more and more difficult to run as computers change.

In such case you just need a rewrite of the drawing and audio implementation, which, I believe, is practically done by Nick Sonneveld, who rewrote them to SDL (probably even years ago, but he was restoring it now).

Definitely you do not need me for this.

Atavismus

Quote from: Dave Gilbert on Thu 20/04/2017 17:24:34
AGS is VERY good as it is now. Making games is a pleasure. That's the bit that everyone wants to keep.
Exactly (and still the best engine I tested for 2D games, especially - ofc - for point'n'click).
An export button for mac/android/ios would be needed imo to be "modern" (yes I know it's a big one).
And maybe an improved save system (to avoid corruption between version).

LimpingFish

Quote from: Crimson Wizard
But in my opinion, the changes that AGS needs may only be solved by rewriting very large parts of it, which is comparable to writing an engine anew. Of course, that's just me, because other people seem to think that AGS is pretty good as it is now.

I think this is the crux of the situation. There are those who think AGS is fine as it is, and, like Dave Gilbert says, what we should be concerned about is ensuring that the games we produce with it continue to function on current, and future, systems. It just so happens that I agree, and that this is how I would like to see us proceed.

As mentioned, I think backwards-compatibility, support for older OS, and multi-platform support should be wound down, if it helps lighten the maintenance of the core code-base. Instead of far-reaching dreams of AGS evolving into something entirely new and all-encompassing, we should be simplifying what we have, and lightening the load on whoever decides to continue with development, be it one person or a team. The less the engine has to juggle, the less that can go wrong. This isn't to say that innovation will die, or that no new features will ever be added to future versions of AGS (like I said earlier, the code is open-source, so people are free to experiment on their own time), it just means that we shouldn't rely solely on those innovations to come from the "official" build.

Things we need to stop doing:

1. Talking about native iOS/Android/Mac/etc port support in the 3.x builds. It's not going to happen. The best you can hope for is third-party ports of the engine, such as the Android and PSP ports currently available. If you want an engine that does all that, switch to a different engine, or code your own. If you can't code your own...too bad.

2. Talking about bringing in professional programmers. Just...stop.

3. Making this all about money. It's not. And attempting to pay someone to do something they have clearly lost interest in doing isn't going to help matters.

Things we need to do:

1. Invite people who have used AGS to it fullest to informally discuss it's future, away from prying eyes. I would include anybody who has released commercial AGS games (Dave Gilbert, Grundislav, etc.) and those who have maintained or contributed, or are interested in doing so, to the development of the engine and editor (Crimson Wizard, Alan V. Drake, etc.), and from there...

2. ...plan out a road-map for future development of AGS. I can't stress enough how important it is that we have some sort of ground plan in place before making any drastic decisions.

3. ????...seriously, I don't know what comes next. Which is why steps one and two are so damn important! >:(
Steam: LimpingFish
PSN: LFishRoller
XB: TheActualLimpingFish
Spotify: LimpingFish

Peder 🚀

I think keeping multi-platform in mind when doing a new version (4?) would be smart even if initially there would be no plans to support it (when choosing 3rd-party libraries etc).
Though I pretty much agree with all your points LimpingFish.

Crimson Wizard

Quote from: LimpingFish on Fri 21/04/2017 00:07:43
Talking about native iOS/Android/Mac/etc port support in the 3.x builds. It's not going to happen. The best you can hope for is third-party ports of the engine, such as the Android and PSP ports currently available.

I am not following this, tbh, what is a difference between "native support" and "third-party ports of the engine"?

There are iOS and Mac ports used by Wadjet Eye, its just that you need a technical specialist to integrate your game with them (Janet Gilbert does that for WE games).

LimpingFish

Quote from: Crimson Wizard on Fri 21/04/2017 00:39:22
I am not following this, tbh, what is a difference between "native support" and "third-party ports of the engine"?

Well, what I mean is that we won't get a version of AGS that has a "Export to..." option for iOS/Android/etc that presents you with a ready to publish file for the App Store or Google Play.

A lot of people seem to want that one-click option, along the lines of what Game Maker does. My argument is that this expectation is too much, for the situation we find ourselves in, and that, unless we're talking about a mythical rewrite of a mythical AGS 4.0, we would be better suited putting a pin in that particular line of thinking. Instead of wringing our hands over what AGS can't do, we should be ensuring that what it can do remains supported.

But let me clarify, because I'm starting to confuse myself. How I see it is, and correct me if I'm wrong, AGS 3.40 by Crimson Wizard is the official version of AGS, as opposed to, for instance, the Draconian build of Alan V. Drake. As it stands, projects created with AGS 3.40 can be run on other platforms through the use of a third-party ScummVM-like wrapper (Android, PSP, etc) or through a combination of the existing Mac port and some extra technical wizardry involving other coders (iOS/Mac). Without a rewrite of AGS from the ground up, it's highly unlikely that these methods will be supplanted any time soon.

If we want to keep that official AGS 3.4x build going, I feel we desperately need to pare back people's expectations, and jettison everything that isn't integral to achieving the best possible version of that official build that we can, so that future maintenance will be focused, concentrated, and kept to a minimum of fuss. If this means no ground-breaking new features, or losing backwards-compatibility and old OS support, so be it. This also means that multi-platform support should remain the domain of those willing to put the work in, and not something that should fall on the shoulders of the person in charge of overseeing continued development of the offical build. This isn't to say that this person can't be mindful of these other coders work, though.

If there comes a point in the future were somebody wants to attempt a rewrite of AGS, be it you or somebody else, that's great. All the things 3.4x can't do and all the features it lacks can be tackled then, and everybody's wishes and dreams can be fulfilled.

We keep hearing about how the old code is a mess, and how it holds back what can be achieved, creates bottlenecks, etc. That may be, but, though it might be ugly, it works. We're playing games, free and commercial, that exist because AGS 3.40 does what it's supposed to do.

For that reason alone, it must be supported.
Steam: LimpingFish
PSN: LFishRoller
XB: TheActualLimpingFish
Spotify: LimpingFish

scotch

#77
Hey guys. I've mentioned this on Discord a bit before, and AGA pointed out this discussion. I haven't read it all yet but I will! Just thought I'd update people on what I'm doing if they don't know.

Years ago I was reimplementing the run time engine so that I could make web games. This was back when Flash was the only practical option. I recently salvaged that work and ported it to modern JS/WebGL because I'm trying to get more open source code out lately. I hope it'll be up on Github over the summer (but I'm currently moving continents and have to work to support that). IMO it's the best bet we have for new engine work. I will of course be looking for contributors so look out for it if you like that sort of thing.

I won't get into why I think it's important to do when people are making nice games in more complex tools like Unity. Just to say I obviously do think there's some value in it. Also I also don't think new features should be done on the C++ engine because it's too hard to build let alone refactor. If I do get this project moving properly I would suggest a freeze, and then 4.0 to be on the new code after community discussion on what features are in demand.

Rough status:


  • Compiled game asset/module recompiler works for most historical games, but code needs refactoring, and ancient dialog scripts need converting.
  • AGS Script VM feels reliable. Relatively fast and debuggable. Plays nice with JS objects so you can implement modules in JS or AGS script - whichever is more appropriate.
  • AGS API is only 25% implemented. This is where all the drugery is. Each of the 1000+ API items in https://dai.io/jagse/misc/agsapi_definition.js must have an implementation, but I'm getting down the list. Boring but also relaxing. It's decoupled so that the legacy stuff is emulated in the API layer and the core engine remains clean.
  • Rendering is WebGL/ES only and is fast and supports effects shaders.
  • Game logic, character animation, pathfinder stuff still has its quirks but it's getting fixed as the API gets testted.
  • Cross-platform font rendering needs some consideration.
  • Async asset loading needs some work.
  • Save states aren't implemented at all
  • Need to make a lot more test games so I can iron out differences between AGS event loop and mine.
  • Desktop/mobile builds needs to be done. Platform stuff is abstracted so it's easy but I'm leaving it until the engine functions properly.
  • Integration with the editor will be started at that point. At the least I'd hope for an Export to {Platform} feature.

I'll update you when I get enough working that it's worth opening up for contributions.

Edit: I should note this is a fresh implementation using the very good API reference as the standard. I'm using the C++ source as a reference but there's no transpiling involved, so it likely never will operate *precisely* like the original engine. My hope is that most old games will be completable after conversion. Maybe a some games will break but that's the cost of going unicode-only, hardware accelerated only and gaining a maintainable codebase.

Snarky

#78
That sounds like a really interesting project, scotch.

But if we're moving to a fresh codebase, wouldn't it be a great time to rethink a few of the basic AGS design decisions, rather than rebuild it to be "exactly" the same with many of the same problems?

Things like...
  • Unicode supported from the start in all String handling
  • Remove all the hardcoded Sierra stuff (the UI, cursor modes, Sierra-style speech, points, etc.) which is only in the way whenever you're making a game with a different UI (which is most of the time) â€" this should be a module or template instead.
  • Get rid of the ridiculous AGS remapping of certain colors and make everything 32-bit.
  • Allow 256 levels of transparency (since you have 8 bits of alpha), rotation by floating point instead of just by integer degrees, etc.
  • Rethink addressing of resources (essentially the name/array index thing we've been discussing for sprites and audio clips).
  • Possibly allow sub-pixel positioning? Maybe make all coordinates floating point?
  • Implement hotspots so a script can easily find their on-screen position, to support hotspot highlighting.
  • Rethink loops, views and walkcycles. Perhaps instead of hardcoding a set of view angles and a set of defined character views (normal view, speech view, thinking view, idle view), make this something you can define per game/template.
  • Possibly rethink how to do non-blocking background events (since all the stuff with timers, repeatedly_execute() and splitting scripts across different functions is one of the main problems newbies have). OTOH, Calin argues that the AGS solution to concurrency is easier than how other engines do it.
  • Better support for script organization, moving handlers for character and GUI events out of GlobalScript.
Maybe you've already fixed some of these things, and maybe it's better to leave some as-is. (And some might be more on the editor side than the engine side.) I'm not saying we should redesign AGS completely (if we were making a new engine from scratch, one thing I would do would be to find other names for "Character" and "Object" to avoid confusion with the programming terms: probably "Actor" and "Prop"), just fix a few legacy issues that really don't make sense in this day and age.

Crimson Wizard

#79
I wonder how many people are secretly making an AGS remake on their own without knowing about each other?
I am aware of at least one more, which I was interested to participate in.

This is both encouraging and worrying. On one hand there may be several remakes emerging in the following years. On the other hand, everyone is working alone, using their favourite technology.

But I guess, this is just how things are.

And, I am kind of glad scotch is making what he described, because that means that I won't have to worry about rewriting engine renderer to modern library, which was bugging me.

SMF spam blocked by CleanTalk