What version of AGS to target when writing new modules?

Started by Kara Jo Kalinowski, Sat 15/02/2025 20:19:16

Previous topic - Next topic

Kara Jo Kalinowski

I wasn't sure if this question would be better suited here for in general, since it's not really a scripting question, but is still technical-related, so sorry if it's in the wrong place.

If I want to write a module/template to be published on the forums for general use, what version of AGS is best to target? Is the latest official release too recent? I know some people still use older versions...but people starting new projects will probably be on the latest version anyway, right?

Snarky

It depends.

Ideally you want it to work with all versions of AGS. It's possible to use #ifdef version checks to adapt to differences between versions.

In practice, worrying about anything below 3.3 is a waste of time, and anything below 3.5 is probably pretty niche. But if you can, why not?

But sometimes the code depends on a feature introduced in a certain AGS version, and in that case it makes sense to make that the lowest supported version. Or if some major part has changed, perhaps it is better to release separate versions of the module for different AGS versions.

I would recommend writing the module for the AGS version you use, and then once it is done, try to test it with the lowest AGS version you're looking to support, as well as the latest RC. Then make any fixes as necessary.

Crimson Wizard

#2
Something to keep in mind: your module's design will be restricted by the lowest version you support.

AGS 4.0 introduced a lot of new syntax features, not just functions, which allow to structure the code very differently. One of the most noteable one is ability to have nested structs and pointers in managed structs. This allows virtually any data structure, and more convenient modules. The cost is that neither of 3.* versions will be able to use them.
In some circumstances it may even be worth to have 2 variants of same module - for 3.* and 4.*.

There has not been similar changes in 3.* version branch for a while, since at least 3.4.0. I may be mistaken, but I think it was 3.4.0 that introduced "for" loops and "switches". Previous versions had to use "while" loops even when "for" style would be more convenient. Although, compared to 4.0 changes, this is a minor difference, that only barely affects the code inside your module's script.

Personally, I would not target versions below 3.6.0 today, because the older versions do not run very well on modern systems, and they are probably used only when a person is already too far into the game development and cannot upgrade.

Danvzare

The oldest version I personally think you should even consider aiming for, is 3.4.3, since it's the last version to work on Windows XP. And there's still people out there that use Windows XP, so if you've got that version covered, you've pretty much made it compatible for the vast majority of people who refuse to upgrade their software.

Any older than that, and you're targeting an audience that either doesn't exist or doesn't care.

But that isn't to say that you SHOULD target 3.4.3. Because like Snarky said, that pretty much only covers a small niche audience.
Personally, I think Crimson Wizard is probably right about targeting 3.6.0.
Besides, it'll make it easier for you if you aren't having to keep support for old versions in mind when writing your code.

That all being said, if you can easily add support for an older version. Why not do it.

Snarky

My impression is that there are still enough people using versions older than 3.6 that it's worth supporting at least 3.5.x as long as it doesn't require any major changes to the code. (A typical example of a trivial change would be the change from System.Viewport to Camera.)

But it's probably even more important to be forward-compatible, so definitely make sure to test it with the newest 3.x RC and also if possible with AGS 4.0.

SMF spam blocked by CleanTalk