OFFICIAL GameMaker Studio 2 Is Here

S

Stratadox

Guest
This is all very relative... Personally I HATE seeing various code actions in a single event, and find it incredibly difficult to work with projects like that. Far better to use one code action and then set SCRIPTS to be the sections (imho). You can see in the action each script that is called all in one place and then MMB on each script to open it and edit it. Now, you may think this is a horrible way to do things, but that's why I say it's all very relative... ;)
Yeah I thought about using scripts to replace code actions, but it's not that its horrible, rather utterly lazy and innefficient, becuase looks like I'm forced now to make lots of scripts which I'll use only once, each one with it's own name for something otherwise could have been just the "Initialize" code block for instance variables in each object. or the block which stores string arrays for language. or the collision code exclusive for an individual object, perfectly identified. So you HATED it, kudos. But it was considered a best practice by many, and people who HATED it had the options not to use it. Now the rest of us don0t.

I'm sorry, but that's not even a proper solution to help users keep long chunks of code organized. Great.
The advantage of multiple (named) script blocks is that the event window provides a clear overview of the high-level commands, while hiding the implementation details in a separate yet accessible window.
A strong disadvantage is that the implementation is tightly coupled to the executing object and more specifically to that one event.
This decreases re-usability, which often leads to code duplication and therefore to a code base that becomes exponentially harder to maintain.


Prominent advantages of using scripts are that they promote code reuse, that they can be used to separate implementation details from the intentions of the object.
A huge disadvantage is the pollution of the global namespace, which promotes informal naming conventions and/or name collisions.


I'd argue that the inability to rely on abstractions (due to GM's lack of interfaces) forces the project into a tightly coupled state, whichever of these methods are used.


Well, if that's the problem, how about using annotations or blanks to clear it? like,

(a wall of codes about doing thing A)
//that code is for A

(another wall of codes, this does thing B)
//that code above is for B

like this. you can you use Ctrl+F to find out what code you're looking for. the blank line is for dividing A and B more clearly.
That would be a blatant violation of the single responsibility principle.


looks like I'm forced now to make lots of scripts which I'll use only once, each one with it's own name for something otherwise could have been just the "Initialize" code block for instance variables in each object
Initialising local variables (i.e. the properties of an object) is something I would (indeed) keep as close to the object itself as humanly possible.
Implementing all other logic, however, is not something the object in question* should be bothered with.

The better way is to encapsulate the logic as much as possible into highly cohesive modules (independent packages), and to keep these as replaceable as you can.



*This goes for GM-objects more than for those of other languages, as GM-objects are almost always models.
 
C

CedSharp

Guest
Yeah I thought about using scripts to replace code actions, but it's not that its horrible, rather utterly lazy and innefficient, becuase looks like I'm forced now to make lots of scripts which I'll use only once, each one with it's own name for something otherwise could have been just the "Initialize" code block for instance variables in each object. or the block which stores string arrays for language. or the collision code exclusive for an individual object, perfectly identified. So you HATED it, kudos. But it was considered a best practice by many, and people who HATED it had the options not to use it. Now the rest of us don0t.

I'm sorry, but that's not even a proper solution to help users keep long chunks of code organized. Great.
If you are unhappy with the current state of code organization in GML mode, why don't you accept with me that we need regions of code folding in the GML editor?
Instead of having many piece of code in one event, you still would have only one code editor, but it would look something like this ( just an example, nothing needs to be exactly the same ):

Code:
[ + ] // Get Inputs {{...}}

[ + ] // Movements {{...}}

[ - ] // Set correct sprites {{
          // Make sprite face current direction
          if( dir != 0 ) image_xscale = dir;

          // If in the air, check if jumping or falling
          if( fall_speed != 0 ) {
              if( fall_speed < 0 && sprite_index != spr_player_jump ) sprite_index = spr_player_jump;
              else if( fall_speed > 0 && sprite_index != spr_player_fall ) sprite_index = spr_player_fall;
          }

          // Otherwise, check if running or idle
          else if( dir != 0 && sprite_index != spr_player_run ) sprite_index = spr_player_run;
          else if( dir == 0 && sprite_index != spr_player_idle ) sprite_index = spr_player_idle;
      // }}
The '[+] and [-]" represent folding points :p
Hopefully this might fake the multiple piece of code from gm 1.4, and also help better organize code.
Just an idea tho ~
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
I am NOT a C, C++ or C# coder (and my JavaScript is limited to minor web stuff), so pardon my ignorance on this, BUT I find it really odd that so many people try to make GML into something that it isn't. I mean, I make huge games and have no issues with variable names or script names, and have no need of methods or inline functions nor lightweight objects. My games work fine, my code is efficient (maybe it could be more efficient with these things, who knows ?, but I optimise it a lot and it works), and on top of things it's all really really really EASY to understand and use. All these things that people keep bandying around make me think that either they are just buzzwords that people like to use to sound clever, or that maybe GM isn't the tool for them... Yes GML can be improved, but why does improving it have to mean copying other languages? GML works well and "does what it says on the tin" and enables me to make great games easily and without having to spend years learning about the intricacies of namespaces and prefabs etc...
 
A

Alessio

Guest
I think having unfolding code sections is a great idea, actually.

