AGS 4.+ Roadmap discussion

[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)