Messages

Not sure if this is intended, but DialogOptionsRenderingInfo seems to have lost .HasAlphaChannel property in 4.0.

Yes, it's been cut out, as well as from DynamicSprite and DrawingSurface.
In AGS 4.0 we decided that all 32-bit sprites and surfaces assume valid alpha-channel, because having this property complicated the engine behavior.

This is mentioned in the changelog in the first post.

- Removed "hasAlphaChannel" param from DynamicSprite.Create() and CreateFromExistingSprite().
- Removed HasAlphaChannel property from DialogOptionsRenderingInfo.

EDIT:
I must clarify, the normal transparent color also works, both when importing a sprite, or when drawing with COLOR_TRANSPARENT in script, because it has alpha 0. In the future we plan to support full RGBA color definition in color properties and script drawing.

Could anyone check out the variant I made? I don't even have a game to test the different perspective myself.
I need to know if what I do is correct and enough for solving this case.

This is a description:
https://github.com/adventuregamestudio/ags/pull/2304

The latest test build may be downloaded here:
https://cirrus-ci.com/task/6688426888527872

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.

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.

- 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

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

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.

[transition animations]

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.

"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.

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.

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.

(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.

@Dave Gilbert, there's a good chance that I found the fix for these "lines" around the objects.

https://github.com/adventuregamestudio/ags/pull/2315

The test build will be found here in a short while:
https://cirrus-ci.com/task/6006716257533952

[1)]

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.

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.

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.

Not going to happen without writing a 3D engine and editor from scratch, so will lock this thread.

Looks like solved, and safe to lock.

Was resolved, a new topic may be opened if someone likes to change existing picker or whatnot.

Closing as was solved.