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.