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

Discussion To "backward compatibility" or not to "backward compatibility"!!

The backwards compatibility thing is great but is a pain in the ass... I think YYG should really consider rethinking it... because if you are always looking at backwards compatibility... things don't always get the changes they should.

OK I'm saying that because I don't have anything that must be ported... but then again... when creating a project you plan things ahead... if your project started with GMS1.. it should end with GMS1! and if you want to port it.. it should be developers responsibility not YYG. (people could make extensions on market to convert the projects... but then again... developers should worry about this not YYG!)

I think keeping new useful features from being add.. because of backwards compatibility is WRONG!! (it's not the path to advance).

I just posted this because I see a lot of features (and a lot of them very good ones) being turned down because of compatibility issues... if GMS2 is a NEW SOFTWARE... modules stuff is different... and all YYG stuff says so... so it should be treated as a NEW SOFTWARE.

What do you think?!
 

psyke

Member
Nope, I totally disagree with you.
We started our project in GMS 1, and when we noticed that GMS 2 had a great room editor, better workflow, it was a must for us to port the game. If it wasn't for the backwards compatibility, I wouldn't have bought GMS 2. And to be honest, the port was very easy and straightforward, I ported everything in one week.

And I don't know what are those "features" that are being turn down because of the backward compatibility, can you give me some examples?
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
Technically, GMS2 is not backwards compatible. You can't use a great many things that you could in 1.4 and you are required to use the workaround compatibility scripts to get a 1.4 game to run. So, the devs have put in a bit of extra effort to try to permit some backwards compatibility, but it's not actually in the engines or the UI but rather through third-party scripts. The changes to GML and the iDE really are quite profound... however, your question seems to imply a "why are they not more profound"? That's easy... The people that work with GMS 1.4 are used to a certain way of doing things, so introducing massive changes from one product to another will alienate a huge section of the userbase. So, they've changed what was most needing work (fundamentally views/cameras d3d/GPU and tiles) and will incrementally add further changes when the users get used to the current ones. ;)
 
Backward compatibility is good... but is counterproductive in terms of technological advancement... the only thing that can be said that really has changed was the IDE (the room editor and the work space... in other words all graphical changes)... what about the coding editor... that is where developers really work?! new coding features... better data handling...

serious developers don't care too much with backwards compatibility... are you seeing Square Enix stop developing software for PS4 because it is not compatible with PS3 games..... developers have to adjust.. not software companies.. thats what i really think...

the event system can not be really modified because it "needs to be backwards compatible"... the way data is handle... in a non OO way.. cannot really be changed because it "must be backward compatible"... I think backward compatibility is becoming a burden to new features.... just saying!
 
Technically, GMS2 is not backwards compatible. You can't use a great many things that you could in 1.4 and you are required to use the workaround compatibility scripts to get a 1.4 game to run. So, the devs have put in a bit of extra effort to try to permit some backwards compatibility, but it's not actually in the engines or the UI but rather through third-party scripts. The changes to GML and the iDE really are quite profound... however, your question seems to imply a "why are they not more profound"? That's easy... The people that work with GMS 1.4 are used to a certain way of doing things, so introducing massive changes from one product to another will alienate a huge section of the userbase. So, they've changed what was most needing work (fundamentally views/cameras d3d/GPU and tiles) and will incrementally add further changes when the users get used to the current ones. ;)
will they add those changes you say to GMS2 or are we only going to really see them in GMS3?! :/
 
will they add those changes you say to GMS2 or are we only going to really see them in GMS3?! :/
My sentiments, also. The entirety of GMS' life, I heard "not until GMS2!" Now GMS is out, and it boils down to the room editor being fixed, along with a new IDE half the users love and half the users hate. (I love it, personally, so no complaints there.)

I like GMS2, and will gladly port my game over to it, but I was expecting much more drastic changes after seeing 80% of GMS' suggestions killed with "not until GMS2."

If YoYo would post a public (detailed) roadmap like Unity does, I'd be much more excited about GM's future.
 
Last edited:

Nocturne

Friendly Tyrant
Forum Staff
Admin
your question seems to imply a "why are they not more profound"? That's easy... The people that work with GMS 1.4 are used to a certain way of doing things, so introducing massive changes from one product to another will alienate a huge section of the userbase. So, they've changed what was most needing work (fundamentally views/cameras d3d/GPU and tiles) and will incrementally add further changes when the users get used to the current ones. ;)
Guys, read that again please... there are good reasons why things are being done this way, and I would also like to say that there are massive changes "under the hood" that you just can't see but that set the groundwork for some amazing future features (although the changes to the way GML works, the new functions and the layers system should all give a fair idea of where things are going ;)). The groundwork needs to be done first though before those features can be added, and the general user base (who may not have any other programming background - in fact they generally don't) have to be given time to adjust to each of the changes and learn the way to use them. GMS2 is just the start not the end...
 
Guys, read that again please... there are good reasons why things are being done this way, and I would also like to say that there are massive changes "under the hood" that you just can't see but that set the groundwork for some amazing future features (although the changes to the way GML works, the new functions and the layers system should all give a fair idea of where things are going ;)). The groundwork needs to be done first though before those features can be added, and the general user base (who may not have any other programming background - in fact they generally don't) have to be given time to adjust to each of the changes and learn the way to use them. GMS2 is just the start not the end...
Again, and I'm not trying to disparage YoYo Games here, I'd have a lot more confidence that these massive changes were actually coming if you guys had enough confidence these changes were coming to give us a roadmap. You say the groundwork is there for big changes, which is great, but @Mike himself said he'd love to have methods in GMS2 if you guys could find time to add them at some point. @Jobo just agreed with Crashlands' sound designer that the audio mixer needs work, and said that he'd love to see it fixed. He then qualified that statement with "but it might never get fixed."