I still don't understand why so many people complain that GML didn't get improvements. The IDE did need a revamp first, GML was good enough for games but sure can be better but programming IS NOT the only main point of game development. Graphics, level design, music and user-friendly are, together with program, something that would not make the game working if missing.

Many people complained the outdated IDE of Game Maker and now that we're getting a much better IDE we have "programmers" complaining and some of the same "programmers" did say that Game Maker's outdated IDE was no problem because "you're supposed to make your own room editor".

In Tigsource, someone even went to say me to use Unity. Unity... for a pixel game? Let's make a NES game for Nintendo Switch then... with Unreal Engine Uber 5x2 Plus T_T
And someone else there also said me to find a programmer only because i did say that i DON'T WANT to be a programmer first, but, seriously, if GML is meant for beginning coders or for someone that wants to make a "small-scale" game like Undertale, WHY should i even get these bogus advices? I want to make a game, i will learn GML programming if i use Game Maker but i DON'T want to be a professional programmer nor i want to get a job as one!
Also someone else on the Game Maker Reddit boards even told me that "will take eight years learning GML and that your first game will be bad"... sure, tell that to Toby Fox, i wanna laugh.

GML is not a C++ replacement!!! It is the scripting language of Game Maker and thank god that Game Maker doesn't have to rely on external programming languages!!! I'm not against programmers at all, without them we wouldn't have those wonderful game development tools. It's those "code elitists", who think everything including love is code and that everyone should be a super coder, that should calm down a bit.

Also nobody said that GML will not be improved! The program is still in Beta! Give it time!
 
Last edited by a moderator:

Juju

Member
find it really odd that so many people try to make GML into something that it isn't.
Likewise.

However.

There is a definite scalability limit with GML. I have slammed into it myself, where the time spent organising large projects far outweights the time spent making the game. Some of that is down to iffy practice for sure, but the more that can be done to gently encourage good organisational behaviour the better.

GML has to be 1) fast to work with 2) accessible. Adding in more options for scoping variables does not do that. Adding in strict datatyping does not do that. Adding in some kind of "method analogue" might just fit the bill.

In my recent adventures writing pathfinding for Irkalla, I've had to use a big array of nodes, indexed using enums, which is traversed by an A* implementation. It's clumsy and harder to debug than it should be. Lightweight objects perfectly fit the bill. It doesn't need to get in the way of other features, it doesn't change the core of GML. It's potentially a bolt-on addition for developers who need to inch a little bit closer to performance.

GM's m.o. is extremely appealing to me as a developer because it cuts away the right things and lets me get on with making the game. The trick here is to raise the skill ceiling without also raising the floor.
 
Last edited:

MontyDrake

Member
If you are unhappy with the current state of code organization in GML mode, why don't you accept with me that we need regions of code folding in the GML editor?
Instead of having many piece of code in one event, you still would have only one code editor, but it would look something like this ( just an example, nothing needs to be exactly the same ):

Code:
[ + ] // Get Inputs {{...}}

[ + ] // Movements {{...}}

[ - ] // Set correct sprites {{
          // Make sprite face current direction
          if( dir != 0 ) image_xscale = dir;

          // If in the air, check if jumping or falling
          if( fall_speed != 0 ) {
              if( fall_speed < 0 && sprite_index != spr_player_jump ) sprite_index = spr_player_jump;
              else if( fall_speed > 0 && sprite_index != spr_player_fall ) sprite_index = spr_player_fall;
          }

          // Otherwise, check if running or idle
          else if( dir != 0 && sprite_index != spr_player_run ) sprite_index = spr_player_run;
          else if( dir == 0 && sprite_index != spr_player_idle ) sprite_index = spr_player_idle;
      // }}
The '[+] and [-]" represent folding points :p
Hopefully this might fake the multiple piece of code from gm 1.4, and also help better organize code.
Just an idea tho ~
That's fine by me, if it helps me keep my code tidy. Actually, right what I miss ANY good way to just help me identify quickly where are specific parts of code. It's all about being organized. We had one tool to help us in pieces of code and now it's gone just because, and apparently with no better feature to take it's place.

I am NOT a C, C++ or C# coder (and my JavaScript is limited to minor web stuff), so pardon my ignorance on this, BUT I find it really odd that so many people try to make GML into something that it isn't. I mean, I make huge games and have no issues with variable names or script names, and have no need of methods or inline functions nor lightweight objects. My games work fine, my code is efficient (maybe it could be more efficient with these things, who knows ?, but I optimise it a lot and it works), and on top of things it's all really really really EASY to understand and use. All these things that people keep bandying around make me think that either they are just buzzwords that people like to use to sound clever, or that maybe GM isn't the tool for them... Yes GML can be improved, but why does improving it have to mean copying other languages? GML works well and "does what it says on the tin" and enables me to make great games easily and without having to spend years learning about the intricacies of namespaces and prefabs etc...
That's great an all, but you're not really getting the point. It's not about making GML into something it isn't. No one here is criticizing GML for lacking functions or working not as intended, at least not me. It's about keeping code clean and tidy. I'm sure you're games are great, and this is all really really easy peasy lemon-squeezy to understand and use. But once a pìece of code reaches 600+ lines (and they do) you just need a good way to navigate through different sections of code (regions, pieces, blocks, call it whatever you want). We had a way (not a perfect one, though) including several pieces of code in the same event. Now we don't, and scripts are not a solution (at least not for me), because as Stratadox said before.

