AGS 4.+ Roadmap discussion

[Crimson Wizard]

As AGS 3.6.1 is closing the final release, and AGS 4.0 is getting public wip releases, I'd like to begin discussion of a roadmap for the future updates.
I suppose that 3.* version branch won't get any major releases from now own (unless someone would want to add more engine ports with full backward compatibility), but there might still be minor updates with fixes and performance improvements.
4.* branch, on another hand, should get a full attention now.

With the opensource AGS development there always have been an problem of undefined roadmap, many changes were done randomly or sporadically, this resulted in inefficiently spent work time, and caused various repeating issues. Frankly, I consider 3.5.0 to be the first "proper" release, and 3.6.0 the first "good" release, and much of their content normally should have been accomplished several years earlier.
The state of 3.6.0 and 3.6.1 is relatively fine, I guess; and if you take AGS 4.0, with its expanded scripting features, it's already possible to do alot of things in AGS games. But there are tasks that have been considered priority at start and are not even properly addressed yet. There is still a number of old problems that make users life worse.

I think we need to define priorities for the next major release(s), and determine which important goals may be accomplished realistically. Even if getting to the goal seems to require a lot of work, the path to it may be split into subtasks, and work done step by step, so long as we stay focused on it.

Thinking of existing problems and choosing priorities, I suppose that potential goals may be categorized.

First of all, there is a typical division based on types of users and uses of AGS:
1) Things that are important for the main bulk of users, and for making common adventure games.
2) Things that are important for advanced users, and advanced or non-standard use of the engine.

Then there's a division based on whether we add something new or try to improve existing:
1) A new feature that would open up alot of new or better opportunities.
2) Getting more opportunities from existing functionality, by extending them or letting users customize it (e.g. by exposing something internal into script).
3) Simply improving performance and convenience of existing features.

Eventually there is a "thematic" feature category, that is category related to doing particular work (e.g. scripting, debugging, translating, creating game content etc) or achieving particular actions in the game (e.g. with script, graphics, audio, video, etc).

IMO we could start with defining a list of things, such as
1) Existing features, things you can do, but which are so not convenient that are main source of wasting time and effort during game making ("bottlenecks").
2) Lack of abilities that cause people to do time-wasting workarounds instead of using a direct solution (also "bottlenecks").
3) Functionality which is more or less common in adventure games, at least in particular genres, but not quite developed in AGS yet (the example I'm personally thinking about is a rudimentary video playback).

This refers to both a process of making a game, and game's capabilities.

[eri0o]

Roadmap presumes things are added in a certain order in time.

My thought was ags4 priority in roadmap would be to do breaking changes (changes in things that break backwards compatibility).

• on_text_input should return a string instead of character, this would enable more easily adding IME support. This is for translation when input in CJK should be accepted.
• Switching from old Freetype to a new one. This would break existing text position but ease if we switch from alfont to SDL_ttf or other text rendering library. A new Freetype means we are closer to having Harfbuzz added to support ligatures in translations for languages that requires these.

For scripting, a breaking change that could unlock new functionalities is changing how the bits for each instruction are distributed, I would give a few more bits so we can go from max 128 scripts to max 2048, just so the top limit for scripts in a game is a bit bigger. So if in the future a packaged script module can contain more script files this would make it less a problem and allow people to better divide their codebases. The current workaround is to put all things in a single script file.


I think new functionality can be introduced more gracefully than modifying things that exists, meaning doesn't have to be in a first release.

On the other hand knowing things ahead is useful to foresee if something needs to break to better implement something, so the breakage could be prioritized, or if doing things in such order has some advantage.

[Snarky]

To come at it from a slightly different angle, I think it could also be useful to think about "strategic goals" for further AGS development.

For example, a goal might be "better support for high-resolution games" (which would probably imply things like performance improvements, better upscaling/downscaling of the game window, sub-pixel positioning and smooth scaling of sprites/textures).

Or "better support for distributed game development" (allowing multiple people to work on a project without conflicts). Or "better support for command-line tools and scripts." Or "better platform support" or "better web support" (e.g. letting the web port write saves to real files, or load resources on-demand). Or for that matter "better parser" if we think the way forward is text-input games, or "better ability to integrate with AI services," in case someone feels a need to have ChatGPT-powered NPCs.

It can be a way to let us think about what sort of engine we want AGS to become.

[Crimson Wizard]

My thought was ags4 priority in roadmap would be to do breaking changes (changes in things that break backwards compatibility).

While this has certain rationale, but I feel reluctant about such approach, because in theory there may be many things that may or should break backwards compatibility at some point, but are either hard to predict, difficult to redesign well, or not as important on their own.
I would not want to have a "race" to get as many "breaking" things as possible in the first release(s); this may become counterproductive.

Instead we could define a new strategy of dealing with breaking changes in ags4 branch, that would allow us to progress more easily in case they become needed.

[eri0o]

One limitation that has a workaround through my rellax module is the lack of in-engine parallax support and use of non integers for position of things (specially the game camera). Camera smoothing is much harder if things are positioned using integers.

I would vastly prefer if things were positioned using double instead, this would really enable smooth cameras. In addition, the parallax effect would look much better.

If the parallax effect was in-engine, we could have a camera splitting when characters separate and still have parallax working!

I don't think using floats is good enough for position, specially in large rooms in high resolution games. In this case I also think it should be possible for a room to not have a background at all, so we could instead make-up the things in the room by positioning pieces of things - either objects or room overlays - so that a room in a high resolution game doesn't need all that ram.

Probably pathfinding can still be navigating only in the integer spots fine, but being able to move the camera a fractional amount would make things look a lot better when scrolling is required.

[Crimson Wizard]

Personally, I've been thinking about ancient AGS problems that complicate working with the game, either while creating or when updating one.

1) Having AGS project under source control.
2) Sharing work on a project among team members.
3) Automating game building, preferably outside of the Editor; in simple words - having standalone compilation tools.
4) Debugging games, things like reading states of variables and game objects in the Editor.
5) Making translating games easier.
6) Game patching with smaller-sized updates; in other words - being able to only distribute few modified game assets and merge them with the game on user's computer.
7) Save system which would allow to upgrade game and convert old saves either with a upgrade tool, or some runtime process on load. Also, make it easier for users to customize save contents.