You can see why such wishy-washy statements would curb our enthusiasm when you vaguely tell us that "amazing features" are in the works, right?

Again, the solution to this is simple: be more transparent. Instead of giving us vague promises for what might be coming two years from now, give us a clear roadmap for the next few months. Then give us a loose summary of what you guys would like to do for the year. Thanks for your consideration.
 

HammerOn

Member
I can't think of a good reason to keep the confusing BGR-RGB color thing for years after moving from the old vm.
Is it that hard for the user to manually change color values to match a standard used in every software other than GM?
It isn't for the sake of the user base because it only makes things harder. It's unexpected for new users and older/advanced waste time dealing with that inconsistency.
I thought I would finally be freed from this weird design in GMS2 but backward compatibility butts in to keep this issue for who knows how many more years.
There are api changes but issues like this are left alone because it can't be automatically converted. As if it would take several months for us to edit color integers... The result is several years of issues.
This small thing raises a huge disappointment when you have to deal with it for time enough and it never changes.

We rarely have large third party libraries (because it's hard to build and deal with a large code base in GML) and 90% of the reason backward compatibility would be useful is when you have a large amount of old well established libraries.
The current state of GMS2 makes it clear that the focus are api and interface. The new features are great for new users but... I'm staring to use GM only as a prototyping tool instead of the main engine for projects because I can't get excited about the future with no core changes for the language plus backward compatibly that only support issues.
 

Hyomoto

Member
Backward compatibility is good... but is counterproductive in terms of technological advancement... the only thing that can be said that really has changed was the IDE (the room editor and the work space... in other words all graphical changes)... what about the coding editor... that is where developers really work?! new coding features... better data handling...

serious developers don't care too much with backwards compatibility... are you seeing Square Enix stop developing software for PS4 because it is not compatible with PS3 games..... developers have to adjust.. not software companies.. thats what i really think...

the event system can not be really modified because it "needs to be backwards compatible"... the way data is handle... in a non OO way.. cannot really be changed because it "must be backward compatible"... I think backward compatibility is becoming a burden to new features.... just saying!
Your improper use of ellipses is distracting and makes me ignore the entire body of your comments. If I dig a bit though, your conclusions are fundamentally wrong and have no weight. PS3 and PS4 have different architecture, so does the Xbox one and Xbox 360. The difference is like Mac and PC, not GM1 and GM2, they are not useful examples. You have no idea what you are talking about.
 

GMWolf

aka fel666
I can't think of a good reason to keep the confusing BGR-RGB color thing for years after moving from the old vm.
Perhaps having a global game setting to switch between bgr and rgb. Make it rgb by default. Switch to bgr when importing, etc.
 

Posh Indie

Member
Guys, read that again please... there are good reasons why things are being done this way, and I would also like to say that there are massive changes "under the hood" that you just can't see but that set the groundwork for some amazing future features (although the changes to the way GML works, the new functions and the layers system should all give a fair idea of where things are going ;)). The groundwork needs to be done first though before those features can be added, and the general user base (who may not have any other programming background - in fact they generally don't) have to be given time to adjust to each of the changes and learn the way to use them. GMS2 is just the start not the end...
This right here is what I am most worried about, actually. The development focus seems to be (VERY) heavily shifted towards people with no programming background (A lot more so than 1.4 development was) instead of developers with programming background that want to release something rather than write their own engine from scratch. I noticed the last major feature update was mostly drag and drop. Is primarily supporting the "no programming crowd" the future of GMS2? If so, that alienates people like myself who actually do know programming but want more raw capabilities and features on the programming side. You probably know from my typical comments that I back you guys entirely and have a lot of faith in you guys to release a quality product. If I am part of the demographic that will be left behind, though... it just feels like you guys put too much hard work into moving forward and getting taken seriously to be retreating back to the educational novice tool focus again.

I've been with GM for a long time, so I understand its roots and all. Drag and drop is great for newer people, but eventually even they will need to branch out or sacrifice a crazy amount of possibilities and limit themselves (If anyone is alright with limiting themselves in the thing they wish to pursue, maybe they should not be pursuing it). The drag and drop focus is what made this software seem like a child's toy before GM8 (and even throughout a decent amount of GM8's lifespan) which undoubtedly hurts sales to a crowd that would be more capable of building marketable projects (Products that will help propel you guys into a more serious position. Not saying there are none, but I have quite a few friends releasing on Steam soon that chose Unity for 2D over Game Maker Studio because they still think it is a drag and drop child's toy with too many limitations).

Honest words, here. Not attacking you guys. I love Game Maker Studio (1.4 and 2) and just want to see it grow. I am hopeful for the future.

I also need to agree. It would be nice to see a more fleshed out road map with major features included as well, so we have a view of what is to come (not just software/exporter release dates).
 

Mike

nobody important
GMC Elder
I disagree. There were several much requested image editor improvements, and a big performance and memory gain in the room editor for large rooms, especially when using multiple overlaid tilemaps. On top of that, the extension system came online which is hardly a beginner feature, and we hope source control will come online soon as well.

We are still big believers in education however, which is why in GameMaker Studio 2 we're trying to bring even more into the product. Many of our highly experienced users began as beginners using DnD, so it seems silly to want to throw that away.
 

Posh Indie

Member
I disagree. There were several much requested image editor improvements, and a big performance and memory gain in the room editor for large rooms, especially when using multiple overlaid tilemaps. On top of that, the extension system came online which is hardly a beginner feature, and we hope source control will come online soon as well. ...
I never said to throw it away, I said there seems to have been a heavy shift in focus again. The image editor additions are great (I'm not one that uses them heavily, but I understand there are a lot of people who do. That's fine.) The last update was still heavily focused on the drag and drop users. The image editor is a neutral feature (so irrelevant to what I was saying as it has nothing to do with code or drag and drop).