A huge disadvantage is the pollution of the global namespace, which promotes informal naming conventions and/or name collisions.
This is not making GML into what it isn't. Game Maker Studio already has a text editor for code, GML already is a language, we already depend on built-in variables, instance variables, global variables, and local variables. This is true to any eviroment which supports coding. The auto-complete window can be easily overloaded with terms you don't need this way, just to name one problem, and its not about GML. But if you want to talk about GML , people talking about missing actual improvements in GML with buzzwords, they may actually know a thing or two more than you supose. They maybe even providing good ideas to improve your dear GML, like the array literals already included, or were you against array literals before they were included? Just because JavaScript used them too. Or are you against tiping score++, instead of score = score + 1, just because it's copying C#? It's not a sin to expect GML to be updated to keep the pace.

But back to my topic: folding, would be an answer (one of possible many), and it's not about being a "C, C++ or C# coder", or copying those languages. Dreamwaever has it for HTML, Notepad++ has it for any language (at least as far as I know), and it's quite common to have this kind of features wherever you have the chance to write code and you live on the 21st century. No matter the language.

It's too much to ask for an efficient way to keep code tidy? or even miss the one we had?
 

Alice

Darts addict
Forum Staff
Moderator
Alright, um, to sort some things out...
I mean, I make huge games and have no issues with variable names or script names, and have no need of methods or inline functions nor lightweight objects. [...] All these things that people keep bandying around make me think that either they are just buzzwords that people like to use to sound clever, or that maybe GM isn't the tool for them...
Many people complained the outdated IDE of Game Maker and now that we're getting a much better IDE we have "programmers" complaining and some of the same "programmers" did say that Game Maker's outdated IDE was no problem because "you're supposed to make your own room editor". [...]
GML is not a C++ replacement!!! It is the scripting language of Game Maker and thank god that Game Maker doesn't have to rely on external programming languages!!! [...] It's those "code elitists", who think everything including love is code and that everyone should be a super coder, that should calm down a bit.
You people might have never felt the need for language features such as object methods or lightweight objects/structures, and you might find the new room editor extremely useful; and that's perfectly fine. You have your way of using GameMaker, you make the sorts of games that wouldn't really benefit from these features, and that's perfectly understandable, because some games are like that. And for people making these sorts of games, the additions available so far are indeed a great improvement, and there's no denying that they are generally a big step forward.

However, there are people who have different, more code-heavy style of using GameMaker, perhaps because the games they make just rely much more on custom logic and coding, and having these additions would significantly simplify things for them. Calling them "code elitist" or implying they just use "buzzwords" to "sound clever" is, in my opinion, rather belittling. These people want to make game fast and efficiently, too, and GameMaker, in many ways, gives them the right tools. In particular, it's an extremely useful abstraction for all these graphics storing and handling, audio playback, game loops etc. etc., not to mention all these textures compilation and multi-platform capabilities.

Overall, it's one hell of a wheel they don't want to reinvent, because they aren't, in fact, the sort of "coders" that just want to use programming languages for everything and overcomplicate things just to show how much of haxxorz they are. They just want to get the things done, and GM is, despite GML shortcomings, one of the best options available at the moment. For them, these language shortcomings are the main source of annoyance and obstacle to make things even smoother; is it wrong that they want that part fixed specifically, and aren't overly enthusiastic about e.g. revamped room editor?

Also, just to show examples that some sort of game-related tasks could really use particular features:
  • object methods- ever used User Defined X events? What you use these events for, you could make even better with methods - you would get descriptive names instead of magic numbers, you wouldn't be limited to 16 events, and it'd be much easier to make a generic user event driven framework that doesn't collide with others. Also, if some code is specific for a single object, you can just put it in the object method, have it neatly kept where it's useful the most, and not clutter the Scripts resource tree for little reason.
  • lightweight structures - storing data for some algorithms; e.g. when solve-generating a Sudoku or other puzzle like that
  • more detailed type system - ability to tell the lists, maps and integers apart; so that if I'm processing some JSON file (say, with dialogue data), I can handle them accordingly (e.g. when there's a list, I process all maps inside, but if it's a map, I process that single map directly); mind, it doesn't necessarily mean sacrificing GML's dynamicity, in a similar way ability to tell strings and reals apart with is_string(), is_real() doesn't mean a once string variable must remain a string forever

Finally, I don't think having a few new GML features will make the language harder to learn. Longer to master, maybe, but as mentioned, new features shouldn't interfere with existing ones (in fact, some changes already made, such as changing the string format, are more breaking in that regard). And I don't buy the argument about "making GML into something it isn't". Just because it works well enough for a certain range of tasks doesn't mean it cannot be improved for others, without harming what's already there. In fact, I find the very notion of "making GML into something it isn't" so vague that it sounds like a buzzphrase to me (kind of like "make America great again"). Like, what is GM at the moment and how the suggested changes (methods, structures etc.) would make it something so different (worse?).

