Following are the reasons why this project was screwed up from the very beginning. Just for the sake of history. I'd like to believe this may help someone to avoid same mistakes, but people seem to rarely learn on their own, so IDK.
Actually, I cannot think of anything that was made right here, from the first steps every mistake that could be made was made.
1. The problem with AGS was the reliance on old library that was already badly working on contemporary systems in 2012. Instead of
immediately moving to better up-to-date library (SDL2 or Allegro5), or framework (like ScummVM) the old library was patched to somehow work on wanted platforms.
Usually the patching was performed by a single person. After such person took their leave, little information remained about their work, and whenever any kind of issue arised with the port, it took a lot of effort to figure out what to do.
Often the library was patched having only one particular port in mind. Sometimes a functionality was added right into this patch, different from the rest of the engine, causing inconsistences.
A lot of additional work related to device controls and graphic modes could be omitted, if we could rely on modern library. For example, I had to rewrite graphics renderers 5 or 6 times adding better display mode selection over those years.
The result: AGS is still based on same old library that work worse and worse on contemporary systems.
2. The problem of AGS was that Windows version was glued to particular old version of MSVS, which was even non-free. Instead of
immediately looking for a way to remove that dependency, we kept it for several years.
Result: many potential contributors could not contribute because they could not even build it.
3. The problem with AGS was bad program code. Instead of
immediately refactor it from top to bottom, this was only partially complete before we switched to compatibility fixes, and then - adding new functionality. Because of that a lot of time was wasted trying to hack new stuff into existing code. Supposedly, the bad code also scared away other potential contributors.
Additional moment: there was already a refactored code made by ScummVM developer, licensed under same license as AGS, which could be used, even if partially. But it was never used.
The result: AGS still has got a lot of non-refactored code which is barely known, and many features or fixes that were very wanted were never added because of that.
4. The problem with AGS was that the engine and editor contained a lot of legacy support that was practically useless for making game in current day, but cluttered up the code and made it difficult to develop it further.
Instead of splitting out legacy support into separate branch, we not only kept it in the engine, but
increased its amount by adding support for even older games.
Because of this, adding any new feature required a lot of extra time, necessity to test whether ancient games still run with this engine after every update. This additionally mixed up with the non-refactored code producing more mess.
It may be hard to fully recognize consequences of this decision. A lot of system limits are there
only because of legacy support and old plugin API support. There was a time when I spent over
half of a year trying to remove these limits
while keeping the legacy support, but in the end just threw the code out, so ugly it was.
Similarily, a lot of features could not be easily added simply because there was some fragile legacy stuff that could break.
Result: amount of time just wasted for nothing is impossible to calculate. Neither it is possible to know how much we could have done more if not for this.
Number of potential collaborators probably did not want to participate in project because of confusing code.
5. The problem with AGS was that with very little number of collaborators nevertheless we sometimes wasted time on something that could have been avoided. It was in our interests to take easier routes requiring less job where possible. Instead, the project started with one developer willing to write a class library specifically for AGS instead of using standard one. Another developer kept waiting several months for those classes, purposedly trying to avoid adding standard ones into engine. When it became clear that there will be none, instead of immediately switching to standard library, that second developer, for the reasons he cannot even explain today, decided to follow suggested idea and write these classes himself. In the end he did, kind of, but then realized that with them he will be drawned into maintaining utility classes instead of working on engine itself, so, again, just threw the code away. So, now we do use standard library, but nearly two years were lost.
This is only one such example. I could probably remember other not so useful stuff that I wasted time on, because someone said (in the end many things I did were not even added to the release).
6. The problem with AGS was the lack of automation. Everything had to be made manually. No automatic builds, let alone tests, nothing. If a person wanted to suggest features or changes, developers had to manually build and test their version to just make sure it compiles.
There was no way to know if all ports are still working or were broken by some of the recent additions except for building them all or waiting when someone tries to. And not everyone could build all the ports, naturally.
Making a full release package with all the data - demo game, templates, etc, - became such ordeal, that frankly, I tried to delay release every time until more changes accumulate, simply because I did not want to go through all this too often.
7. The problem with AGS was terrible organization. This was a project without actual leadership nor vision. There was no development plan, no documentation. Everyone just did some stuff as they see fit.
There was very little communication between game developers and AGS developers. With lots of ideas it was difficult to filter out things that were actually important to many people. A lot of critical nuances stayed unknown until occasionally mentioned years later.
A lot of tasks, even mentioned on forums, were never solved, even though several people could state their interest in that. Good example is this thread:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=51340.0Just look at this:
From 2014 to 2018, and it did not move anywhere. Meanwhile, this is not even related to engine code or C++.
If organization were better, perhaps a number of other problems not directly related to coding engine could have been solved. (e.g. this:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=55646.0)
Simply because people could notice that such task exists.
