OFFICIAL GML Updates in 2019 (Follow up AMA)

Status
Not open for further replies.
Amazing thank you guys for everything!
GMLive has saved me so much time, I would love to live code editing as a built in option.
 
K

Kios

Guest
GML QUESTION: Is this going to affect the html5 export performance in any positive way?



My question comes from the observation that anyone with a JS background has made, that you guys are JS'ing gml, which is great btw.
But this begs the question, in a world where gml can be easily transferred into js, how is this going to impact the html5 export.

I like these changes, but I really hope that at some point you guys give us the possibility of a lightweight stripdown html5 export or something equivalent, that perhaps we can use for instant games and beyond. Perhaps these JSsy changes are you guys going in the direction of improving the quality of the web export? One can only hope.

Maybe you guys should also look into the main engine core being compiled into wasm*, and the player logic into js, specially given that gml will now map easily into javascript.

*wasm is decreasing in size and increasing in performance with every iteration.
 
A

Arconious

Guest
Just want to show my support and appreciation -- these are the kind of changes I was looking forward to when buying into GMS2. Great work, looking forward to release of these improvements/additions!
 
J

J_Dev

Guest
dont worry Once its out i will be making MANY videos on the subject :)
Thanks for being willing to help people! If I can make a request, take the actual examples from the blog and explain them. For instance, the new keyword section's vector3 function and how it defines an "add" method. I look forward to the info.
 

GMWolf

aka fel666
Thanks for being willing to help people! If I can make a request, take the actual examples from the blog and explain them. For instance, the new keyword section's vector3 function and how it defines an "add" method. I look forward to the info.
Well I breifly touch upon that in a video i just made on the update.
I would rather wait for some more concrete info / an actual release before making more detailed videos as it is not clear if this is the final form. (I wouldnt want to make a video that turns out to not be true once the update hits)
 
E

Ephemeral

Guest
Wait, is this change to scripts going to break the way instance-scope variables work from inside scripts? I've been avoiding that on principle but that is a major piece of functionality that a lot of users take advantage of...
 
F

FrancisClase

Guest
Ahora vale la pena comprar GMS 2, estaba pensando en cambiar a otro motor, pero le daré una oportunidad a GMS2, gracias chicos. :)
 

GMWolf

aka fel666
Wait, is this change to scripts going to break the way instance-scope variables work from inside scripts? I've been avoiding that on principle but that is a major piece of functionality that a lot of users take advantage of...
From what I gather: if you declare a function within the scope of an obect, then the self variable will be bound.
But if you declare a function in global scope, it will behave like a script does now. (So it will be 'bound' to global object, but any instance will 'overule' it).
But it very well could be that it get fully dound to the global object, in which case you would have to pass the self object in.
Perhaps you could call it with the dot notation though.

GML QUESTION: What happens when you call a global-scoped function from an instance? is the global instance bound to that function?
GML QUESTION: Could you use the . notation on non method functions? ie:
Code:
//Global scope
function doThing() {
    x = 10;
}

//some other part of code
inst.doThing();
Or will this not work because inst does not have instance variable doThing?

What would be the way to call a global scope function with self?
 

Lukan

Gay Wizard Freak
I'm seeing a lot of questions and not a single answer thus far... AMAs usually have answers :whistle:
 

Bingdom

Googledom
I'm seeing a lot of questions and not a single answer thus far... AMAs usually have answers :whistle:
YoYo games is based in the UK, and I doubt they outsource their support.

At the moment, the time for them is 1:20AM. I'm sure they'll get to it (like they have been in other threads), but at a more reasonable time.

Anyways, it looks like pretty cool stuff. Hopefully it won't be too buggy when it comes out.
 
Last edited:

Gradius

Member
Oh... oh my.

Still holding out for (optional) variable data types still... but this is a massive leap in the right direction. Ability to have a proper non-clumsy version of vectors, tuples, etc. Functions/scripts with properly named arguments. Proper error handling. Better garbage collection. It's all lovely, lovely, stuff.
 

zargy

Member
I'm really pleased that these improvements are being made. This might be enough for me to finally pick GMS2 up at some point.
GML QUESTION: Someone already asked about variable reflection for lightweight objects (like the variable_* methods), but I'll add method reflection onto that. Can we have something like method_get_name & method_get_argument_names?
GML QUESTION: Can we use the new keyword with standard objects in any way? Being able to give defined objects their own constructors would be very handy.
 

GMWolf

aka fel666
GML QUESTION: Someone already asked about variable reflection for lightweight objects (like the variable_* methods), but I'll add method reflection onto that. Can we have something like method_get_name & method_get_argument_names
I assume these would be the same as normal variables. Variables that hold the function
 
M

MadTinkerer

Guest
Just when I've finally given up hope of actually getting proper structs (a.k.a. lightweight objects) and decided to switch to Godot Engine, literally the next day this is announced.

I'm happy at the news, but YYG, you're giving me whiplash. This will be (potentially) the third time I'll be switching back to GMS2 from another engine. If you can actually do it this year, great. But you better actually do it this year, because I need to get my game done. I have to pay the bills eventually, and I can't wait for this forever.