Look, I acknowledge that for a lot of people, room editor or sprite editor or even D&D changes are just what they needed, and I don't feel it's a bad thing these improvements happened. However, it'd be really nice if you in turn acknowledged that others have a different style of using GM, and that they might not be as excited as you are, and that it doesn't make them "code elitists" or anything. I'm aware the subsequent instalments have some more or less major GML changes planned; it's just that at the moment, with no defails about specific language features known, there isn't really much to be excited about in that area.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
Okay, I don' think I'm making myself 100% understood here... When I talk about "buzzwords" I mean that I see a LOT of people (not necessarily in this topic, mind) using things like "OOP" and "structs", etc... but I get the impression they don't really know what they mean. It wasn't me trying to belittle anyone, but rather me trying to explain that a lot of the time it seems like people belittle GML by saying it doesn't have these features without actually knowing what they are or necessarily HOW they would benefit. And I'm all for GML growing and evolving, especially if it adds to the language and improves it, but NOT for "just for the sake of it", and not at the sacrifice of its ease of use.

you make the sorts of games that wouldn't really benefit from these features
I'm not sure quite what you mean by that... I have made fighting games, stealth games, puzzle games, agility/reflex games, strategy games, and currently I'm making a massive procedurally generated dungeon crawler for two players... so what "sort" of games do I make that you are referring to? Also note that I never use user events (hate them), use modular code and compartmentalise my game logic, create reusable scripts and take great care to optimise and organise my code. I haven't used the oom editor in GMS for years and do almost everything through code... I will say that the typing for lists, maps, etc, would be handy for some cases (JSON, like you say, for example), but again, I think that it's specific edge cases rather than the normal ones.

All I'm saying is that GML was never intended to be like any other language and was created by mashing various different ones together to create something new. Since then it's evolved into its own beast with its own way of doing things and just because other languages permit you to do certain things in certain ways I'm not sure that it necessarily follows that GML should too. If it's just going to copy C++ then why not just change to C++, for example? Get what I mean?

proper instance methods
Could you explain just what you mean by that?
 
B

benface

Guest
Could you explain just what you mean by that?
Sure! I mean "proper" because we do have the awkward "user defined events" that kind of mimick methods, but with terrible drawbacks that make them almost unusable as explained by Alice. And I mean "instance methods" as opposed to "static methods" because they would be executed on the instance, not on the uninstantiated object. So basically I'm simply talking about being able to define object-specific methods, with arguments, that could be executed on instances of that object and its children (and of course being able to override them in the object's children, like events). A very simple example would be a `obj_character` object that has a `die()` method; in each event that makes the character die, you'd write "self.die()" or something. I know that it is currently achievable in many ways, but they all make me cry a little.
 
I

icuurd12b42

Guest
Sorry Noct, but the things that are missing, which I enumerated to Russell in another topic are quite essential to me and a lot of people that come from a OO background. and the minor additions to the language would not affect anyone. GML is in fact begging for some OO features like object member scripts, structures, and lite objects with member functions by it's UI alone

Finding code over the web is extremely difficult to convert to GML exactly because the language does not have the basic features every other language has now. And no, I'm not going to move the c++ because I found a vec library I would like to use in GML? that makes no sense

I dont expect you to "get it". there's a lot of stuff that people need that others dont get. in the language and in the UI itself. but they are necessary
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
I know that it is currently achievable in many ways, but they all make me cry a little.
Why? If what you are requesting can already be done, and in various different ways, why add yet another one to the mix? My problem here is that it's easy for someone coming from something they know to say "oh, this should have THAT" because "THAT" is what they know and it makes sense. But as a GML programmer, I don't know any other way and yet can make perfectly good games that make me money and that people love to play. So, you saying that I can already do this thing with instance methods without actually using instance methods, just makes it all seem pointless...

Btw, I'm not trying to be a luddite here, all I'm trying to point out is that GML is a compromise between power and ease of use, and adding something "just because all the rest do it" isn't a good enough argument for adding it, imho. Things being added need to be considered very carefully and just saying add this and add that because a minority of users think that it's what is needed to "bring GML in line" with all the rest of the most common languages isn't a good enough argument. There is nothing wrong with GML being the black sheep of the family MEANWHILE the user can still do everything that is required.
 

Alice

Darts addict
Forum Staff
Moderator
Uh, I dunno why people would say they want more "OOP" or "structs" just for the sake of saying them. Somehow, I find it more likely that they *learned* about "OOP" and "structs", found them useful in some programming projects of theirs, and would like it appearing in GML as well. Perhaps because sometime, somewhere in their game they found a problem they could easily solve using the OOP/structs/whatever toolset, but they aren't supported by GM.

I have made fighting games, stealth games, puzzle games, agility/reflex games, strategy games, and currently I'm making a massive procedurally generated dungeon crawler for two players... so what "sort" of games do I make that you are referring to? Also note that I never use user events (hate them), use modular code and compartmentalise my game logic, create reusable scripts and take great care to optimise and organise my code. I haven't used the oom editor in GMS for years and do almost everything through code... I will say that the typing for lists, maps, etc, would be handy for some cases (JSON, like you say, for example), but again, I think that it's specific edge cases rather than the normal ones.
I don't see static data driven games on the list, such as visual novels or adventure games or RPGs (as opposed to data-light games like agility/reflexes ones or procedural games). And that's quite relevant here, because I in turn tend to make story-heavy games (heck, even a simple puzzle can turn story-driven for me...), which means the need for more or less flexible dialogue system, dialogue storing etc. and I find JSON to be extremely convenient for that task. It's basically either that, or trying to express my dialogue directly in GML (which is rather a pain to setup and comes with some GML overhead) or a custom format (which might be actually pretty handy, but custom language takes time to prepare; and probably would benefit from typing features).

