AGS4 and the death of legacy

[AlanDrake]

So, to make coding AGS less aggravating, I'll be starting a branch whose purpose is to wipe out legacy stuff. Whether or not another engine will steal its throne in the far future, this can be done now. Deleting all that stuff is certainly more pleasing than adding features wrestling with all these chains littering the source. And should make things easier to understand which in turns could also help the other AGS-inspired engines.

So far I'm experimenting and taking notes, since my knowledge of the inner workings is not as advanced as Crimson's.

I can say though that I've succesfully blasted away those pesky pixel_size/multiply_up/divide_down conversions, which had almost 400 occurences all around, and after compiling it all worked the first try. I feel greatly encouraged.

I'll create a proper branch on my repo as soon as the VS2015 branch is officially merged with master.

Things to cut away:

• legacy options
• deprecated script commands
• old audio system
• old savegames handling
• backward compatiblities to make older games run
• CD Audio
• legacy global variables (not to confuse with the new ones, distinction is not clear in the code)

[ghost]

If you are going that way, then I strongly advise to scrap at least the parts of plugin API that:

• acquire actual memory addresses of internal engine's objects (characters, room objects and so on) I believe plugins must work either with interfaces or by calling script functions.
• deal with script function pointers (get ones and register ones). The latter normally should be remade to work same way as Script VM works inside the engine, that is - by the use of function and argument definitions, instead of raw pointers of unknown type.

[gurok]

You could probably remove the legacy pathfinding too. It will break an old Ben Jordan game, but I would rather have a known algorithm (Djikstra / A*) that we can adjust.

Edit: It is probably just a matter of reverting back to this commit: https://github.com/adventuregamestudio/ags/pull/160/commits/d7ce6ef322da6039218857ff6019a659e43bb746

[ghost]

I have a question, because I do not exactly know the plan here.

Are you going to eventually merge those breaking changes to master branch?

If so, you need to consider that there will be two separate programs in two different branches: the one that runs games of certain range of versions, and another that runs games of another range of versions (and these ranges do not cross, or cross only partially).

If someone would like to add a bug fix for the old version, to keep run old games with, you would have to point them out to the correct branch. Same goes for bug reports, etc.

Or someone may build the latest version because of habit, and then be surprised by old games not working with it. Perhaps the engine should display a message, suggesting them to use older version.

BTW, have you considered creating a clone of repository instead?

[ghost]

Then again, perhaps we could let ScummVM team take the old games support on from here. Alyssa Milburn might still have her Ags for ScummVM port, which was unfinished last time I checked, but maybe someone would like to update and complete it. I also heard they had plans to add hardware-accelerated renderer support couple of years ago, which would suit running latest AGS games.

[AlanDrake]

I really don't know... on one hand even CJ used to break compats to older versions, so it would make sense to leave behind the current backward compat version on its own branch. On the other hand they'll end up having two different purposes, so two repos could also make sense. Might even be the other way around, after all the backward compat engine doesn't need the editor, it could be on its own on a separate repo.

[ghost]

Might even be the other way around, after all the backward compat engine doesn't need the editor, it could be on its own on a separate repo.

That is another option, yes.

I am not so sure about not needing an editor, because someone might want to try restoring old game project. Hmm idk, maybe that's not relevant, since editor is still in the main repository history.

[AlanDrake]

Well, I couldn't contain my excitement, so I ended up making a branch out of the pull request. I'll omit the dll commit when I recreate the branch, if you ended up removing them.

I'm learning more about the code by taking it apart than all my previous attempts at studying it. I'll keep cutting away and limiting the compatibility to 341, at least until I reach the barebones stuff that is actually being used. Then I might try some heavier refactoring if I am still alive.

[ghost]

You may actually take a look at "experimental" branch in this repository, it contains refactored and renamed room and game classes (and many others).

I have never found time to put these into master, being too busy with other things, and was always sorry about that.

Not everything there is compatible with recent code, for instance it used custom container classes, which were abandoned in favor of STL in master, but that might be easy to fix.

They are located in "Common/game" and "Engine/game" folders: https://github.com/adventuregamestudio/ags/tree/experimental/Common/game https://github.com/adventuregamestudio/ags/tree/experimental/Engine/game

Although, their reading and writing has slightly different format, because I removed room object limits there. Also, since they are made long ago, some things there could use outdated code. So IDK if that fully suit your purposes. Perhaps only as a reference.

Also, there was a second attempt to refactor GUI class in more recent branch in my personal repository "develop-3.4.0--gui-refact-next" (with STL containers): https://github.com/ivan-mogilko/ags-refactoring/tree/develop-3.4.0--gui-obj-refact/Common/gui