Besides that - anything that is very inconvenient in the Editor, in terms of user interface. One example could be the "room explorer" proposal.


In terms of graphical improvement, I'd mention following things:
1) More performant resource management by the engine. This refers primarily to sprites, so I put it in the "graphics" category. Classic AGS sprite streaming and caching is inefficient for high-res games (also it does not work well on consoles because of their File I/O restrictions). This might require both improving what engine is doing internally, and providing better control to user, in script and game settings.
2) Better video support. This may be important for video-based games, aka FMV games, but that's only one use case.
On another hand, I noticed that some people prefer to make fullscreen sprite animation sequences instead of using videos, as the Theora seems to not support a good enough quality. This is suboptimal, because sprite-based animations require more disk space (even if compressed, total size of all sprites will still be larger than a well compressed video), more memory space (for the similar reason), more loading/preparation times etc. There may be other open-source alternatives, but also there's an option of letting people write video decoding plugins. With the latter, not only we may save on engine's executable size for games that do not need the video playback support (majority of AGS games?), but third parties will be able to support video formats of their own choice.
3) Shaders, user-defined. This has been asked for so long... and this is a "industry standard" in game engines for a couple of decades now. Shader support will open innumerable possibilities for the graphic effects in games. The big question is how to implement this though. I guess, there are 2 major approaches: a) generic Shader API, and b) have users provide separate shaders per graphics driver.

[eri0o]

On video decoding av1 dav1d decoder is the smallest I found that still performs alright.

https://code.videolan.org/videolan/dav1d

I wrote a CMake for building it easily - they use meson. It takes around 2MB (the resulting dll) and the license is alright. If we don't want to ship in AGS itself for whatever we could dynamic load it. The decoding API is alright too. The issue though is encoding av1 is a little slow - for the people making the animations. I don't know when patents expire in the old h264 format, but av1 is something newer. I guess at some point there will be some hardware decoding for it. The vpx stuff when I looked built to 40MB so they would be a lot more bother to build and have available.


I think my general things for porting wishlist is still the same I had in mind