If you hate user events and never use them, you probably won't find the object methods useful personally. Well, I use user events regularly, as they allow me to keep object-specific logic to object itself rather than cluttering the scripts tree with it. Object methods expand upon that concept - they aren't alien body we want tacked onto GML, it's a logical expansion on concept already present in GM. In that regard, trying to claim it's trying to "make GML something it isn't" is a miss, because GML already has some sort of method predecessor.

All I'm saying is that GML was never intended to be like any other language and was created by mashing various different ones together to create something new. Since then it's evolved into its own beast with its own way of doing things and just because other languages permit you to do certain things in certain ways I'm not sure that it necessarily follows that GML should too. If it's just going to copy C++ then why not just change to C++, for example? Get what I mean?
First things first: if you can suggest me a 2D game engine exactly like GameMaker, but with C++ instead of GML, could you please point me to one? Because those who complain about GML shortcomings and yet still use it don't do it because they secretly like the language - it's just that it's the only language they can use with otherwise extremely useful engine that is GameMaker.
That argument might not be as missed as "if you don't like JavaScript, why won't you write your websites in C#?", but it comes close.

And now comes the fun part.

From what you say, it sounds like object methods aren't that needed, lightweight structures aren't that needed etc., and adding them is "making GML something it isn't", and perhaps that only a few people want that and such.

But Russell Kay explicitly mentioned there are GML changes to come. Also, there were some hints: some old GMC where it was mentioned that named events/methods, don't remember which now, was to be planned in the next major release (i.e. GM:S 2), reserving of the struct keyword. I'm not quite sure, but revamping the type system to be more specific than null/string/omnipotint was also some seriously considered suggestion (just not for 1.x). Generally, I recall some old hints that these features were planned, and no recent statements that would claim otherwise. With what little data I have, it's not unreasonable to hope that's actually what they plan to add, sometime, eventually; and unless YYG staff like Mike or Russell defies that, I will stick to that notion.

If my suppositions are correct, then it's not only us who want to make GML "something it isn't"; it's YYG, too.

With that in mind, I'm not worried that GML will never get the features I want implemented. I'm not really "angry" or in any other way resentful that it's not already in the current instalment of GM:S 2, either (especially since I know for many folks the current improvements are important). I'm just withholding my enthusiasm about GM:S 2 (especially compared to functional 1.4) until these features, which are priority for me, are actually added.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
Alice, see my last reply... ;) I'm not really arguing with adding things and expanding it, I'm just trying to understand the reasoning behind it because so few people care to explain in any depth, and so it often looks like they don't really know why they want something, they just think it would be cool or it's what they are used to. As for what Russell and Mike want, I know that well! I've just spent a week in their company... :) However, both of them come from an EXTENSIVE programming background, and occasionally lose sight of the fact that the vast majority of GameMaker users do not have the same grounding and vast knowledge that they do... so while they'd like to add things into the language, that doesn't mean they should or will.

Like I say, I'm not averse to extending things and learning new stuff, I just want to make sure that it's being extended and built on for the right reasons and without excluding huge swathes of the userbase. :)
 
B

benface

Guest
adding something "just because all the rest do it" isn't a good enough argument for adding it, imho
Well good, because that's not part of my arguments.

My main arguments are encapsulation (what scripts definitely don't provide), flexibility (compared to user defined events that don't have names, don't take arguments, and are limited in number), and modularity/abstraction (inheritance, ability to override/extend/modify).

Look, I realize I won't convince you, but I'm sure you can understand that because something CAN be done with a given tool doesn't mean it's best done with it. I'm not against scripts, they can still be useful to execute things in the global/static context. Heck, I don't really have anything against user defined events either if it's easier for beginners somehow (although I'm not so sure I see why). All those things can coexist.

With that in mind, I'm not worried that GML will never get the features I want implemented. I'm not really "angry" or in any other way resentful that it's not already in the current instalment of GM:S 2, either (especially since I know for many folks the current improvements are important). I'm just withholding my enthusiasm about GM:S 2 (especially compared to functional 1.4) until these features, which are priority for me, are actually added.
Same here. GM:S 2 is pretty cool, and I'm really happy that they're finally giving the IDE some love as UI/UX is very important to me. But I will probably end up waiting to see what the 2.1 update brings, even if it's in a year or two.

However, both of them come from an EXTENSIVE programming background, and occasionally lose sight of the fact that the vast majority of GameMaker users do not have the same grounding and vast knowledge that they do... so while they'd like to add things into the language, that doesn't mean they should or will.
Ugh, please just tell me you didn't somehow convince them not to add "advanced" features like methods? lol
 
Last edited by a moderator:

Alice

Darts addict
Forum Staff
Moderator
I just want to make sure that it's being extended and built on for the right reasons and without excluding huge swathes of the userbase. :)
Well, how structures are excluding?
Someone might make a game without ever looking at the "struct" keyword, and without its existence bothering them. They aren't forced to use it, but it's there if they need it (again, say, for storing state of Sudoku solver or something and without clogging up memory with built-in object variables).