EDIT: I guess that came off as more than a little cranky. I have a sprained ankle right now, so sorry about that. But the part about waiting actual years for this and switching engines back and forth (because everything has many of the features I need but nothing has all of the features I need) is true. At least until the features in the blog post are implemented, and then GMS2 finally has everything I need. :cool:
 
Last edited by a moderator:
This is amazing, I can't wait for this. Sooooo happy it's finally happening :D

I find this weird:
Code:
var log = function(a) {
    show_debug_message( a )
}
For a local function,

but:
Code:
function log(a) {
    show_debug_message( a );
}
For a non-local function


It would seem more consistent to be:
Code:
log = function(a) {
    show_debug_message( a );
}
The only difference being the "var" to represent it as local, just like with variables.

But maybe I don't know how this higher level coding stuff usually works :p
I have only basic knowledge of "real" languages.
I don't even really know what the benefit of using local vs instance functions would be.
 
I

immortalx

Guest
It's clearer now why GML updates were planned for Q4 and not earlier as many of us requested. This very early blog post is a rare thing these days, where companies tend to keep their books closed. I can only read this as "we're open for discussion" and that's a truly wise decision for such important features. Kudos to you YoYo.
I can only hope that notable members here will put their hand by making suggestions, and help shape the language to something that'll be the right thing for both them and the rest of us.
 
Yay! This is really good to see. We'll see if I actually get a chance to make use of this for my current project (which is already very far into development). I am really excited to take advantage of these new features when they come out. And, I look forward to future updates as well. If GML would consistently get new features I can only imagine what GMS2 could become. (So don't stop after this update just because it's a lot better than it was before).
 

FrostyCat

Redemption Seeker
I'm happy for the change that'll be coming in 2020, but let's keep our heads level and think a few steps ahead. Thoughtful feedback, not shallow felicitation, is what YoYo needs to make the new GML truly great. Besides, it's not in my character to not rain on a party.

GML QUESTION:

Chained Accessors
  • When chained accessors were last discussed, the promotion of data structures to true types was stated as a prerequisite. Has this been done?
  • Can accessors chain with the dot operator (e.g. foo[1].bar)?
  • Can accessors chain with the method syntax (e.g. foo[2]("bar"))?
Function Type
  • If a parameter name conflicts with an existing instance variable name, which wins? Example:
    Code:
    a = "foo";
    var log = function(a) {
        show_debug_message(a);
    }
    log("bar"); // foo, bar or no compile?
  • How will a var keyword used inside a function definition be scoped? Will the current "pull-up" behaviour still apply, or will this get new handling?
    Code:
    var func = function(a) {
      var b = "bar";
      show_debug_message(b);
      return a+1;
    }
    func(0);
    b = "baz"; // Is this local- or instance-scoped?
  • If two var statements have a name conflict, and one is inside a function definition and the other outside, what happens? Will this be allowed to compile, and if it is, which wins? Example:
    Code:
    var a = "foo";
    var log = function(b) {
      var a = "bar";
      return a+string(b);
    }
    show_debug_message(log("baz")); // barbaz
    show_debug_message(a); // foo, bar or no compile?
  • Will Auto-Complete be smart enough to hint parameter variables only when the cursor is between the function's braces?
  • Will Auto-Complete refrain from suggesting methods belonging to foreign objects?
  • How are optional arguments now handled?
  • How are functions with an arbitrary number of arguments now handled?
  • If given a function-type value, what will typeof() and string() return? And are other type-conversion functions prepared to handle this?
  • If a script-global function is stored in an instance variable, is it legal to call it from another source? Example:
    Code:
    // In a script
    function foo() {
      return x;
    }
    
    // In obj_a's Create event
    goo = foo;
    
    // In obj_b
    bar = obj_a.goo(); // Is this legal? If it is, whose x does it return?
    baz = method(obj_a, goo);// Or is this legal instead? If it is, whose x does it return?