• Multi-touch support, I wrote about it but no one never commented on it. I could implement it if people are ok with the idea I fronted - GUI button multi-touch and pointer API.
• Asynchronous saving the game, every non-Windows, non-Web port the game will hang while saving, so saving async save game would be nice. Console ports require some workaround to have this either way, it would be nice to have in the main engine.

Erh, about complex save game stuff, I guess making it easier for people to create their own saveformat is easier, like, making dictionaries serialize/deserialize easily plus some reflection support so you can read all r/w properties of something and store/load into something.

[Laura Hunt]

As an end user, my list of improvements when looking at what aspects of AGS seem to lag with regards to what seems reasonable to expect from an engine these days seems to be very similar to what's already been mentioned:

- Better performance, especially with hi-res games.
- Improved translation system.
- Savegames that don't break when you so much as look at them wrong. This is so incredibly important in a world where players expect patches and updates to occur automatically and seamlessly.
- More robust audio system. I think most of us would rather have a play command fail silently and produce a warning log than crash the player's game entirely with an NPE.
(- While we're at it, support for real-time audio FX, integration with FMOD, but this might be asking too much.)
- More pre-coded maths functions: distance, abs, clamp, etc.
- Better default scrolling algorithm. Screen scrolling in AGS is super clunky and practically forces you to use an external module.
- Including tween and parallax functionality out of the box maybe?
- Include a pre-compiled Mac wrapper with every new version, so that even if devs need to do some manual work, it'll still be a lot easier to produce a Mac version than compiling from scratch.

Also, on a very personal level, I would absolutely love to have diagonal baselines, for more flexibility in non-traditional side-perspective adventure games. But of course, this is a very specific case so I guess that, like video playback, it would depend on how much demand there actually is for something like this.

I'm sure I'm forgetting about some stuff, but all of this does seem pretty important in my opinion.

[Snarky]

CW's list is pretty much the same things I would prioritize, with special focus on the save game issue.

- More pre-coded maths functions: distance, abs, clamp, etc.

It also occurs to me that if we had function overloading (or generics), offering these would become a lot easier and more elegant, since you wouldn't need separate absInt()/absFloat() etc. functions. I don't suppose that's supported in the AGS 4 compiler already?

(Talking about scripting language improvements, a small thing that's a real pain in the ass when writing modules is that you can't use properties in the module where they're declared, but have to use the getter/setter methods instead—and that IIRC the compiler doesn't throw an error, but it fails at run-time. But this is probably too low-level for a roadmap.)

[Crimson Wizard]

(Talking about scripting language improvements, a small thing that's a real pain in the ass when writing modules is that you can't use properties in the module where they're declared, but have to use the getter/setter methods instead—and that IIRC the compiler doesn't throw an error, but it fails at run-time. But this is probably too low-level for a roadmap.)

I think this might be already fixed in the new compiler in ags4.

[Laura Hunt]

It also occurs to me that if we had function overloading (or generics), offering these would become a lot easier and more elegant, since you wouldn't need separate absInt()/absFloat() etc. functions. I don't suppose that's supported in the AGS 4 compiler already?

Yes! This is one of the things I had in mind and I totally forgot to mention. Such a PITA sometimes to have to convert FloatToInt and back to IntToFloat and so on when a function only takes one type of variable as argument.

[Crimson Wizard]

Well, there are two separate problems here: implicit type casting and overloading.
Implicit type casting allows to assign float to int and back without extra function, but this means possible loss of precision.
Overloading allows to have function of same name which has different argument list.

But in any case, suggestions for script syntax should be separated, because there's currently a single dedicated developer who works on compiler (fernewelten), and overall this category of tasks does not have much connection or dependency on the rest.

[eri0o]

The alternative to Overloading as mentioned by @Snarky would be generics, with generics you could have T <T>abs(T v) (like c# generic math), and then if you use abs(-5) or abs(2.4) it would automatically pickup the type from the value and apply the correct method.

It looks similar but it's different because with generics there is no overloading across Script Modules (which I think can be reasonably complex to implement), and also, functions that aren't using this generic approach are the same, but functions that use the generics approach would be compiled having some different name like abs<int> and abs<float> and the call would be correct adjusted at compile time.

I think when using pure Overloading, all functions need type information in their names and there's some trickery disambiguating across script modules (and maybe plugins too).

[Crimson Wizard]

The problem with templates or generics AFAIK will be that the whole code should be available in script at compilation time. This means they won't work for engine/plugin script API. For these function overloading will be the only way to have multiple variants of the same function.

[eri0o]

Yes, but then you would pay the disambiguation at runtime. And the disambiguation can be expensive - you have to check every script module, plugin and the like to see if there's a match somewhere. I think if Overloading is a thing, it should require some special keyword like "overloadable" or just "overload" so that you only pay for it in functions marked as such. So you could do like "import overload int abs(int a); import overload float abs(float a);" and then only these specifically you would have such. I don't know, I like language that is simpler but I also like things to perform well. 

[Crimson Wizard]

"Overloading" is not resolved at runtime, it's resolved at compilation time. It is compiler that decides which exactly function is called, choosing from the declared variants in the visible scope. Engine only has to do the linking when loading the script, same as usual.
Could be you are confusing it with "overriding"?
E.g. see: https://en.wikipedia.org/wiki/Function_overloading

Indeed, it's likely that function names has to be exported with type infos in their names, similar to how they are currently exported with number of arguments ("name^N").


In regards to "generics", I do not think that true generics are possible in AGS script at all at this point. I do not know all details of this mechanism in languages that support them (like C# or Java), but the way I understood, they require all types to have a common interface. In AGS simple types don't have any interface, and even most of the structs do not have a common parent.

"Templates" could work, maybe, but like I mentioned, they will only work correctly if the whole function code is in the script, because it has to be cloned with different types at compilation time. Of course one may try to declare a template in engine's API, and then let compiler generate calls using made function names, in a similar vein to what you posted above, like "abs<int>", "abs<float>", etc. But that would rely on engine implementing necessary variants, and compiler won't even know which are supported by the engine and which are not, won't be able to report error if user uses the function with unsupported type.

This leaves "function overloading" to be the most obvious choice for the engine API, imo.

[Mehrdad]

Thanks guys for your hard works. I'm 2D animator and not programmer. So I want these in AGS 4.0

1- Increase performance
2- MAC port by Editor
3- iOS port by Editor
4- Custom "Turn before walking". For ex : If character is Left and click Right use  "loop animate" ( I have a custom turning module that wrote by Gurok. It has a little bugs. If you want I can send it for you)
5- Animation sprite editor and put anchor point in character for adjust with previous situation.
6- More than one frames for stand character. For example if character stop it use more than 1 frame for standing ( see Neverhood game)


Thanks in advance

[Crimson Wizard]

4- Custom "Turn before walking". For ex : If character is Left and click Right use  "loop animate" ( I have a custom turning module that wrote by Gurok. It has a little bugs. If you want I can send it for you)
6- More than one frames for stand character. For example if character stop it use more than 1 frame for standing ( see Neverhood game)

I think these two mean supporting transition animations; that is - animations that are played whenever character switches between 2 states, such as walking and standing, walking in one dir and walking into another dir, and so forth.

[Snarky]

Templates would also be very useful, even if limited to script-only. The big benefit I could otherwise see of generics over function overloading is for functions that act on collections (arrays), but templates can solve that.

@Crimson Wizard, I think you mentioned at some point that it might be possible to pretty much just take the component of the C or C++ build process that handles macros and drop it into AGS, since it's more or less its own separate language. Could that also enable templates?

I think all of this is mostly relevant for people writing "utility code" such as modules. So the strategic goal is something like "create a better ecosystem of libraries/modules to address various game needs, by making it easier to write flexible, general-purpose code."

[eri0o]

For preprocessor macros it's somewhat possible to switch for some already existing one instead of our own, but we could make our own better too. The problem with more complex macros is the autocomplete, currently our autocomplete will adjust depending on the available macros while also showing information that is from comments or macros themselves. So the way autocomplete is built would need to be redone.


On the things I would like to improve front, searching things that aren't in scripts, like if you are in an AudioClip it would be nice to be able to see where it's used, including the Views.

[Postmodern Adventures]

My wishes:

-Sound when mouse is over button.
-Assign an image or cursor view in Hotspot properties.
-Easy Parallax in object properties.
-Soft scroll.

And the most important:

-A loud applause for all the people who works in this engine. You're amazing!

[Crimson Wizard]

Script preprocessor may be replaced by a third-party program, because in AGS script preprocessing is based on C syntax. (Autocomplete also could be replaced with something made by others).

But besides the autocomplete, the practial problems with macros are also that:
a) they are not type safe,
b) they increase the size of the code, because macro contents are essentially copied into each place where you call them from. Real templates also increase the size of the code, but only for each combination of type arguments. If you have a template function of <int>, you will have 1 <int> variant of that function generated and called from anywhere. With macro all the code is copied to the calling location each time.
c) they are not stepped into during debugging, also for the same reason as above. Which means that they are going to be more difficult to debug. Also, any errors would report not the lines in macro, but lines where they are called from.