How instance methods are excluding?
Again, someone might make a game without them and they won't get in a way. Not only that, if they used User Defined events so far, they now get something even better. And, as it was already said, the methods are really useful for keeping the code near the object. Maybe you don't mind keeping object-related logic in scripts from completely different resource tree; I find that sort of thing distracting, interrupting my workflow.

How more precise typing is excluding?
Would it be really so hard to learn that aside from is_string/is_real/is_undefined functions there is something like is_ds_list/is_ds_map/is_ds_stack etc? (instead of ds_exists we have now, which doesn't 100% resolve whether some variable is intended as, say, a list or a map). I would find that pretty logical and consistent.

As far as I see it, neither of proposed changes breaks anything for existing users, while opens up possibilities for others.
Seriously, the fact that strings now cannot be wrapped in apostrophes is more excluding/limiting than all that!

You yourself said that "GML was never intended to be like any other language and was created by mashing various different ones together to create something new". That sounds pretty much like a basic premise of a multi-paradigm language to me, and supporting different styles of programming would actually nicely follow up the idea of "mashing different languages together to create something new".
 
I

icuurd12b42

Guest
>However, both of them come from an EXTENSIVE programming background, and occasionally lose sight of the fact that the vast majority of GameMaker users do not have the same grounding and vast knowledge that they do... so while they'd like to add things into the language, that doesn't mean they should or will.

Well that does not mean they used every trick, old and new. in fact, like me, they may have gotten stuck in their own ways.
 

Mike

nobody important
GMC Elder
We will keep adding to GML over time, but for this version the UI was a big enough change. We had to stop somewhere, or it would never have come out.

There's loads of things we want GML to have, but we will make sure it can still be used in the same manner as it is, because that's what makes it easy to get into. But things like structs, methods etc we all want, but we're not going to throw them in for the sake of it.

Strings now use \ notation so newlines are \n, quotes inside would be \" so " \" " give a a quote inside a string.
 
C

Carl

Guest
From what you say, it sounds like object methods aren't that needed, lightweight structures aren't that needed etc., and adding them is "making GML something it isn't", and perhaps that only a few people want that and such.

But Russell Kay explicitly mentioned there are GML changes to come. Also, there were some hints: some old GMC where it was mentioned that named events/methods, don't remember which now, was to be planned in the next major release (i.e. GM:S 2), reserving of the struct keyword. I'm not quite sure, but revamping the type system to be more specific than null/string/omnipotint was also some seriously considered suggestion (just not for 1.x). Generally, I recall some old hints that these features were planned, and no recent statements that would claim otherwise. With what little data I have, it's not unreasonable to hope that's actually what they plan to add, sometime, eventually; and unless YYG staff like Mike or Russell defies that, I will stick to that notion.
For what it's worth; what you say rings true in my ears as well, although I don't have the links / sources at this moment. With that said, I have been hoping for some "modern additions" to the GMLanguage for a few years now with respect to what was talked about back in the days, and would be one to welcome change, because why not? Ternary expressions, for instance, was an awesome addition. <3

We will keep adding to GML over time, but for this version the UI was a big enough change. We had to stop somewhere, or it would never have come out.

There's loads of things we want GML to have, but we will make sure it can still be used in the same manner as it is, because that's what makes it easy to get into. But things like structs, methods etc we all want, but we're not going to throw them in for the sake of it.

Strings now use \ notation so newlines are \n, quotes inside would be \" so " \" " give a a quote inside a string.
Fair, but regarding "easy to get into"; additions to the language doesn't have to make starting out with GMS2 harder? Thanks for the \ notation, by the way.

PS: How does GMS2 work with strings? Is a new string created in memory each time the text has to change (str += "asdf")? In that case, it would be really nice to have something like StringBuilder in Java and C#, which makes editing strings in O(n) time instead of O(n^2) possible (you're most likely aware already, but I'm throwing it out there). -- Edit: Use Buffers. Got it.
 
Last edited by a moderator:
J

JackOatley

Guest
Are colors still BGR as opposed to RGB? Like, it may seem silly, but I'd like that to be changed or optional. I usually pick colors from separate art software, but then realize I have to swap them all up. I can't think of other situations, personally, where I use BGR.
 

xygthop3

Member
Any word on what, if any, new shader texture sampler types and formats will be available? eg:cubemaps

Now that you're using DX11, will we have access to the Geometry shader?

Also what version of OpenGL is used?
 

FrostyCat

Redemption Seeker
PS: How does GMS2 work with strings? Is a new string created in memory each time the text has to change (str += "asdf")? In that case, it would be really nice to have something like StringBuilder in Java and C#, which makes editing strings in O(n) time instead of O(n^2) possible (you're most likely aware already, but I'm throwing it out there).
String builders already exist from GMS 1.x, they're called buffers.

See this post for a demonstration (against concatenations, specifically).
 
B

benface

Guest
There's loads of things we want GML to have, but we will make sure it can still be used in the same manner as it is, because that's what makes it easy to get into. But things like structs, methods etc we all want, but we're not going to throw them in for the sake of it.
Thank you for the response Mike! I know you can't say much on future plans, but when you say that you're not going to throw them in "for the sake of it", does that mean you don't plan on throwing them in at all or...?
 
C

Carl

Guest
String builders already exist from GMS 1.x, they're called buffers.

See this post for a demonstration (against concatenations, specifically).
Right. Thanks, glad to see that. I never got around to try GMS 1.x much, though I remember reading about buffers now that you mention it.
 
I

icuurd12b42

Guest
What will happen to Marketplace assets!? I mean right now no asset work on there

upload_2016-11-5_21-23-37.png

But when it opens up, how is GMS2 going to handle stuff like functions and concepts in the asset that are no longer supported?


You can't expect us to rewrite every asset we have in the marketplace and maintain 2 versions of everything!!??
 

FrostyCat

Redemption Seeker
What will happen to Marketplace assets!? I mean right now no asset work on there

View attachment 4131

But when it opens up, how is GMS2 going to handle stuff like functions and concepts in the asset that are no longer supported?


You can't expect us to rewrite every asset we have in the marketplace and maintain 2 versions of everything!!??
Some of it will still be accessible via shimming scripts automatically inserted by GMS 2, but there's only so much that they can do. That's why they are now forking the Marketplace into 1.x and 2.x streams. If you want a slice of both pies, you need to have a finger in each.
 
I

icuurd12b42

Guest
Assuming the shimming script also appear when you add an asset... right now it does it on import gmz...

I guess there is no way around assets being in two places. shame. My assets just doubled from 25 to 50...
 

kburkhart84

Firehammer Games
I currently only have 1 asset up. I wanted to upgrade it to work with GMS2, but I don't want to force them to re-purchase it in order to use it on GMS2. I honestly don't care to support GMS1 after the upgrade. My plan would be to keep the old version available for the people that purchased it, and also let them get free access to the new version for no charge. I don't want to give away the old version either though, rather I'd probably put it at an enormous price in order to allow people who purchased to download, without allowing anyone else to purchase the old version.

So, is there going to be any way for me to do what I want here? My original hope was to release the new version alongside the GMS2 upgrade without the difficulty.
 

kburkhart84

Firehammer Games
you can set the visibility to private on your asset too
That will allow people who purchased it to still download? If so, it will be better than simply putting a huge price on it.

Now I'll need to figure out how to get those people into the new version for free if they want it. If the marketplace will let me simply change my product to GMS2, than I can keep the same listing and let people know if they want the old version they can directly request it from me(with proof of purchase). That is probably the best solution, especially since not that many people have purchased my stuff yet.
 
C

CedSharp

Guest
That will allow people who purchased it to still download? If so, it will be better than simply putting a huge price on it.

Now I'll need to figure out how to get those people into the new version for free if they want it. If the marketplace will let me simply change my product to GMS2, than I can keep the same listing and let people know if they want the old version they can directly request it from me(with proof of purchase). That is probably the best solution, especially since not that many people have purchased my stuff yet.
There is a way to view all purshases of assets. I find it sad tho that you can't actually see their email ( it's hidden ) because you could've sent them an email telling them you offer them the new assets for free.
They could then reply to you with a proof, for example the order number, which you can then validate exists using the search option:


I'll have to investigate, but I'm sure there is a way to send an email to those who purshased your product. Maybe you could send yoyogames the message you want to send them and ask them to send it to all your customers?
( I know it sounds bad but it seems to be the only possible solution )

Otherwise you'd have to advertise it in the description of your own asset, hoping that your customer will come back seeking a gms2 version.
 
I

icuurd12b42

Guest
That will allow people who purchased it to still download? If so, it will be better than simply putting a huge price on it.

Now I'll need to figure out how to get those people into the new version for free if they want it. If the marketplace will let me simply change my product to GMS2, than I can keep the same listing and let people know if they want the old version they can directly request it from me(with proof of purchase). That is probably the best solution, especially since not that many people have purchased my stuff yet.
Yep private assets are still active. and they can be found too (marketplace bug) if you know the name and type it in the search. so the huge price would fix the unwanted new purchases
You can ask for the order ID they have with the asset and do a lookup in the purchases menu in your marketplace tools. and you can send them a gmez file...
 
P

ParodyKnaveBob

Guest
Object methods: yes, they'd be nice, and no, they don't require magic numbers. Some notes, whether or not relevant: I love User Events (but do wish they were more user-friendly); I've only ever used "methods"-proper in Javascript (since when I was PHPing it up years ago, I never hit a wall I couldn't climb using my tried-and-true procedural functions); I haven't touched the GMS2 beta.

So! Concerning pre-methods, GM's user events:

Problems: limited to sixteen, take a little extra effort to make and keep modular.

The sixteen limit means if you have lots of different functionality you want to modularly separate, and the fifteen thousand or so other events (probably hyperbole $;^ J ) don't do it for you, then you'll resort to the global script resources which get lots of either 1. specific and explicit naming or 2. abstracted modularity for reuse. Either way will take extra efforts which could be reduced with methods.

"Extra effort to make and keep modular"? Touched on above. Explored more thoroughly below:

Can be done: inheritance, arguments, naming.

Perhaps I misunderstand something, but with GM object parenting and event inheritance (and overriding), inheritance isn't a problem at all. Can anyone give an actual case to the contrary?