Source control is a welcome addition, but again, I would consider that a neutral feature (Unless drag and drop projects don't get source control features, I wouldn't know. I don't use drag and drop, haha).

Same with the room editor, that is a benefit to both drag and drop users and GML users.

... We are still big believers in education however, which is why in GameMaker Studio 2 we're trying to bring even more into the product. Many of our highly experienced users began as beginners using DnD, so it seems silly to want to throw that away.
Exactly my point, actually. They start there. They don't typically end there (unless they intend to use GMS as nothing more than a hobby tool. You saw what people uploaded to the Showcase in the past. Do we want to turn GM back into that again?) There is no reason the drag and drop needs to be such a heavily flaunted feature. If GM is falling back to the hobbyist plaything, then why not just advertise for Construct 2 instead?

Sure, give them some focus and don't let them fall into mediocrity, but you should really foster the growth of the experienced users as well (I am talking a balanced focus, not a one-sided focus). Neutral features that cater to all do not trick me into thinking we have any of your actual attention.
 

Mike

nobody important
GMC Elder
There is no way beginners will use source control. That's definitely a more advanced thing. We also added things like static array creation to GML, and a heap of other GML functions.

The only thing I'm getting from this, is that unless we added classes or type definitions then that wouldn't satisfy?
 

Posh Indie

Member
There is no way beginners will use source control. That's definitely a more advanced thing. We also added things like static array creation to GML, and a heap of other GML functions.

The only thing I'm getting from this, is that unless we added classes or type definitions then that wouldn't satisfy?
You're extrapolating and interpreting the way you want to, here. If you need me to point you to the release notes, I can (I assumed you would know where they were). Does drag and drop really need a live preview conversion to GML? That's a hefty feature to add for people that don't care about GML. That feature is definitely an "intended for education" feature. But hey, at least now we can view syntax errors by mousing over an exclamation point. Without that I think I couldn't have continued to use Game Maker Studio anymore...

My point with that last line? I'm fairly certain most people using GML (By your own definition, "advanced users") could have determined what the syntax error was without hovering an exclamation point (And if not, there were other ways to find out). Our updates are lacking substance. Was it a nice addition? Sure. Why not. Welcome to Game Maker: Studio 1.5.

I don't need classes or type definitions. I take it that was supposed to be a snide remark claiming your advanced users are only happy if it's straight code, but common sense states that not being the case (Otherwise, GM would still be looked at entirely as joke software due to advanced users, you know... using straight code).

Game Maker Studio is highly capable as it stands, but that does not mean we should use that as a reason not to express our opinions and reach for more (Especially with GMS2 in its infancy). Again, I would like to restate, a more intricate road map would alleviate a lot of bad feelings. By that I mean just adding general timelines for major features (Before you think I meant adding every planned bug fix).
 

Storyteller

Member
There is no way beginners will use source control. That's definitely a more advanced thing. We also added things like static array creation to GML, and a heap of other GML functions.

The only thing I'm getting from this, is that unless we added classes or type definitions then that wouldn't satisfy?
Backwards compatibility in this software rather does drag it down a bit. In direct response here, please add Classes and Interfaces as well as other OO features. Decouple expose the engine to third party languages or implement C# (or some other modern language) over the proprietary GML. Rather, aim for GML++, an iteration above GML. GML, or whatever scripting/programming language are the core of game development. Template languages and Drag n Drop are great for young people and amateurs to learn game development, however at some point more control is required to expand and reach ones potential.

Does GMS2 really iterate beyond GMS1, or is it merely a 'major version change'. Id have thought that GMS would have broken from the GM8 and previous iterations to something beyond backwards compatibility, however, it really seems like just a name change instead of GM9. When will we get a truly professional 'studio' developed by a team backed by a major software corporation and not another version of the simple 'gamemaker' developed by a guy for his computer science class?

(been here since 4.3)
 

Juju

Member
You're extrapolating and interpreting the way you want to, here.
You've pointed out some bad things, which has a place, but nothing in the way of "I would enjoy and appreciate feature X." You've not given Mike much to go on.

Does GMS2 really iterate beyond GMS1
Are you kidding? It's got a totally different IDE! The jump from GM6 to GM7 was way smaller than this.
 

Posh Indie

Member
You've pointed out some bad things, which has a place, but nothing in the way of "I would enjoy and appreciate feature X." You've not given Mike much to go on.
I have given plenty to go on. "Anything of substance". That's very broad and easy to fulfill, yet the best we can get is hovering an exclamation point. That speaks volumes of my feature expectations (Just add something bigger on the GML developer side) and trust in YoYo Games' capabilities (I believe they are capable of doing this) as a company. The point is, I want stuff that is not super trivial is all. I want to believe non-educational users are going to continue being considered valuable.

To put it into the (apparently) required format: "I would enjoy and appreciate anything of actual value." A better road map (yet again) would alleviate this concern almost entirely. If I can see some guaranteed future additions to put my mind at ease, I would be a lot more willing to sit back quietly.

To clarify: I am someone who will be buying the entire GMS2 collection upon release. I am not knocking the software. I am not looking for a specific feature (outside of multi-threading, but that has already been verbally addressed to some degree). I am just looking for reassurance, which is where my perspective is coming from.
 
Last edited:
I'm tired of the whole backwards compatibility debate, but here's my thoughts anyway - it is nice, but this is a huge version change - so I think I'd prefer something *mostly* backwards compatible rather than "we can't change anything ever because it will break the compatibility we want".
One thing I'd certainly like to see changed is BGR vs RGB - this isn't Delphi anymore. I think one of the reasons given for not changing this is that people would have to reverse the order of all their colors (Wait a minute, don't we have to do that EVERY SINGLE TIME ANYWAY?) as compatibility scripts couldn't be generated due to too many different use cases.
I personally think this reason is not very good as we already have to reverse the colours anyway or make a script to do it for us (extra unecessary steps + more typing, yay) - maybe just tell users to update their hex colours? I'm actually very willing to say that I would prefer to change my old colours to a more standard format (RRGGBB) than stay with the weird order for the rest of eternity - also, dare I ask how many *new* users and beginners really use hex? There's already enough stuff we need to change (apparently I can't have empty [] in front of an array for personal clarification anymore, though these aren't automagically removed) so why not just have one more thing for the sake of usability.

I know you want the process to be as seamless as possible and I appreciate that (though my game that heavily relied on depth and had variables named "layer" does not port at all), and I really do love the software, but I fear that we'll first hear the "backwards compatibility" excuse and then the "we can't change it because people are already using it" excuse 2 years down the line. I imagine this will just repeat come GMS3 or whatever comes next. This just forces the software into a rut. I don't need classes or anything (those it's hard to say those wouldn't be nice), just a little more room to move forward. Wouldn't it make more sense to make a change and tell developers to update now while we're in beta rather than when they've already settled into GMS2, forcing you to put off changes again?

I've purchased and love the software and appreciate the work you are all doing, but I do want what I think would be beneficial to the software in the future. I don't want anything crazy, just more than what would be useful on the Amiga (unless you plan on an Amiga export module :p). I'm just talking from the point of view of someone who has been making games on modern systems for 13 years, rather than yearning for machines from 20+ years ago. I know the devs are probably older and maybe wiser than me, but I don't suggest things for the sake of it.

On top of this, I can't get excited about "amazing features" that are "under the hood" until I know what they are and what they're for. How about tell us maybe? There is an object in a box. You don't know what it is, you don't even know if there even is anything in the box, and you're not allowed to open the box. Thrilling, huh.

Also, please don't respond with something completely unrelated to what I've said - that means no "but the image editor" or "Nyuh classes" or whatever as they've got nothing to do with my points. For clarification of my points:
  • Backwards compatibility is generally good, but please don't let it force the product into a rut - again but not until GMS3(!)
  • Make changes now while the product is in beta - now isn't the time for excuses, it is the time to listen to your (paying, might I add) customers before the product is officially released. You can't decide not to make changes just because you like it the way it is. Sometimes life is just like that.
  • BGR still sucks. Nobody but those of us forced to use it actually use it. Get over it, then fix it.
  • Give us a roadmap beyond "The product will be released this quarter" maybe - we can't be excited about features we are unaware of
  • I've been making games and software a long time too, in several languages - I'm hardly new to this and I don't think I'm a total idiot so I don't suggest stuff for the sake of it. Did you know that new changes and features (to code related stuff, not the image editor) can be beneficial? As far as I can tell, nobody asked for cameras and look how useful those are!
  • New point: If you can't be arsed with doing this stuff, hire someone who can. Preferably someone more open to changes and feedback.
Sorry if I come across as rude at all, I'm not trying to be. I think I'm just tired of asking for basic stuff and getting met with a brick wall, so I'm trying to make my points REALLY obvious and clear as well as why I make the points.

As a side note, is it not true that old tilesets are not truly compatible - I did a test and found out about those "compatibility" tiles for tile 0 that are just sprite assets but have a UV property that we can't edit for some reason (unless we open the room data in notepad)? Doesn't this mean that we'd have to create new/edit our tilesets anyway since we can't place compatibility tiles ourselves? Though it would probably be nice to have access to this UV thing anyway for drawing parts of sprites on asset layers. Perhaps if they can be animated too.
 
Last edited:
Your improper use of ellipses is distracting and makes me ignore the entire body of your comments. If I dig a bit though, your conclusions are fundamentally wrong and have no weight. PS3 and PS4 have different architecture, so does the Xbox one and Xbox 360. The difference is like Mac and PC, not GM1 and GM2, they are not useful examples. You have no idea what you are talking about.
@Hyomoto (For the sake of readability, sorry for my misuse of ellipses. Hope this is less distracting) :)

Backward compatibility is good but is counterproductive in terms of technological advancement.

The "only thing" that really has changed was the IDE (the room editor and the workspace... in other words all graphical changes). What about the coding editor that is where developers really work?!

I think backward compatibility is becoming a burden to new features.... just saying!

(EDIT: The PS3 and PS4 example was a bad example! But my point was... people won't leave GM if there is no backwards compatibility as long as it "delivers". What do I mean by "deliver"?! new code features, like:

1) GML++ (OOP)

2) better way to handle data (in a JS way.. "a = {}; a.level = 10; a.attack = 2;") [not using objects]