My wishes:

-Sound when mouse is over button.
-Assign an image or cursor view in Hotspot properties.

I'm sorry, but this is small features that are relatively easy to script. I'd like to discuss bigger goals here, especially ones that cannot be solved with scripting or too difficult to script; and don't want this thread to become a collection of "new object property" requests.

[Crimson Wizard]

The situation with generic algorithms would be improved somewhat if all managed types in AGS had one universal parent. Similar to how each class in C# or Java is implicitly a child of "Object" type. Then you could have generic functions or containers working with a pointer to parent class.

This may be tricked in script too, for custom types, as illustrated here:
https://github.com/ivan-mogilko/ags-crawlproto/blob/master/Array.ash
but this trick is limited by the lack of downcasting (and the fact that it only works with custom structs).

[cat]

One aspect, while making the script language more flexible and modern, is to still make it easy to use for beginners. Not all AGS users have coding experience. On the other hand, some features like generics, function pointers(!) etc. will make it nicer for experienced programmers to get into AGS. I think the balance between those two user groups is important.


On my personal wishlist would be:

- Better support for source control/parallel editing/merging e.g. storing room files as xml/json (possibility to recreate the sprite file from sources has been a huge step in this direction)

- Better room editor - this so important part of AGS deserves more love
--having more than 10 objects in a room is cumbersome, because the dropdown in "Edit this room's..." only shows 10 entries no matter how much space there is and doesn't support scrolling with the mouse wheel or a scrollbar.
--undo: It happens easily that I move an object by accident when I forget to lock it. There is no way to undo this and since the room file is not readable I cannot undo the change via source control.
--no copying of room coordinates when in walkable area/hotspot mode (right-click is erase here)

