Post-3.4.0 development

[Crimson Wizard]

With 3.4.0 almost out, it is time to mark out further development and say few words about past experience.

My biggest considerations regarding the past development are: lack of clear priorities and dissipation of efforts.

* I am very much saddened by the fact that the project did not, and still does not have any guidance or participation of experience game developers who would at least give advise on course of improvement for editor and engine. Even when some insights or comments are made by such developers on forums, they are so sporadic, and so lack emphasizing, that they become lost in the lists of issues. Like with this patched games problem (aka loading old saves), for example: I believe we could try address this issue months if not years ago, if there was a strong expression of how important that is earlier. When my attention was brought to this I found myself stuck in the 3.4.0 finalizing process, which I could not complete for a very long time.

* The biggest practical problem was development of two versions at once: improving existing stable version and working on the new version. On several occasions I had to spend many weeks updating and fixing old version, instead of finalizing new features and moving forward.

* It was always dissapointing for me to see other contributors willing to apply lots of effort and spend time on something that I did not consider much important while there were other more interesting and worthy tasks. For example, I know that it took Gurok several approaches to complete and fix implementation of "for" and "switch" commands in script, while both were no more than convenience ways to do loops and "ifs", rather than something completely new; at the same time there is a great need for full user managed structs support, and similar advanced improvements that would truly enhance AGS scripting.

========================================================================

Current situation is that we are still in a dire lack of human/time resources. That is why I have to follow advice given by Nick Sonneveld and change the way I work on AGS from now on.

* The development will be done in one branch only. There won't be any distinct updates of the previous versions, except for serious bug fixes (patches).
* Features will only be accepted into development branch in a working state, even if partial, but the implemented part should already be working, otherwise it should not be accepted. There should no more be any "experimental", raw stuff in the developed version, when we have no idea how long it takes to make it work. In other words: the feature may be limited, but at least must be working in said limits.
* We will set up a list of "milestones": features of big importance and high priority. As soon as at least one such feature is put into the repository in complete state, we create a "checkpoint" and start preparing MAJOR release. No more features will be added to this new version after checkpoint, only finalizing/fixing existing ones.
* If no "milestone" feature is found in development branch, but certain average amount of time has passed (2 - 4 months?) and we have something good in there, fixes or features, we create a "checkpoint" and start preparing MINOR release.
* I frankly and sincerely be deaf to people asking me to add "little more" into the version, especially to the previous version. I realize people sometimes want little additions to complete their games, but working on such requests distracted me greatly in the past and made me loose time I'd rather use more efficiently.


PS. Other than all this, I am still rather pessimistic about whole thing.
Also I really want to make a game myself :-(.

[cat]

I think the new development/branching/release strategy is a great idea. Supporting old branches costs a lot of time and effort.
It's also a good idea to establish a roadmap with milestones and upcoming features.

And please do make a game :-)

[Crimson Wizard]

Milestones could be both new big features, and compilation of similar fixes/improvements on same field.

Potential list of milestones (things I remember now) - without any specific order:

1) Loading saves from old game version. That is in progress now.

2) Resolution switch at runtime. I made an experiment, but Direct3D requires special treatment: all cached graphics need to be reinitialized when switching to different fullscreen mode, which is doable, but with complex AGS code we need careful check up and testing all possible cases.

3) Sprite limit. Remove 30k sprites limit, and 2GB sprite file limit. Latter may be related to not only sprites.

4) Custom speech API. Let user script speech in similar way as custom dialog options are scripted.
Older discussion thread: http://www.adventuregamestudio.co.uk/forums/index.php?topic=48518.0
Newer discussion thread: http://www.adventuregamestudio.co.uk/forums/index.php?topic=51443.0

5) Room elements limit removal. This stands out from other limit removal tasks. From my previous experiments I recall that either game data format or save format or both had to be adjusted to allow rooms with arbitrary number of regions to initialize without problems. But more importantly, Room Editor has to be revamped, because currently its region/object selection controls are non-suitable for larger/varied numbers of elements. There is an experimental version of the Editor made by tzachs which incorporates new room editing model. We may take that or use as a reference.
Also some older discussion on this topic, linking here only for reference.

6) Complementary runtime get/set properties. There is a bunch of properties in many game elements that can be set at design time but cannot be changed at runtime. Some of them cannot be READ at runtime, which could be additionally annoying (one example I stumbled upon recently is Mouse Cursor's hotspot coordinates, which may be changed at runtime, but cannot be read). The task might be to find such EXISTING parameters (we are not talking about adding new parameters here) and ensure there are appropriate get/set properties for them in script, when reasonable.

7) GUI overhaul. Redesign GUI elements, or at least their properties, so that that could be more conveniently customized: sizes, colors, using images for subparts, and so on. Maybe remove existing gui modes and introduce proper modal/modeless GUIs.

8) Screen layers. Introduce screen layer concept and possibly merge GUI and Overlay game elements, since they both are graphic elements that are not part of the room. Allow overlays and GUIs (or merged type) be put in any order on screen. Allow speech above GUIs, and so forth.


CONTINUING...

9) Support for pointers inside user managed structs. This will make them self-sufficient and ultimate addition to AGS Script.

10) Rewrite engine plugin API. Explanation for reasons and example of new implementation is here, although that would need a review anyway.

11) Plugin API for script interpreter. Let using other script languages natively in the game (without AGS Script as a medium).

12) Replace prebuilt libraries on Windows. This may be solved in two steps: first - start building them from source code which matches those versions of libraries most; second - upgrade to newest libraries. Latter may require doing compatibility fixes / introduce backwards-compatibility options.
Most notable is an ancient fonts library AGS uses, which causes annoyances enough to note it as a separate milestone.


CONTINUING...

13) Editor should be able to import very old AGS games, similar to how it imports 2.72 games now. After all, formats are known (down to 2.52) and engine can load them, so why not?

14) Save rooms as XML for the editor's project. Of course Editor should still be able to import binary room files (CRM), and convert them into XML. It should be determined how to keep binary room data (bitmaps) though.