Future AGS development

[SuperDre]

The "clues" which tipped you off would really to me be indicative more of a desire to drop cross-platform compatibility instead of backwards compatibility of the engine..but in any case, I've responded to both interpretations with my opinion on the matter, so let's not get off topic here.

Personally I think crossplatform compatibility is much more important than backward compatibility.. If it was a seperate engine and data/bytecode set I might agree, but for using a newer engine as a agsdeveloper you still have to load the old project and tweak it. Compare it to say visual studio 2008 and visualstudio 2010, a lot of times you still need to make tweaks just to get your 'older' project running in the new enviroment, same goes for when you switch .NET frameworks..
but then again, I haven't got a clue to the extent of BC in the AGS-engine is.. I would say cleanup/refactoring the code is much more important as keeping FULL BC, and mind you, if cleanup/refactoring is done properly it should even be possible to keep the BC..

[dbuske]

Maybe putting all characters and objects that belong in a room show up in the editor.
Even the main character.

[monkey0506]

What do you mean?? Like the "Characters" and "Objects" selections in the drop-down for what to display in the room?

[theo]

I would say cleanup/refactoring the code is much more important as keeping FULL BC...

I couldn't agree more. The gigantic patchwork that is AGS could do with a nice enema - flushing out old obsolete thinking with a new, modern framework, built for what AGS (and the market) is now and not what it was ten years ago. Contrary to your opinion though, I think Backwards compatibility can go screw itself. I (having worked on the same AGS project for over 5 years now) certainly appreciate the backwards compatibility of all new versions of AGS that I have updated to during its production.  But from a broader perspective, is it worth the bogging down that the code as a whole suffers from now? I sincerely doubt ut.

That said, I have full understanding for why the AGS code base is what it is at this stage, and I fully respect the choices CJ has done during the project as a whole. That it now is a huge patchwork, was inevitable. I'm merely pushing for a flush now, rather than keeping on patching stuff simply in order to open up ancient AGS projects. Look forward, friends!

[Wyz]

I kind of agree with Theo there. Here is what the best-case scenario is in my opinion:
I like the idea of an AGS 4.0 which does not need to be truly backwards compatible so can have a modern codebase.
I like the older version of AGS to be ported to ScummVM so older games can be played on modern systems.
As for the 3.x branch, well I'm not sure but I think we might just keep on patching on that version while AGS 4.0 is under development. This is how a lot of projects work nowadays, and it has some sense in it. As soon as AGS 4.0 is stable either 3.x and 4.x can be made compatible or 3.x can be ported to ScummVM too.

As for now, well, I waiting for someone to take on one of these projects, or another one, at least has some sense of direction. I'll love to join in but I have no time to start these projects myself at the time.

[Calin Leafshade]

Agreed.

Now that the engine is open source it would make sense to stop feature development on the 3.x branch and just bug fix until we have a stable 4.0.

However, no one who has the required skills is likely to volunteer to spearhead the next iteration. Coders that have the time, inclination and talent to lead such a project are, shall we say, thin on the ground.

[monkey0506]

Something I don't understand is why people keep saying that they want backwards compatibility dropped, but then turn around and say that they want a ScummVM port all in the same breath.

The single foremost reason why the ScummVM team has said they do not want to spend their efforts developing a ScummVM port of AGS is the lack of backwards compatibility between engine revisions.

If we dropped backwards compatibility for all prior versions in favor of an entirely new codebase, the proposed AGS 4.0, we would have to guarantee that AGS 4.1, 4.2, 4.3, etc. were backwards compatible at least to AGS 4.0 or the ScummVM team is going to look at it the same as they do the existing branch.

I wouldn't necessarily be against the idea of a fresh AGS 4.0 so long as the 4.0+ versions were backwards compatible with the 4.0 engine.

[Wyz]

I wouldn't necessarily be against the idea of a fresh AGS 4.0 so long as the 4.0+ versions were backwards compatible with the 4.0 engine.

But of course, that's the whole idea. Also not to rush things so that we don't have huge revisions after the 4.x branch goes stable. That way keeping that branch itself backwards compatible would be much easier.

Isn't the 2.x branch pretty compatible with itself? Then the ScummVM team should not have much trouble with it.

[Atelier]

I don't know whether there's a suggestion thread anymore, apologies if I missed it.. but one thing I've always missed and I probably speak for others is the allowance to wrap text in a list box. At the moment if the string is too long it just carries on over the bounds of the box, meaning you can't put long phrases or such without using workarounds.