How JavaScript beats GameMaker Language (GML)

You're viewing a single comment in a conversation. View all the comments
  • 4 Comments

  • Order by
  • That's one of the things I think is truly missing. being able to implement stuff in JavaScript is great, but it's not tightly integrated into the engine (yet). There is currently no parity with all the plugins/behaviors. a lot of stuff has not been implemented yet. and I get it the team is small and there is not enough time, and any feature that gets prioritized impacts other features. but the experience is not quite there yet. it kinda sucks when you want to trigger an action, you have to wrap it an a construct function. that adds so much bloat to a project, when one of the major benefits of using JavaScript is the way you organize your code. and its not just parity with plugins/behaviors, it's also parity with their SDK. there's pretty much 2 kinda similar but different code bases(JavaScript / plugin SDK). don't get me wrong it's great that they added support for javascript in the engine. it just feels very disconnected and I hope that changes time.

      • [-] [+]
      • 0
      • Ashley's avatar
      • Ashley
      • Construct Team Founder
      • 0 points
      • *
      • (2 children)

      There are a few options already for integrating code and events, such as callFunction to jump from JS to event sheet, and script blocks/actions to jump from event sheets back to JS. What would better integration look like to you?

      • Like another example is the disconnect between the editor and game, what I mean is other engines have way to enhance the editor, in unity you create a public variable and it becomes exposed in the editor, that's a simple example to illustrate what I meant by disconnect, to truly add extra functionality you have to use another editor to write JavaScript (which is different from the JavaScript you use to write your game, because the internal functionality of the engine itself that's exposed in the SDK is not exposed in the JS API), but it feels very disconnected which is the point i'm trying to make.

      • callFunction is fine, the issue is you have to write boilerplate events to invoke actions on plugins/behaviors that don't have an exposed interface. there are 30 behaviors in construct and only 9 of them have interfaces, didn't even count the plugins because there are too many. you're post highlights the performance boost of JavaScript, but a large portion of functionality needs a workaround to call in js? I am not sure what better integration looks like, I can only describe my experience.