3) custom events (or access to current events... addListeners and removeListeners)

4) methods (I know that this is in the making ..and it's cool)

5) named arguments (for example using JSDOC to name the arguments?)
Code:
/// @param {real} instance_id The unique instance ID value of the instance to check.
would make argument0 also being accessed as instance_id

6) passing arguments to events. Create event would be super awesome with this and would reduce the number of "with(object)" used.

Code:
event_call(instance, "damage", arguments) // "damage" would be a custom event

on damage event:

health -= argument0 // or using JSDoc rename it [value].
if (health < 0) {
   killer = argument1; // or using JSDoc: [caller] or could even be builtin (not really a fan of builtin variables)
   killed = true;
}
...to name a few (then again these are ideas, so hold on to the rocks you're about the throw xD)

I bought the software and as said before, a detailed road map would be important so that people can see in what people are investing their money :)
you can't expect everyone to be like me and buy something because you say "awesome things are coming!!". Don't want to sound rude, sorry :)
 
Last edited:

Mike

nobody important
GMC Elder
Guys, I've given you the reason behind these things; you may not like them, you may not agree with them, but these are the reasons and it's not going to change. Backwards compatibility is a big thing for us. We want folk to upgrade, we want then to get the benefits of the new software, and the only way to help do this, is to make it as seamless an experience as possible.