[Crimson Wizard]

- Better support for source control/parallel editing/merging e.g. storing room files as xml/json

Open room format is done in AGS 4.0.

There may be other issues that conflict with team editing, one of those is sprite numbering.
A related ticket was: https://github.com/adventuregamestudio/ags/issues/463 but it's old, and parts of discussion are outdated. We need a new one. It would be beneficial to find potential problems and gather a list of them.

--no copying of room coordinates when in walkable area/hotspot mode (right-click is erase here)

This is done in AGS 3.6.1, where context menu is called by Shift + RMB in area paint mode.
See the notes in the changelist:
https://www.adventuregamestudio.co.uk/forums/ags-engine-editor-releases/ags-3-6-1-release-candidate-rc-1/

- Better room editor - this so important part of AGS deserves more love
--having more than 10 objects in a room is cumbersome, because the dropdown in "Edit this room's..." only shows 10 entries no matter how much space there is
and doesn't support scrolling with the mouse wheel or a scrollbar.

So, there's a proposal to implement a proper room object explorer:
https://www.adventuregamestudio.co.uk/forums/editor-development/suggestion-room-explorer-a-tree-like-control-for-navigating-room-contents/

--undo: It happens easily that I move an object by accident when I forget to lock it. There is no way to undo this

Right, proper Undo/Redo system is something that room editor does not have. The area mode has Undo, but it is implemented suboptimally (by storing a full copy of mask) and has only 1 step.

