• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!
  • 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.

 Suggestion: Script annotation

GMWolf

aka fel666
I am a firm beleiver in reflective code when creating libraries, especially in GM where other solutions may not be availbable.

However, there is not much opportunity for reflective codde to be used effectivly at the moment as GM offers very little support for adding meta data.

That is why i suggest you include new syntax to add such information to scripts.
I propose two forms of syntax:
Code:
//suggestion 1
@something here
script_get_annotations(script)

//suggestion 2
#meta something here
sccript_get_metadata(script)
I will assume suggestion 1 for the remainder of this post, but the second suggestion would work in the exact same way.

In any script, you could write @something to add data to the script. Any number of such lines could be inserted into a script.
When calling script_get_annotations(script), it would return an array filled with each of the annotations as strings.
the following:
Code:
@global
@object oPlayer
would return the array ["global", "object oPlayer"] when the script_get_annotations() script is called.
It would then be up to the developer to know what to do with this data.

This would open up many possibilities to create far more powerful libraries. example use could be to define what script should run when a certain script is called by an object (@polymorph scr_parent object) , to explicitly define the return type of a script (@returns string), or globally binding scripts to events (@event ev_mouse ev_left_press). The possibilities are infinite.
This could even be used by future GM functions to implement more complex behaviour that would have previously needed the user to run arbitatry code at game startup.

This could even be expanded to objects, in order to have metadata about objects too. (I have in the past seen code that would simply use variables, create the object, then destroy it again after having extracted the variable.)

I believe that adding such functionality will drastically improve the quality of libraries, as developers will be able to offer much more complex behaviour with a very simple data driven approach. This would greatly benefit GM as a product as more the language will become far more mature as a result.
 
Last edited:

Mike

nobody important
GMC Elder
We currently have no plans for this, and it's not something we save out on a compile (99.999999% of devs woulldn't want it o it would be wasted space/memory). However it is something I use a lot in tools so I understand why you might like the addition.

File a suggestion, but don't look for it any time soon, it'll be WAY down the list....
 

xDGameStudios

GameMaker Staff
GameMaker Dev.
May I ask what are the suggestions that are up the list, now I got really curious?! :D
(just kidding it made me laugh thinking of it.. not in a bad way) ;)

I know you don't what to make a features road map... but I think it would be awesome :p if I saw I feature I really wanted being added
I would jump to buy the software right away (if I hadn't buy it yet)
 
Top