Multiple Functions in a Script
  • How will GMS 2.2.3 tell unconverted old scripts from new scripts that has code intentionally not placed in a function() declaration, just to run on startup?
  • What will happen to script_execute(), now that multiple subroutines can go inside the same script?
  • Will there be something like script/function_execute_params(f, arr) where an array of parameters are expanded to function parameters, so that arbitrary-parameter functions can be called with runtime-built arguments? (the "17-case-script_execute()" hack isn't general enough anymore)
  • What will the role of asset_get_index() be for script names from now on? Will it support function names instead?
  • How are optional or arbitrary arguments now handled? What will happen to existing scripts that already take arbitrary arguments (i.e. use the argument[n] syntax)?
  • Will this supercede the clunky "add arguments in a GUI" system currently used in the extensions mechanism for GML extensions?

Lightweight Objects
  • What would inheritance look like with "lightweight objects"?
  • What does the static scope syntax look like with "lightweight objects"?
  • Are there plans for adding OOP interfaces for existing non-primitive types (e.g. resource tree types, data structures, buffers, etc.), particularly "orphaned" types like matrix, vec3 and vec4?
  • Will the built-in JSON functions transition to working with lightweight objects and arrays, as opposed to maps and lists? Or will they both be more or less equivalent in terms of behaviour with the garbage collector?
  • Will overloading operators, iteration/indexing, serialization (i.e. what string() would return if given as the argument), cloning, and boolean casting be supported? This is important for types that have well-defined mathematical operations (e.g. vectors and quaternions) or see frequent serialization (e.g. virtual board states).
  • How will different types of lightweight objects be distinguished from each other? Certainly typeof() wouldn't help as its proposed behaviour would just return "object".
  • Are there plans for renaming what we now call Objects to something like "Actors" to avoid future confusion?

new Operator
  • Are any existing resource types (e.g. data structures, buffers, etc.) retrofitted to support the OOP way of initialization?
  • Would using var inside of the function effectively give a "private" method or field?
  • The current proposed syntax presents a risk of unwanted behaviour if the new operator is omitted. For example:
    Code:
    function Vector2(_x, _y) {
      x = _x;
      y = _y;
      mag = function() {
        return sqrt(x*x+y*y);
      }
    }
    From here both var v = new Vector2(0, 0); and var v = Vector2(0, 0); are legal if called from within an instance (the latter questionably so only because of the default return value), but the latter will silently do unwanted behaviour. Would you introduce some sort of class keyword to prevent the second call from compiling, or let it slide and become a logic bomb, or handle it some other way?
  • If you do introduce the class keyword and make the distinction, the new operator would become a meaningless filler. Would you be open to OOP without the new operator? This would open the possibility of semantic, in-line data modeling similar to what GMSugar currently does.

Exceptions
  • How are custom exceptions defined?
  • Is there always one catch to a try, or can there be multiple catches for different types?
  • What kinds of code are allowed for handling an unhandled exception?
  • What happens if code for handling an unhandled exception throws an unhandled exception of its own?
  • For catastrophic errors or unhandled exceptions requiring asynchronous follow-up (e.g. submitting error logs to a server, integration with error reporting software such as BugSplat, etc.), what hooks/mechanisms are available?

Garbage Collector
  • Will data structures be garbage-collected?
  • Will circular references be garbage-collected? Example:
    Code:
    var a = [0],
        b = [a];
    a[@0] = b;
    a = undefined; // Will this allow a and b to be GC'ed?
  • In addition to current primitive GML types, strings, arrays and destroyed instances, what else are garbage collected?
  • Does implementing the garbage collector imply the promotion of any other dynamically allocated resource (e.g. buffers) to a true type, away from numeric indexing?

On-Boarding Concerns
  • Will YoYo release red builds to educators and power users sometime in Q3, so that they can create learning materials for the new syntax additions ahead of time and help spur adoption that way?
  • What happens to existing GML extensions on the Marketplace that have not been adapted to the new syntax?
  • What use cases for these new syntax elements have YoYo developers tested against? Will the internal test suite be open-sourced in ahead of time to help document that in an applied sense?
  • A lot of current advice on data organization will be obsolete following the GML 2.2.3 revamp, and you can be sure there'll be smart-alecs in 2020 trying to bump up old topics "advising" our 2017 selves. Will automatic topic closures be in place to prevent misinformation from spreading on the GMC?
 
Last edited:

Miradur

Member
Thx @FrostyCat , the first one to address honest words, I don't expect it to be published until February 2020 either.

YoYo has therefore decided to go in the direction of programmers, because all the naïve GMS users should understand only nothing,
as I do. For beginners with little programming experience, it becomes much more difficult when the learning curve points so steeply
upwards. Even more code will simply be copied, because only a few people will understand it if linked accessors or light objects are
used.

But at least we get to know such serious changes in advance, because from 2020 on you can step GMS, as it is now, into the barrel.
It will also mean that such basic things (for beginners) as tile collision, sprite editor revision, etc., will fall by the wayside.

I'm also a little surprised about the joy here, just a month ago I often read that they will leave GMS and now many party here, due to
an announcement that will be implemented at the earliest February 2020?

You are easily satisfied and seem to have a lot of money in the bank if you can wait a year. And the fact is, it's just promises at the
moment, because we all know the update policy of YoYo and I don't want to start at all.


Miradur
 

rmanthorp

GameMaker Staff
Admin
GameMaker Dev.
I'm seeing a lot of questions and not a single answer thus far... AMAs usually have answers :whistle:
Sorry if this wasn't clear in the initial post but we are going to let questions build over a period of time and return once the dust has settled with the answers.

Oh, and we are aiming for a full release by Q4 2019 so while I understand the Feb2020 concerns our sights are firmly set on the end of this year for stable.
 

Coded Games

Member
How will the script changes affect projects that heavily depend them? For example in my game each card is defined by a script. The name of scripts determines its type, for example card_1 and ucard_1 act differently in the game.

GML QUESTION: Are there any changes to functions like script_get_name, script_execute, or script_exists?
 

GMWolf

aka fel666
I'm also a little surprised about the joy here, just a month ago I often read that they will leave GMS and now many party here, due to
an announcement that will be implemented at the earliest February 2020?
Hehehe. Yeah. Yep yep yep.
I was ready to walk away. You see, my main issue with GM was code organizations.
I often said I liked the engine, just hated the language.
I suspect this is also true for many others.
But these new additions would actually make a massive difference.
Now yeah, they probably won't turn out just as perfect as I imagine. But even the. They will really help things.
You are easily satisfied and seem to have a lot of money in the bank if you can wait a year
GameMaker is a hobby for me, and many others. We can afford to pivot all the time.
 

Sammi3

Member
Hehehe. Yeah. Yep yep yep.
I was ready to walk away. You see, my main issue with GM was code organizations.
I often said I liked the engine, just hated the language.
I suspect this is also true for many others.
But these new additions would actually make a massive difference.
Now yeah, they probably won't turn out just as perfect as I imagine. But even the. They will really help things.

GameMaker is a hobby for me, and many others. We can afford to pivot all the time.
I'm the same, have been using different engines over the last few months and had been thinking of leaving GM. Code organization was annoying for me and it became difficult to create highly structures systems without having inflated code. I feel a bit confident, that with a little bit of hacking things together, you could manage OOP in GameMaker after this update. Imagine being able to create an Entity Component System after this :)
 

takis76

Member
12 Years have passed and YoyoGames decided to support Multiple Dimension Arrays and Objects. I prefer Structs most.
I am screaming in the forums about the 2D arrays are very small since the GameMaker was in version 4 and maybe earlier. The answer from the YoyoGames when I was asked them to support multiple dimension arrays was: "The Game Maker is for 2D games and more than 2D arrays are not necessary". I was explained to them all programming languages regardless if they can create 2D programs or 3D programs they support infinity index arrays since 1970. Also the objects in all of these years in the GameMaker were in generic a normal object which you needed to add them in the room and not apply any sprite to make it invisible and then you needed to apply local variables bounded in this object. Also the x and y variables where reserved in this object. Always I was screaming all of these years and I told them is better to create normal structs to hold more complex data and also told them to create and multiple array structs like C++.
So many years were passed. The GameMaker changed so many versions it became GameMaker 5,6,7,8,8.1 then it was sold to new founders then became GameMaker Studio 1 then GameMaker Studio 1.4 and then GameMaker Studio 2 and all of these years we beg people to create plugins to support multiple arrays.
Anyway I never used the GameMaker since it was in the version 7 because the game project I was creating used multiple arrays and structs and I was using other programming languages like C or BlitzMax or DarkBasic which support all of these many years ago and finally YoyoGames decided to add this at the end of 2019 and a decent programming language support all of these many years ago.
Another one thing which Yoyo Games needs to wake up, because it still sleeps in its long coma for many years is to adding a support of real 3D functions and support real 3D objects. A REAL 3D ENGINE. We do not live in 90s. There are competitors out there. The Unity creates 2D and 3D games, the Unreal Use 2D and 3D now The Game Creators with the new Application Game Kit they support 2D and 3D engine too. If I will start and name game engines which support 2D and 3D the list will become long. The philosophy of the GameMaker was to stuck in 2D realm and place limits in the functions. A real 3D Engine with Shaders, collision, spine, model animation, physics. This pseudo 3D which you place some 2D boxes in the room and then you create a game like a Wolfenstein reminds you live in 1980. This is a shame for YoyoGames.
Supplementary. I had an account here in the Yoyogames forums and was one of the early users and now I wasn't found it and I created a new one.
 

JackTurbo

Member
As someone who has been actively looking outside of the GMS sphere at coding patterns and principles, often the brick wall I've been hitting is how to implement these ideas in GMS due to GML's lack of certain features.

I'm personally pretty optimistic about the potential of these additions and look forward how much they'll simplify implementing established patterns to my projects.

@GMWolf I'm expecting you to drop some tuts on the subject once the gml updates are out! :p
 

2Dcube

Member
YoYo has therefore decided to go in the direction of programmers
I agree, more options is nice but it also complicates things, like the introduction of "var" did before.
I will happily use some of the new features as I have learned them in other standard programming languages but I know if I were just starting with Game Maker now it would be too much.

Unfortunately I think YoYo wants to keep up with programmers and (semi-)professional users as that's where the money comes from, I imagine.
 
Z

zendraw

Guest
I agree, more options is nice but it also complicates things, like the introduction of "var" did before.
I will happily use some of the new features as I have learned them in other standard programming languages but I know if I were just starting with Game Maker now it would be too much.

Unfortunately I think YoYo wants to keep up with programmers and (semi-)professional users as that's where the money comes from, I imagine.
unfortunately wuld be them making it like a lego builder and making you pretty much a modder rather then a game dev. unfortunate is that they deny 3D as if its a plague. gml is perhaps least complicated language there is, maybe you need to get good.
 

JeffJ

Member
I've honestly never understood those people who keep clamoring for 3d in GM. And I understand it even less these days. Simple reason being that there are so many tools out there that are much, much better at everything related to 3d than GM could ever be, and some of them even completely free and open source.

There have been a lot of YYG decisions that I've disagreed with a whole lot, but one decision of theirs that I definitely agree with is that they should stick with one focused mission of being the best 2d game development tool there is. That alone is hard enough with the current competition out there, but it's doable, and that's what they should focus on. 3d will only be a 💩💩💩💩show, something they will never be able to compete with, and it will only be wasted resources for them and everyone else. GM needs more focus, not less.

Do you also want Photoshop to do your spreadsheets? Or your hammer to put in screws? Use the right tool for the right job.
 
Z

zendraw

Guest
I've honestly never understood those people who keep clamoring for 3d in GM. And I understand it even less these days. Simple reason being that there are so many tools out there that are much, much better at everything related to 3d than GM could ever be, and some of them even completely free and open source.

There have been a lot of YYG decisions that I've disagreed with a whole lot, but one decision of theirs that I definitely agree with is that they should stick with one focused mission of being the best 2d game development tool there is. That alone is hard enough with the current competition out there, but it's doable, and that's what they should focus on. 3d will only be a ****show, something they will never be able to compete with, and it will only be wasted resources for them and everyone else. GM needs more focus, not less.

Do you also want Photoshop to do your spreadsheets? Or your hammer to put in screws? Use the right tool for the right job.
that is very close minded thinking, i am not asking GM to compete with 3d that is out there, but 3D to support further game maker in its 2D ambitions. and here is a simple example. making one 3D model rigging it and texturing it and importing into game maker VS drawing or rendering a bazzilion frames for 8-16 directional movement and making a ton of texture pages which further throws your game in the gutter. this wont remove the classical low res low frame animations people love to do it will only enhance the 2D possabilities for people who want a more HD or realistic look for theyr game. all it takes is a good shader, good mesh animation support and good 3D rendering. that is all to bring game maker alot of levels higher. they can beat around the bush with these insignifficant changes or additions all they want, it wont make game maker better nor people better at game making.

keeping game maker in the sprite hell circle is good in a way but too much goodness will eventually suffocate it. if not for pixel art, sprites wuld be 99% obsolete in game dev.

if yoyo cant implement these features in the engine then maybe they shuld hire more or other people.
 

Jase217

Member
I've honestly never understood those people who keep clamoring for 3d in GM. And I understand it even less these days. Simple reason being that there are so many tools out there that are much, much better at everything related to 3d than GM could ever be, and some of them even completely free and open source.

There have been a lot of YYG decisions that I've disagreed with a whole lot, but one decision of theirs that I definitely agree with is that they should stick with one focused mission of being the best 2d game development tool there is. That alone is hard enough with the current competition out there, but it's doable, and that's what they should focus on. 3d will only be a ****show, something they will never be able to compete with, and it will only be wasted resources for them and everyone else. GM needs more focus, not less.

Do you also want Photoshop to do your spreadsheets? Or your hammer to put in screws? Use the right tool for the right job.
It's simple, they like the engine and the way it does things, and believe it could be used easily for 3D games (Which it is already). Why would yoyo want people to move on to a different engine just for a little more 3D Support? There is definitely some demand for it after all.

As for the topic I'm very excited for these changes, especially functions, after using GM for years now I've had so many times where those would be useful.
 
Last edited:

JeffJ

Member
that is very close minded thinking, i am not asking GM to compete with 3d that is out there, but 3D to support further game maker in its 2D ambitions. and here is a simple example. making one 3D model rigging it and texturing it and importing into game maker VS drawing or rendering a bazzilion frames for 8-16 directional movement and making a ton of texture pages which further throws your game in the gutter. this wont remove the classical low res low frame animations people love to do it will only enhance the 2D possabilities for people who want a more HD or realistic look for theyr game. all it takes is a good shader, good mesh animation support and good 3D rendering. that is all to bring game maker alot of levels higher. they can beat around the bush with these insignifficant changes or additions all they want, it wont make game maker better nor people better at game making.

keeping game maker in the sprite hell circle is good in a way but too much goodness will eventually suffocate it. if not for pixel art, sprites wuld be 99% obsolete in game dev.

if yoyo cant implement these features in the engine then maybe they shuld hire more or other people.
I don't really follow. You say that what you want is to improve the 2d capabilities, and then go on to mention how you want to be able to more easily throw in a fully rigged and textured 3d model. How is that improving 2d?
You also make it sound like 2d is restricted to low res pixel art style, which is far from the case.

Lastly, the thing about this type of discussion is that it very quickly leads to the question: where does it end? You may have your ideas for how much 3d support should be added, but then when they finally do start acknowledging 3d and spending time and resources (of which they have very little) on it, it will only be a matter of time before people start asking for more, and soon it's a whole new suite of things to support. There are already so many other things we desperately need, and so in the end it really is a question of prioritizing what resources they have according to - at least to some degree - the wishes and needs of their key demographic users. The majority of whom just aren't that interested in 3d, because those of them who are/were, have moved onto other, more suited tools.

Why would yoyo want people to move on to a different engine just for a little more 3D Support? There is definitely some demand for it after all.
Because they don't have unlimited manpower and resources, and they need to prioritize accordingly. You talk about demand, but if you actually read the statement in this thread, all of the upcoming GML changes is a direct response to a community survey they ran a while back (which I remember participating in personally), where GML enhancements was the number one highest wish. So they are actually responding to demand. 3d just isn't high enough on the list, so you are in the minority in this regard.
 
I

immortalx

Guest
that is very close minded thinking, i am not asking GM to compete with 3d that is out there, but 3D to support further game maker in its 2D ambitions. and here is a simple example. making one 3D model rigging it and texturing it and importing into game maker VS drawing or rendering a bazzilion frames for 8-16 directional movement and making a ton of texture pages which further throws your game in the gutter. this wont remove the classical low res low frame animations people love to do it will only enhance the 2D possabilities for people who want a more HD or realistic look for theyr game. all it takes is a good shader, good mesh animation support and good 3D rendering. that is all to bring game maker alot of levels higher. they can beat around the bush with these insignifficant changes or additions all they want, it wont make game maker better nor people better at game making.

keeping game maker in the sprite hell circle is good in a way but too much goodness will eventually suffocate it. if not for pixel art, sprites wuld be 99% obsolete in game dev.

if yoyo cant implement these features in the engine then maybe they shuld hire more or other people.
There are literally tons of 3D engines with IDEs out there that are powerful, mature, and come with plenty of features. Asking YYG to be a competitor for them is not just a "just add another dimension folks" thing. I cannot imagine the amount of support functions needed in the language, let alone the changes that should be made in the engine. On the other hand, there aren't any really good 2D engines out there, with the exception of Ubisoft's UbiArt framework which might be the holly grail, but is both proprietary and closed.The rest of the "hybrid" engines don't do as good of a job as GM in the 2D department, especially when it comes to ease of use. This is the market that YYG can shine and they better keep doing what they do best.
 

GMWolf

aka fel666
GML QUESTION: How will we be able to test if a lightweight instance has a variable? Would that have to be done throug varaible_* functions, or could we get a keyword to test it? It would be useful to do cool ducktyping things.
 

Jase217

Member
Because they don't have unlimited manpower and resources, and they need to prioritize accordingly. You talk about demand, but if you actually read the statement in this thread, all of the upcoming GML changes is a direct response to a community survey they ran a while back (which I remember participating in personally), where GML enhancements was the number one highest wish. So they are actually responding to demand. 3d just isn't high enough on the list, so you are in the minority in this regard.
I agree and yes I have actually read the statement in the thread. This stuff is definitely a higher priority, I'm not arguing that. My point is I don't think they should just rule it out and never try to improve it's 3D capabilities eventually, It doesn't need to compete, but having some easier ways of doing basic 3D things would go a long way. I'd bet this isn't that far down that wish list!
 
Last edited:
Z

zendraw

Guest
I don't really follow. You say that what you want is to improve the 2d capabilities, and then go on to mention how you want to be able to more easily throw in a fully rigged and textured 3d model. How is that improving 2d?
You also make it sound like 2d is restricted to low res pixel art style, which is far from the case.

Lastly, the thing about this type of discussion is that it very quickly leads to the question: where does it end? You may have your ideas for how much 3d support should be added, but then when they finally do start acknowledging 3d and spending time and resources (of which they have very little) on it, it will only be a matter of time before people start asking for more, and soon it's a whole new suite of things to support. There are already so many other things we desperately need, and so in the end it really is a question of prioritizing what resources they have according to - at least to some degree - the wishes and needs of their key demographic users. The majority of whom just aren't that interested in 3d, because those of them who are/were, have moved onto other, more suited tools.



Because they don't have unlimited manpower and resources, and they need to prioritize accordingly. You talk about demand, but if you actually read the statement in this thread, all of the upcoming GML changes is a direct response to a community survey they ran a while back (which I remember participating in personally), where GML enhancements was the number one highest wish. So they are actually responding to demand. 3d just isn't high enough on the list, so you are in the minority in this regard.
you focus on the word 3D and fail to see the potential of adding rigged meshes and textures in game maker. so let me say it this way. ok so they dont need to add "3D" what i wuld like them to build into game maker is a rigged mesh that i can animate. and what is hard to follow? didnt i just give an example of how a simple rigged and textured mesh wuld remove the need for bazzilion sprites, code and gameplay limitations becouse of the vast number of sprites needed? what is hard to follow exactly? and these changes that are such a high priority are just laughable and essentially for comfort, they dont push game maker any further as a game dev engine, GMS1 pushed it as further as it culd, there is nothing new and signifficant here, but i can guarantee you if they put this simple thing, a rigged mesh that animates, that alone will impruve game maker alot. my point is these changes and additions arent game changers.
 

gnysek

Member
I agree and yes I have actually read the statement in the thread. This stuff is definitely a higher priority, I'm not arguing that. My point is I don't think they should just rule it out and never try to improve it's 3D capabilities eventually, It doesn't need to compete, but having some easier ways of doing basic 3D things would go a long way. I'd bet this isn't that far down that wish list!
While they don't want to have 3D at all in fact. It requires too much attention then. I also wish it will be possible to use 3d models in 2d, but... there are other tools for that already (at least two of them are free to use), so it's better to add the features they don't have, rather than what GMS2 doesn't want to be.

However using flat polygons/vertex shapes for 2d graphics, isn't a 3D.
 

Fanatrick

Member
I'm also a little surprised about the joy here, just a month ago I often read that they will leave GMS and now many party here, due to
an announcement that will be implemented at the earliest February 2020?

You are easily satisfied and seem to have a lot of money in the bank if you can wait a year. And the fact is, it's just promises at the
moment, because we all know the update policy of YoYo and I don't want to start at all.
A bunch of us have been requesting this for a decade now, it's only natural and hardly surprising. We're rejoicing about their movement in this direction after their years of catching up with the industry and blindly following some short-lived trends. The worst part of the engine was easily its scripting language, hearing that's about to (potentially) change should be met with positive feedback.

I also don't see what keeps you from your usual work in the meantime. I don't have a problem with real questions being raised (especially technical) but some people seem impossible to satisfy.
 

rmanthorp

GameMaker Staff
Admin
GameMaker Dev.
I agree, more options is nice but it also complicates things, like the introduction of "var" did before.
I will happily use some of the new features as I have learned them in other standard programming languages but I know if I were just starting with Game Maker now it would be too much.

Unfortunately I think YoYo wants to keep up with programmers and (semi-)professional users as that's where the money comes from, I imagine.
Our answer to 'YoYo has therefore decided to go in the direction of programmers' will be Sequences (also planned for the Q4 update). We will have more to share on Sequences soon but it's very designer focused and will be learning far more in the accessibility and 'less code' direction. I'm personally very excited for when we can share more about Sequences :)
 

