Did you do this:
After cloning the repository run the following command in terminal to install the main binary files
python install.py mac

What do you mean ./ENIGMA in the project path? what project, the xcode project?

I still seems to work for me...

The license is well written and I do like the license I just would have preferred a well-used license which has been field tested. The main concern for users is suddenly finding a hole in the license so they would have to release their code under the GPL, our original intent won't  matter if lawyers can find such a hole. I appreciate that you will get a lawer to look over it but other lawyers are good at finding holes that one layer wouldn't.

I don't like limitation 4 and 5:

4: so I couldn't theoretically create a RPG game engine based on enigma without everything being GPL :/ Companies like to create internal engines which they can use for multiple games, so this wouldn't be suitable.
5: for a platform such as android the combined work IS a dynamic library, this would also stop plugins being created, for example some emulators can have a game engine plugin, that isn't the best example however.

I was hoping to just generate a static page for all the built in completions that only change when updating enigma (so the page can be cached) and send various project specific completions in a way that it can be stored on the client and updated when needed.

Sorry I didn't mean using a JavaScript parser to check EDL I meant implementing a basic parser (in antlr) which exports to JavaScript. When that success it can call the server for further analysis. It would check for specific basic problems such has missing an operator to give the user feedback as they type. It is to save calls to the server.

Thanks for that, that's not exactly what I wanted to hear about image editors :p but I agree with ace but also looking at code mirror.

Here are the main components I was thinking:
File sever: all this does is send yaml data for the resource when requested by the client via a URL (any web server, Dropbox API or local file system)
Enigma server: takes requests to parse files (via urls) and compile the game, executing the game will depend on the file server (local can just run).
Interface: calls to the file server to get list of all resources then when a user wants to edit a specific resource it requests the data from file server, also calls the enigma server for syntax checking, compiling etc

Ill have to lookup whether that has been fixed when I get home, but I don't mean it has to be LGPL, other licenses such as the GNU Classpath exception.
I feel writing our own exception would cause more trouble down the road and potentially deter users. Compared to using a tried and tested prewritten license.
Your license could potentially stop useful engines on top of enigma or companies that want to release multiple games with the same engine.
From a user perspective the more open the license is the better, more choices for game engines, new engine ideas being tried out etc

Low level Access will utilise the same basic enigma sever but the sever will be running locally rather than remotely. This allows one code base to be reused for both online and desktop components.

TogetherJS is definitely a lofty goal but it's good to think about the future potential of the IDE.

Most frameworks use WebKit or chromium afaik but yes if they don't they are not suitable.
I agree about syntax checking, I was mainly thinking of using a basic JavaScript checker first before calling the server to reduce impact on the server. If the user has done something really stupid it won't need to call the server.

Yes you make a very good point, I'll have to create a prototype and modify the competition so that it is more suitable. Which sounds quite fun, it's just finding the time..
Btw I know of a few good code editors but I'm interested to find out which image editors are available and which you would recommend.

Ah good so the compiler is GPL
Ok let's say the engine is worth stealing and a company created a closed source engine on top of it. They still have to make their changes available under the LGPL and if they are paying developers to work on it then it will benefit this project.
From a consumers perspective I'm willing to pay for an engine based on enigma if it adds substantional features. For example unity adds a number of expensive 3rd party components integrated in their engine and it can be worth paying for it because of those components.
I don't personally believe stopping enigma clones is a good idea, at the end of the day we are all trying to develop a really good game engine. The more built on the game engine the more stable it will become

The nodejs-webkit project is just one of the possibilities, if the interface is decoupled from the backend it could allow different technologies to be used:
QT: http://qt.digia.com/Product/User-Interface-Creation-with-Qt/HTML5/
WebkitGTK: http://webkitgtk.org/
wxWidgets: http://docs.wxwidgets.org/trunk/classwx_web_view.html
chromiumEmbeded: https://code.google.com/p/chromiumembedded/

I have no doubt that some c++ code will be needed for integration in the backend but hopefully that won't be too much of a problem.
Speed is a definite concern but i'm hoping there will be opportunities to optimize for cases such as large scripts and multiple windows/tabs. A way to manage unused tabs to load in and out of memory would be good with some UI trickery to appear instant would be cool! But we'll have to see what the performance concerns are and try to come up with clever solutions.

As for server side certain features such as basic syntax checking could be done on the client Javascript side, caching of the c++ code generated from each script would be useful to only compile the changes made.
Then there is actually delivering the game to the user which would probably best be handled by a custom plugin (something like the unity player).

