• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

 [Feature Request] Support running GML code inside room editor

M

mateusmp

Guest
Hello!
I've being using GM since version 7, there was a big upgrade in the general GM interface since then, however I still think that GM workflow is somewhat restrictive. What I mean is that we cannot customize the editor to make our work easier. Well, we sure can create a lot of windows and the tile feature is very useful for building maps now. However, we are still limited to what the IDE provides. In the last update we received a interesting feature: The Variable Editor. It's promising, helps to control object customization in rooms, however, the workflow to change/see these values is still too primitive. I'd like to propose an improvement to take better advantage of this new feature.

So, my suggestion is to allow GML code to run inside the room editor, without any restrictions. Someone might have already suggested this, but I couldn't find anything. Anyway, let me elaborate a little more:

What we can achieve with this:
  • Add debug drawings to show ranges, values, trajectory, and any other useful information for the level design.
  • Allow the creation of custom editors and tools to aid development.
    • The code should be able to save/load files (as any other GML code) and be able to modify current variable values from instances in the room. Create instances (tiles and others) and destroy them would be very useful. We might need to create custom functions for this, but I think it's acceptable (even if they are only available for the editor code).
Code that causes changes to Default Variables (x,y, sprite_index, etc) and the ones defined in the Variable Editor are persisted in the editor/project.
Basically we would have the "game" running in the editor, however, just in parts. The idea is to have the following events to allow this (any object may have them):
  • Room Editor Begin: Called a single time when the editor code begins running
  • Room Editor Update: Called every "frame"
  • Room Editor Draw: Called every "frame" allows drawing to the room screen.
  • Room Editor End: Called when the editor is closed (or a build is started)

These events are the minimum, with these we should be able to make any kind of tool/helpers needed. Other events may be added later, however, I think these two should be enough. Another important thing is: Any code added to these events should NOT be included in the final build. These are EDITOR only.

But how to handle a code with errors? Well, we should definitely NOT crash the editor. The behavior I expect would be that as soon as an error is received, the IDE should display the error in the console window and stop any editor events from running. A new button in the tool bar should be used to "recompile" the code and start running editor events again.
To avoid unnecessary IDE overhead, the code should only be executed when there is a room editor open.
The Room Editor End event is important to reset position (or other variables) to their correct value inside the game. Note that GM should not care about that. The tool developer should care about storing and restoring any changed variable that was "animated" in order to reset to the initial state. Ideally, building the project should stop these events (and call room editor end) so that the instances have a chance to be properly reset.

Currently I'm seeing this being used directly inside Instances and Objects.

Some example usages:
1- Coin Tool

I want to add a few "coins" in the room, but I want them to be in a very specific shape, say, a Circle. So I create a tool: tool_circle_coins.
In the Room Editor Begin code I initialize a few variables and in the Room Editor Update I add some code to grab user input and detect when the tool is activated (Like, by pressing 'C'). When the tool detects that, It begins to draw a circle with coins that I can increase/reduce with the mouse wheel (Draw code in Room Editor Draw). When I click, the tool understand that it should create those coins and add them to the room.
To use the tool I simply add it to the room and I should be able to "activate" it by pressing 'C' (as designed in the Editor Room Update code).

2 - Debug info and Animations
I have some Signs in the room, which should have a text on them during the game. However I don't want to make a single sprite for every text, then a good solution is drawing it during runtime. The problem arises when we want to manage the Signs and see how they look like in the game. Well, if we add some custom code in the Room Editor Draw event for the Sign, we could easily make it draw the desired text over the sign, so we can see how it will look like in the game. With this it's also much easier to see the text for each sign, without needing to open the variables (or instance creation code) windows. Another thing that would be good to know in editor "time", is the speed of some animations. Would be very useful to be able to change the animation/speed of some objects and see them running in the editor.

Note: This are only examples, I don't have this use cases in my projects or anything, however, I do have some similar uses and I'm sure most of you will see some use in this feature too.

I know it's a very big feature and I can't say how hard it is to implement in GMS2 in the current state. However, I do believe that it should be feasible.

Sorry for the long thread! Leave you opinions in the comments!
I'd love to hear the opinion from GMS2 staff and the community about this!

Thank you and Merry Christmas! ~~
 
Last edited by a moderator:

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
There are plans to allow editor plugins which would be able to do what you want, but it would likely be in C# (the language that was used for much of the editor itself and commonly used for this purpose) rather than GML While I imagine that people would afterwards do extensions that would allow to do something with GML itself in turn, that would likely be clumsier than with C#.
 
Top