XanthorXIII

Member
GML Question
Is there going to be a dedicated space for declaring functions in a project. I’d almost like to see some assignable header like file that we can create and assign to objects separately
 
K

Kyle Yancey

Guest
I realize the easiest way for you guys to do this would be for us to declare all of our methods for an object in the create event, but I'd really love a way to add methods with separate code windows in the same way we add event scripts. Help a brother out.
 

FrostyCat

Redemption Seeker
YoYo has therefore decided to go in the direction of programmers, because all the naïve GMS users should understand only nothing,
as I do. For beginners with little programming experience, it becomes much more difficult when the learning curve points so steeply
upwards. Even more code will simply be copied, because only a few people will understand it if linked accessors or light objects are
used.
I just don't understand this kind of sentiment about YoYo allegedly trying to obfuscate GM novices.

If linked accessors are really that difficult, then explain the positive feedback I get from my Universal Accessor workaround for chained accessors, some from people with less than a year's worth of experience. Not being restricted to one nesting level opens up new opportunities, and it doesn't have to be hard.

If light objects are really that difficult, then explain all the positive feedback GMWolf gets from his tutorial for the array+enum workaround, again some from people with less than a year's worth of experience. Being able to bind actions and data to things outside of the main stage opens up new opportunities, and it doesn't have to be hard.