Again, you may not like or agree with it, but these are the choices we've made, and it's not going to change.

And (MaddeMichael) please stop being so insulting. We've been incredibly open about features and changes, and are always open to constructive criticism. Telling us we're lazy arses if we can't be bothered to implement what you think should be done is downright disrespectful. We listen to all feedback. Just because we don't agree with you doesn't mean we lazy and can't be bothered is no help to anyone. Be constructive, and be prepared to have us disagree. We're hardly noobs either, and we make our choices for what we believe are good reasons - some of which we can not tell you; accept this, you do not get to dictate business strategy to us.

Now, give us good features that we agree with, and we'll certainly consider them. If we don't we'll try and give you reasons. By all means, feel free to convince us. But we are a limited resource and will implement the things we deem are the best thing for the product.

So I'll say again. You may not like our choices, but unless we get a robust reason and solution to an issue we won't do them. I find it incredibly offensive that you say we're closed to change and feedback, and even a quick search here will show you this isn't the case. So if you simply want to insult us, keep it to yourself, I'm not interested in reading your abuse. Got some positive suggestions that will help and not cripple the product in other ways? Then I'm all ears.
 
Last edited:
Guys, I've given you the reason behind these things; you may not like them, you may not agree with them, but these are the reasons and it's not going to change. Backwards compatibility is a big thing for us. We want folk to upgrade, we want then to get the benefits of the new software, and the only way to help do this, is to make it as seamless an experience as possible.

Again, you may not like or agree with it, but these are the choices we've made, and it's not going to change.

And please stop being so insulting. We've been incredibly open about features and changes, and are always open to constructive criticism. Telling us we're lazy arses if we can't be bothered to implement what you think should be done is downright disrespectful. We listen to all feedback. Just because we don't agree with you doesn't mean we lazy and can't be bothered is no help to anyone. Be constructive, and be prepared to have us disagree. We're hardly noobs either, and we make our choices for what we believe are good reasons - some of which we can not tell you; accept this, you do not get to dictate business strategy to us.

Now, give us good features that we agree with, and we'll certainly consider them. If we don't we'll try and give you reasons. By all means, feel free to convince us. But we are a limited resource and will implement the things we deem are the best thing for the product.

So I'll say again. You may not like our choices, but unless we get a robust reason and solution to an issue we won't do them. I find it incredibly offensive that you say we're closed to change and feedback, and even a quick search here will show you this isn't the case. So if you simply want to insult us, keep it to yourself, I'm not interested in reading your abuse. Got some positive suggestions that will help and not cripple the product in other ways? Then I'm all ears.
I just made a post with some suggestions. I don't think I am being rude and I'm very sorry if I seemed so.
I get it, you want the be backward compatible but it's that backward compatibility that gets people to complain with things like:

"I already bought the modules from Studio 1.4, why do I have to pay them again"

and you reply:

"You have to because it's a new software a new product."

I'm not complaining myself just saying. GM it's a new software with old in mind, got it ;)
Not being rude or insulting anyone, just gave some ideias and wanted to know some answers.
 

psyke

Member
I think most of the points discussed here are valid, and I also think GMS 2 needs a DECENT roadmap.

Unreal Engine has a very good and solid roadmap of all the major changes and new features for the upcoming versions, and this is something that is really missing here. Considering that UE4 is much bigger than GMS 2, I don't think a roadmap would be a challenge for you guys.

Are we getting a new Particle Editor?
Are we getting a new Shader Editor?
Are we getting a new Interface Editor?

I think a lot of people here didn't know about that, but it was discussed here: https://forum.yoyogames.com/index.php?threads/suggestions-new-editors-and-visual-extensions.16663/
The only thing that bothers me is the "wish-list" mentioned in link above, isn't that supposed to be the roadmap? I mean, all those "wishes" will come true one day, right?
 
Like, Jon Snow, I know nothing ...

Having said that, for the sake of FUTURE compatibility, wouldn't it be wise to add support for BOTH BGR and RGB? This way v1.4 scripts could still be imported, people used to v1.4 coding could still code it the old way, but the rest could use the "proper" way of coding this while leaving it open v1.4 people to be able to convert to the newer, more accepted way of doing things? By FUTURE compatibility, I mean that something like this would allow YYG to drop BGR support in a future update. V2 would be an in-between state ... a warning, if you will, to people who still code the 1.4 way to get ready for changes ahead.

This way you still get people upgrading while not possibly alienating people who may come to GMS2 from a programming background.
 

Mike

nobody important
GMC Elder
We already have a roadmap. When it's complete, we'll do another one. Theres no point in doing a feature roadmap when more than half the product isn't even released yet.

The wishlist refers to things we'd love to do. This doesn't mean it'll get done, just that the suggestion is already one we've thought of ourselves and given the chance, one we'll implement. We have lots of other things we have to do, before doing things we'd like to do - many of which won't ever get done. Many of these are not public, nor will they be, but they use up resources so limit the things we can tackle.

In terms of the things listed here - which is all about backward compatibility, I've already stated our reasons. Whether you agree with them or not is irrelevant, we considered a lot of things when doing the product, and backwards compatibility was a major requirement, and as such we had to make certain choices. This will not change. We are not going to put in a runtime switch that would require massive amounts of dev and testing, and would probably slow things down as there would be a low level IF at every step of rendering. BGR is irritating, I agree - but it is not limiting, and that would be the main concern to us.

So agree, or don't. If you read the reasons behind it, and think about the amount of dev work required to have a switch on every rendering path, on every platform, the speed impact of having an extra IF every time you drew something, not to mention the testing involved and it's a massive undertaking - all for something that is a small irritation. I'd much rather use that effort putting in significant new features like runtime language support, or a particle editor - something like this.
 
