What do you mean by nope? The way monkey works is by taking the code you write in monkey and then when you compile the game it'll translate the code to the native target you're writing it for. So if you want to make a game in HTML5 you would compile it in HTML5 and then it would translate the game into javascript. You don't have to do any of the work translating it.

as in "never ever touching anything that works like that because intermediate languages are the devil's work"

Well you should try it out first. Before thinking it's "the devil's work". And it doesn't work as an intermediate. It translate the monkey code into the NATIVE code for the platform you're coding for. So you can create an App or game for iOS, XNA, GLFW, Win/Mac, html5, and others all at the same time. So each one is optimized for the platform. There is no risk to it either. I say try it out for a bit before coming to the conclusion that it's bad. :)

I'm sure that this is a great system for those who prefer design work over the more tedious platform-specific coding, but for those who want maximally-effective code, it's not ideal. :\ [quote]So each one is optimized for the platform. [/quote]Looking at the JavaScript of the example game you linked to in the OP, I see quite a few bad practices: DOM0 event handlers (window.onwhatever). These is bad because it can cause problems if you attempt to use multiple scripts together. If they both bind to the same event on the same DOM node using the DOM0 properties, then one overwrites the other. Pollution of the global scope. Lots of CFG_WHATEVER variables. Lots of functions jammed into the global scope, that aren't encapsulated in a singleton or other container. Messy, messy, messy. Introduces the risk of variable collisions when outside code enters the picture, plus it'll pollute the UIs of many in-browser debuggers, such as Firebug. Lack of compatibility checks or graceful degradation. I'm seeing things like XMLHttpRequest being used without regard for browsers that might not support it. I could understand showing an error message, but not even checking for errors is just bad. General sloppiness. Direct use of "undefined" even though you can actually set a global variable with that name (use void 0 instead). Utterly useless functions like "dbg_object" and "new_bool_array". Redundant reinventions of the wheel in the form of functions like "string_replace" (use var.replace) and "string_startswith" (use var.indexOf). User agent string checks (no no no no NO!). References to paths on the hard drive of whoever wrote this code (hi, Matthew!). All that can be found in the first quarter of the <main.js> file. Mistakes like those aren't found in optimized code. In fact, reinventing the wheel instead of using native methods should [i]reduce[/i] performance.

Please note that Monkey is still fairly new. So everything isn't perfect. Also that most of the coding errors in the game it self is on my part for bad programming. not the program itself.

[quote]Please note that Monkey is still fairly new. So everything isn't perfect.[/quote]I know, and I tried not to be too hard on it by adding my first paragraph. [quote]Also that most of the coding errors in the game it self is on my part for bad programming. not the program itself.[/quote]The part I looked at was the first chunk of "main.js". I didn't see any game-specific script; it appeared to be the foundational code for whatever game engine Monkey runs off of. :\

Well everything is done at compile time. Which is why you don't see any game specific code.

Oh. I should look harder for the actual game-specific code when I have the time. The library code should be alterable by the Monkey developers at any time, so the game-specific code is gonna be the make-or-break stuff. I do find this all very interesting, by the way. Thanks for posting -- it's certainly a nice break from the rash of political threads hitting B.next.