YoYo is giving you easier, more formally supported tools to explore the other side of the game coding coin --- data-oriented code, as opposed to action-oriented code. It's not "harder", it's the complement to your skillset that most GM users have been deprived of over the past 20 years. Knowing how to check collisions is as essential as knowing how to access a JSON structure. It's just that mainstream GM education, the design of the GML language thus far, and popular sentiment make it seem not that way.

If there's anything I'd say few people will understand, it's all the hackish manoeuvres from people like me shoehorning data-oriented features into a language that chronically neglects data-handling use cases. That won't be the case anymore soon. I've never been more happy to see the days of my trickery-driven creations numbered and making way for more accessible, well-supported alternatives.

I agree, more options is nice but it also complicates things, like the introduction of "var" did before.
I will happily use some of the new features as I have learned them in other standard programming languages but I know if I were just starting with Game Maker now it would be too much.

Unfortunately I think YoYo wants to keep up with programmers and (semi-)professional users as that's where the money comes from, I imagine.
What do you mean by "like the introduction of var did before"?

As far as I'm concerned, var was never "introduced", it has been there for as long as GML has been around. You will find mentions of it even in the Manual for GM 1.0 (the first version after Animo), and its behaviour has been more or less constant this whole time. Mark Overmars knew what kinds of problems could arise if instance and global are the only two scopes available.