Guys, I've given you the reason behind these things; you may not like them, you may not agree with them, but these are the reasons and it's not going to change. Backwards compatibility is a big thing for us. We want folk to upgrade, we want then to get the benefits of the new software, and the only way to help do this, is to make it as seamless an experience as possible.

Again, you may not like or agree with it, but these are the choices we've made, and it's not going to change.

And (MaddeMichael) please stop being so insulting. We've been incredibly open about features and changes, and are always open to constructive criticism. Telling us we're lazy arses if we can't be bothered to implement what you think should be done is downright disrespectful. We listen to all feedback. Just because we don't agree with you doesn't mean we lazy and can't be bothered is no help to anyone. Be constructive, and be prepared to have us disagree. We're hardly noobs either, and we make our choices for what we believe are good reasons - some of which we can not tell you; accept this, you do not get to dictate business strategy to us.

Now, give us good features that we agree with, and we'll certainly consider them. If we don't we'll try and give you reasons. By all means, feel free to convince us. But we are a limited resource and will implement the things we deem are the best thing for the product.

So I'll say again. You may not like our choices, but unless we get a robust reason and solution to an issue we won't do them. I find it incredibly offensive that you say we're closed to change and feedback, and even a quick search here will show you this isn't the case. So if you simply want to insult us, keep it to yourself, I'm not interested in reading your abuse. Got some positive suggestions that will help and not cripple the product in other ways? Then I'm all ears.
Oh, gee, thanks for highlighting me.
Listen, I had no intention of being insulting (if it was the "can't be arsed" bit, that was my Yorkshire shining through, sorry!), more of an attempt to try to get an actual answer. I apologise for any offense caused - I do not believe insults are a good thing in general.

Well, at least now I know that it may well not be worth me purchasing any additional modules.
 

Mike

nobody important
GMC Elder
Oh, gee, thanks for highlighting me.
Listen, I had no intention of being insulting (if it was the "can't be arsed" bit, that was my Yorkshire shining through, sorry!), more of an attempt to try to get an actual answer. I apologise for any offense caused - I do not believe insults are a good thing in general.

Well, at least now I know that it may well not be worth me purchasing any additional modules.
Saying "Can't be arsed" is one thing, telling us to hire someone that can be, and who is open to change and feedback IS insulting, especially with the effort we go to to respond to users here.

It's currently just after 9pm here and I've been answering stuff on here for a couple of hours - as I do most nights. My job is 9 to 5-ish like most people, but I spend a LOT of my free time responding and helping where I can. So before posting anything that might be deemed as offensive - and you clearly knew it might be as you said it yourself, please remember, we don't have to be on here or answer anything at all - it's not actually part of our job. All yoyo staff who post here do off their own backs because they want to be helpful to those learning, and to try and get feedback and ideas for new features for you guys.

Posting Insults is the quickest way to piss everyone off and drive them away. We've been told that the "direct line" customers have to devs on here is one of the things users like the most, so please remember it's a voluntary action.
 

Posh Indie

Member
...runtime language support...
Disclaimer: @Mike did NOT say this was definitely going to be added. I do not want to be chalked up as the fire starter, nor do I want to make his life miserable when people start pointing to this as a written promise.

That's what I like to hear, thank you. I just like to know there are things for us in the planning. Honestly, runtime language support would be insane (In the good way). I also agree with you on the BGR thing, that would fall under my use of the word "trivial" since currently it does work as-is, and switching Red and Blue would not change the end results.
 
Saying "Can't be arsed" is one thing, telling us to hire someone that can be, and who is open to change and feedback IS insulting, especially with the effort we go to to respond to users here.

It's currently just after 9pm here and I've been answering stuff on here for a couple of hours - as I do most nights. My job is 9 to 5-ish like most people, but I spend a LOT of my free time responding and helping where I can. So before posting anything that might be deemed as offensive - and you clearly knew it might be as you said it yourself, please remember, we don't have to be on here or answer anything at all - it's not actually part of our job. All yoyo staff who post here do off their own backs because they want to be helpful to those learning, and to try and get feedback and ideas for new features for you guys.

Posting Insults is the quickest way to piss everyone off and drive them away. We've been told that the "direct line" customers have to devs on here is one of the things users like the most, so please remember it's a voluntary action.
Again, I'm sorry, I really didn't mean to come across that way - I added that bit about "not trying to be rude" to my post because I suck at talking to people in general and I've always feared accidentally insulting someone (which I apparently did, so I guess the anxiety has a reason) - I even worry that posting something like "have a nice day" could be taken the wrong way, but sometimes I take a chance. I suppose this wasn't a good one.
I really do appreciate what you all do - I think I even said that in the first place too - and I love helping too, that's why I'm here. I suggested what I thought could help, but I screwed it up. All I can do is say I'm sorry, I never wanted to upset anyone.
Can we please settle this nicely? At least end the argument so we can stop filling this thread with negativity.
 

Mike

nobody important
GMC Elder
I have actually said elsewhere that runtime language support is very high on the wishlist. This one will get done at "some point", I deem it as vital.

.........just no idea when.
 

Posh Indie

Member
I have actually said elsewhere that runtime language support is very high on the wishlist. This one will get done at "some point", I deem it as vital.

.........just no idea when.
I put the disclaimer since I had not seen you mention it before. Just covering bases to save everyone the headache. Runtime language support (Now that it has been brought to my attention) and multi-threading are basically all I would ask for at this point in time (But both, I realize, are a rather large undertaking).
 

Mike

nobody important
GMC Elder
Course.... depends what you think runtime language support is. I suspect it might not be what you think it is! :)
 

Posh Indie

Member
Course.... depends what you think runtime language support is. I suspect it might not be what you think it is! :)
Assuming you mean a language that evaluates at runtime? Something that would be crazy useful for incorporating modding support? Scripting languages? I really should stop talking in questions? Haha.
 
Last edited:

Mike

nobody important
GMC Elder
Nope :)

