AGS 3/4 short-term roadmap for next update(s)

[ivan-mogilko]

To recap current post-3.5.0 situation: in the end of 2019 it seemed that there's certain momentum gained with priorities discussed and @sonneveld finally preparing a SDL2 port branch, but then things stalled again unfortunately.
There seem to be big deal of my own fault in this too, thus my intention now is to set up a quick plan and make sure a step is made (or steps...).

What do we want to have

Guess the general conclusion was that:

• We want to keep a backward-compatible branch which will support all existing features and may run old games (aka ags3);
• We want to have a branch without backward compatibility where we may do any experimentation and big overhauls we like without worrying of compatibility (aka ags4). (Which may or may not have old game support back later depending if a good data migration method is developed or not)

What are priority tasks at the moment

• Better backend (SDL2).
• Better port support: mobile, and probably console (i.e. Switch) in the perspective if we manage to implement it in the main repo. In the worst case we may refactor engine to let others apply their custom console backends/plugins more easily.
• Improve game source editing, which roughly splits into two subtasks:
  • make all the game source use open (text-based) format;
  • separate game building into multiple tools capable of running outside IDE and build process launched from command line.
• Improve out-of-the-box game packaging for ports (e.g. Android, which currently may be done by editor plugin).
• Make a plan for "AGS 4" engine/editor revamp, because we need some concept goals for that branch, besides generic "make it better AGS".

How to divide tasks between ags3/ags4, in principle

• If it's about backend and engine's perfomance, then it's applicable to both ags3 and ags4. Ideally, backend should be same in both. Besides that ags3 may need extra code to support old features, and ags4 will require more code to support new ones in the future.
• Improvements to game authoring tools should be prioritized for ags4. Because ags3 is for bacward support, changes should be limited to enhancing what we already have where it's possible to do without spending much time; also note it's not known when ags4 builds will begin rolling out.
• Ideally there should not be any format changes in ags3, both in project and compiled game.
• Any serious game changes go only to ags4. For ags3 updates - only minor additions, if they actually make difference for existing game projects, and only if there's spare time for that.
  
  As soon as there's defined ags4 roadmap, ags3 game updates should cease naturally.

Primary tasks for the nearest future

With all the above said, here's a table of priority tasks:

Task	AGS 3	AGS 4
Switch to SDL2 backend	yes ignore non-essential differences for now, fix broken compatibility later	yes allow to "cut corners" and disable certain things, as some features may be reimplemented differently later
Update ports	yes	yes
Separate game compiling tool(s)	yes, but use most straightforward approach at least enough to automate - script compilation - game packaging	yes (full revamp)
Redesign project source format	no	yes
Roadmap for big game engine redesign	no	yes

Task: SDL2 backend

Tickets for the reference: #1096
Branches for the reference: https://github.com/sonneveld/ags/tree/ags3--sdl2,
https://github.com/ericoporto/ags/tree/ags4--sdl2-sound-1

I'd like to do this in a parallel ags3-sdl2 branch forked of current master (ags3), because it will take several steps to make all things done, and many things will break in process thus require testing and fixing.
Besides engine itself, engine ports will have to be updated, and also editor will have to be updated to not use Allegro4 (hopefully it will be less complicated than the engine, as it uses only a subset of features from that library).

This could be something like AGS 3.6.

In regards to AGS 4, depending on how this will go we may either merge ags3-sdl2 branch into ags4 directly, or pick out changes and apply over ags4 branch (if merging is too complicated).
I guess in the end ags4 branch's differences will take their impact and we'll have to do things separately anyway.

Task: Engine port update

Tickets for the reference: #600 (?), #864 , #379
Branches for the reference: https://github.com/sonneveld/ags/tree/ags3--android-studio, https://github.com/sonneveld/ags/tree/android-64bit,
https://github.com/ericoporto/ags/tree/ags3--android-studio,
https://github.com/ericoporto/ags/tree/opengles2-render