Beginner education material for GM over the past 20 years has consistently over-emphasized action-oriented programming over data-oriented programming. Most GM users have never been properly taught the other side of the coin. That's at fault here, rather than var actually being difficult.

I don't really follow. You say that what you want is to improve the 2d capabilities, and then go on to mention how you want to be able to more easily throw in a fully rigged and textured 3d model. How is that improving 2d?
You also make it sound like 2d is restricted to low res pixel art style, which is far from the case.

Lastly, the thing about this type of discussion is that it very quickly leads to the question: where does it end? You may have your ideas for how much 3d support should be added, but then when they finally do start acknowledging 3d and spending time and resources (of which they have very little) on it, it will only be a matter of time before people start asking for more, and soon it's a whole new suite of things to support. There are already so many other things we desperately need, and so in the end it really is a question of prioritizing what resources they have according to - at least to some degree - the wishes and needs of their key demographic users. The majority of whom just aren't that interested in 3d, because those of them who are/were, have moved onto other, more suited tools.

Because they don't have unlimited manpower and resources, and they need to prioritize accordingly. You talk about demand, but if you actually read the statement in this thread, all of the upcoming GML changes is a direct response to a community survey they ran a while back (which I remember participating in personally), where GML enhancements was the number one highest wish. So they are actually responding to demand. 3d just isn't high enough on the list, so you are in the minority in this regard.
I'll propose a counter-argument. In order for GMS 2 to excel as a 2D engine, it must open its asset and drawing pipelines wide enough to accommodate community-implemented 3D.