~exhale~ Arguments. Technically, no, you can't supply an argument directly to the user event call. However, you can reserve certain variables, arrays, or data structures to indirectly (or explicitly if you want) serve as the arguments. Planning your naming in advance of course can allow for more reusable and modular code via parenting (inheritance). Nevertheless, I do kind of find myself rolling my eyes when I once again find the need to create an artificial argument (since I generally prefer the lovely, lovely, namable, inheritable, contained user events vs. external-resources-from-objects scripts).

Named User Events have really never been a problem. First, there were variables to overcome GML's magic number syndrome. Then, came constants, which became macros. Now, we have enums, too.

Code:
_obj_target.die();
Code:
with (_obj_target) {
  event_user(UE.DIE);
}
  • Yes, you have to manually create your UE enum.
  • Yes, you have to plan in advance which user events will be globally used in which ways (and which user events may or may not be "free" for even more customizing, depending how the particular objects are being used).
  • Yes, you're limited to sixteen -- for each object (although parent-child branches can abstract this further with any so-called "free" events, and completely different object trees (e.g. menu vs. enemy) won't need overlap at all).
  • No, you're not required to muck around with magic numbers.
  • (Note: you can do the same with alarms, too; in this way, you can even increase your GM "methods" to twenty-eight, although it takes yet more effort and planning.)
Regards,
Bob
 
M

MidnightFairProd

Guest
Drag and drop code is great, but I would really enjoy seeing what the new room editor looks like.
 

SnoutUp

Member
Is there or will there be a way to disable "node" UI or have workspaces look more like in 1.4? The choice between single object in screen scrollercoaster and clutter-oriented mess (enabling the overlapping of the windows) is not very pleasant to me. Maybe I missed some sort of setting, tho. The improvement 1.4 needed was opening code in the same object windows (tabbed, like GMS2 does right now), but I never looked at my workspace (which frequently has ~10 scripts and objects opened & it's fine) and thought "I wonder how this looks from space, if only I could zoom it out" or "Wish I could stack all of this vertically and just scroll up and down looking for the one window I need".

I needed to rant a bit. GMS2 is an improvement in other areas for sure... I just don't use those areas.

I'd gladly pay for tabbed windows & variable auto-completion update for 1.4... Too bad Parakeet IDE is expensive and reviews are not very good.
 
I

itameio

Guest
Will we be able to use non-latin characters in the drawing event? would the draw engine be able to display, arabic, for example, correctly now?
 
Last edited by a moderator:
T

TheGutsyDavid

Guest
64bit and Multicore support would help me think of upgrading from GMS1 MC towards GMS2.
Performance matters. Power efficiency matters.

I think the CB should have lasted much longer and the beta release shouldn't had been so bad/empty, just look at all the questions and unknowns.
Going by the website, GMS2 sounds like a step back from GMS1, sounds like a good level and sprite editor tho!
Your marketing team really freaking sucks.


The IDE is great and looks awesome, hope that the improvements coming sway me more towards upgrading.
Good luck.
 
T

TheGutsyDavid

Guest
FWIW - multicore kills power efficiency. It certainly doesn't improve it.
That pretty much goes against everything said about the topic in the whole industry of software and hardware.
Yes, if you plan on using all the cores available to do more. Better for Desktop, IMO.
No, if you keep the same work and spread it out. Better for Mobile, IMO.

If you know how to code well and know how to create extensions, you can have multicore right now in GMS.
That skill is not in my toolbox. =)
 
Last edited by a moderator:
T

TheGutsyDavid

Guest
I can only point you to all the Whitepapers from Intel, ARM, NVIDIA, AMD...wont be hard to find nor read.
Using 2 cores at 50% is better than using 1 core at 100%. 100% needs more volts and creates more heat.
Everyone has been saying this for years and the industry moved to more cores because of this.(and more)
All companies use this logic. So, what I would be surprised is who does not?

And obviously, comparing the performance of one Core to another companies Core would be an Apple to Orange comparison.

Going by the Steam Hardware & Software Survey: October 2016, 1.92% of users have 1 CPU core.
Which is a fraction more than the XP + Vista users on it which GMS2 doesn't even support.

98% of the desktop market has 2 or more cores, 100% of the mobile market has 2 or more cores, 100% of the console market has 2 or more cores.
 
I

irvinmujcin

Guest
nice and price is ok for master collection and console when when need it

Quick question guys:

I've just entered game development, I've been making my first game with RPG Maker. Now I wanted to make a big step forward and bought GameMaker Studio 1.4 a few weeks ago, to develop my next game under this engine. But since I was just learning to use that engine, should I just stop bothering with 1.4 for now and wait until this new version gets released? I like the new UI and the features, but do you think it is justifable to spend money on GM2 as a noob developer? :) Or should I stick with 1.4 for now?
If you have money buy this new one but stay with old one there is same if you have old or new.Just idea make money not engine if you know what i mean.I have game on paper and gm 1.4 master collection but i will buy this gm2 full.
 
Last edited by a moderator:
J

Jaqueta

Guest
Tiny Rant: Why does GMS2 still doesn't support Mouse 4...5...6...7... Buttons? COME ON GUYS IT'S 2084!!

Besides that, I'm loving the interface. But there's definitely room for improvement, such as Collapsible Code Spinets.
 
Top