I have never written a Undo/Redo mechanism myself, but I've seen couple of examples in other projects. Commonly this is done by implementing both forward and reverse operations for each operation that user may do in the editor; each operation has an ID and arguments that may be recorded. When user issues a command, you save the operation info in a list, and run "forward" operation. When user does Undo, you take operation's info from that list, and run "reverse" operation. Redo is done similarly, but having a "undoed operations" list, and rerunning "forward" operation.

EDIT: opened a ticket: https://github.com/adventuregamestudio/ags/issues/2321

[ryu]

3) Shaders, user-defined. This has been asked for so long... and this is a "industry standard" in game engines for a couple of decades now. Shader support will open innumerable possibilities for the graphic effects in games. The big question is how to implement this though. I guess, there are 2 major approaches: a) generic Shader API, and b) have users provide separate shaders per graphics driver.

One possibility is to use SPIR-V for shaders. This is the Vulkan standard, and there are tools to transpile it into GLSL, HLSL and MSL. Does this cover all the graphics drivers currently supported by AGS?

[Crimson Wizard]

One possibility is to use SPIR-V for shaders. This is the Vulkan standard, and there are tools to transpile it into GLSL, HLSL and MSL. Does this cover all the graphics drivers currently supported by AGS?

Possibly.
We also have SDL3 as a potential future backend, and from what I heard it also has an abstract shader language support, although I personally did not dig too much into that yet.

[ryu]

I'm sorry, but this is small features that are relatively easy to script. I'd like to discuss bigger goals here, especially ones that cannot be solved with scripting or too difficult to script; and don't want this thread to become a collection of "new object property" requests.

