I agree that any system would be better than none. And to create "One GUI System to Rule Them All" is insane. But beside @Nocturne's statement, we have no information whatsoever about this. And, at the pace YYG, I am worried about when we would have that GUI tool available. If anyone have any further info about this please send a link, I would be very happy to know more.Much better to integrate better GUI tools / support into the IDE which then allows the user to create whatever type of GUI they require.
That's on the devs behavior alone. C'mon, you cannot blame an engine feature "badness" to a lazy behavior of developers. lolwhen you end up with 90% of games all using the same default template and looking the same because the majority of people will just change the text and background colour of menus and think "that'll do".
I'm not sure if I agree that GM needs a built in "GUI system" either but I don't see how a bunch of users making similar looking menus is a problem? Any developer worth their salt will do more thanbut I don't agree with GMS2 needing a prebuilt "GUI system" - as Nocturne said above that's when you end up with 90% of games all using the same default template and looking the same because the majority of people will just change the text and background colour of menus and think "that'll do".
I don't think a one size fits all solution is needed or even being asked for. Just a system that does a few things well will be enough for most. And any additional functionality would then be up to the user to implement.different games have different UI requirements and the breadth of possible implementations unique to each game makes it unrealistic to offer a "one fits all" solution
Hahahahaha, exactly. That cracked me up.Any developer worth their salt will do more than change the text and background color, not YoYos problem if other users decide to be lazy.
It doesn't seems that @rIKmAN is against it. Or anyone for the matter (if I am reading it right o.Ô).But I don't agree with your arguments against such a system.
But a particle system doesn't seem to be the best approach for a priority either. Every game have/need a GUI, not every game have particles. And you could do preatty neat things with sequences that emulates particles! =Dlike a more powerful particle system
You are right...but right now, I can make the GUI I want with the included DrawGUI event...but if I need more powerful particles, its going to take some more serious coding. I'm not saying that particle systems should be at the top of the list either...I'm just saying that IMO more people would prefer they make a more powerful particle system before they make a GUI system that doesn't take much effort for us to roll our own for. That's the reason I specifically mention the particle system.But a particle system doesn't seem to be the best approach for a priority either. Every game have/need a GUI, not every game have particles. And you could do preatty neat things with sequences that emulates particles! =D
Well he said explicitly he is against a pre built GUI System. So I assume he is saying he would be against pre made buttons, text boxes and other things of that nature.It doesn't seems that @rIKmAN is against it. Or anyone for the matter (if I am reading it right o.Ô).
I crave for something like that, 100 with you there.a 64 bit executable
At this point, GUIs are easy enough to make. I don't disagree with much of anything they want to do with GUIs, something lower level, a high level system with pre-built components, whatever....they can do a few different things for all I care and people can choose which way they want to go with it. I simply don't want them to remove the current methods we have for GUIs because they currently allow us total freedom.He would rather see more low level functionality for GUIs rather then pre built functionality you can use out of the box. I agree pre built GUI functionality shouldn't be a priority but I don't agree with his
arguments against pre built functionality.
Wops! My mistake. I agree with you, pre-build GUI would be better.Well he said explicitly he is against a pre built GUI System. So I assume he is saying he would be against pre made buttons, text boxes and other things of that nature.
Hmmm, maybe mine too. But GUI is a good BASIC thing that many users need. Don't you agree with that? More to the point, is a thing that entry level Game Makers will look for. Advanced particles would be a thing for vets mostly. And 64bits too.the 64bits would get my vote
I don't want to annoy you, by any means, but I have a Particle Lab in the framework. You can edit your particles and it saves and load particles in GML code. Check it out. If it's not good we can make it better. =]our own particle system editors
That's on the devs behavior alone. C'mon, you cannot blame an engine feature "badness" to a lazy behavior of developers. lol
I didn't blame anyone, or say it was YYGs problem - just that it will happen given the nature of GMs userbase being mainly beginners.Any developer worth their salt will do more than
change the text and background color, not YoYos problem if other users decide to be lazy.
You don't have to agree - that's the beauty of opinions!But I don't agree with your arguments against such a system.
I don't disagree with that...I just don't think its that high of a priority. Coding your own GUI builds character!!!!! But seriously, there are GUI systems on the marketplace(you already know LOL), but there aren't any advanced particle systems that I saw(just pre-built effects using the current particle system). And the 64bit runner is not something that can just be implemented by a veteran coder, it takes Yoyo to do it. I also think that sometimes an issue with this software is when it "over-caters" to the beginner crowd to the point that veteran power users can't do things we would like, or have to wait longer for features(how long did we wait for the recent gml features in 2.3?!?!).Hmmm, maybe mine too. But GUI is a good BASIC thing that many users need. Don't you agree with that? More to the point, is a thing that entry level Game Makers will look for. Advanced particles would be a thing for vets mostly. And 64bits too.
Not annoyed, and its good that people have made these. But my point about the editor is specifically one integrated into the IDE(as far as the plugin system part). And as far as a better particle system, your editor is still using internal particles, not making them more powerful. I would like to see(or may eventually make myself) a more powerful particle system overall, and then have an editor for it be part of the IDE through a plugin. The same plugin system would let me make a configuration dialog for my input system, and let the 3d people make their 3d level editors within the IDE.I don't want to annoy you, by any means, but I have a Particle Lab in the framework. You can edit your particles and it saves and load particles in GML code. Check it out. If it's not good we can make it better. =]
This is basically my viewpoint. I don't care if they make a basic GUI system for beginners to cookie cutter stuff with. But I would prefer to see expansion of sequences, 9-slice sprites, and other things that we can use to make our GUIs better without the cookie cutter approach.I'm also not against integrating better UI support - I just think it's better to give people better in-IDE tools to build UIs than it is to actually provide a complete UI system itself.
Hahaha. Ok, I know that you are joking there. But not everyone could do that. And yeah, totally agree that the market place is there to provide things.Coding your own GUI builds character!!!!! But seriously, there are GUI systems on the marketplace(you already know LOL),
Yeeeeah.... not specifically that one, sorry. But if you want to tweek around particles and see the result, it's there. =]But my point about the editor is specifically one integrated into the IDE(as far as the plugin system part).
Ow, I have those too. The buttons and frames are made using the nine-slice technique too. And the function is there for use if one needs it. Tiled and Streched.9-slice sprites
I could foresee that being a possible issue but then again I think the games people most often associate with GM are games like AM2R, Hotline Miami or Undertale and they certainly wouldn't fall prey to cookie cutterIt then becomes associated with "cookie cutter" menus just like the RPG Maker menu system that was mentioned, or "low effort" games like the Unity splash screen did - which then does become YYGs problem as it affects the engines brand/reputation.
Yes I know, I'm not advocating for such a system or saying that those kinds of developers want or need such a system. I was simply saying if such a system existed I don't think it would hurt GMs reputationAny developer "worth their salt" is already making unique game specific UIs without any issues
Yes, I was just critiquing your opinion. No ill will intend as I have a lot of respect for you.You don't have to agree - that's the beauty of opinions!
Yeah that is pretty much how I see it.At this point, GUIs are easy enough to make. I don't disagree with much of anything they want to do with GUIs, something lower level, a high level system with pre-built components, whatever....they can do a few different things for all I care and people can choose which way they want to go with it.
Absolutely agree, that would be backwards progress. Doubt they would do that anyways.I simply don't want them to remove the current methods we have for GUIs because they currently allow us total freedom.
Yes I am in the same boat, I am not against such a system but would rather they focus on other features.But, I AM against them messing with GUI stuff right now when there are too many other more important things IMO.
Its good that you make these things...but something integrated into the IDE is pretty much always going to be better. It is also much more likely to run faster as it can use the underlying code instead of GML to do it. Your stuff is good to fill in the gaps, while we wait for them to integrate them.Hahaha. Ok, I know that you are joking there. But not everyone could do that. And yeah, totally agree that the market place is there to provide things.
Yeeeeah.... not specifically that one, sorry. But if you want to tweek around particles and see the result, it's there. =]
Ow, I have those too. The buttons and frames are made using the nine-slice technique too. And the function is there for use if one needs it. Tiled and Streched.
Sorry if I am annoying, but the thing really have a whole lot of tools in the box. Have a look. If it's not good I can make them better. =D
Yeah, the difference there is that their editor extension system allows users to create things that are tightly integrated natively into the IDE as standard.I feel like GMS is in the same place a certain other engine was at some point. They depended on their users to create these nice things but eventually are getting around to adding them to internal(or buying them out in some cases )
Mate, I can understand you perfectly fine. No worries. =]I'm sorry for my broken english again.
Indeed, this is exactly what I'm getting at when I mention the benefits of such a system and how much of a game changer it would be if they would make it happen.Yeah, the difference there is that their editor extension system allows users to create things that are tightly integrated natively into the IDE as standard.
The long talked about GMS2 IDE Extension system "just needed documentation" around 4yrs ago, so not sure what happened, but without it users cannot natively extend the IDE and so any extensions are usually GML based (or system specific via DLLs, Dylibs etc) and so even if they are amazing extensions they can't be integrated into the IDE like the engine you mentioned above and will always feel external to the overall IDE workflow.
GM DOES let you do a GUI easily enough though. Just because it isn't pre-made like in other engines doesn't mean its not there. That said, I don't think it would be bad for them to add such a higher level system, just that I think other things are more important right now, as the lower level system they have for us to make our own GUIs works just fine. It IS just an opinion. Some seem to agree with me, others agree with you more. What matters is what the developers end up agreeing with in the end.So you can't promote your game engine in the industry with like this "We have a GUI system". Because there isn't a game engine without a GUI system except Game Maker now. Sorry but it's a reality.
Yeah I never acknowledged that part of your post. I don't have any issue with them doing something like what you suggest. I just disagreed with your objections against pre built GUI features but I knew you weren'tHowever as I mentioned I think if YYG provided better tools for building UIs then people would make extensions / systems with the basic UI elements you mention which people could use, allowing YYG to then focus on other things.
Well it could very well be complex or at the very least time consuming to implement. Especially to test the system and make it user friendly. It's a bit of a bold claim to say that it wouldn't be complexIt doesn't seem to be a thing too complex to pull off anyways.
Can you explain this a little bit? Gms gives me drawing methods and GUI event (for the fixed screen positioning) for that. not more. E.g there are not a input text element, a list box element...etc all of media libraries (I'm skipping game engines) also have drawing functions. I cannot see the advantage provided to me here except GUI events, sorry.GM DOES let you do a GUI easily enough though. Just because it isn't pre-made like in other engines doesn't mean its not there. That said, I don't think it would be bad for them to add such a higher level system, just that I think other things are more important right now, as the lower level system they have for us to make our own GUIs works just fine. It IS just an opinion. Some seem to agree with me, others agree with you more. What matters is what the developers end up agreeing with in the end.
I think we understand each other just fine. The DrawGUI events let you draw things at the same positions regardless of final resolution(making it easier to position GUI elements). And it is easy enough to make buttons that draw text, react to mouse-overs and clicks, etc... for example. That's what I mean though, they don't have pre-made buttons or anything right now, but they have what you need handy to make your own buttons. The same can be said for option buttons, check boxes, input fields, etc... I understand what you want as far as a GUI system, I just don't think it is that high a priority.Can you explain this a little bit? Gms gives me drawing methods and GUI event (for the fixed screen positioning) for that. not more. E.g there are not a input text element, a list box element...etc all of media libraries (I'm skipping game engines) also have drawing functions. I cannot see the advantage provided to me here except GUI events, sorry.
I think we all understand the gui system differently.
Actually even these are enough for most people;
-Addable GUI layers in the room.
-Some basic elements (text fields, list boxes, input texts, sliders... ) to add in a GUI layer. (We may drag created elements from asset bar to the room screen)
-Some basic stylization methods for elements in Coding side.
Well.If you want something that is pre-built with the components, there are several on the marketplace already. I don't think there is a high priority for them to make some internally at this time since alternatives are easy enough to either do yourself or find done for you. Other features I'm wanting that to me have higher priority are things that you can't just find on the marketplace. They either require much more extensive coding(like a particle system), or simply require source code and the developers to do it(64-bit executable, plugin/extensible IDE). A GUI system simply doesn't fit that category for it to take a higher priority.
I 100% agree, we each have our own priorities. And I don't oppose these basic demands, I just think they have lower priority is all.Priorities can change for each of us of course.
Although I respect it, I just don't understand why some GMS users oppose such basic demands.
Indeed, this is why I say a GUI system takes less priority over other things. We can't just do a few clicks and get a more powerful particle system, or a 64bit runner, or plugin IDE.It's not even that hard to make a GUI visually. You could easily make a GUI layer in the room editor, drag objects onto the layer, and have said objects draw to the GUI layer via draw_self(). Depending on the game you'll need to use different events to have it interact correctly, but I honestly can't see that being harder then checking for a mouse click, getting the mouse window X and Y, and see if that's over any GUI element, and then just calling a user event.
Yeah, that's not as simple as dragging something onto the room editor and it just works, but it's way simpler then a lot of people seem to be making it out to be.
Besides using external code(via DLL, etc...) there isn't a direct way to do it internally. The closest thing would be to figure a way to divide the thing in very small chunks of work(small as in can be done in just part of a 60 times a second room speed). Then you could just have an object do it bit by bit each step event. In the past I had a thing that loaded stuff from zip files and did little by little so it would still animate a loading screen. The hard part to me would be figuring out how to split the work in this fashion.If I could request anything, I'd request a way to use more then one thread. So I could throw stuff like generating a world or loading a save or etc onto a different thread then the main game so things don't pause all the time. Probably is a way I haven't figured out though.
Like kburkhart mentioned it can't be done with vanilla GMS2, but if you wanted to play around with an extension then kraifpatrick released YYC-Overwrite which includes the ability to run GML in seperate threads natively.If I could request anything, I'd request a way to use more then one thread. So I could throw stuff like generating a world or loading a save or etc onto a different thread then the main game so things don't pause all the time. Probably is a way I haven't figured out though.
This is misleading.. A GUI system is something present in all kinds of games.. being them platforms, visual novels, RPGs, FPS, RTS games.I don't think there should be a built in GUI system for the same reason that I don't think there should be a built in platforming system, visual novel system, etc. GameMaker, at least to me, has always been about providing the fundamental tools to build what you want, not building half of what you want for you. Although I understand that on some level that's a subjective distinction.
Actually I don't wait these advanced systems from the Yoyo group. I 'm waiting some basic elements (input,slider,listbox...etc) and a GUI layer in the IDE. Better than nothing. (Most game engines only have these.We can handle more.)I'm talking about Buttons/Lists/Containers/Panels/Labels allow to establish a parenting relationship between them (NOT inheritance) but a "has relationship"
Yeah, right? Agree one-hundred percent!Every game has GUI of some kind and thinking that GUI Systems are something limiting doesn't make much sense.
For something like that to be useful, you have to answer a bunch of additional questions, and that's where the limitations come in:This is misleading.. A GUI system is something present in all kinds of games.. being them platforms, visual novels, RPGs, FPS, RTS games.
It's like saying "I don't want GMS to have a particle system" or "we don't want the sequences feature".
A GUI system is not pre-made windows like you see in RPG Maker.
Every game has GUI of some kind and thinking that GUI Systems are something limiting doesn't make much sense.
The RPG Maker examples are bad examples and look similar because they all consist on a background image with a window placed at the center of the screen with 3 vertically placed buttons inside it. So it's not strange that they look alike they are EXACTLY the same.
Pick a game anyone in the game industry or a picture from a game menu or GUI whatever you would like and I (and half the people here) can describe to you the "GUI Components" that actually exist behind the scenes that put the GUI together. It's only limiting if you cant customise things.. if you can change the appearance of everything then what is limiting you?
I don't need YYG to make us default menus/default title screens/default item shop menus/ and default game over screens... that is not what a GUI system is about...
I'm talking about Buttons/Lists/Containers/Panels/Labels allow to establish a parenting relationship between them (NOT inheritance) but a "has relationship"
your item list for example would be for example:
1) A panel (that you could customize to look like what ever you want.. 9patch.. whatever)
2) With a main vertical container inside
2.1) then you could have another vertical container to hold the items (then each entry in the list could be a horizontal container with)
2.1.1) a picture (the item icon)
2.1.2) a label the item name
2.1.3) another label for the amount
2.2) then you could have a horizontal container in the footer with two buttons USE and CANCEL
View attachment 33593
I gave this example do you think this is somehow limiting? I could give you millions of examples.
For something like that to be useful, you have to answer a bunch of additional questions, and that's where the limitations come in:
Each of those questions, and many, many more, have to be answered even for something as simple as that. Some of those answers are binary, and whichever one you choose people will be unhappy, some of those answers could be optional but would then require more code. In fact a decent GUI system would still require a fair amount of user written code to be useful, which is just one more thing users have to learn, and unlike learning to code it themselves that knowledge won't be transferable, in a way learning a complete GUI system will be a lot like learning drag and drop. Useful inside of GM, helpful to new programmers, teaching some core concepts, but overall something you pretty much have to transfer out of in the long run with anything complicated.
- How do you set the values in that?
- How to do you tie the values given to actual things in your game?
- Can you move those panels or not move those panels in game?
- Does it have keyboard support, and if so how is it implemented? Can you turn it on and off if you don't want it?
- Does it pause all your other code? If so how?
- How does it handle being over other objects (i.e. if it is a pop up menu) or can it not do that?
- Do you create this in code or in an editor or both and if in an editor, does it give you an object at the end?
- Does it work in room space or gui space?
A good example of this is something like flexbox for css. Flexbox is very useful and there's a reason it and things like it were created. But it is still something you actually have to learn and has very little value outside of its context except that it does provide a useful framework for how to layout certain types of UI. And, it only provides a layout. If you want to actually interact with that layout, you need even more coding knowledge. Most of the people asking for a GUI system, don't just want a layout system, they want that system to be tied to actual things in their game which is another thing entirely.
The built in particle system is another good example. It actually takes a bit of time to learn the basics and even more to create useful things with. It is not something beginners usually start with. But unlike GUI the particle system is necessary because, at least as far as I know, it is basically (maybe actually) impossible* for any user to create a particle system as efficient and optimized as the built in one. So it provides something that is actually irreplaceable in certain contexts. This is not true of GUI elements.
One last thought, there are many marketplace assets for menu and gui frameworks. Why doesn't everyone just use them? Here are some possibilities (and this not about any particular framework out there).
With the exception of the first, which presumably a built in wouldn't be, this illustrates why a built in system won't work. If all you needed was a system, they already exist, many of them for free. So in a very real way, GameMaker does come with not just one, but many built in UI systems and people already aren't happy. Why would it be any different for a built-in one? or why aren't people asking for YoYo to release an official asset with a tutorial that covers the basics?
- They aren't good
- They don't do what you want
- They're too complicated
There is also one other possibility which is that the real reasons the market place assets don't solve the issue is that even with good systems, the way GM lets you interact with those systems is less than ideal. Its this last thing that I think is actually the case. This is where I think there could be (and sounds like will be) a lot of helpful and meaningful improvement. Things like the ability to visiualize in the editor what your GUI looks like, display text or 9 slice, allow the built in events to work with mask collision on the gui layer, etc.
the system could be something like sequences, you would need the GMS2 GUI to have a special environment where you could handle GUI much like tile layers... maybe GUI layers.. that would have special functions. If you had a GUI system you would need a way to place items, bind code/values ..etc... With GMS 2.3 we now have functions you can have a button have a bunch of callback.. onHover, onClick, onLeave.... that you can customize and use to call your custom code.For something like that to be useful, you have to answer a bunch of additional questions, and that's where the limitations come in:
Each of those questions, and many, many more, have to be answered even for something as simple as that. Some of those answers are binary, and whichever one you choose people will be unhappy, some of those answers could be optional but would then require more code. In fact a decent GUI system would still require a fair amount of user written code to be useful, which is just one more thing users have to learn, and unlike learning to code it themselves that knowledge won't be transferable, in a way learning a complete GUI system will be a lot like learning drag and drop. Useful inside of GM, helpful to new programmers, teaching some core concepts, but overall something you pretty much have to transfer out of in the long run with anything complicated.
- How do you set the values in that?
- How to do you tie the values given to actual things in your game?
- Can you move those panels or not move those panels in game?
- Does it have keyboard support, and if so how is it implemented? Can you turn it on and off if you don't want it?
- Does it pause all your other code? If so how?
- How does it handle being over other objects (i.e. if it is a pop up menu) or can it not do that?
- Do you create this in code or in an editor or both and if in an editor, does it give you an object at the end?
- Does it work in room space or gui space?
A good example of this is something like flexbox for css. Flexbox is very useful and there's a reason it and things like it were created. But it is still something you actually have to learn and has very little value outside of its context except that it does provide a useful framework for how to layout certain types of UI. And, it only provides a layout. If you want to actually interact with that layout, you need even more coding knowledge. Most of the people asking for a GUI system, don't just want a layout system, they want that system to be tied to actual things in their game which is another thing entirely.
The built in particle system is another good example. It actually takes a bit of time to learn the basics and even more to create useful things with. It is not something beginners usually start with. But unlike GUI the particle system is necessary because, at least as far as I know, it is basically (maybe actually) impossible* for any user to create a particle system as efficient and optimized as the built in one. So it provides something that is actually irreplaceable in certain contexts. This is not true of GUI elements.
One last thought, there are many marketplace assets for menu and gui frameworks. Why doesn't everyone just use them? Here are some possibilities (and this not about any particular framework out there).
With the exception of the first, which presumably a built in wouldn't be, this illustrates why a built in system won't work. If all you needed was a system, they already exist, many of them for free. So in a very real way, GameMaker does come with not just one, but many built in UI systems and people already aren't happy. Why would it be any different for a built-in one? or why aren't people asking for YoYo to release an official asset with a tutorial that covers the basics?
- They aren't good
- They don't do what you want
- They're too complicated
There is also one other possibility which is that the real reasons the market place assets don't solve the issue is that even with good systems, the way GM lets you interact with those systems is less than ideal. Its this last thing that I think is actually the case. This is where I think there could be (and sounds like will be) a lot of helpful and meaningful improvement. Things like the ability to visiualize in the editor what your GUI looks like, display text or 9 slice, allow the built in events to work with mask collision on the gui layer, etc.
I assume that wasn't pointed at me. I've said before, I'm not against the suggestion...I just think there are higher priorities that should be knocked out first.I don't quite understand why people tend to become so overwhelmed by others suggestions here in the forums. it's almost like: they don't use it, they don't want it... NO one needs it!!
Unity/Godot/Unreal have GUI systems built in... do you think they are limited? If the idea itself was something that limiting why would top rated engines use it and invest resources into developing those?
Sorry for the phrase, don't get it wrong. This is a programmer ego. Just like that "I can do this, let those who cannot do it think about it. I don't care. Everybody should code input text, gui elements and events... Because I can do it..."That being said.. if people actually think it's a bad idea.. and the GMS community will not gain anything with it... then okay, I'm really sorry for this suggestion
I stand by every word I said.What we know so far:
It's that simple. I wish we have more information, but we don't. ¯\_(ツ)_/¯
- We don't have a native Game Maker GUI System;
- YoYo is quite busy right now with sequences until 2021;
- There are options, free and paid, on the marketplace;
- You could make your own GUI;
To be honest, I think my currently released ui asset has too many bugs and hickups. This is not the case for my development version, which is quite stable.One last thought, there are many marketplace assets for menu and gui frameworks. Why doesn't everyone just use them? Here are some possibilities (and this not about any particular framework out there).
- They aren't good
- They don't do what you want
- They're too complicated
Mate, I agree with you. But GM will not make anything about it until 2021.To add to the conversation.
Not quite a problem for me, I can have my place for the time being.Mate, I agree with you. But GM will not make anything about it until 2021.
These are typically things that are easily and necessarily replaced. (Despite my thinking that a GUI system is pretty low priority), I would argue that a properly done GUI system isn't exactly the same. It is something that would probably get used more often instead of custom solutions, assuming it was done right. For example, I don't see many posts about people using a custom GUI due to the implemented one not being good enough. A GUI system is one of those things that if done right can be customized enough to be unique for each game.GML has built-in speeds and acceleration, which are arguably even more fundamental than GUI elements. How much use does it see these days?
How many other things that are built into the current GML ecosystem face the same fate, where with usage most commonly seen in the user community, it lies unused in the engine in favour of custom-made alternatives?
I personally have been on some of the other lawns...and you are 100% right about Unity and the scene editor. I don't see as much discussion about the GUI system though...back before Unity 4.6 got the new system you had only the Immediate mode GUI which was widely hated so you needed an external system but after that people have generally been OK using the internal system from what I have seen. Yes of course, it gets criticism(as will anything), but it isn't as bad as the previous system at the least.And for those of you who think the grass is greener on other lawns, have you actually been on those lawns? For example, Unity comes with its own room editor, but if there's one thing that Unity's developer community never agrees on, it's which room editor to use.
That is honestly the way I would prefer it...the GUI system is not that high of a priority IMO. There are simply too many other things that would be better.Mate, I agree with you. But GM will not make anything about it until 2021.
This makes sense 100% to me. The hard part I see with this is simply that Yoyo can't(shouldn't) advertise 3rd party stuff as the solution to things that are missing from the engine(the GUI system is no exception). They can advertise the ecosystem in a general sense as a benefit to the engine, but advertising something as a replacement for something missing in the engine can look bad. So if we are to make what you want happen, its up to use users, not Yoyo.Quite frankly, this fuss about GMS 2 not having a UI framework built-in looks more like a problem with the way novices are on-boarded, than a problem with GMS 2 itself.
For example, Spalding's platformer movement code is now the de-facto standard, despite it never having been built into GM at any point in time. Every responder knows it when they see it, and most of the time when a novice asks about it, it's some broken variation of it. For something that works only for a specific genre, it surely gets a lot of coverage.
The GM tutorial scene is spending a lot of time teaching stuff that novices will only use once or twice, but not the stuff that novices will use throughout their stay with GM. That in my opinion is making new users drop more than not having a UI framework built in. Had they been directed towards one of the many Marketplace UI frameworks as part of on-boarding and actually taught how to use it, not having a UI framework built-in is no longer an issue to them. They can just use the one they were on-boarded with as a template, the same way Spalding's platformer movement code is used now. The same thing applies to tweening, formatted text, lighting, etc.
That is a moot point. No engine will ever have everything. That is the whole reason they have marketplaces to begin with.... advertising something as a replacement for something missing in the engine can look bad. ...
On this we agree. A GUI system can be nice, but it simply isn't a priority to me since we can easily get what we want right now with what we have, and use the marketplace to save time if the components provided fit the need.I have to side with @FrostyCat on this one. It sounds great, sure, but this is definitely a "Grass is greener" scenario. It will not be able to cover every use-case. Even the engines that have a GUI system in place have custom GUI systems in their store (Which should speak volumes). I am just not sure this should be a priority, personally.
I agree partially with this. Its good that they have the marketplace and they can brag about it in general...but I don't think it would be a good idea for them to brag about a specific asset covering something that many people think should be internal to the engine. Its a point you will see on other engines' forums as well. People complain about engine developers becoming dependent on the store to fill in the gaps instead of doing the work. to create the systems internally. Some people would say that its a bad thing(moot point or not). I feel like it wouldn't be good business to advertise directly that if you want a GUI system, you need to use some asset. That's the point I was making.That is a moot point. No engine will ever have everything. That is the whole reason they have marketplaces to begin with.
Ya, have to agree with Frosty too. Unity have a very huge marketplace. There are options in ours for GUI. Mine and @Tthecreator are examples.problem with the way novices are on-boarded
Let's say it's already not looking great.advertising something as a replacement for something missing in the engine can look bad