For ags3 there were some improvements to Android port prepared by @sonneveld, which I'd like to have applied. Probably they will have to be added before SDL2 update.

Task: Compilation tools separation

Tickets for the reference: #872, #1007

Wiki page on existing game files and build step table: https://github.com/adventuregamestudio/ags/wiki/AGS-Game-Build-process-(3.5.*)

Task: Project source redesign

Tickets for the reference: #469, #1008, #1281

Other older tickets with roadmap drafts, for the reference

AGS 4 refactor/rewrite master ticket: #450 (pretty early, may be outdated now)
Sonneveld's draft for 3.6 engine/backend perfomance improvement: #762 (may borrow some ideas)
also note the idea about data migration between engines: #762 (comment)

[ivan-mogilko]

I've been reconsidering the status of the master branch recently; originally (early in 2020) my thinking was that there could be a smaller 3.5.1 update with both some utility improvements and few new script API additions, some of which were added already. But as time goes it seem less a good idea to have another API update in backward compatible branch, for various reasons. Besides a need to maintain more versions at the same time, this may keep Editor users at the old branch and delay transition to newer one. Doing any API updates in the old branch is also awkward because you try to keep changes to minimum, and thus loose an opportunity to make a better feature redesign where it would be desired.

So, my current thinking is that we should not have any new versions containing API changes in the older branch, and only have perfomance updates (as stated above in this ticket). For this reason, the post-3.5.0 master branch should not become a 3.5.1 version as it is, because it already contains new script API.
What I consider to do with it instead is to create a new branch at the point before any script changes were done, call it somehow to make it clear it's a backward compatible branch ("ags3", or maybe find better name), and then copy all non-API changes made since 3.5.0 there. That might become a 3.5.1 update. This is also where we merge SDL port, creating e.g. version 3.6.
(There's an option to skip 3.5.1 completely, assuming we instead focus on polishing SDL version to make it fully usable asap, but it may not go as well as I hope, so maybe 3.5.1 could still be released as a small improvement update before SDL port is safe enough to use for actual game development)
The current master may then be merged with "ags4" and basically we continue to develop based on what is now in "ags4" branch.

The SDL port will be applied to both old branch and new one. This is still might be possible to do in one go as "ags4" for now can receive merges from master without serious conflicts (more or less). Any further perfomance update will probably have to be applied separately, as branches will become more different over time.

We still need to think what version number we should use in the new branch. It definitely should be > 3.6, as 3.6 is for backward compatible branch with SDL. Maybe it makes sense to jump over couple of numbers just in case there will be other significant updates in the future (although idk if it's worth to do so).

[AlanDrake]

I agree with the plan.
We could go for version 3.8 for the new development. I think reserving 3.7 for a backward compat major rewrite is enough.

[ivan-mogilko]

Following the idea from above comment, reused existing "ags3" branch (looks like I forgot to delete it earlier), merged latest release-3.5.0 in and cherry picked commits from master that only contain perfomance/utility enhancements and bug fixes applicable over 3.5.0.
https://github.com/adventuregamestudio/ags/tree/ags3

[morganwillcock]

To make the CI work again where should the change go?
#1131

[rofl0r]

so the SDL2 version will become 3.6 now ?

[ivan-mogilko]

so the SDL2 version will become 3.6 now ?

Yes, this was the initial idea. 3.6 should be a SDL2 port with backward compatibility.

[ivan-mogilko]

An update: there are following branches now:

• ags3 -- a backward compatible branch, still based on allegro 4, has some commits made after 3.5.0 (without changes to game features);
• ags3--sdl2 -- a SDL2 port made on top of ags3;
• ags4 -- compatibility breaking branch
• master -- its status is currently uncertain, in short it's a mix of ags3 changes and some additions to script api and game features which were not "officially" announced yet (some people could have used this, but they probably may update to ags4 too).

I guess, if ags3/ags4 division is surely decided, then ags4 and master should be merged, for the second (and hopefully final) time.

SDL2 port needs extensive testing, so it's probably too early to merge into ags3 and ags4; at least CI must work correctly before it's done. Then we may put SDL2 version (ags3 based) on forums to let more people try it out.
Perhaps also people who already use ags4 for making games (@AlanDrake ?) might do tests with sdl2 version. I might create a temporary ags4--sdl2 branch for easier testing if necessary.

Something else that has to be decided actually, in regards to Windows version, whether we distribute engine dynamically or statically linked with SDL2. AFAIK the reasons for static linking with allegro 4 was simplicity of game installation (you basically just need an exe), and I am concerned users may not like having to add extra SDL2.dll, as it's another thing you can forget, or other reasons.
Technically, static linking seem possible, there's short notice here: https://wiki.libsdl.org/Installation, which also gives a link to this reference: https://hg.libsdl.org/SDL/file/default/docs/README-dynapi.md (idk how much relevant to us)

[rofl0r]

ags3--sdl2 -- a SDL2 port made on top of ags3;

imo this should be merged into master right away so that it gets some more testing and development on 3.6 can proceed.

[ivan-mogilko]

To clarify, what's currently in "master" is not meant for 3.6. This is the reason why I created separate ags3 branch. The master branch has already contained changes to script and game data, which I dont want to apply onto compatible branch anymore (I made a mistake with planning these changes in the past).

But your suggestion implies that "master" should stay at "ags3" for now at least until 3.6 is released?

Maybe I planned everything wrong again.

[rofl0r]

But your suggestion implies that "master" should stay at "ags3" for now at least until 3.6 is released?

my understanding was that ags4 is, well, the far-in-the-future branch, ags3 stays basically 3.5.x with only backports of bugfixes, and master becomes the 3.6 version which is basically 3.5+SDL2, plus all future developments targetting 3.x, backwards compatible to all 3.x games .

[ivan-mogilko]

As explained in the head post, I thought to have 2 branches - ags3 and ags4, but perhaps I was not clear about ags4 being a master branch.

We wanted to switch to ags4 as soon as possible and make it master, because there are people who would like to continue developing it without having to deal with restrictions imposed by all the compatibility code in ags3.

I would not want to do any game-related development on top of ags3 anymore, because it's becoming more complicated, and also inconvenient and unnecessary in presence of ags4 branch. Basically it becomes unclear why do we need an active ags4 branch if 3.5.0+ is still being developed. Or other way around: why continue adding more stuff in backward compatible branch when we have the one that allows to do bigger changes. We also simply don't have so many contributors to regularily develop in two branches at the same time.

The only thing that were delaying this was SDL2 port, because I am persuaded that ags3 will also benefit from being based on a contemporary library. My thinking was to get SDL2 into ags3, and then to ags4 as soon as it becomes clear that it's a stable thing.

Regarding "master" branch, I made a planning mistake in the beginning of the year, and already pushed some new game features there. But now I am in doubts about these.

I see three ways out of this:

1. Consider current "master" to be "ags3", with these additions, and then ofcourse also add SDL2 port there, and continue developing as 3.6.0 until it's stable. (Optionally, if SDL2 takes too long to polish, we could also release an intermediate 3.5.1 using only changes from before SDL2 code is added). This is simplier, but it also means that besides SDL2 and related problems we will also have new API and game functions that potentially also may require fixes and optimizations, creating extra burden.

2. Merge current "master" into "ags4" again to make sure ags4 has all recent commits, then reset "master" to "ags3" head. Add SDL2, and continue as in p1. The upside is that 3.6.0 will contain strictly SDL2 and some utility enhancements. The downside is that, well, resetting master is not a good thing and it requires everyone else to fix their local copies.

3. Merge current "master" into "ags4" (or vice versa) and keep it there. Thus ags4 becomes new master. SDL2 is being finished in ags3 branch as usual, and merged/ported to ags4 (whatever is possible) when it's stable. The upside is again that branches are well separated functionally, but the main question, I guess, is whether it's fine to do changes as big as SDL2 port in a non-master branch.

[rofl0r]

my opinion is that it's a mistake to make ags4 master and focus all development effort there, because to me it seems it will lead nowhere. the ags4 effort has no clear goals apart from "the old code sucks, let's rewrite it without caring about legacy"-i've rarely seen such an effort succeed, especially given that those that propagated this huge undertaking rarely seem to write code at all.

my preference would be to make, as written above, the ags3 branch a legacy-fixes-only, make 3.6 (SDL2) master and focus main effort there, and leave the ags4 branch as the playground that it currently is.

[AlanDrake]

Define "main effort", @rofl0r.
AGS3 only needs SDL2 and bugfixes, anything else could cause regressions, or annoy ScummVM devs who want to port the engine.

Ags4's branch goal is to make development less painful, it's basically ags3 with new features. and no backward compat. It works fine and I'm using it. We'll probably dub it AGS 3.8 or similar.

When it comes to making new games, nobody needs to deal with three types of legacy savegames, obsolete game structures and systems that were replaced once or twice.

[ivan-mogilko]

the ags4 effort has no clear goals apart from "the old code sucks, let's rewrite it without caring about legacy"

Current ags3, or 3.6, also do not have any clear goals whatsoever. All these years it was a slow drag towards unknown. Improve a bit there, and a bit there.
Every time I was thinking about any bigger goal, I found myself concerned about legacy compatibility and quickly lost enthusiasm. This is one of the reasons why today I find myself uninterested in doing any big work on AGS.
(Several years ago I already had a branch with lots of major changes, which later dropped and deleted, because it became too ugly trying to maintain compatibility with old scripts.)
I am not saying this legacy support problem is unsolvable, with certain effort it definitely is, but personally I don't have neither energy nor interest to do this anymore. And I don't think anyone else was interested in this, except maybe Nick Sonneveld.
At the same time, keeping this support in the new versions has less and less practical sense.

make 3.6 (SDL2) master and focus main effort there, and leave the ags4 branch as the playground that it currently is.

Alan's question's right, what is the main effort in this context? Why have it in compatible branch, what is it for there?
And how to make ags4 a "proper" branch and not a playground, if not by starting actively working there?
There were multiple ideas I and some other devs mentioned in various discussions that we wanted try, they are just not documented properly anywhere. Guess, I simply did not know whether to bother.

I feel like this discussion is going in circles many years. This whole project was a giant mistake from the beginning. We should not be developing new game features in the engine meant for running old games. Once all the ports were stable, we had to make another branch, or even another repository, and continue development there. These are separate tasks, each done by people who are interested in them. To be frank, I was never really interested in supporting old games, but I had to feeling responsibility for the previous work (and hate myself for this).

[fernewelten]

As far as I can read up on the discussion that led to ags4, a lot of thought and effort had been put into it and the roadmap had been determined after a lot of painful deliberation.

So why not continue with that roadmap? @ivan-mogilko 's #3 would be nearest to the roadmap as it had been originally planned.

[fernewelten]

"the old code sucks, let's rewrite it without caring about legacy"

Actually that's a beautiful motto to go by. Improve or redesign or add in moderate steps, and whenever local code stands in the way that is only needed for compatibility to 2.x, drop that code locally. Whenever a largish body of decluttered, augmented code has accumulated, look for ways to improve/refactor the high-level structure.

I wouldn't suggest rewriting the old codebase completely in one go, but AFAICS nobody has suggested that, at least not here.

IMO it would also be fine to just drop large blocks of code altogether if those support features that the contemporary OSs don't support any longer (e.g., the Windows game explorer?), or that have become moot (ancient file formats). Provided those are easy to confine.

[rofl0r]

well, i believe there was at least one big item on the ags3 roadmap still: decoupling the build tools from the editor. and i don't think this touches any code that can change behaviour for older games.

To be frank, I was never really interested in supporting old games, but I had to feeling responsibility for the previous work (and hate myself for this).

well, you may hate yourself, but the many people that can still play all these beautiful titles due to your work certainly don't. you've done a great service to the community, tbh.

[rofl0r]

When it comes to making new games, nobody needs to deal with three types of legacy savegames, obsolete game structures and systems that were replaced once or twice.

if i was to make a new game, i'd certainly care whether the features my game uses work only in this particular development version of ags i'm using or whether they will be seen as legacy and removed in the very next engine version. if you make a commercial game you could maybe think at first "it's a one-off project anyway", but half a year later you may want to support a new platform (like android) that's coming along and is now supported by ags4, but then you'll have to backport all features you need on your own to your now old engine version.

[ivan-mogilko]

well, i believe there was at least one big item on the ags3 roadmap still: decoupling the build tools from the editor. and i don't think this touches any code that can change behaviour for older games.

This may be as well done while having ags4 branch as master, either in ags3 first and merging to ags4, or even in ags4 itself and then backported to ags3 (minus any format changes if they happen in ags4).
It's just that there is already some work being done for modifying editor in ags4 (like most recent #1138), so it may be simplier for most contributors to work in that branch knowing they may easily replace code or old design decisions that they don't like.
And not everyone would want to work on this task either, so they would not need to wait to when ags4 becomes master, wondering whether meanwhile ags3 may get code changes conflicting with their work in ags4.
Implementing this to ags3 could be done by people who are more tolerant to dealing with legacy code or features would they happen to get in a way.

But it's a good idea to review what is supposed to be done to achieve this "decoupling" milestone. I was gathering related tickets in the github project: https://github.com/adventuregamestudio/ags/projects/1 (was toying with these "projects" out of curiosity, but they may be ignored). I also wrote this quick overview in the repo wiki: https://github.com/adventuregamestudio/ags/wiki/AGS-Game-Build-process-(3.5.*), specifically interesting is Build steps table.
We need to specify what is the final goal of this decoupling: what should be outside of editor, what data should be put outside of a bigger file blobs, and make checklists of what would be necessary and enough for backward compatible branch (ags3).

[ivan-mogilko]

if i was to make a new game, i'd certainly care whether the features my game uses work only in this particular development version of ags i'm using or whether they will be seen as legacy and removed in the very next engine version. if you make a commercial game you could maybe think at first "it's a one-off project anyway", but half a year later you may want to support a new platform (like android) that's coming along and is now supported by ags4, but then you'll have to backport all features you need on your own to your now old engine version.

The features that were (or still going to be) cut in ags4 are all considered obsolete for more than 10 years, and people are either not using them anymore, or not advised to use anyway. From what I understand, people who start their games today in 3.5.0 will likely be able to upgrade to "ags4" with minimal trouble.

We ofcourse understand necessity of transition between versions, and not like want to cut or rewrite everything at once. We are also regularily in touch with game developers and learn what problems they have with the program.

Idea was that at start "ags4" will be supporting latest ags3 project formats. In a rare situation when someone wants to upgrade their ancient game or game still using ancient features to the newer AGS, they do upgrades in steps. First upgrade to latest ags3 (3.5.0 or 3.6.0 etc), then upgrade resulting project to whatever "ags4" is, and so forth. Similar thing had been already done, I've seen people upgrading very old projects from pre-2.72 era first to 2.72, then to 3.2.1 and 3.5.0.

In this transition there are two main points afaik: updating game project (assets) and updating script (as API may change).

Updating game project could be done by continious loading/saving them in steps, across few AGS versions, as explained above
(@morganwillcock also suggested someone could provide project conversion tools for this, that's an option for any interested volunteer)
The worst case scenario is when there's no direct equivalent to old data. There's an actual example of this: since AGS 3.* "global messages" and "room messages" were deprecated, and suppose to be manually replaced with String arrays in user script if you update from 2.72. True that in such case user would have to do extra work rebuilding the game functionality, but that to be expected if your game project is so old.

When updating script and encountering that some API was deprecated users normally replace it with new functions. If there are too many of these, it's possible to write a "compatibility layer" as a script module: such module would provide functions with old names which internally use new API. (I believe it's fairly possible to use this method withing ags4 and support almost all cut-out features, as they have equivalents in new script)
Worst case here would be if the feature does not have any direct equivalent, this could happen if something was completely redesigned, or old feature was considered a bad idea (example: Character.IgnoreWalkBehinds which is a hack that breaks z-order logic). Well, yes, in such case user will have to rework the game. But again, this is to be expected if you upgrade across many versions.

[persn]

But it's a good idea to review what is supposed to be done to achieve this "decoupling" milestone. I was gathering related tickets in the github project: https://github.com/adventuregamestudio/ags/projects/1 (was toying with these "projects" out of curiosity, but they may be ignored)

Just want to chime in and say that I like that the tasks are easy to find in a board like this, makes it easier to find them when I want to orient myself on the current status of the decoupling

[ivan-mogilko]

Alright, since there are at least few things ought to be done for ags3, I think to retain ags3 as master branch for now. But because current master contains script and game changes, which I won't like to make part of further ags3 releases, I also would like to move (basically reset) master from its current position to ags3. I know this is not a very good thing...

SDL2 port will be merged into ags3/master as soon as build server can build windows and linux at least.

Ags4 branch may be freely developed further in parallel. I don't know how easy that would be to merge or port any things from ags3 to there, depends on changes. It's best to merge sdl2 port into ags4 too as soon as at least our build server can make windows and linux builds, that might make transition easier for developers.

In regards to code changes the rules remain: ags3 should not have any new game features, only fixes, perfomance enhancements etc. All new script api and game features go into ags4. This may also make sharing things between these two easier, in theory (so long as game and utility engine code is nicely separated).

[ivan-mogilko]

Alright, since there are at least few things ought to be done for ags3, I think to retain ags3 as master branch for now. But because current master contains script and game changes, which I won't like to make part of further ags3 releases, I also would like to move (basically reset) master from its current position to ags3. I know this is not a very good thing...

Ok, done...

[messengerbag]

I agree with the plan.
We could go for version 3.8 for the new development. I think reserving 3.7 for a backward compat major rewrite is enough.

Just bringing this up in case some of you devs missed it, an argument for why "ags4" should be released as AGS 4.0: https://www.adventuregamestudio.co.uk/forums/index.php?topic=58611.msg636629477#msg636629477

[morganwillcock]

Just bringing this up in case some of you devs missed it, an argument for why "ags4" should be released as AGS 4.0

Has anyone said it wouldn't be? It's just a branch name.

[messengerbag]

Ivan wrote on the forums:

We do not yet know what number will [ags4] use, but probably we'll skip couple of them to reserve for "ags3" branch, so somewhere in the range of AGS 3.7.0 - 3.9.0.

And Alan Drake wrote in the thread above:

Ags4's branch goal is to make development less painful, it's basically ags3 with new features. and no backward compat. It works fine and I'm using it. We'll probably dub it AGS 3.8 or similar.

I'm suggesting that it shouldn't be released as AGS 3.8, but as AGS 4.0, for the reasons given in the forum thread. (And another reason: if "ags4" becomes AGS 3.8 and then later there is an actual AGS 4.0, it's going to be confusing to go back into the archives and come across discussions such as this, particularly for any future developers who weren't involved.)

[morganwillcock]

Thanks. I couldn't understand within the context of the forum thread where the confusion comes from, but now I do and I agree with you.

[AlanDrake]

I have no strong preferences.

[ivan-mogilko]

SDL2 backend is in master branch now.

AGS 3.5.1 is the last version that has Allegro 4 backend, and it may be found in "release-3.5.1" branch. Regular patches could be still applied to that branch of course.

I hope not, but if there will be a dire need for a larger allegro-based update, version 3.5.2 may be created by branching of release-3.5.1.

I can also create a more explicitly named branch or tag marking the last allegro4-based version, if necessary.

[ivan-mogilko]

From now in master branch we work on completing SDL2-based engine for AGS 3.6.0.

It's important to note that SDL2 backend was also merged into AGS4 branch, so it's going to be used for all future AGS development.

In parallel I also started making stand-alone tools to replace the logic embedded within the Editor. See #1262, #1264, and one more may be coming soon. These tools on their own do not have ties to particular version, but to complete their integration we would have to modify the Editor too. That might be done as a part of 3.6.0, or as a next update, depending on how soon all necessary tools will be ready.

[ericoporto]

I would like to suggest on ags3 to keep editor build with current implementation and additionally have the command line tools separately - deliver them in a zip/tar.gz called ags3-sdk. The disconnection is not going to be a small task, I predict it will be hard to sync ags3 to ags4 during this disconnection. Giving a bit of time with both should help picking up differences. Then later, disconnect the Editor on ags4.

The idea is to have a release that people play with that have both, I am curious to see what bugs people would pickup by using.

[ivan-mogilko]

I was wondering if we may do this in 3.6.0, but guess you are right in that these tools may require more testing.
The Editor will have to have an internal code replaced with process calls, and the project folder structure might change to accomodate for any temporary output.
This is also the reason why I was tagging these tool tasks with a different milestone (not related to exact version).

But I still consider doing this in ags3 even if as an extra update after 3.6.0. Maintaining game building in both editor code and tools will become a big annoyance. I.e. with the unicode translations I already had to change both editor and translation compiler tool, and they have to be tested separately.

[ericoporto]

let's move the disconnection to a 3.7.0 then. Just have a single major release with both. There's already a switch of backend of the Engine in 3.6.X, a switch of build tools is a new surface for bugs, I really would like having both together for a little time to try, test and compare things, and also getting feedback.

[ivan-mogilko]

Closing this now, so making a quick recap.
Current state: 3.6.0 is released and 3.6.1 beta in work (planned performance / convenience update); meanwhile ags4 has a certain progress.

1. Switch to SDL2: done in 3.6.0 (ags4 updated). (See a path towards moving from Allegro to SDL #1096 and few other related tickets.)
2. Better mobile support: Android port is upgraded in 3.6.0, iOS update is in works (iOS SDL2 based port for release 3.6.X #2009), the console ports are still not included in our project, but supposedly our move to SDL2 made it easier for the third-parties to create and maintain theirs.
3. Out-of-the-box game packaging for ports: added Android and Web (emscripten) packaging to the Editor since 3.6.0, which is quite useful.
4. Game source update: rooms were remade as open format in ags4 (Editor: change game project's Rooms to open format #469), which is a major improvement. But two tasks still remain, one is sprites storage (Editor: change Sprites storage in the game project to open format #1281) which is a highest priority in this context, another - dialog scripts (Editor: store Dialog scripts outside of Game.agf #1008).
5. Game building separation: sadly the progress here was minor, we have tools mostly enough to compile game scripts (including dialogs) and package them into the game. Two major tools missing currently are one to compile main game data from the Game.agf (Tool: Build main game data from Game.agf #1188), and compiling spritefile from the source images (steps may vary depending on the engine branch). With the room source update in ags4 there's also now a need for a standalone tool that compiles room binaries from xml + resources too. For more information on tools better see a dedicated milestone and a project.

---

On the future plans, for ags4:

• 4.0 milestone
• Master plan ticket with discussion: AGS 4.0.0 Milestone proposal #1298

---

ags3 branch (3.6.* and on) does not have any far going plans at the moment, besides performance improvements and certain engine port updates. Finishing tools for this branch would be preferable, since people might keep using older versions of the Editor for a while, plus it might help recovering older projects. There's no "master ticket" for the next update though, only milestones:

• 3.6.1 update,
• 3.* minimal toolset