Same story, started the work, then could not put it to master for some reason, and could not find time after.

[ghost]

Another thing that I feel a need to mention, since that bothers me, is that keeping a big split branch may lead to problems in the future. I've been there, so I can tell...

Common case is when you have a branch which changes 100 things at once, and you keep it for several months, then someone makes pull request that changes a code, which was also changed by you somewhere in the middle of your branch. And then you get into dilemma: either force that another contributor to wait until you finish your giant work, or merge their request now but then go back and recreate half of your branch, because it is no longer consistent. The longer you keep unmerged branch, the more this situation will repeat.

[ghost]

At last but not least... having no particular plan set for the project/team may lead to situation when you are making something in your own branch, and someone else wants to make changes to master branch, which are inconsistent, or even contradicting to yours. I just think I have to point that out, because the opinion, for example, on what to keep and what to strip out, may vary between collaborators.

The lack of strictly defined plan may also cause some people wanting to work in master branch, unaware of future break of compatibility (assuming this is what going to happen according to your idea), which would also take them by surprise.

I don't mean to sound like I want to control what you do, but I am getting nervous seeing as a very serious change is going to take place without preliminary agreement; like defining the goals of the project and branches at least.

[AlanDrake]

My current plan is to simply to strip down 3.4.1 from dead features and backwards compatibility, then do some refactoring after having learned the big picture. When I have a clean 3.4.1 compliant AGS we may see about the future.

If possible I would force (our few) collaborators to keep their current work on a separated 3.4.1 branch (name it 3.4.1-classic or something). Or they can just roll with my butchered branch, I'll be keeping compatibility with 3.4.1 gamedata for a long time, and in the plus side they don't have to deal with arcane stuff like those coord multipliers that make your brain melt.

We can't just keep delaying forever because people change the code with new features. You should have indeed merged your refactored classes back then and forced everyone to deal with it. (I will try to take inspiration from your experimental branch if I can)

Otherwise, if we need to start a new repository, we could announce officially that the current ags repo no longer accepts new features, except fixes and improvements.

If collaborators want to voice their concerns about their features then they should speak up, else we can just assume their tacit approval. 😁

[ghost]

Alright, I will just leave this be then.

[ghost]

