Been into language design recently, and I was recently reflecting on how glad I am that I have gone on to use languages other than GML. It has really broadened my horizons as a programmer.

From the point of view of language design, I hope to give an objective summary of GML's strengths and weaknesses. I have not used GML in a while so forgive me for any inaccuracies.

GML can get stuff done. GML, by virtue of its close integration with GM, makes arguably the most daunting part of making a game rather easy - getting started. This is by far GM's greatest strength. It is an excellent prototyping tool, as a result.

Let's size up GML:

- It is a procedural language. GML scripts consist of a series of function calls, with very little possibility for object oriented type control flow.

- It is dynamically typed, variables can be reassigned as strings or numbers at run time.

- It is weakly typed, it is entirely possible to use the number 1 as an object, as a data structure reference, and as a sprite, all by accident.

- It is integrated in an event-based framework. This event based framework is rather convenient, and provides a more or less logical way to divide up functionality.

- Arrays exist only as local to a script, or part of an object. There is no way to use an array as a value passed eg to a script.

- Data structure support is limited to built in constructs.

- Object orientation is limited to heavyweight objects with a physical presence (a hackish solution is to hide the physical presence of abstract objects, eg for a monster controller object).

Strengths:

- It is integrated in a convenient game development framework. It has an adequate standard set of functions.

- It encourages separation of code into events

- It is dynamically typed and does not force users to worry about type declarations

Weaknesses:

- It really only has two types - numbers and strings.

- Arrays exist - but not as a type. They exist only as a part of the local context, or of an object. They therefore are not appropriate for building abstractions on top of. You cannot, for example, have a standard set of scripts for treating an array as an inventory, as you cannot pass the array to those scripts.

- Scripts can only return a single value, and it can only be a number of a string. This severely limits the ability to build abstractions using scripts. This severely limits the ability to do useful things in scripts without directly modifying objects using the script. This breaks encapsulation badly.

- The data structures that do exist must be manually freed, and are awkward to use.

Did I mention it is almost impossible to make meaningful abstractions in this language ? It is, however, not entirely impossible.

Consider a very standard scenario where you want abstraction:

You are creating an inventory, and want to be able to have multiple, unrelated parts of the code to use this in a consistent way. You want to be able to pass an inventory from one object to another.

This is very hard to do in GML. What you can do:

- Create a set of scripts:

inventory_create(ds_index)

inventory_add(ds_index, name, amount)

inventory_get_amount(ds_index, name)

inventory_destroy(ds_index)

Now, as the implementation, have inventory_create make a ds_map. Then, each script will call a ds_map function that does the appropriate action. You will be able to change the internal structure of the inventory, eg make it a grid of nested structures instead of a map, without touching the places where the inventory is actually used. This goes for any other concept that needs some sort of data structure as its implementation.

Overall, this is not an entirely satisfying scheme, and scripting languages can do far better. I believe unless you code with many many small scripts GML will be promoting rather bad programming habits.