I mean "text" resources that let you deal with languages/translations more easily.
 

GMWolf

aka fel666
Nope :)

I mean "text" resources that let you deal with languages/translations more easily.
Will those text resource be used for other things? I would love to store json in the project itself, and be able to get the text easily!
could be used to store slope information for tiles, build decision trees... the possibilities would be endless!

BTW, we already have 'notes', could we not have a 'note_get_text' function?
 
@Mike, a question. Not trying to beat a dead horse or be an ******* here, just genuinely curious: You guys decided to keep colors as BGR for backwards compatibility. That's fine (I honestly don't care either way - not a big deal to me to switch some colors around.) That said, what's the endgame plan here? Are you guys planning on keeping BGR forever, even though nobody likes it, just because it's how GM started? If not (I hope not!), then when do you plan on changing it? If between major versions, where many people will be starting brand new projects anyway is a bad time to break compatibility, when is a good time?

Thanks for your time. If you can answer this, that'd be great. I think a lot of people here are probably complaining about BGR twice as much as they would be if they understood the reasoning behind keeping it.
 

Storyteller

Member
...snip...

In terms of the things listed here - which is all about backward compatibility, I've already stated our reasons. Whether you agree with them or not is irrelevant, we considered a lot of things when doing the product, and backwards compatibility was a major requirement, and as such we had to make certain choices. This will not change. We are not going to put in a runtime switch that would require massive amounts of dev and testing, and would probably slow things down as there would be a low level IF at every step of rendering. BGR is irritating, I agree - but it is not limiting, and that would be the main concern to us.

So agree, or don't. If you read the reasons behind it, and think about the amount of dev work required to have a switch on every rendering path, on every platform, the speed impact of having an extra IF every time you drew something, not to mention the testing involved and it's a massive undertaking - all for something that is a small irritation. I'd much rather use that effort putting in significant new features like runtime language support, or a particle editor - something like this.
So change it to RGB.
Tell everyone you are going to change it to RGB.
Make an import script that converts the old BGR to RGB as needed.

You get to use the same color scheme as everyone else and maintain a 'standard of practice' used across the computer graphics industry, and maintain backwards compatibility at the same time. Yes, it will be a bit of work, for you the dev team to write that script, instead of each user changing their code, but in the end you get what is a better product. You even say its an inconvenience. Eliminating inconveniences for your user base should be a core goal.

Earlier, you stated:

...snip...
Again, you may not like or agree with it, but these are the choices we've made, and it's not going to change.

...snip..

We're hardly noobs either, and we make our choices for what we believe are good reasons - some of which we can not tell you; accept this, you do not get to dictate business strategy to us.

Now, give us good features that we agree with, and we'll certainly consider them. If we don't we'll try and give you reasons. By all means, feel free to convince us. But we are a limited resource and will implement the things we deem are the best thing for the product.


So I'll say again. You may not like our choices, but unless we get a robust reason and solution to an issue we won't do them. I find it incredibly offensive that you say we're closed to change and feedback, and even a quick search here will show you this isn't the case. So if you simply want to insult us, keep it to yourself, I'm not interested in reading your abuse. Got some positive suggestions that will help and not cripple the product in other ways? Then I'm all ears.
That highlighted part, thats a no-no in game dev 101. You do not make the game you want to play, and you shouldn't be making the GameMaker you want.
You make the game your players want. You should be making the game maker your users want.

We all dictate business strategy to you, in whether we buy your product or not. Its hard I imagine, to have your job, to be this open and direct with your customers and communicate with them. A lot of factions here want different things, you personally want different things as a developer, and even your parent company may dictate certain things.

I can tell from your posts you are worn thin. As this is a Public Beta, expect a lot of opinions to get voiced and feathers ruffled. Ive seen some really immature things be said by YoYo staff in the past. I know Ive said things here and there on the net Id like to take back. As a company, All of you must remain professional. Some of us are deciding to continue using your software based on how you interact, on how you have matured as people, yes people, with feelings, a job and a lot of love and passion for GM.

Me,
  • I want a professional IDE that allows for common industry standard practices with modern languages decoupled from the engine.
  • I want a modular interface where I can change how I make games as much as what platform I export to.
  • I want to get rid of GML, a proprietary language and use C# or Python or Javascript, that translates to other skills later
    (or can be brought in by people that already know one of them).
  • I want a tile and sprite editor better than or at least as good as common freeware pixel editors.
  • I want a soundboard at least as robust as musagi and sfxr (or bfxr).
  • I want a room layout editor that functions from multiple perspectives, side view, top down, 3/4, isometric.
  • I want Box2d or similar physics.
  • I want internal variables exposed.
  • I want a scene graph view of things I can work with.
  • I want OO coding and interfaces. I want to define structs.
  • I want one heck of a 2d gane environment that leverages the best in underlying libraries on todays hardware to compete with Unity, Unreal and Godot.

Backwards compatibility is great. Its also holding you back from making GM be the Best it CAN be. You have to cut the apron strings sometime. Moving to a C++ codebase is great. It should have been the turning point from the old, to the new. There is a middle ground here.

We the community are reaching out to you, now, while the product is under development in a public beta, telling you what we need. This is demand. If you dont supply it, we will buy other software that does. This isnt a dictation of business strategy, its simple economics. Try to remember who uses the software at the end of the day. Listen to what we are asking for. Make that software first, then fit in your personal wishlist. Please, try to relax and remember, some of us are trying to help you and may be from different cultures with different norms and language barriers. Im sure it is stressful and at times trying. You ar an ambassador and a proprietor.

Im not just doing business with 'Yoyo', Im doing business with Mike, and Nocturne and others. People helping people right?

Lets help each other make games, thats what this software, and especially this community, has been about from the beginning. If anything should remain 'backwards compatible', it should be that.
 

Posh Indie

