Engine & Editor V4.0 Alpha - Proposal

[CTxCB]

I love all the work you're all doing in AGS, but I really do believe in order to make AGS even more amazing, reliable and easy to use across multiple platforms there needs to be some changes to AGS' interior. Below I've listed the proposed changes I believe would have to be made as Engine and Editor V4.0 Alpha suggestions, these are not things that will happen... But if they can, I believe they should.

Engine

• Consider a move away from Allegro (including alfont, almp3 and alogg) and dumb (that's the name of a library!) libraries, opting to instead move to SDL 2.0 (including SDL_image, SDL_mixer, SDL_ttf and SDL_net) (https://www.libsdl.org/). I understand that this would take a lot of work, but I truly think if coupled with the needed rewrite... AGS Games could run more reliably, and it'd be easier to make AGS cross-platform without needing extra teams working on different ports.
• Networking is something that could be added as a little side-thing simply because SDL_net does a lot of the real work and only editor functions would be needed, I think.
• If a move to SDL 2.0 happens, consider allowing OpenGL and Vulkan support for newer graphic cards and processors.
• Consider looking for a new video library which is built for SDL 2.0, just because it'd probably make videos much better overall and possibly even add functionality.

Editor

• Consider making a move to Lua as a coding language, and allow Lua to handle Arrays, Lists, Random Numbers, and such. Rooms and scripts would be coded in it and work with AGS using bindings. I believe Lua would be much better for AGS because it'd be much faster to compile and run, and be much easier for game design.
• Consider moving away from .NET for the editor's framework to Mono (http://www.mono-project.com/). Mono is based upon the .NET framework and is cross-platform with Windows, Mac, Linux and I believe also phone platforms... This coupled with SDL2's cross-platform nature could mean Windows, Mac and Linux Editors and Engines could be built from one person with much less difficulty than there already is.

[Danvzare]

Consider making a move to Lua as a coding language, and allow Lua to handle Arrays, Lists, Random Numbers, and such. Rooms and scripts would be coded in it and work with AGS using bindings. I believe Lua would be much better for AGS because it'd be much faster to compile and run, and be much easier for game design.

I don't like Lua. Never have. I much prefer the coding language we have right now. It's a lot easier to use that Lua in my opinion.

Consider moving away from .NET for the editor's framework to Mono (http://www.mono-project.com/). Mono is based upon the .NET framework and is cross-platform with Windows, Mac, Linux and I believe also phone platforms...

I thought most Linux users hated Mono, to the point of almost condemning it.
At least, that's the impression I got whenever I looked at anything coded using it.

Except for these two caveats, you've got some good ideas. Are you going to try to implement them?

[CTxCB]

Consider making a move to Lua as a coding language, and allow Lua to handle Arrays, Lists, Random Numbers, and such. Rooms and scripts would be coded in it and work with AGS using bindings. I believe Lua would be much better for AGS because it'd be much faster to compile and run, and be much easier for game design.

I don't like Lua. Never have. I much prefer the coding language we have right now. It's a lot easier to use that Lua in my opinion.

Consider moving away from .NET for the editor's framework to Mono (http://www.mono-project.com/). Mono is based upon the .NET framework and is cross-platform with Windows, Mac, Linux and I believe also phone platforms...

I thought most Linux users hated Mono, to the point of almost condemning it.
At least, that's the impression I got whenever I looked at anything coded using it.

Except for these two caveats, you've got some good ideas. Are you going to try to implement them?

I don't know C++, but I'm open to learning it once I have a working computer again if nobody else can step up to make the changes... Which would be early next year! The reason I suggested Lua is simply because I think the coding language currently available, whilst good at what it does... Arrays, Lists, Random Number Generation, so on are badly handled, even if Lua is just behind the scenes and accessed through a binding to keep all the current code as is, Lua has so much functionality built in that AGS could benefit from.

If you have a better suggestion for a cross-platform framework that supports Windows, Mac and Linux, please feel free to suggest it... Because I do feel the limit of only being able to create your games or easily release them for Windows is a driving force between people moving away to other available products, even paid (Adventure Creator being an example). I think the problem here is that the engine has been built on a primarily Windows-orientated game development library, Allegro, and the editor has been built on a primarily Windows-orientated framework, .NET, and instead of fixing that sooner it's been built upon with more and more code to a point where such a task is very daunting. I don't blame anybody for that, I just think now is the time to stop working on AGS after the release of 3.4.1 and focus on these shortcomings.

[morganw]

If you search around the forum a bit you'll find a couple of people who have implemented a replacement engine, although they are work in progress:

https://github.com/tzachshabtay/MonoAGS (C#)
https://github.com/CalinLeafshade/adore (Lua)

There is currently an effort underway to cleanup the existing code, removing a lot of legacy components, so you may want to have a read here.

[tzachs]

Hi, as morganw mentioned, feel free to take a look at my project (work in progress), which is my "take" on how AGS 4.0 should look. It's not a rewrite but a completely new code base.

RE some of the points made here:

SDL- I'm using OpenTK, a c# binding for OpenGL which lets you choose whether to use SDL2 as your backend (or the native OpenTK backend).

Coding Language- Engine, Editor and scripting language are all intended to be c# and work cross-platform. Theoretically every language that can run on .Net can be used as a scripting language, though, possibly even including lua.

Re linux users hating mono- Well, I would say that the biggest reason linux users hate Mono is because it's c#, and c# is Microsoft. Microsoft used to be the biggest hater of linux (and open source in general), but it's quite the opposite today (in fact, Microsoft today is part of the linux foundation). Developers also hated developing c# on linux, because the only available IDE was MonoDevelop and it was not good. Today you have more (probably better) options for c# IDEs on Linux (people really dig both VSCode and Project Rider). There are other concerns about mono which are still valid today, like library size and performance (it is slower than dot net framework on Windows). For those 2 reasons, I'm planning to switch from Mono to .Net Core once OpenTK adds support for it (in their plans). .Net Core apps can be self-contained with a (hopefully) much smaller footprint, and are much faster than mono (and also faster than .Net framework), and it's open source, so all wins.

Networking- I'm not currently planning for building in networking, but as it's going to be simply a c# project (with no sandboxing), anybody can use the networking APIs from the standard library (or use any existing c# networking library).

Vulkan- Currently I'm only supporting OpenGL (and planning on adding DirectX support for XBox eventually), and Vulkan is not currently a priority for me, as it's not used exclusively yet in any platform and I'm tending to believe that 99.99% of AGS games won't need the high capabilities it gives you. That said, OpenTK might support Vulkan in the future, and then I might get it for free, and if not, I'm accepting encouraging contributions if somebody wants to add support.

Video- current plan is to use ffmpeg for video, it looks like the most complete solution for cross-platform video (and audio) streaming.