As much as YoYo would like to pat itself on the back about being the king of 2D game engines in general, it's not. It's only the king of 2D pixel action games, and anyone looking at the showcase with a critical eye can see that. It's not the king of any non-action genre because of its longstanding policy against data-oriented language features. It's not the king of 2D vector graphics, 2D skeletal graphics, 2D hi-res raster graphics, or 2D CTL text because its asset and drawing pipelines are closed to third-party expansion. Just look at YoYo struggling to play catchup in-house with Spine, video or non-Latin text, for instance. What if Esoteric could drop in the integration themselves, or if we could just drop in Harfbuzz or Pango ourselves?

It's also incredibly parochial to think that there's a hard line between 2D and 3D, and that code for one side won't ever see use in the other. For example, a page curl transition or perspective-compliant flip (i.e. not a simple image_xscale-with-sine flip) could certainly find use in games with 2D graphics, but they both have an obvious 3D influence. And increasingly mechanically 2D games come with 3D presentations, so the line blurs even more there.

It's precisely because YoYo doesn't have infinite in-house resources that it should design GMS 2 to be better at delegating. If Unreal's community could come together to make a 2D engine out of a 3D-geared engine, so could the GM community if YoYo would make GMS 2's core and IDE more extensible.
 

Bentley

Member
I understand the changes to arrays. I understand chained accessors. Everything else is new to me : ( But I'm excited, as it means that there is stuff to learn and use.

Can anyone explain what's happening with scripts?
 

matharoo

manualman
GameMaker Dev.
Can anyone explain what's happening with scripts?
Each script will have a function inside it, which is the script's main function. If there's code outside the function but inside a script resource, it will be executed when the game starts, before any room is loaded, and at a global scope.
Code:
/// Executed globally when the game starts
global.timePlayed = 0;
global.logData = ds_list_create();

// The script itself
function gameStart () {
    // Script code
}
All functions inside scripts (like gameStart()) are global. So you can have multiple functions inside one script resources.

Everything else is new to me : (
I recommend you check out some OOP videos/classes, especially classes/objects.
 
A

atmobeat

Guest
I'm pretty excited about the changes. As a GM user who has come back to programming through GM, I'm not sure I appreciate what all can actually be done with the new changes but I look forward to learning from this community. I've often read in the forums or heard in videos that one thing lightweight objects would be useful for is controller objects that don't need all the built-in variables and everything that accompanies them. But from what I read in the post, lightweight objects are not going to have their own events. So...

GML QUESTION: if I want an input object that reads my hardware every frame, a camera object to update the view, etc. how do I do that? Lightweight objects appear to just be storage containers. Can they perform logical operations, comparisons, etc.? Do I just need to use a normal object and in its step event tell the lightweight objects to do something each frame? Do the new functions/methods help here somehow? Sorry if I'm missing something here, but again I have a pretty limited background in programming.
 

FrostyCat

Redemption Seeker
Each script will have a function inside it, which is the script's main function.
Correction: There can be multiple subroutines inside a script post-changeover, not just a single main one. It's just that pre-changeover scripts will be adapted and wrapped inside a main function of the same name.

This makes 2020 scripts useful for implementing groups of related system-wide functions, along with the global setup they need. Here's an example based on my personal GMC Jam template:
Code:
ini_open(working_directory + "settings.ini");
global.sfx_on = ini_read_string("settings", "sound", "on") == "on";
global.bgm_on = ini_read_string("settings", "bgm", "on") == "on";
global.bgm_current = undefined;
global.bgm_inst = undefined;
ini_close();

function sfx_play(snd) {
  if (global.sfx_on) {
    return audio_play_sound(snd, 0, false);
  }
  return undefined;
}

function sfx_config(enable) {
  global.sfx_on = enable;
}

function bgm_play(bgm) {
  global.bgm_current = bgm;
  if (global.bgm_on) {
    bgm_stop();
    global.bgm_inst = audio_play_sound(global.bgm_current, 1, true);
  }
}

function bgm_stop() {
  global.bgm_current = undefined;
  if (!is_undefined(global.bgm_inst) && audio_is_playing(global.bgm_inst)) {
    audio_stop_sound(global.bgm_inst);
    global.bgm_inst = undefined;
  }
}

function bgm_config(enable) {
  global.bgm_on = enable;
  if (global.bgm_current) {
    bgm_play(global.bgm_current);
  } else {
    bgm_stop();
  }
}

GML QUESTION: if I want an input object that reads my hardware every frame, a camera object to update the view, etc. how do I do that? Lightweight objects appear to just be storage containers. Can they perform logical operations, comparisons, etc.? Do I just need to use a normal object and in its step event tell the lightweight objects to do something each frame? Do the new functions/methods help here somehow? Sorry if I'm missing something here, but again I have a pretty limited background in programming.
You keep doing those the traditional way with invisible "heavyweight objects". "Lightweight objects" are more for modelling data and its associated operations than carrying out actions in the game world, much like data structures and arrays are now. Not everything in game development is in terms of overt action.

The new method syntax will allow you to formally name reusable actions that your "heavyweight" controllers will routinely do, so that will benefit both data- and action-driven code.
 
Last edited:
Status
Not open for further replies.
Top