Member
...You do not make the game you want to play...
Believe it or not, many people do make games they want to play under the principle that if they, themselves, like it, there will be enough like-minded people in the world that like it too. Not to mention, if it fits your idea of an ideal game you will be more emotionally invested and interested in the project, therefore you are more likely to finish it since it is something you hold a passion for (And the quality naturally tends to improve). People that develop just for the money tend to be the ones that see Stardew Valley release and try to release a Harvest Moon clone right afterwards because "It did well, so will mine!". Then they fail and wonder why. Just saying.

Ninja Edit:
Or they make HTML5 games like @True Valhalla. (This is in jest. Poking fun at you for being successful, haha.)
 
Last edited:
Believe it or not, many people do make games they want to play under the principle that if they, themselves, like it, there will be enough like-minded people in the world that like it too. Not to mention, if it fits your idea of an ideal game you will be more emotionally invested and interested in the project, therefore you are more likely to finish it since it is something you hold a passion for (And the quality naturally tends to improve). People that develop just for the money tend to be the ones that see Stardew Valley release and try to release a Harvest Moon clone right afterwards because "It did well, so will mine!". Then they fail and wonder why. Just saying.
This. All the best games I've played are very obviously games the creators themselves wanted to play and see made. You can't just blindly follow your fans around. If they actually knew what was best for your game, they'd be making games themselves. I don't think storyteller's example was a very good choice, hahah.
 

psyke

Member
So change it to RGB.
Me,
  • I want a professional IDE that allows for common industry standard practices with modern languages decoupled from the engine.
  • I want a modular interface where I can change how I make games as much as what platform I export to.
  • I want to get rid of GML, a proprietary language and use C# or Python or Javascript, that translates to other skills later
    (or can be brought in by people that already know one of them).
  • I want a tile and sprite editor better than or at least as good as common freeware pixel editors.
  • I want a soundboard at least as robust as musagi and sfxr (or bfxr).
  • I want a room layout editor that functions from multiple perspectives, side view, top down, 3/4, isometric.
  • I want Box2d or similar physics.
  • I want internal variables exposed.
  • I want a scene graph view of things I can work with.
  • I want OO coding and interfaces. I want to define structs.
  • I want one heck of a 2d gane environment that leverages the best in underlying libraries on todays hardware to compete with Unity, Unreal and Godot.
1 - GMS 2 IS a professional IDE;
2 - The GMS 2 is much more customizable then GMS 1;
3 - Why? GML is the reason me and a lot of users are still working with Game Maker. It's easy to understand, and it's made for GAMES;
4 - GMS 2 already has a pretty decent Sprite and Tile editor;
5 - GMS 2 doesn't have ALL the tools to create a game nor any of the game engines out there. You don't have a 3D modeler or Soundboard inside Unity or Unreal Engine;
6 - Why would you want that? Creating a game from top down or side view is the same process;
7 - ??? Box2D is already in Game Maker since GMS 1;
8 - What do you mean by that?
9 - Aren't Scene Graph Views only used in 3D games?
10 - ...
11 - No offense, but Unreal just sucks for 2D games, and Unity has a lot of flaws as well. Don't know what the hell is Godot.
 

Posh Indie

Member
1 - GMS 2 IS a professional IDE;
2 - The GMS 2 is much more customizable then GMS 1;
3 - Why? GML is the reason me and a lot of users are still working with Game Maker. It's easy to understand, and it's made for GAMES;
4 - GMS 2 already has a pretty decent Sprite and Tile editor;
5 - GMS 2 doesn't have ALL the tools to create a game nor any of the game engines out there. You don't have a 3D modeler or Soundboard inside Unity or Unreal Engine;
6 - Why would you want that? Creating a game from top down or side view is the same process;
7 - ??? Box2D is already in Game Maker since GMS 1;
8 - What do you mean by that?
9 - Aren't Scene Graph Views only used in 3D games?
10 - ...
11 - No offense, but Unreal just sucks for 2D games, and Unity has a lot of flaws as well. Don't know what the hell is Godot.
Forgive me for piggybacking here, but reading your responses made me actually read the rest of his post.

@Storyteller
1 - Already covered.
2 - Write your own engine if you want 100% control.
3 - Just go use Unity.
4 - Already covered.
5 - Musagi, sfxr, and bfxr are free. What's wrong with just using them? They don't need to be integrated into GMS.
6 - The only one listed that needs a new grid type is isometric. The others are already covered by the current grid.
7 - Already covered.
8 - They... are?... Unless you mean, "All the internal variables used within the IDE itself for non-game related things". If so, why? Might as well ask YoYo Games to make their commercial product open source... If you meant neither of these, I am with @psyke. I have no clue what you are getting at.
9 - Not sure if this would even be worth the time investment, either way.
10 - Just go use Unity.
11 - Game Maker Studio will never directly compete with any of these, because it is fundamentally different from them all. This is actually the biggest draw to Game Maker Studio.

You sound rather impossible to please, actually. You effectively requested, "Can you throw Game Maker Studio out and write every single thing again from scratch? Oh, and make sure to include everything under the sun in the next version." Show them how it's done, please. I'm certain they want to see this "One IDE to rule them all, but also to compete with Unreal, Unity, and-"... wait... Godot? Seriously? Game Maker Studio is a commercial product. They will never try to become more like (or compete with) a free engine. That just makes no sense. But if you think Godot can compete with Game Maker Studio, please have at it. I like having premium support.

For me, Game Maker Studio already beats Unreal and Unity by a long shot because when I buy Game Maker Studio I actually own it, I'm not leasing it. I want to make 2D games, which Game Maker has been focused on for a long... long time. GML's trade off is the speed at which one can develop. GML is also very capable (and Game Maker's portfolio of hit games is constantly growing because of the freedom we currently have). There are a few big things missing that I would like to see, but none of them are included in this list, sorry.
 
Last edited:
Top