The suggestion by @Postmodern Adventures points to something bigger. There are many small features that are missing from the engine, but are relatively easy to script. Writing these scripts (if you have the skills) or looking them up on the forums (if you don't) for the Nth time, is a waste of time, maybe not so much for an individual developer, but for the larger community it is.

The best workaround AGS offers today is templates, but that's an all-or-nothing solution. A template may have some features you want, but also others you don't, and reading a template to customize it requires good programming skills that not everyone has.

So one idea for 4.0 could be a mechanism for the community to develop extensions to the engine at a more granular level than templates, so that devs can pick and choose the individual features they need, rather than loading entire templates. For example, someone could create the Sound-on-Hover extension and publish it in some official repo. Does this make sense?

[Crimson Wizard]

So one idea for 4.0 could be a mechanism for the community to develop extensions to the engine at a more granular level than templates, so that devs can pick and choose the individual features they need, rather than loading entire templates. For example, someone could create the Sound-on-Hover extension and publish it in some official repo. Does this make sense?

But there's already such mechanism, it's script modules and engine plugins:
https://www.adventuregamestudio.co.uk/forums/modules-plugins-tools/

A person may script a module, upload it somewhere, and then other people download and import to their games.

The only persistent issue is the lack of organization. This may be resolved by implementing a script module database, or perhaps a in-Editor menu for looking up for script modules in a list of repositories.

[edmundito]

I have an endless list of suggestions, but I will keep it brief. This is based on my own experiences with the engine, watching people develop on streams, and helping others.

Changes I'd like to see, in no particular order:

1. Steps towards a multi-platform editor, at least Linux first. I'd love to see the editor not be dependent on Windows in the long term, and not require people to stick with Windows, either.
2. New GUI editor - to have more modern features such as button customization with 9-point images, group/align objects, change button background color, mouse wheel scroll support, etc.
3. New Dialog editor/dialog scripts. The way modern dialogs are designed is very different nowadays, it's more of a tree structure than a bunch of questions right off the bat. It's also frustrating to not be able to reorder the dialog options.
4. Built-in controller support and parallax scrolling
5. Shaders
6. Memory inspection on breakpoints
7. Changing a module header should not recompile the entire game, only the areas that use it. I'm not sure how to solve this other than introducing a concept of import and auto-import modules.
8. Find and manage modules and plugins from the editor instead of having to come to the forum.
9. Easier Apple (mac/ios) exporting. This is one area that I will try to contribute towards!

[RootBound]

This may be resolved by implementing a script module database, or perhaps a in-Editor menu for looking up for script modules in a list of repositories.

This would be really helpful! I spend a lot of time searching the forums for relevant modules that are not outdated.

2. New GUI editor - to have more modern features such as button customization with 9-point images, group/align objects, change button background color, mouse wheel scroll support, etc.
3. New Dialog editor/dialog scripts. The way modern dialogs are designed is very different nowadays, it's more of a tree structure than a bunch of questions right off the bat. It's also frustrating to not be able to reorder the dialog options.

Seconded for both of these!

Right now I spend so much time drawing different sizes for the same button style, and if during later testing I decide to change the text of a button, I then have to go back and redraw the button image to fit the new text.

And having a tree structure for dialogs could hugely accelerate the user experience there.

Spoiler

I'm assuming @edmundito that this structure would mean a kind of built-in automation of "selecting this option activates this next set of options and deactivates the parent option", i.e., that that would be an inherent property of the "child" options. (Perhaps deactivating the parent option would optional, like a checkbox).

And this would integrate with dialog script somehow, which would still be needed to include any additional actions besides opening child options, like playing animations and so on when the dialog option is selected by the player.

Obviously these details are too specific for this "roadmap" thread, hence the spoiler section. Just wanted to put that out there, though.

[close]

[Snarky]

3. New Dialog editor/dialog scripts. The way modern dialogs are designed is very different nowadays, it's more of a tree structure than a bunch of questions right off the bat. It's also frustrating to not be able to reorder the dialog options.

Are you familiar with the Dialog Designer tool and editor plugin?

[Tomags]

6. Memory inspection on breakpoints

That would be great!

[Snarky]

This may be resolved by implementing a script module database, or perhaps a in-Editor menu for looking up for script modules in a list of repositories.

This would be really helpful! I spend a lot of time searching the forums for relevant modules that are not outdated.

I have a bit of a hard time imagining how this would work in practice. What information would this database have to make it easier to find relevant modules, and how would it be populated and maintained?

I guess it would be possible to search e.g. all projects tagged ags on GitHub, but I'm not convinced it would add a great deal of value.

[cat]

@Snarky Ideally, it would be implemented like npm or nuget or whatever they are called. It would be integrated in AGS an you could browse and add it directly to your game.

But a first step would be a database that supports filtering for supported AGS version or sorting by last update. I have quite a few ideas, but this is actually not part of the 4.x roadmap discussion and should probably happen in another thread.

[RootBound]

@Snarky @cat Looks like this is on a potential list of things for the website update, mentioned in that thread:

And these ones are on the "For future consideration" list (not in any order):
...
- Hobbes: On the topic of Modules/Plugins, I was wondering... if we're building a Games Database, should we also build a Modules/Plugins/Template database where people can upload, categorise etc

[Snarky]

But besides the autocomplete, the practial problems with macros are also that:
a) they are not type safe,
b) they increase the size of the code, because macro contents are essentially copied into each place where you call them from. Real templates also increase the size of the code, but only for each combination of type arguments. If you have a template function of <int>, you will have 1 <int> variant of that function generated and called from anywhere. With macro all the code is copied to the calling location each time.
c) they are not stepped into during debugging, also for the same reason as above. Which means that they are going to be more difficult to debug. Also, any errors would report not the lines in macro, but lines where they are called from.

While it's possible to write very complex macros where this would be a problem, I think in practice most macros would be relatively simple and the drawbacks insignificant. I could definitely see myself using macros to ensure that modules are compatible with AGS 3.4, 3.6 and 4.0, for example, expanding to slightly different code depending on the version number/API-support. (This is probably already possible in many cases, but I don't believe the current preprocessor macros allow you to e.g. turn SETCOORDS(x,y) into Coord.X = x; Coord.Y = y;, for example.)

[eri0o]

