What are the pros and cons of different game engines?

[Danvzare]

I like AGS, so I've kept using it. But it's occurred to me recently that I've never really considered the benefits and drawbacks of using AGS.
Then I started thinking about how some people will choose a game engine, start working on their game for a while, find a problem with the game engine, choose another game engine, recreate their game up to the same point, find another problem, and just keep doing that over and over until they either give up on the project or settle on a game engine. (Usually the former.)
So then I started thinking about the various pros and cons of every game engine.

For Adventure games alone, you have:

• The Unity Plugin "Adventure Creator"
• Adventure Game Studio (of course)
• Sludge
• Visionaire
• And Wintermute

(assuming I haven't forgotten one)

For more generic game engines, you have:

• Unreal Engine
• Unity
• Game Maker Studio
• Or a custom built engine

So what would you say are the pros and cons of the various engines? Why would someone choose AGS over the others, or reject AGS over the others?
Personally I think a big pro for AGS is that it's completely free and open source, with an active community.
But I think a big con for AGS is that it's really difficult if not downright impossible for multiple coders to work on the game at the same time. It's not really a drawback that affects most of us, since we generally work on games on our own, but I still think it's a major drawback.

Thoughts? 

[Jared]

Well you'd need somebody who has tinkered with all of them to really tell you, and I don't know how many people have done that given the time sink that making an adventure game is.

You're correct that collaborative work on programming is difficult in AGS, not impossible but requires some coordination.  I left a project in a huff when issues with SVN meant I was getting constant compiler errors.  Ideally I wanted guys to write the new code and give me references for where they wanted it copied and pasted but I got ignored.

There are a couple of other things about AGS that to me seem to suggest its hobbyist roots.  Maybe I'm just paranoid but I've always felt as though the global script balloons too quickly and had memory concerns over it. (I understand some devs make characters objects in a scene for this reason) Other than that drawbacks of AGS would be a lack of 3d support, the fiddliness of some of the in-engine tools (I'm thinking particularly about walking areas, I've always found drawing those awkward), no real cross-platform capability in engine (though I understand there are decent third party tools) .

Due to my limited experience with others, I can't say that much.  Sludge, as I recall was very lightweight and used some odd formats, but as it was a hobby from one programmer there wasn't a lot of documentation.  I see there have been some new releases from another programmer, and sludge is also apparently open source now as well as free.

A drawback to Adventure Creator to me is that can't look at screenshots without getting a migraine lol.  There are a lot of menus with a lot of stuff in them, God damn.  But seriously I'm sure pros would include Unity being a highly optimized modern pro engine, the full 3d support, COLOSSAL online support, full cross platform infrastructure, the graphical tools look very flexible, etc. I mean frankly it looks pretty great.  I'd be using it if I had the time to commit to learning from scratch, but as I said the number of menus is intimidating.

Downsides to AC is the entry price point, apparently the licences agreement is that if you make a big profit you give some to Unity, people say there is a general awkwardness to working in 2d in Unity, and my understanding is that AC doesn't support walk-behinds in the same way AGS does.  It may have changed but apparently you needed to create everything you walk behind as an object in the scene.  It's something that can be done very quickly in Photoshop, but it's still a bit of extra busywork.

A free general engine you didn't mention is Godot which seems to have the reputation as the hipsters Unity.  Godot is free and anecdotally has more intuitive features for 2d gaming.  It's very lightweight in terms of design and file size but also surprisingly feature rich.  I played around with it briefly following a platformer tutorial and found it surprisingly intuitive.  3d support as well, no cross platform built in, but apparently there are 3rd party porters.  The amount of engine support and community online seemed pretty healthy.

[Crimson Wizard]

Other than that drawbacks of AGS would be <...> no real cross-platform capability in engine.

What do you mean? AGS engine is working on several platforms for about 10 years now...

I also thought Godot allows to build game for many platforms, at least its in my memory from the time was I checking it out.

But I think a big con for AGS is that it's really difficult if not downright impossible for multiple coders to work on the game at the same time.

You're correct that collaborative work on programming is difficult in AGS, not impossible but requires some coordination.  I left a project in a huff when issues with SVN meant I was getting constant compiler errors.  Ideally I wanted guys to write the new code and give me references for where they wanted it copied and pasted but I got ignored.

I wonder what were the problems that people face when code same game together. Obviously it goes down to splitting the tasks between the people, just like in any other programming project. If each person works strictly on their own, and even better in their own module(s) and/or room scripts, I imagine there should not be too many conflicts.

[Pax Animo]

For Adventure games alone, you have:

• The Unity Plugin "Adventure Creator"
• Adventure Game Studio (of course)
• Sludge
• Visionaire
• And Wintermute

(assuming I haven't forgotten one)

For more generic game engines, you have:

• Unreal Engine
• Unity
• Game Maker Studio
• Or a custom built engine

I'm not sure why AGS isn't on the "For more generic game engines, you have:" list.

I've seen and are personally developing a game in AGS which is not your bread and butter point and click adventure game.
I'm currently having no problems at all. (even if I needed someone else to work on a separate part of a script, I don't see an issue with just having that person send me the script and I'd place it where it's needed. (obviously crimsons solution to this is much better)

Ok so AGS may not be able to handle say, fast paced first person shooters, or maybe it can? maybe it's already been done?  but to assume it can only handle adventure games seems to me to be a misconception which is maybe because it's called Adventure Game Studio.

So to name a few styles which I believe ASG can handle, (tell me if I'm wrong)
RPG
Fantasy
Open World
Puzzle
Casual
Isometric (maybe some pathing issues on this one?)
Platform
Third-Person

I'm in no way experienced in most of this but I wanted to share my thoughts. 

[Crimson Wizard]

The current cons of AGS, perhaps from my personal perspective:

- Game editor is frankly subpar; user interface is often awkward and limiting.
- Game project source is difficult to read, let alone work with, outside the editor. Most of the game data is inside a big xml file, and rooms are saved in binary format so you cannot even look what's inside of them without launching AGS. Imported sprites are written into one big file, where again you cannot look into them or replace without running editor. This also makes parts of the project prone to file corruption: anything happens during saving the game may make you loose a whole room, or all of the sprites.
- For the same reason, it's complicated to work with AGS games under a version control tool (svn, git etc): as parts of the game are binary blobs, it is impossible to track the actual history of their changes.
- Lack of Unicode text support.
- Imperfect translation system, where translations may be complicated to update and easy to break. No true support for localizing other parts of the game rather than the texts: such as images, sounds, voices (you have to do this by hand, sometimes using workarounds).
- Building game packages for other platforms than Windows and Linux requires manual labour. No official support for gaming consoles.
- Scripting language is a mix of low-level and high-level concepts, but does not get any of these to the logical conclusion. So on one hand you cannot refer to plain variables and structs using their memory adresses, on another you have "managed" structs but the use of these is limited by incomplete syntax and unsupported features. It's like having bits of both worlds instead of one but complete.
- Script's implementation is slower compared to popular scripting languages. This won't be noticed if you have a regular point and click scene, but may quickly become a problem if you e.g. script a fast paced arcade sequence with physics simulation, etc.
- Most of the things may be only created at the design time. You cannot have dynamically created rooms or objects. This complicates working on anything that is not a standard point and click scene, and forces you to precreate almost everything in the editor, even if you need an object only for some temporary visual effect. If you want a "procedurically generated" scene or game, you have to precreate a number of dummy objects and reuse these.
- Game saves contain practically a virtual memory state, and may be restored reliably only if the game contains exactly same game objects.
- Lack of contemporary visual effect support: e.g. no GPU-based object rotation, no custom shaders, let alone any 3D effects. Any additional effects have to be scripted with the use of the pixel drawing (aka "software drawing") which is significantly slower.
- Engine is not well optimized for high-resolution games: the way it draws things, or loads resources, maybe works well with "classic" low resolutions, but not with higher ones.
- Abscence of debugging and diagnostic capabilities: you cannot tell what's going on inside the engine when it runs your game.

[Ali]

Also worth looking at is PowerQuest from Powerhoof: https://powerhoof.itch.io/powerquest

It's a name-your-price Unity plugin and I've seen it used in Intergalactic Wizard Force, which certainly feels AGS-y from a player's POV.

[Danvzare]

A free general engine you didn't mention is Godot which seems to have the reputation as the hipsters Unity.  Godot is free and anecdotally has more intuitive features for 2d gaming.  It's very lightweight in terms of design and file size but also surprisingly feature rich.  I played around with it briefly following a platformer tutorial and found it surprisingly intuitive.  3d support as well, no cross platform built in, but apparently there are 3rd party porters.  The amount of engine support and community online seemed pretty healthy.

I completely forgot about Godot, thanks for bringing that up.

I'm not sure why AGS isn't on the "For more generic game engines, you have:" list.

Mostly because "Adventure" is in the name. But that is a good point. AGS is pretty versatile for an engine that was originally made for just adventure games.
Although while it's definitely easy to make non-adventure games with AGS, you've got to admit that a lot of stuff that AGS does is geared towards adventure games, such as inventory items and the walk to function.
I'm fairly sure every engine I listed in the "Adventure Engine" list could support non-adventure games, and it wasn't meant to discredit AGS as being limited or anything. I was just saying that these engines in particular focus on making adventure games, not that they're only for adventure games.

Also worth looking at is PowerQuest from Powerhoof: https://powerhoof.itch.io/powerquest

It's a name-your-price Unity plugin and I've seen it used in Intergalactic Wizard Force, which certainly feels AGS-y from a player's POV.

Ooh, that looks interesting.

[Jared]

Also worth looking at is PowerQuest from Powerhoof: https://powerhoof.itch.io/powerquest

It's a name-your-price Unity plugin and I've seen it used in Intergalactic Wizard Force, which certainly feels AGS-y from a player's POV.

Oh wow, I had no idea this existed, this looks great!

[Nurz]

The current cons of AGS, perhaps from my personal perspective:

- Game editor is frankly subpar; user interface is often awkward and limiting.
- Game project source is difficult to read, let alone work with, outside the editor. Most of the game data is inside a big xml file, and rooms are saved in binary format so you cannot even look what's inside of them without launching AGS. Imported sprites are written into one big file, where again you cannot look into them or replace without running editor. This also makes parts of the project prone to file corruption: anything happens during saving the game may make you loose a whole room, or all of the sprites.
- For the same reason, it's complicated to work with AGS games under a version control tool (svn, git etc): as parts of the game are binary blobs, it is impossible to track the actual history of their changes.
- Lack of Unicode text support.
- Imperfect translation system, where translations may be complicated to update and easy to break. No true support for localizing other parts of the game rather than the texts: such as images, sounds, voices (you have to do this by hand, sometimes using workarounds).
- Building game packages for other platforms than Windows and Linux requires manual labour. No official support for gaming consoles.
- Scripting language is a mix of low-level and high-level concepts, but does not get any of these to the logical conclusion. So on one hand you cannot refer to plain variables and structs using their memory adresses, on another you have "managed" structs but the use of these is limited by incomplete syntax and unsupported features. It's like having bits of both worlds instead of one but complete.
- Script's implementation is slower compared to popular scripting languages. This won't be noticed if you have a regular point and click scene, but may quickly become a problem if you e.g. script a fast paced arcade sequence with physics simulation, etc.
- Most of the things may be only created at the design time. You cannot have dynamically created rooms or objects. This complicates working on anything that is not a standard point and click scene, and forces you to precreate almost everything in the editor, even if you need an object only for some temporary visual effect. If you want a "procedurically generated" scene or game, you have to precreate a number of dummy objects and reuse these.
- Game saves contain practically a virtual memory state, and may be restored reliably only if the game contains exactly same game objects.
- Lack of contemporary visual effect support: e.g. no GPU-based object rotation, no custom shaders, let alone any 3D effects. Any additional effects have to be scripted with the use of the pixel drawing (aka "software drawing") which is significantly slower.
- Engine is not well optimized for high-resolution games: the way it draws things, or loads resources, maybe works well with "classic" low resolutions, but not with higher ones.
- Abscence of debugging and diagnostic capabilities: you cannot tell what's going on inside the engine when it runs your game.

Sorry to resurrect an old thread, but which of these cons still stand in AGS now entering version 4?

[Crimson Wizard]

Sorry to resurrect an old thread, but which of these cons still stand in AGS now entering version 4?

Hmm, let's see...

...Most of the game data is inside a big xml file, and rooms are saved in binary format so you cannot even look what's inside of them without launching AGS. Imported sprites are written into one big file, where again you cannot look into them or replace without running editor. This also makes parts of the project prone to file corruption: anything happens during saving the game may make you loose a whole room, or all of the sprites.
- For the same reason, it's complicated to work with AGS games under a version control tool (svn, git etc): as parts of the game are binary blobs, it is impossible to track the actual history of their changes.

Since 3.6.0 there's a command that fully recreates spritefile from the source images, making it possible to rely only on these sources when sharing a project (although the process of recreation takes time, but it's in range from tens of seconds to few minutes for huge projects).
In AGS 4 Rooms are now stored in open format.

- Lack of Unicode text support.

General Unicode support was added in 3.6.0. There are still few things not working without extra effort from the user, primarily related to the RTL languages (Hebrew, Arabic, Persian), and possibly text input not working well for more complex cases like Chinese.

- Imperfect translation system, where translations may be complicated to update and easy to break. No true support for localizing other parts of the game rather than the texts: such as images, sounds, voices (you have to do this by hand, sometimes using workarounds).

There's a first step towards better translation format in AGS 4, where translations are now saved in PO format, making them more break-proof. But other problems still remain.

- Building game packages for other platforms than Windows and Linux requires manual labour. No official support for gaming consoles.

Since 3.6.0 there's automatic building for Android and Web (Emscripten).

- Scripting language is a mix of low-level and high-level concepts, but does not get any of these to the logical conclusion. So on one hand you cannot refer to plain variables and structs using their memory adresses, on another you have "managed" structs but the use of these is limited by incomplete syntax and unsupported features. It's like having bits of both worlds instead of one but complete.

AGS 4 features a new script compiler, which fills in multiple gaps in the script syntax. There are few strange cases which do not work yet, but this is being addressed right now afaik.
In addition, "managed" structs are not limited anymore, and you may have managed structures of any complexity in script.

- Script's implementation is slower compared to popular scripting languages. This won't be noticed if you have a regular point and click scene, but may quickly become a problem if you e.g. script a fast paced arcade sequence with physics simulation, etc.

While it's true that AGS script is slower than other scripting languages, its runtime performance has been improved in 3.6.1, and a new script compiler in AGS 4 optimizes the compiled script making it somewhat more faster. There's probably still a potential for optimizing it further.

- Most of the things may be only created at the design time. You cannot have dynamically created rooms or objects. This complicates working on anything that is not a standard point and click scene, and forces you to precreate almost everything in the editor, even if you need an object only for some temporary visual effect. If you want a "procedurically generated" scene or game, you have to precreate a number of dummy objects and reuse these.

This still stands in general.

However, since 3.6.0 the Overlays became a noteable improvement in this respect. Since these may be created dynamically, and now you may have unlimited numbers of them, it is possible to use overlays to generate graphical scenes at runtime.

- Lack of contemporary visual effect support: e.g. no GPU-based object rotation, no custom shaders, let alone any 3D effects. Any additional effects have to be scripted with the use of the pixel drawing (aka "software drawing") which is significantly slower.

AGS 4 supports Rotation for almost everything (including cameras).
There's still no custom shader support though, or other things.

- Engine is not well optimized for high-resolution games: the way it draws things, or loads resources, maybe works well with "classic" low resolutions, but not with higher ones.

In 3.6.0 -> 3.6.1 engine received a number of performance improvements, making high-res games run faster, and even require less memory for some reason.

- Abscence of debugging and diagnostic capabilities: you cannot tell what's going on inside the engine when it runs your game.

Since 3.6.0 there's a System.Log script command that lets you print something to the engine log.
Since 3.6.1 there's a Log Panel in the Editor that lets display the engine log while you test run your game.
These two things combined improve debugging capabilities.
Unfortunately, while useful, it's still a manual workaround; as there's no mechanism to make engine tell you scene contents, or values of variables, etc.

[Snarky]

You sometimes complain about how you haven't (in your view) done a good job improving AGS, @Crimson Wizard, talking about mistakes you've made and so on. I think this list is a great demonstration that you, along with the other contributors, have in fact made great strides, even just in the last couple of years. Most of the things you listed as the major weaknesses of AGS back in 2021 have been addressed, or are currently being addressed, at least to some extent.

[Crimson Wizard]

You sometimes complain about how you haven't (in your view) done a good job improving AGS, @Crimson Wizard, talking about mistakes you've made and so on. I think this list is a great demonstration that you, along with the other contributors, have in fact made great strides, even just in the last couple of years. Most of the things you listed as the major weaknesses of AGS back in 2021 have been addressed, or are currently being addressed, at least to some extent.

Because they were not done in time. These should have been among the first things addressed in the open source AGS. Instead it took me almost 10 years to just force myself to work on some of them.
The first 5 or 6 years of development were majorly a waste of time, wrong directions taken, effort being spent on adding hacks and temporary solutions.

[Snarky]

Even if that were true, mistakes made 10 years ago are water under the bridge. Good stuff is happening now!

[Nurz]

Yeah, I endorse all the efforts made by everyone involved for AGS to still exist. I also hope it will continue to adapt to modern technologies, while retaining it's character.

And I'm glad you focus on performance and efficiency. The engine already gives non-programmers an easier route for creating their game. Naturally, the more low-level mechanics are exposed as buttons and options, the easier it is for beginners to get the hang of it. But while the lack of knowledge can be more or less compensated by a helpful community, a poorly performing game is detrimental to both the creators and the players. This is not a complaint, of course, just a statement.

[Stupot]

You might want to rethink Unity, at least until they u-Turn this nonsense.

https://www.axios.com/2023/09/13/unity-runtime-fee-policy-marc-whitten

[Nurz]

You might want to rethink Unity,

I don't know if you are addressing to me, but if I was to use another engine, that would be Defold. Not widely known, but proven, stable, fast, lightweight, and free.

[Danvzare]

You might want to rethink Unity, at least until they u-Turn this nonsense.

https://www.axios.com/2023/09/13/unity-runtime-fee-policy-marc-whitten

This honestly reminds me of the time Steam started charging for mods. 
I bet just like Valve, they'll reverse their decision, but I wonder if there will be any lasting impact, or if people will just forget the stunt they pulled after a couple of years. 

On the other hand, if they decide to double down, this could be the end of Unity.
In that case, maybe I might edit that original post just to remove Unity from it.