The answer

[Goombert]

I wanted to take a bit of time as we have not posted an announcement for some time and I want to fill everyone in on the state of the project. Josh is currently nearing completion with JDI, it is a major portion, pretty much "the" portion of the compiler we have all been waiting for to be finished. We have been doing a lot of organization inside ENIGMA's engine and moving things where they properly belong over the past few days. If you are having any issues or anything you should stay on a prior commit for a little while until we sort some of these huge glaring cluster f***s out. For instance TGMG and Polygonz designed the actions around hardcoding everything and making them not modular enough to be excluded from projects, we are currently working on readding them to the system that actually implement them.

The completion of JDI means several things, one being that all those little compiler/parser bugs will finally be resolved. The other is that we will finally have the pretty printer capability we need for writing proper HTML5 and JavaScript ports, and Josh can mainly focus on getting us solid stable mobile device and embedded systems platform support. This will also mean even more improvements to speed and optimization capabilities over Game Maker, because currently well ENIGMA is faster using a compiler written by a 15 year old boy ^_^ and the new one is going to be by a 22 year old Computer Science college graduate who has built it with a very intuitive and thorough design.

The purpose of all this is to bring a few major systems into play, namely OGRE and provide underlying abstraction layers for other plugins and also namely physics extensions. One of ENIGMA's biggest opportunities over Game Maker is the level of abstraction and modularity provided by its engine. This means that objects can be implemented in any number of ways, for instance all of ENIGMA's underlying parts can be swapped out for a 3D oriented game engine vs a 2D one while maintaining that backwards compatibility and not having the systems get too intertwined.

I myself am currently working on a few major implementations for ENIGMA. Mainly I am looking to provide OGRE for a great alternative graphics system and Bullet Dynamics for 3D collision detection, physics simulation, and real time destruction capabilities. All of this is expected to be included in the default ENIGMA installation, as these extensions are expected to very lightweight mainly due to the level of abstraction provided by these API's. We will have updates soon enough 

[Josh @ Dreamland]

Ahh, exciting times.

A couple points:

JDI ("Just Define It") is a dual-purpose module in ENIGMA. It serves as a C++ definitions parser (so ENIGMA knows what draw_text is) as well as a framework by which other tools can communicate definitions to ENIGMA (such as the JavaScript port). I'll say more on this in a minute.

On top of JDI sits ENIGMA's parser. The parser takes all your scripts, events, actions, etc, and breaks them into pieces which it arranges in a way that makes dealing with them abstract. That is, the concept of with() and if() and while() cease to exist; the loops are loaded into memory in a way that makes them distinguishable from one-another, but independent of the syntactical constraints of any one language (ie, EDL).

After the parser runs, the abstract data is then pretty-printed into the desired output language. The output syntax may look exactly like the input syntax, or nothing like it; what matters is only that the output language can simulate (or use directly) all the constructs of the input language. In other words, it must be able to somehow make statements such as if, for, do, while, and with work, along with EDL's general arithmetic and function call statements.

One of the challenges here is making sure that JDI is capable of handling type coercion and overload resolution perfectly. This is 90% of the reason that the existing parser does not do any code decomposition; I was fearful of my ability to correctly interpret it and put it back together. JDI (or more specifically, the framework it lays out upon which ENIGMA's own representation is based) will be responsible for finding a good overload. When the new parser is implemented, its failure to do so will result in a syntax error.

To ensure that JDI is performing correctly, I am first attempting to remove (or at least substantially reduce) the number of parse errors incurred when reading ENIGMA's runner. Since C++11, this number has more than tripled. I am presently about half done rewriting that component.

Following that, type coercion will be fixed, which includes fixing the AST to assume that any identifier followed by ( is a function (right now, it's assumed to be a missing semicolon).

Once it is clear that JDI's AST is working correctly, I will finish implementing and testing ENIGMA's extension of it, thus completing our implementation of the new EDL specification.

Following that, it will be ready for pretty-printers. There isn't much else to do in that department, C++-side.

[egofree]

Excellent ! The future of ENIGMA looks very exciting. 

The main 'problem' right now is that ENIGMA is not very well known. I asked Pixel Prospector to add ENIGMA to their resources section. We will see. Also, when i will have finished my game, i will put it to various sites and promote that it was done with ENIGMA.
GM is the most famous tool for games development, but ENIGMA has the same functionalities and even more, and above all it's open-source and free ! It deserves to be famous.