(- While we're at it, support for real-time audio FX, integration with FMOD, but this might be asking too much.)

So FMOD is proprietary and I don't really think integration with something proprietary should be in main ags basically because of how ags tends to outlive other software and the maintenance burden and all that. Also the audio has recently been rewritten when transitioning from allegro to SDL and it's working alright right now. Additionally good audio libraries with a permissable license are apparently hard to come by. With all that said, Valve just made today their Steam Audio library apparently fully open source with an apache license

https://github.com/ValveSoftware/steam-audio

Still need to inspect this thing in how easy is to build, how portable this actually is, and if the license has any catches, the support. Anyway, lots of things to check but it appears to cross a lot of boxes in features that it looks promising.

It appears this Steam Audio Library doesn't do decoding it would be something that would replace OpenAL (in our case mojoAL).

[Crimson Wizard]

There's always a engine plugin option, where plugin would replace one part in the audio processing chain, that is roughly speaking:

    Decoding -> playback control -> Audio Filters -> Output

For example, a plugin may provide decoding for some exotic format, in which case it passes decoded data to the engine to play as it plays anything else. Or plugin may provide an audio output in some alternate form. Or it may filter (modify) the sound data in between decoding and output.

In order for this to work engine must be capable of "plugging" plugins into this chain, which it currently is not.

All this is theoretically possible to support, but IMO would require collaboration with game authors, because we need to know how many people seriously need this, which functionality they require, and preferably use their help in designing and testing (not to mention that someone will have to write and maintain the plugins).

[cat]

Since this was mentioned in another thread (not sure if this feature is too specific or fits a roadmap):

The possibility to specify movement per frame of a walkcycle (this is to avoid sliding or showing characters with a limp)

[Crimson Wizard]

Since this was mentioned in another thread (not sure if this feature is too specific or fits a roadmap):

The possibility to specify movement per frame of a walkcycle (this is to avoid sliding or showing characters with a limp)

Yes, I believe that's too narrow and it's better to open a separate discussion for this, or just open a ticket.
But I'd be interested to know an opinion on its design, and which use cases there may be. In the most primitive sense this may be done by flagging a frame as "moving" or "non-moving", but the question is whether will that be enough or not.

There are other animation-related issues that may be discussed separately (or altogether) as well:

- Having a script callback for particular frames. Alan Drake has this in his experimental branch (although not done completely right in my opinion), where he uses this specifically for substituting footstep sounds. I've been thinking more about frame "tagging", where user may mark a frame as "trigger event" regardless of whether it's for a sound or not.

- Having a customizable view schema/template which defines loop roles (directional facing/movement, and anything else). This may come useful if we develop the transitional animations (see this comment above).

[eri0o]

Oh, I only mentioned the Steam Audio Library there because it appears to be similar to OpenAL-Soft (the positional audio, hrtf, filters, ...) but with Apache instead of LGPL license. It appears it comes with additional features too (the proprietary compatibility stuff), but the backend not being SDL (it would be the system ones directly, so the mechanism to select which per platform would change).

I also noticed that it was mentioned something like ags script package management here before

8. Find and manage modules and plugins from the editor instead of having to come to the forum.

So I tried this before

https://github.com/ericoporto/agsmodulelist
https://www.adventuregamestudio.co.uk/forums/modules-plugins-tools/editor-plugin-agsget-version-0-1-0/msg636615733/#msg636615733

It's just really a ton of boring work to archive and update all the AGS modules whenever someone releases something.

I made a plugin for the Editor too - it's broken because I need to rebuild with newer AGS.Types. But you can see how it worked in the gif.

It used a lock file similar to npm

https://github.com/ericoporto/agsModuleList/blob/master/agsget/agsget/EditorPlugin/AGS.Plugin.AgsGet/AgsGetCore/ManifestAndLock/PackageLocker.cs

I documented the logic here - the lockfile specifics I explained in the forums plugin page.

https://github.com/ericoporto/agsModuleList/tree/master/agsget

Anyway, it's actually fully written, the problem is keeping the module list updated. The list can be browsed here

https://ericoporto.github.io/agsModuleList/

I tried to create an issue to then update Everytime a module was released but soon I ran out of steam.

Yeah it could be a website with database and all that but I think it will be an even bigger pain to maintain - the amount of attempts to hack the few sites I maintain is just ridiculous and I had to scale down and give up on a ton of db based things I had through the years.

Anyway, if someone else wants to take on this I have a ton of information to share xD

[Laura Hunt]

I forgot to include this in my list of suggestions; In fact I keep forgetting to mention it and it probably would have been a good suggestion for AGS 3.6.0 or 3.6.1, but it's probably too late for that: the possibility to set the width of the textbox for the Say command, just as it's possible to set the width of the Think text with game.speech_bubble_width. It's just weird that Say doesn't have an equivalent function.