Ideally I would like to use TogetherJS (https://togetherjs.com/) for a google docs like collaborative game editor.

But the contest is for the basic components that can be used to develop this project further, it could completely fall on its face but I'd personally like to find out how it will go.
I split the topic at your post hope you don't mind!

The compiler itself could easily be GPL as games don't need to link to it and the engine is developed around the compiler so if some assholes did want to do that they would need to write their own IDE and compiler and at that stage why not use a different 2D game engine which is open source.

That would be a significant investment paying developers to create an IDE and compiler and patching in bug fixes, and they would need to have an end product significantly better than ENIGMA in order to make any money. It is also in their best interest to keep development of the ENIGMA engine progressing and to submit their bug fixes to the community, which they have to as part of the LGPL anyway.

My opinion on the 2 points raised above:
1: assholes will be assholes, if they want to release a closed source enigma that exception won't stop them, they can cover there tracks and I doubt it is even worth taking legal action in a case like this. The OS version would be more attractive to developers and will have more features and bug fixes. If anything there closed source version may attract more enigma users when they find out.
2: hoarding bug fixes is not good for anyone it just means they have to merge every time we update enigma, they are welcome to spend there time doing that if they don't have much else to do.

I would personally prefer a more standard license such as LGPL that users can feel confident in. Rather than a custom exception that may have loopholes etc and that has not been as thoroughly checked. What would we loose from using LGPL?

The initial implementation will be using Java's built in Rhino Javascript implementation just like the original EGMJS which used this to run your javascript gml parser. The reason is that it adds very little overhead since java is already needed for LGM and debugging is much easier when it is not called through JNI/JNA.
V8 is a piece of cake to compile for Mac and Linux but unfortunately as you said windows is a right pain but i'm hoping to work on an ENIGMA extension which will run javascript as a scripting language anyway so it will need to be dealt with.

I wouldn't personally have emscripten do the work, I really don't like the dependence on LLVM and getting everything setup, adds unnecessary headaches. I would rather keep emscripten as a developer tool so users of enigma won't need to run emscripten itself (unless c++ extensions are used). Instead the enigma engine can be compiled by the enigma developers and called by the javascript code which enigma exports. Emscripten is too slow to run on every compile and writing out javascript directly will allow a much faster run-debug cycle.

Progress on your game, its looking much more like the actual game now:


But here are the errors I am trying to fix before the game will play like GM:

1) Parenting doesn't work, but you can easily get around this by copying the events over to the children.
2) Instance-destroy can't be used in collision event in enigma yet (gives EXC_BAD_ACCESS) {related to depth} {myiter seems to be 0x0}
3) The code "depth = 1 - y - 8;" seems to cause an EXC_BAD_ACCESS error in step event as it is put after an instance_destroy();
4) sometimes the bullets and people don't appear {related to error 4} something to do with setting depth
5) health isn't decreasing or bullets aren't being created
6) blood puddle and blood splatter isn't showing (unless you set depth to -1)

The easiest way would be for someone to fork my github (https://github.com/amorri40/Enigma-Game-Maker), modify any files required, submit a pull request. The when I get the pull request I will check which games use the functions implemented from here (http://www.alasdairmorrison.com/enigmaexamples/index.php), test the implemented functions in all of the games that require them and if they pass, I will merge the function into main svn. If they fail I will just reject the pull request with a reason.
Very easy to implement this system (its already implemented and ready to go now), very easy to accept and deny new functions, contributors can modify any files they want (add a new platform, bugfix etc) and easy to use (just click the fork button on github).

I have fixed this problem but need to wait until I separate the changes I want to add to svn from those that I don't.

I can get your game almost to compile, but currently enigma does not allow alarm setting in scripts so it causes a compile error.

These are the functions from your game that enigma doesn't have:

action_if_collision
display_set_size
get_string
message_background
message_position
message_size
show_info
show_question
sound_global_volume
sound_stop_all

I will implement action_if_collision, get_string and show_question when enigma allows setting alarms in scripts.

Would you mind if I ported the game to iphone and android at the same time?

Edit: Ok after replacing the script alarms with action_set_alarm, I manged to get it to run, but enigma currently has a few problems displaying it:



I'm looking into them and i'll try to fix if I can.

Open terminal, type:
cd "path to trunk folder"
java -jar lgm1*

wait for it to finish giving alot of text output in the terminal, and copy and paste it here.