GameMaker: Studio vs Godot

Language does not support actual objects, structs, real data types, functions, overloading, even argument naming. Developers generally have to code around the lack of these features in very tricky ways.

The GUI must be hard-coded, leaving a lot of tricky calculations and jumping through hoops to accommodate different devices and displays; it's probably the least developed and hardest thing about GMS2 compared to comparable engines

In late 2012/early 2013, YoYo Games released a version of their new Studio IDE for cross-platform development that would import games and destroy all of the image type resources for some legitimate purchasers of the software by superimposing a pirate symbol on top of the image. This was due to a fault in their digital rights management software implementation which they use as a method of combating pirated copies of the software. Though the false positives bug is reported to be fixed, the DRM is still in place and may affect placeholder graphics, etc. YoYoGames publicly stated they would remove the DRM at a later point in time, but that other less-invasive DRM techniques would remain.

You need to buy extra modules to be able to export to platforms like Android, iOS, HTML5 and others.

There are no built-in refactoring tools. For example, you can rename a resource, but GM:S will not automatically change the mentions of it across the code to the new name. Furthermore, because all file formats are text-based, basic refactoring could be achieved by simply doing "find & replace in all files" -- which is a feature offered by pretty much every external code editor nowadays -- but no such feature here. Hitting Ctrl-F will pull up a rather odd Find/Replace box but selecting a word before hitting Ctrl-F will not autofill the Find field for you like it will in most tools. Even that you have to cut and paste yourself.

The cost for this tool is hindering for indie developers who have little money to work with.

In the past, the developer failed to update the software for iOS and Android when game-breaking updates were made to those platforms.

The change from 1.x to 2.x was cosmetic, the engine and language stayed the same. The roadmap for future development is also cosmetic and includes updating the sprite editor, adding an audio editor, and adding a "mini map" for the IDE.

No marquee select, no layers, can be glitchy, no grouping, etc.

Doesn't support embedding videos in a game.

There are several options with more flexibility, better learning resources, and a lower price point.

Because it uses GML, a very non-standard custom language, new users do not learn a transferrable language and become locked in.

Documentation and resources largely focus on proprietary scripting language, which is necessary for achieving full potential of the software due to poor drag and drop integration.

Support entirely focused on new iteration depriving even basic functionality of this version with any purchase that hasn't already been activated. It is still possible, thought not intuitive, to download this version on the trail screen for GM S 2. But no purchased (wildly expensive) module can be added any longer.

While the editor of course has features for intending code such as auto indent and smart tabs that can be turned on or off, these features work in unusual ways and, overall, the editor is not very adaptable to various typing styles. Also, Home always takes you to position 0 and never to the beginning of the text no matter how many times you hit it. Thus, if you hit Home and then Enter a new line, with auto indent on, it will always mess up the indentation on the line following the new line leaving you to fudge around to fix it manually. If you prefer tabs over spaces, forget it. Finally, if you leave the GameMaker app and try to click back into the code editor, the code editor will not fully get the focus sometimes leaving you with the ability to type but not tab. It usually takes two clicks to fully focus the code editor from outside the GM app.

They are not beautiful - for example, Undertale.

As opposed to other engines, which are open source or owned by game companies, GameMaker is developed by YoYoGames, which is owned by Playtech, a gambling software company.

Although C# is also supported by Godot, it is only supported by a separate version, and Mono must be downloaded separately. While GDScript is very accessible, and if you know Python you'll pick it up fast, having to learn a new language to fully make use of the platform can be a bit discouraging. And for those learning to code as well as learning Godot for the first time, many would rather learn a language they can 'take with them' when they explore other platforms in the future.

The base C++ code from Godot is not documented, it's hard to set it up, to compile and hard to extend, it could use better programming standards.

Minor bugs can go unaddressed for some time, due to it being a free program.

GDScript is copy of python and the real problem is, it is not python. Which means it cannot have all the power and new features that is available in Python or other programming language.

It does have some good features but it is not good enough for what you need if you want to deep dive into game development. You can just feel that by the godot team is solving that matter by supporting mono version. Because C# is popular in other game engine and it contains all the new features that is available from new programming language.

If i give you very simple example for why GDScript is immature, GDScript does not support asynchronous programming. Which is very efficient for performance of your game.

You may mention about multi-threading because asynchronous programming is one way of multi-threading. However If you try that in Godot, you cannot multi-threading where you want to implement asynchronous system. For example, Autoload (Fake singleton) where you want to manage data in real time. Autoload is not real singleton. It is not a separated thread that manage data. Therefore everything is synchronous in autoload. Even though you create new thread from Autoload script, your game will just stop and wait for your thread to finish its task...

The recent release of Godot 4 brings new features, but isn't yet fully documented, and performance may not be as optimized.

Given that you can target both desktops and consoles with the same code base in other engines, the lack of support for consoles in Godot is pretty hard to get past if targeting desktops for a game. But asking for an open-source engine to target consoles is probably too much to ask. But it would be interesting to see some legacy consoles targeted even if current ones cannot be.

Godot has an OOP architecture. Everything is an object internally and data is spread among many classes, thus it's difficult to optimize (i.e. not cache friendly, difficuly to vectorize or paralellize, etc).
Read about "Data Oriented Design" for more info about the problems and solutions.

Scenes can be made up of other scenes. That makes some sense. But even the smallest object (or prefab or asset) in a scene -- such as that spoon on the table or the marble on the floor -- is still called a scene... except when it's called a node. This is a bit odd for those coming from other engines. With all the great decisions behind the basic design of this engine, the choice of this term from all the potential other terms out there seems really out of place and only serves as a constant reminder that not everything about Godot is great.

Godot does not have an easy and automatic way to import atlases created by other tools. However, there are plugins that can be used to import atlases from other engines.

Box2d has much more features.

Godot has no native support for implementing advertisements into your game.

Coming from a Unity background, Godot engine is hard.