3. Difference between simulation and game.

Difference between simulation and game.


  • Btw, I was looking at the code and this is getting my attention:

    var ENVIRONMENT_IS_NODE = typeof process === 'object' && typeof require === 'function';
var ENVIRONMENT_IS_WEB = typeof window === 'object';
var ENVIRONMENT_IS_WORKER = typeof importScripts === 'function';
var ENVIRONMENT_IS_SHELL = !ENVIRONMENT_IS_WEB && !ENVIRONMENT_IS_NODE && !ENVIRONMENT_IS_WORKER;

    I still have to look at this, but I'm suspecting this will behave weirdly because the game mode runs in a sandbox with almost no variables set except those defined in the API.


  • The best thing to do I guess is just compile a smaller version of the ai and see if that works, if that works, experiment with adding some more code to the compiler.


  • Seems to use the (ENVIRONMENT_IS_WEB || ENVIRONMENT_IS_WORKER) case. The code runs fine in the simulation part so there shouldn't be any javascript error (I assume). Is there maybe some kind of size limit for the game mode or any other reason why no code would be executed?


  • I've tested myself and its use WORKER (in browser) and SHELL (in game mode)


  • Best thing to try is just to run a a bot that only does console.log('hello world'), then its easy to blame the compiler or the code


  • I couldn't even execute the text messages since no code got executed in game mode. I tried to upload the code via the grunt script, which told me that the code is to large(~2,5 mb). Is there some kind of documentation for the maxiumum file size? Have to assume that there's some kind of limit which doesn't apply in simulation. Emscriten does support some kind of code optimisation and shortening which currently "eats" the function I actually want to run in JS. Got to play around with that some more. Thanks for the help though!


  • Seems like the optimized one is around 500kb, still eating my functions though-.-

  • Dev Team

    Code size is limited to 1 MB at the moment. We've changed the error message to make it more clear.


  • Looks like a lot of wasted effort there - why would you do something that C++ does poorly and then translate it to javaScript, which could do it much better?
    Ditch this emscripten thingymajingy, it won't give you any benefits. You'd use C++ for speed and native binaries, translating C++ to JavaScript is a novelty thing.


  • Please keep it fun... besides, emscripting makes games in browsers possible. Improving emscripting would make it possible to ship it more easily to mobile browsers...