This just came to my mind (as I made a big refactoring PR): dropping compatibility will reduce the range of games you can use to test the engine with. I heard you are developing a game yourself, so it may be easier in your case, but that may also make sense to create a collection of test games. (This is something that we should've done a while ago....)

[AlanDrake]

You're right. If we had a tutorial game that implements one feature for each room, it would make both our testing easier and the users happier.

This could be a community effort, make people pick a feature, prepare rooms then compile them into a big project. I would have really really loved to have such a thing when I first tried AGS. The demo game is a poor reference. What do we do ? Open a new issue to talk about this or just post on the forum activities to get the ball rolling?

EDIT: Right, you had already made a post about that on the forums, I had completely forgot about it...

[ghost]

Right, you had already made a post about that on the forums,

I suggested a sample game for the showcase, which is a bit different, but someone mentioned feature per room idea too.

[AlanDrake]

Just so you know, I've broken the part that handles upscaling when using lowres assets in hires mode. Which is probably good, I'll just remove it completely for the time being, I'm sure it can be rewritten in a much better and cleaner way. Also it would be nice if one could specify the scale instead of just High/Low on the Sprites manager. this needs some thinking over. I probably could simply upscale the assets when I start the engine, but we need to decide how to treat the sprite when used by DrawingSurfaces. Use the original or the upscaled one ? Both cases have their pros and cons.

[ghost]

I do not know if I am expected to answer anything? There is still no clear plan stated yet, just a general direction, and you are working alone in your own branch, I find it uneasy to support conversation about hypothetical future design.

Perhaps it would be better to simply make a list of changes in the end?

[AlanDrake]

It's just my attempt to involve our dormant team. After all the whole purpose of this is to make AGS more pleasant to code for us and newcomers. I'll keep an ear open for ideas, and I'll also keep pestering everyone so they remain aware this branch exists, otherwise it'll just end up like all the other dead branches.

Is there anything else from your branches that I could try bringing in ?

[ghost]

Is there anything else from your branches that I could try bringing in ?

This all confuses me so much, that I hardly know what to reply.

Is this a branch where you work alone, gather ideas from everyone but implement them yourself? Are you planning to keep that branch in your repository only? If not, how long since you want to merge to this one, or rather, what point do you want to reach before doing so?

Indefinite goals and ending conditions - that is what makes branches die.

Regarding design ideas, like sprite rescaling and stuff, I found github not a right place to discuss such matters, at least for this project. Actual game makers very rarely post here (I am not even sure if many of them read these discussions), so you are loosing a chance to hear their opinion, in comparison to AGS forums.

[AlanDrake]

Are you planning to keep that branch in your repository only? If not, how long since you want to merge to this one, or rather, what point do you want to reach before doing so?

No, but I think I'll need at least another couple of weeks before reaching a stable point, then I'll try to make a pull request. A lot of things are finally starting to make sense to me, but I'm still stumbling around half blind. I'd rather not work alone, but at the moment it doesn't look I get to choose.

Are you planning to keep that branch in your repository only? If not, how long since you want to merge to this one, or rather, what point do you want to reach before doing so?

I'll be sure to ask the forums and discord/irc as well.

[ghost]

I asked, because from your previous question (about bringing something from my branches) it sounded like you are looking to put various unrelated things in your branch. I did similar things before and that only ended with trouble.

That's why we've made a branch/commit convention, which suggests that feature branches are dedicated to strongly defined tasks. That really helped to keep things organized.

[ghost]

What I should probably mention too; if everyone have decided to follow compatibility breaking path, then you do not have to do whole "legacy cleanup" thing (whatever you put into the definition of "legacy") in one go. If things are not easy/clear for you, instead you could choose particular legacy feature you consider worth getting rid of, and make a pull request. And then continue doing that step by step.

This will also let other people to participate (for example,@gurok proposed changes to pathfinder above).

[AlanDrake]

You're right again, there's some stuff I could already prepare a PR for. Some other instead is proving to be a little more problematic, by taking out the multipliers I have opened a whole can of worms, I'm afraid it'll take several separate attempts to get it straight, of course it had to be the first thing I tried to do... I'll keep using my branch as a testing ground, I wish I could add comments to code without actually modifying the file, I'm littering the code with my naive observations but it can't be helped I need them... I'll prepare the branches once I'm reasonably sure they're safe.

[ghost]

I wish I could add comments to code without actually modifying the file, I'm littering the code with my naive observations but it can't be helped I need them...

That's not a problem at all. I've been adding similar notes too when I just started (some of them are still out there). Any comments in code is better than none.

[ghost]

@AlanDrake , I tried to hold myself for some time, since I honestly wanted to cease my participation on this project, but probably I still should have said this... I apologize for not doing this earlier, but I was not in proper mental state, and I did not want to argue. And I am still not sure if what I am going to say holds any value in current circumstances.

The thing is that I do not agree with what you are planning to do.

Indeed that's partially because you are going to throw away all the functionality to run old games, which we were gathering for years, piece by piece, spending so much time just to let people play them on contemporary platforms. What would happen to that now, if, for example, the old branch won't run on some newer version of Windows or Linux, and so on? When the legacy features are inside same project, and you replace old libraries with new ones, or add new OS support, you automatically allow legacy games take advantage of those libraries or run on new OS. With legacy features separated, you would have to update two projects differently, and something tells me no one will bother to update legacy one.

You are calling AGS code "aggravating" and hard to understand. I agree it often is, but that is not only, and even not so much because of legacy stuff, but rather simply because the code is bad. Besides actually outdated stuff, there is old stuff which is still being used (simply because there are no alternatives), but it is coded no better (if not worse) than outdated parts. AGS always needed restructuring and refactoring. While I was still working on it I wanted someone to help me do it so much, but unfortunately no one did. And now, when there is an interest in this again, it appears one find it easier to just throw away the code which they do not understand. That's very sad.

(That's ironic you mentioned "coord multipliers that make your brain melt", because these caused lest trouble in comparison with everything else. After I found out what they do, I simply ignored them.)

Some of the legacy features you said you want to cut, are still used. There are long-standing members of AGS community who make games only in 8-bit mode, for instance, and these games are not some random crap, they are good games that earned AGS awards.

I believed back then, and I still do(!), that it is possible to solve "legacy" problem by restructuring the code. There are examples of how it was partially solved along the way. Take the conversions done during game loading, that you are removing in your branch. They are already picked out and grouped in distinct functions. They do not cause trouble! The conversion makes old format be loaded into new format, and the engine later works only with new data.

Similar restructuring could be done to all the legacy checks throughout the realtime functions. Out of the top of my head, engine could have distinct runtime classes to work with new versions and old versions of the game. For example, something like Character class and LegacyCharacter class.

Much of the legacy script functions could be relatively easily supported via reuse of the newer ones.

Of course, that does not mean that those legacy features need to be kept in the Editor. Since Editor is mostly for making new games, that will be less painful to remove these unused options from it. But the interesting consequence of engine's compatibility could be that one could use newer engine with older Editor.

One last thing to mention here. You said that you aim at making code easier for developing AGS-inspired engines. The thing here is that if one is making totally new engine, they do not need to see most of AGS code. Much of game objects and gameplay can be easily recreated just following basic concepts, they do not have to copy code from AGS. (Unless these engine writers are beginner coders). There are already multiple new engines written by people who formerly used AGS (Adore by Steven Poulton, Gobby by "Journey Down" team, Adventure Creator for Unity, MonoAGS currently being developed by Tzach Shabtay), and it does no look like they suffered from not being able to take particular code from AGS. On the other hand, if someone would like to write new "AGS games player", to run all AGS games with, they would have to search through more than one branch to find how old game support was done. And since the code in old branch (the one containing legacy features) still will be unrefactored, that would be more difficult for them.

Take recent Scotch's announcement on forums, for example. He said he's writing a practical replacement for AGS engine on Js/WebGL, and he is aiming at supporting running all games, uncluding very old ones.

Of course, what you do is an interesting experiment, and may be very useful to improve your understanding of how AGS works. But I ask you to consider the alternate option I mentioned above.

With the route you chose there is of course a "third option": clean the code to make it easier, refactor, and then find way to get legacy stuff back without screwing existing things up.

But there are other considerations too.

If I try to gather worst problems of AGS now, including those that make updating it difficult, from my own perspective the list would be this (in no particular order):

1. Outdated back-end (Allegro 4 and accompanying libraries - font, sound). Makes it hard to support contemporary platforms. Needs to be replaced completely.
2. Outdated software renderer. In many cases supporting it requires writing software drawing methods (like alpha blending, for instance) duplicating hardware-accelerated functionality. Makes it nearly impossible to support advanced graphic effects, like fast scaling and rotating (including camera effects), and so on. Needs to be thrown out, and 8-bit support reimplemented in some other way (like shaders).
3. Generally bad state of code. Must be refactored.
4. Bad plugin interface. It is generally not safe, and also literally prevents from modifying certain engine's internal data structures, which is ridiculous and must not be tolerated. But replacing old plugin API is easier thing, because plugins are attachable part of game, and may even be recreated. For example, @jjsat successfully recreated few plugins to make them portable.
5. Savegame format. Not only it is badly structured, and writes redundant data, the order of data there makes it hard to change some things (like remove object limits). Savegames may be safely rewritten from scratch, because in AGS there is rarely a need to maintain saves compatibility between major releases.

If you look at this list, cutting the legacy features off barely solves anything, except making refactoring bit easier. At the same time, all those big issues will remain. Of course you may say, that after you remove lefacy stuff, it may be easier to work on those problems too, but I do not think these issues are related much. The engine consists roughly of two parts: the game logic and back-end (renderer, audio players, etc). Removing certain stuff from one part won't necessarily solve anything in regards to another.

I feel like your decision is mostly dictated by the wish to create an "easy" version of en engine for your own purposes, without forethinking of any future goals.

That's basically what I wanted to say. Maybe I could add something else, but it seems too much text already. I tried to discuss all this on forums many times in the past years (I do not remember if you've been around then), and it's hard to repeat myself again.

Sorry if my ramblings cause more confusion or discourage you. I'd really wish if other collaborators, like @sonneveld, who was working on SDL replacement, say anything, but everyone seem to be silent so far, which makes me think that either they agree with your plan, or do not believe other way is worth trying.

[AlanDrake]

AGS always needed restructuring and refactoring. While I was still working on it I wanted someone to help me do it so much, but unfortunately no one did.

That is not surprising, I had wanted to do it in the beginning, but it was like wading through the jungle and I had not enough experience with c++ for such a big project, so I got discouraged and just ended up hacking together the few features I needed and called it a day. After all I had more interesting and rewarding things to do.

(That's ironic you mentioned "coord multipliers that make your brain melt", because these caused lest trouble in comparison with everything else. After I found out what they do, I simply ignored them.)

Ironically. that's what caused me most trouble so far, it was like that code was actively fighting me for survival. The whole concept was wrong, because it was designed for 320<-->640 in mind. It's also detrimental to new games, like for that poor soul on the forums that increased the width to 427x240 and suddenly everything was weird and broken. This is not acceptable.

Indeed that's partially because you are going to throw away all the functionality to run old games, which we were gathering for years, piece by piece, spending so much time just to let people play them on contemporary platforms.

And all that stuff will live on in the classic branch. I just don't believe any source developer should suffer to implement new features trying to keep compatibility with the age old. AGS was born for letting people make new games, not for our inner circle to play older games. That's a plus. New game developers are not attracted to the tool because it plays older games, but because it enables them to make their own.

I feel like your decision is mostly dictated by the wish to create an "easy" version of en engine for your own purposes, without forethinking of any future goals.

Yes, I admit it, I do this for selfish reasons, I want AGS source to be more mantainable and easier to bend to my needs.
And that's a perfectly valid reason, it's what motivates me. Without that I'd simply have no incentive. I can't refactor the current code, but maybe, with a stripped down AGS, I can make an attempt.

Anyway I'm still not entirely sure what to do about 8bit, I'm leaving that for last. I have fond memories of palette magics from Deluxe Paint days, but very few people can pull it off today (the only one developing a 8bit game I know of is Scavenger). It's also likely we'll come up with a better way to implement it, so we'll have to scrap away all the old code anyway. We'll just have to see. Were it for me I would even destroy the text parser. God helpe me, I hate text parsers.

At the moment I'm in the process of removing the older script commands, that is probably going to keep me occupied for a few days.

Sonneveld said he was busy with RL stuff, so he had to put the SDL branch on hold, at least for the moment.

[AlanDrake]

So, I stumbled into interactions.h/cpp and realized there's a whole new layer of legacy complexity rooted deep down. It doesn't look like I'll be able to just cut it away and be done with it, nope, I've been staring at the code for a couple of hours, and I'm still unsure how to divide and conquer this mess...

[ghost]

Legacy interactions were fully replaced with script handlers at some point (around 3.0). If you look around, whenever an Interaction is mentioned there should be respective script event handler (called InteractionScripts) nearby. The latter is just an array of function names. This pair goes in every class that has some events to script (rooms, objects, etc). They are deserialized in pairs too, if its 3.+ then InteractionScripts are loaded, if 2.72 and lower - then Interactions are loaded.

If you simply remove every struct that is called Interaction, InteractionVariable, and similar EXCEPT InteractionScripts, then you may see the picture more clearly.

Example:

   ///// These are legacy interactions
    Interaction     **intrChar;
    Interaction      *intrInv[MAX_INV];
   ///// And these are contemporary event handlers
    InteractionScripts **charScripts;
    InteractionScripts **invScripts;

To summ up, you need to leave only InteractionScripts, the rest is for legacy support.

[AlanDrake]

Thank you, that helped. I actually managed to make the engine compile without breaking serialization/deserialization. Now it's the Editor's turn... EDIT: aaand done. Now I'll resume the cleanup of old script functions, then global vars and etc.

[ghost]

I would like to try restoring another one of my older branches, with new savegame format. A while ago I spared some time to filter out data that should not be in savegames (because it never changes) and regroup the rest to make it look comprehensible. Did you have any particular plans for this that might be taken into account?

Now I'll resume the cleanup of old script functions, then global vars and etc.

What do you refer to as "global vars"?

[AlanDrake]

No, so far I haven't any specific plan for the savegame format. But I have a long term plan for serialization in which I'd like each component (and subcomponent) to have its own version and be able to upgrade itself.

What do you refer to as "global vars"?

The Global variables from the editor's panel, I didn't even know/remember they were considered legacy until I read the comments. And I even used them in my game back then, shame on me. Although, I have to say it's comfortable not having to manually import them everywhere. But if it's deprecated I should get rid of it, I guess, which will stop other people from getting confused.

[ghost]

The Global variables from the editor's panel, I didn't even know/remember they were considered legacy until I read the comments.

I think there might be a misunderstanding... in the 3.0 the global variables pane is converted to hidden script module on compilation, so it works through same means as any other variable in script. That's practically visual programming.

The "graphical variables" in script API (Get/SetGraphicalVariable), or "globalvars" member in the game struct, they are completely separate thing that gets loaded only from 2.* games. 3.0 editor does not create these.

PS. This is the same as dialog scripts, these were separate kind of script in early days, but now they are converted to normal AGS script, so they are basically just a kind of special visual representation now.

[AlanDrake]

Oh, I haven't stumbled in the part that converts to a hidden module, I guess I'll try to wipe all those OldInteractionVariable/InteractionVariable/globalvars[] and see what happens.

[rocifier]

I would be interested in helping with the cleanup but we would need to setup some strong guidelines and restrictions for it before others can contribute. What do you think about setting up some kind of roadmap or at least a TODO list?

[AlanDrake]

Sorry if I'm not being much alive at the moment, I have too many interests preventing me to focus on a single project, I'll surely get back on the piece eventually. But in the meanwhile, if you want to prod me and talk shop, I suggest you join the discord channel. Talking about the stuff might fool me into putting some effort.

[rofl0r]

i fear that this project will not lead to the death of legacy, but to the death of AGS. as soon as ivan's no longer around, nobody will keep the "legacy" AGS alive, so it will not work anymore on the next incarnation of operating systems. while the effort put into a legacy-free AGS will only benefit a handful new games, if even that.

I believe time/effort would be better spent by improving upon the existing codebase, while keeping it compatible. I'm sure there's tons of places where one could put energy into and still get reward out of it, without throwing everything that's not seen as chic&modern over board.

even if someone else will keep maintaining the legacy code, having such a split (as was seen in the past with python2/3 and lua 5.1/5.2) just divides the community in an unhealthy way.

[AlanDrake]

I see your point, but the death of AGS will only happen when no developers will be there to keep it up and running. A discouraging codebase prevents many from even trying. I've taken various things apart, and there's various stuff that's tricky and just doesn't works as you would expect it.

Adding new stuff to 3.4 is no simple task, and refactoring isn't a simple job. Whenever I tried I just burned out, so from my point of view a cleanup is vital.

Besides if we actually manage to clean up and refactor the codebase, it could help in the future to upgrade the legacy someway.

[ghost]

The death of AGS will happen when no one is making games with it :) (I believe saying this back in 2012 in one of them "future of AGS" discussions).

Anyway, I will probably repeat myself again, but my opinion only strengthened, that there is little benefit from clinging to old code. Even if you manage to clean it up and refactor somehow, all the main problems of it still remain: it's based on old technology (libraries), script with limited abilities which felt non-contemporary years ago, weird design choices that root deep into the system.

On the other hand, if you do not see keeping legacy support a priority, existing code holds even less value, because most of the basic stuff which makes a foundation of adventure game could be recreated without even referrring to AGS code. Then, some of the components may be plain copied over from AGS, like the script interpreter, if you wish to keep same script (it is practically a stand-alone program, connected to the engine by its API). Similarily, a legacy behavior could be recreated as well, in a form of an alternative work mode, or plugin.

Personally, I've came to the conclusion that the engine needs full rewrite from scratch several years ago. I've even started to work on alternative, writing it on top of Allegro 5 library (but that's only one of the options). I had to cancel that work though, realizing that I will have to cease work on AGS itself, and people kept asking me to fix/improve things in it for their games (besides, at the time no one mentioned to be interested in helping me). Still wondering if that was a mistake on my part. I've returned to same thought earlier this year, and then learnt that several people are already writing their own alternatives to AGS, or have thoughts to start these. Personally, I'd rather join one of them if I had an incentive to continue doing anything AGS-related.

But, I guess this is all about your preferrence and goals. I joined this project thinking about redesigning AGS into a contemporary game engine. Instead, a year later found myself trapped in supporting old games and legacy features. After couple of years more I did no longer understand what am I doing and why. Today my old choices seem absolutely stupid to me.

[jdiperla]

Well CW I think over the last few years you have been the heart and soul of AGS. I would rather see support for older games be separated from supporting a new revised engine. And I think the priority should go to the new engine and support on the legacy stuff should come only if there is time to do so. Can we do something like that? Can the developers put their foot down, hold their temptations and place and start something like this?

CW, what wold you write the new engine in if you had a choice? Would you stick with C++ and C# or would you move away from that? Most people nowadays focus on porting. Which means Mac, Windows, iOS and Android for a certainty. Would that mean moving from Allegro 4 to 5 or even to SDL 2? OR would you do a rewrite on a more web based approach such as phonegap(Javascript, HTML, CSS).

I think it's important to focus on keeping things familiar with the current AGS and what makes it great and for why people use it. Otherwise it will be a different engine all together.

[ghost]

@jdiperla, I do not feel this is a right place to answer the questions you are asking me. I posted here just to state my opinion about very particular idea (continuing developing AGS with the existing codebase). I would not want to "steal" this thread or make it deviate onto another topic.

Besides, knowing what coding language I would use is really not the big importance, because people are often biased towards what they are used to.

[fdslk1]

Hello fellas, I wasn't going to comment on this, since I'm not developing for the engine itself, but I'm a user that actually use AGS and loves it.

If you want some input from a user that actually uses AGS, I'll just pinpoint some stuff that I've seen asked several times by other users that I think will come in handy in your decision making.

• A lot of users want and need better mobile support. Or at least better documentation. You can see an apk ready to download in some forums, but most users are unsure what to do with said apk or how to actually compile to mobile. So a native support for compiling to mobile (Android/iOS) in the binary version of AGS could come in handy.

• AGS is a hell of a software, that can handle a lot, but with mobile at current state, a lot of other users have asked if it can be ported to HTML5, which could even be a better solution than just going mobile. With the current state of WebAssembly, I'm not sure whether that's possible or not, but it will certainly attract a lot of new users and keep the user base at large.

• AGS may feel dated for a lot of users since it works mostly as old school game engines. The only thing I would add to it, and most people would find useful is scability to sprites and objects within the scene editor and parallax scrolling.

The rest of legacy options, I think CD Audio can be removed since that is becoming old tech nowadays. The 8 bit and palette system I would encourage not to remove since the very grace of AGS is the support of retro pixel style, which as most know: something people actually buy.

Anyhow, this is what I learned from other users, google searches and forum scavenging and that I see in most engines now to be added. I hope my insight comes in handy to you.

AGS is a great engine, it won't die while it covers better porting to other mediums than just desktop.

[rocifier]

Hmm as a dev interested in contributing this is a bit discouraging. A cross-platform rewrite would be an enormous undertaking and I'm not sure if there are enough interested devs floating around who know javascript. The thing that attracted me in the first place to AGS was its old school code base and its support for legit retro games on modern operating systems - not just "retro styled".

[ghost]

A cross-platform rewrite would be an enormous undertaking and I'm not sure if there are enough interested devs floating around who know javascript.

I heard there is already one javascript rewrite underway. Do not know much details myself though.

The thing that attracted me in the first place to AGS was its old school code base and its support for legit retro games on modern operating systems - not just "retro styled".

I am honestly confused by this, what is "old school code base"? The code in AGS is simply bad, which was very frankly admitted by its author. Similarily, I am also not sure what is the difference between "legit retro games" vs "retro styled"? With all honesty, I cannot think of any reason why one cannot make a retro game on modern codebase. Indeed there may be certain difficulties, like running 8-bit games with palette tricks on modern engines with 3d hardware-accelerated renderer (if that's what you mean?), but there are ways to solve even that.

Anyway, the meaning of what I was saying earlier was that, in my opinion, it is too late to continue refactoring AGS code "in place". You will spend lots of time, but will have a lot of same compatibility and system support issues in the end. It may be better, and perhaps even faster to recreate it, using contemporary backend libraries, and more convenient program design. That, even if you want to just have same behavior in the end.

[rocifier]

By old school I just mean C++ mixed with C. I guess you are right about modern engines being able to produce that style of retro games, where you actually can't tell (fake low res with nearest-neighbour sampling etc.)

If I was going to do this I'd use pixi.js which has masking support for the novel walkable masking technique we use, and deploy it using https://crosswalk-project.org/ with that combo we could probably get 60fps on most devices.

[fdslk1]

Anyway, the meaning of what I was saying earlier was that, in my opinion, it is too late to continue refactoring AGS code "in place". You will spend lots of time, but will have a lot of same compatibility and system support issues in the end. It may be better, and perhaps even faster to recreate it, using contemporary backend libraries, and more convenient program design. That, even if you want to just have same behavior in the end.

Honestly, I think for cross-compile the only thing AGS needs is the ability to port to HTML5. That's my mho

[rofl0r]

html5/javascript are quite bad technology, even though it is currently hyped... but in order to use it as a platform one needs a bloated, memory-hungry browser. example: firefox sources ship in a 200 MB compressed tarball, it takes an hour to compile on x86 system, and more than 4GB RAM. at runtime, the browser will need at least 200 MB, plus a lot more if you want fast javascript, which means there needs to be a JIT. that's only the baseline to be able to use JS at all. the game itself may then consume lots more. not exactly what you would want to run on some slim gaming console attached to your TV, etc. if you want fast code that's cross-platform, your best option is still C/C++. and that's exactly why still most of the more complex games are written in those languages. note though that even C++ will use a lot more RAM than C due to its coding style which heavily relies on dynamic allocation of new objects.

[ghost]

I found javascript a nice and easy language, but I only learned it recently, and have no idea of how well it performs (or how HTML5 performs). Since @jdiperla asked above, I would actually choose C++ if I were doing rewrite, but then again I may be biased here because I am very used to this language. There is already an "alternate" adventure engine written in C# (Mono), but I did not check its system requirements yet.

Perhaps, there could be a sense for having a js port alongside with "main" C/C++ program, but then it would have to be supported by another group of developers, because maintaining both at the same time would be overkill.

I also heard that there is a way to generate js script from C/C++ program (asm.js), but what is required and how it works is beyond my knowledge atm.

[jdiperla]

I think the export to HTML does mostly have to do with the fact that the game would then be available on multiple platforms. I have heard many folks on several forums say that Javascript performs significantly faster than C++ as well. It also seems to be that a few of the modern systems are making less and less use of C++ and I suppose it is feared that it may disappear almost entirely within the next decade. This is of course debatable. I think with Cordova/Phonegap/NodeJS... many feel that creating something in HTML5, CSS and Javascript will allow them to reach all the necessary platforms for their apps: Windows, Linux, Mac, Android, iOS and Universal Windows App(X-Box, windows phone, etc..).

Honestly, I spent the $70 for adventure creator on Unity because of it's cross platform capabilities. I have been creating an adventure game that has taken significantly long to do in AC. I am honestly torn on what to use as an engine, so I decided, what the hell? Let me try and make my own in Javascript. So I began experimenting in Javascript with Phaser and Easystar. Using software like ExtJS and Codemirror, etc... You can even make a cross platform editor that will work on desktop and mobile too.

The downside of using web technologies however is that there is no easy way to compile to a console or handheld video game system as far as I know. I think it would be possible to write up a plugin for Unity maybe that can import the game and then compile it to those consoles since Unity can use Javascript. But that may need to be a side project for somebody to do. The other issue is that web technologies leave your source and data open and exposed. Some game Dev companies may not like that idea. I know code can be obfuscated, but I believe that it can easily be reversed. One site offered a solution of obfuscating code by hiding in image files and that it was impossible to de-obfuscate that way. Not sure how accurate that is, but that is what they claim.

But going back to being torn about the engine to use:

AC: Powerful, some what user friendly. But unless you know Unity very well, you will only make a basic type adventure game. Unity is free, but has different license types that make it confusing and limiting. Visionaire: The closest thing to AGS, but the licensing and purchase options are astronomically stupid. AGS: My preferred engine of choice, but porting to anything else is just not easy.

I feel what is holding back AGS right now is also the fact that we are focusing on Legacy support and thinking of refactoring the code. I think it has done a decent job of going way back on legacy. And CW and others have dedicated and done so much to this engine. But I understand CW too when he mentions he wants to give up on upgrading AGS further. It just seems to be stuck in 2004. But maybe that is something that SCUMMVM should handle going forward. I think, whether C++ or C# is used or even Web Technologies, whoever develops AGS further should re-invent AGS to something a little new behind the scenes. It should have that familiar AGS feeling and ease of creating adventure games of course(We need to know, this is still AGS), but updated to have fewer bugs, more features, updated technology and cross platform capabilities. Maybe instead of going with the usual versioning system of 1,2,3,4... We can go with the year instead. For example: AGS 2018, the next versions: AGS 2018.1, 2018.23, etc...

I don't know. I love AGS. Nothing about the engine except it's lack of easily porting the games bothers me about it. If we can just solve that problem, I would be happy for a few years ;-)

[ghost]

I have heard many folks on several forums say that Javascript performs significantly faster than C++ as well

I wonder how is that possible for interpreted language to perform faster than the language it is interpreted on? :P Usually this goes down to how well the program is written (and how much optimization compiler does), because it is not hard to write a bad C code that would work slow.

PS. IMHO, with average adventure game the runtime speed is not a very big issue (I think that loading resources as player walks around is the most critical part).

[jdiperla]

LOL, good logical point. This is why we need you CW...

I guess it is also how well you write your code. Bad code in C++ can run slower than great code written in Javascript. I believe Game Maker Studio uses Javascript. As far I see, even if it is not faster than C++, it runs very effectively on most systems. The same with other games written in Javascript. So I don't see performance being the most significant issue of moving to it. For example, see this engine demo written in Javascript that is a few years old: http://jsgam.sourceforge.net/spookyadv/

Link to source: http://jsgam.sourceforge.net/

I believe it is more the code being publicly viewable by anyone and also porting to other systems like consoles.

I have found encloseJS that seems to compile to machine code. And then I also found that Emscripten(LLVM to Javascript) can convert C++ Projects to Javascript. Of course, as with anything, who knows how effective it is and how easy it is to use.