• 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.

Question - IDE When will we have a GUI system, is it planned?

rIKmAN

Member
I'd agree with adding / integrating more tools to the IDE to help build / layout GUI's, but 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".

Also as Frosty mentioned, 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, and is not something I would personally want YYG to devote time to attempting - to the neglect of other areas which that time could be spent improving which (imo) are more important / deserving.

Much better to integrate better GUI tools / support into the IDE which then allows the user to create whatever type of GUI they require.
 

Kezarus

Member
Much better to integrate better GUI tools / support into the IDE which then allows the user to create whatever type of GUI they require.
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.


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".
That's on the devs behavior alone. C'mon, you cannot blame an engine feature "badness" to a lazy behavior of developers. lol


Until we have something we will continue to make our own GUI Systems on the Draw GUI event. Fine by me.

If any of the veterans (or anyone really) could tell me if the Framework that I made is good enough I will be very happy too. =] I personally don't like to just complain about things without at least try to provide a solution and just wait for the good will of others.
 

MissingNo.

Member
but 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'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 than
change the text and background color, not YoYos problem if other users decide to be lazy.

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
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.

But I agree with you and @kburkhart84 that a GUI System isn't the best priority right now as there is more pressing matters. But I don't agree with your arguments against such a system.
 

Kezarus

Member
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.
Hahahahaha, exactly. That cracked me up. 😂😂😂


But I don't agree with your arguments against such a system.
It doesn't seems that @rIKmAN is against it. Or anyone for the matter (if I am reading it right o.Ô).


like a more powerful 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
 

kburkhart84

Firehammer Games
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
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.

That said, there are other things that would be more important, especially things to make better these new things they just released. If I could choose between a new particle system and a 64 bit executable, the 64bits would get my vote. Destructors for structs would as well(though there are alternatives out there). I'd also vote for equal code as far as gamepads on the different platforms(on Windows the gamepad indices are 0 - 12, on Linux it can be 20+). Yeah, I'd take particle systems over GUIs, but there is plenty that I would take over particle systems.

The one I REALLY want is the extendible IDE, as we could then make our stuff like 3d room editors, things to define properties of stuff(like RPGMaker's magic, item, armor, etc... database stuff), our own particle system editors, and tons more.
 

MissingNo.

Member
It doesn't seems that @rIKmAN is against it. Or anyone for the matter (if I am reading it right o.Ô).
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.

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.

a 64 bit executable
I crave for something like that, 100 with you there.
 

kburkhart84

Firehammer Games
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.
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.

But, I AM against them messing with GUI stuff right now when there are too many other more important things IMO. Extendable Plugin IDE, 64bit executable, fleshing out of the new features(destructors for structs, bezier curves for animcurves, dope sheet editor, maybe more features for sequences, you know...things we can REALLY use to make our games better, or easier to make. A GUI system right now wouldn't make a better GUI than one I can make with what we currently have...but these other things I mention would either allow me to make a better game, make it easier to organize code and develop the game, or both.
 

Kezarus

Member
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.
Wops! My mistake. I agree with you, pre-build GUI would be better.


the 64bits would get my vote
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.


our own particle system editors
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. =]


At this point, I don't know if a GUI System is just wishful thinking or if YoYo will or could make our wishes came true about it. They just release a sh** ton of features and the roadmap up until 2021 is full and none of the features we are talking about here are there. Any official news about it is more than welcome.

Until then, what we could do is take matters on our own hands and make it easier for other peoples to use Game Maker. I am really not that great and the likes of @FrostyCat and @rIKmAN are always around helping people. Hell, they helped me more times that I can remmember. I am very grateful, you guys are amazing. The Framework is just my particular way to help others too. =]
 

rIKmAN

Member
That's on the devs behavior alone. C'mon, you cannot blame an engine feature "badness" to a lazy behavior of developers. lol
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.
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.

It 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. Unity are big enough that it didn't affect them, YYG maybe not so much with other free and viable alternatives. All just opinions of course.

Any developer "worth their salt" is already making unique game specific UIs without any issues - but that's not to say that the support and tools in the IDE to help build them shouldn't be improved, I'm all for that.
But I don't agree with your arguments against such a system.
You don't have to agree - that's the beauty of opinions! :)
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.
 

kburkhart84

Firehammer Games
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.
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?!?!).

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. =]
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'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.
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.
 

Kezarus

Member
Coding your own GUI builds character!!!!! But seriously, there are GUI systems on the marketplace(you already know LOL),
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.


But my point about the editor is specifically one integrated into the IDE(as far as the plugin system part).
Yeeeeah.... not specifically that one, sorry. But if you want to tweek around particles and see the result, it's there. =]


9-slice sprites
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
 

MissingNo.

Member
It 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.
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 cutter
syndrome.

Any developer "worth their salt" is already making unique game specific UIs without any issues
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 reputation
much because professional developers wouldn't make cookie cutter menus anyways and the big games are what people think of when they think Game Maker.

You don't have to agree - that's the beauty of opinions!
Yes, I was just critiquing your opinion. No ill will intend as I have a lot of respect for you.

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.
Yeah that is pretty much how I see it.

I simply don't want them to remove the current methods we have for GUIs because they currently allow us total freedom.
Absolutely agree, that would be backwards progress. Doubt they would do that anyways.

But, I AM against them messing with GUI stuff right now when there are too many other more important things IMO.
Yes I am in the same boat, I am not against such a system but would rather they focus on other features.
 

kburkhart84

Firehammer Games
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
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.

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 :) )
 

erayzesen

Member
I'm sorry for my broken english again.

I agree with you about the particle system editor. But I think GUI system is very important part then a particle system editor. Why?

Because all of game engine's workflows have this part. (Old and very old game engines too) Actually GUI system isn't a feature , it's a mandatory part of game engines.(like event systems, like input systems) :)

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.

Other issue, Unity, Unreal , Godot, mono, cocos2d-x, haxe, heaps... all of them have a GUI system and their users can make creative,great, complex menu projects with fast way. So these engine users can make very creative menu scenes with a built-in GUI system. Bad samples can't change these samples. Some users can use the built-in system as it is.This is none of our business.

You may also write your advanced gui systems in game maker except builtin GUI system.

And I think Particle system editor is very important feature after the GUI system.
 

rIKmAN

Member
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 :) )
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.

I think if the extension API ever comes to fruition and gets a public release we'll see massive workflow improvements in terms of editors, tools etc that would be created and integrated into the IDE by users.

It's a bit of a catch 22 for YYG where it's obviously a lot of work for YYG to document and support, but it would also then save YYG a lot of work as the functionality gaps people ask them for would be filled by users using the API, so hopefully one day it gets to the top of the priority list for a least a serious discussion.

@MissingNo.
No ill will at all - like I said it's just opinions.
Different people have different wants and needs, nothing wrong with discussing things - this place would be pretty quiet if we didn't.

However 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.
 

Kezarus

Member
I'm sorry for my broken english again.
Mate, I can understand you perfectly fine. No worries. =]

And I cannot agree more with @erayzesen's opinion. Yeah, GUI is a pretty important thing to have! Unless you are making a text-based game!

IMHO, it should be at top spot for every one to use. It doesn't seem to be a thing too complex to pull off anyways. On top of that, other engines have it. It doesn't look good to YoYo. =/

But, again, I don't know YoYo's intentions about this matter officially (I am looking at you @Nocturne ☜(ಠ_ಠ☜), lol). The roadmap is pretty cramped with sequences, I highly doubt that they get more into their plate.

What we have is the second best option: we do our own. Is it ideal? Nopz. Is it inside the language? Nopz. But does it work and get the job done? Hell yeah! We have to use what is in our reach.
 

kburkhart84

Firehammer Games
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.
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.
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.
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.
 

MissingNo.

Member
However 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.
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't
against GUI accessibility in general.

I'm not really a strong supporter for pre built GUIs despite the way I may sound. I'm more in @kburkhart84 camp where I don't mind if they do or don't add something like that but prefer they focus on other features.

It doesn't seem to be a thing too complex to pull off anyways.
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 complex
to implement for the developers as not many of us are in a position to say how big of a task it could be.
 
Last edited:

erayzesen

Member
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.
Can you explain this a little bit? Gms gives me drawing methods and GUI event (for the fixed screen positioning) for that. not more. :D 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. :rolleyes:

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.

edit: By the way, my criticism is only about the non-built-in GUI system, except that I am happy with all the innovations made. Game maker has advantages on other sides as much as the lack of GUI system, I can't deny that.
 
Last edited:

kburkhart84

Firehammer Games
Can you explain this a little bit? Gms gives me drawing methods and GUI event (for the fixed screen positioning) for that. not more. :D 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. :rolleyes:

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.
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.

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.
 

erayzesen

Member
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.
Well.

Priorities can change for each of us of course. :rolleyes:

Although I respect it, I just don't understand why some GMS users oppose such basic demands. :)

E.g. a builtin Particle system editor, it's not bad idea for me. Why would I find this demand negative? Maybe this is not a primary priority for me. But this saves time, I can make more beautiful,complex particle effects in my games with this feature in the future.
 
Last edited:

BenRK

Member
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.
 

kburkhart84

Firehammer Games
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.
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.
 

BenRK

Member
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.
 

kburkhart84

Firehammer Games
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.
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.
 

rIKmAN

Member
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.
Take a look at this post which contains the details / links to the GitHub repo.

Apologies for going a little off topic OP.
 
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.
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

Sprite-0001.png
I gave this example do you think this is somehow limiting? 😟 I could give you millions of examples.
 
Last edited:

erayzesen

Member
I think the Yoyo group is taking these demands into account. There are always these demands under the promotions made in other channels, people give up the game maker just because of this deficiency they hear.

I'm talking about Buttons/Lists/Containers/Panels/Labels allow to establish a parenting relationship between them (NOT inheritance) but a "has relationship"
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. :D (Most game engines only have these.We can handle more.)

Someone wrote something like "Drag coded instances(For GUI) to room, This is such a simple thing.. "

I can't see text sizes, frame dimensions proportional to this with this way. I think there are only 2-3 button in your scenario. You have to make a correct layout for a complex options menu.(See the example I gave on the previous page.) Imagine you have tabs in your settings. In the simplest, think that you will make an input settings menu. And imagine you're making your first game in Game Maker and you have some deadlines. That would be a pretty sad welcome.
 
Last edited:

Kezarus

Member
Every game has GUI of some kind and thinking that GUI Systems are something limiting doesn't make much sense.
Yeah, right? Agree one-hundred percent!


The thing is, most of veterans and programers (I am one, too, but I don't agree) will say "Yeah, but you could make your own IDE. It's not that hard", etc. Welp.... for me this is equivalent to:
- Okay, I want to make a fence!
- Right! We offer you some raw wood and iron. You can make the wooden boards, nails and a hammer... it's simple.
- But all the other stores are selling wooden boards and nails... o.Ô

But I digress. I think this discussion come to a halt like, people are agreeing and disagreeing, but there is no new information and no action to be taken besides what was already done or proposed.


What we know so far:
  • 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;
It's that simple. I wish we have more information, but we don't. ¯\_(ツ)_/¯
 

samspade

Member
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:
  • 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?
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.

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).
  • They aren't good
  • They don't do what you want
  • They're too complicated
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?

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.
 

erayzesen

Member
For something like that to be useful, you have to answer a bunch of additional questions, and that's where the limitations come in:
  • 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?
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.

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).
  • They aren't good
  • They don't do what you want
  • They're too complicated
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?

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 think you're talking about "GUI Layout Managment System". If it does, of course I will not say no.

But the problem is Gms haven't a GUI system now. Actually, I am trying to express this;

Simple E.g. : Html have a builtin input texts, links, buttons, listbox, checkbox..etc All of these in html supports. Some desktop application frameworks have these elements too. Unity,godot...another engines have these elements too. And these environments have methods, events for these elements. So these environments are supporting (code side or ide side) these basic elements. We want this in Game Maker now, not more. (At least for now.)

Yes, these aren't stylize, these are coming to you default style. You just working on stylization for unique projects. In the backside working on events, usability.

Why? I can code this.

Of course. But imagine this sample; GMS have builtin input text element and events. I could working on more unique features about input text elements, I could write libraries about that. I can do richer gui operations. So more quality, more richer designs, earned more time...

In another side, imagine a game studio using GMS2. You started to work in there. They asked you to make complex menus and they gave a homemade gui framework. After, you started in an another game studio. They asked you to make complex menu and they give another homemade gui framework again. This is a chaos, this is literally nothing but time wasted. Sorry.

We have to look at this demand from different sides.
 
For something like that to be useful, you have to answer a bunch of additional questions, and that's where the limitations come in:
  • 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?
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.

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).
  • They aren't good
  • They don't do what you want
  • They're too complicated
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?

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.

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?

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 :)
 

kburkhart84

Firehammer Games
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?
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.

And yes, if they did it right there would be very few limitations on the system. Another engine for example has one that applies in 2d space, but it can even be transformed in 3d space as well, for buttons on consoles in 3d space, etc... and the one in 2d space can even use 3d elements too. I'm not saying we need that stuff here(its beyond the vision they have for GMS). But the point is that a GUI system can be made without the limitations some people seem to think you would get.
 

erayzesen

Member
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
Sorry for the phrase, don't get it wrong. This is a programmer ego. :D 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..." :cool: :D

But I was developing an experimental game engine in SDL in the old times. You couldn't say that in SDL community "Please add a gui support. " Because SDL isn't created for that, it gives middle level features to you, you should create your own high level systems. This makes perfect sense.:)

But Game maker created to make games with fast way. (Wasn't Yoyo Games motto something like that?) Event it has a drag and drop system except the coding for no programmer base users. It also has many tools to make our job easier.

Other side, all of games needs gui elements.(basic or advanced) All of games have menu and basic ui systems. (health bar, inventory bar, name input box,main menu, options menu...etc)

Well, why I should write these basic elements in gms2? Because the slogan tells me that I can make games quickly. But it doesn't have a GUI system and all of other environments have this. (Even those who do not use this slogan.)

This is what I mean.
 
Last edited:

FrostyCat

Member
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?

For those of you who think that things can become universally accepted just by being built into the engine, have you considered what happened to built-in directions as a potential outcome if YoYo decides to build a GUI framework into GMS 2?

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.
 

Kezarus

Member
What we know so far:
  • 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;
It's that simple. I wish we have more information, but we don't. ¯\_(ツ)_/¯
I stand by every word I said.

@xDGameStudios, answering your question, "When will we have a GUI system, is it planned?". No we don't and no it's not planned. Really sorry. =/

It's pointless to argue about it as priorities on YoYo's side are already set. Again, we don't have any official information about GUI.

The best that we could do is use something from the marketplace or make our own GUI.

Is it reasonable? Nope! GM lose users for lack of basic features like these. I really don't see why so much resistence on the idea. These are, again, basic features. I agree with @erayzesen, this seems to be a lack of empathy for those that can't make a GUI. I add to that that we want to make games, not buttons and text boxes.

I don't think we have anything to add to the discussion without more information. We are not going anywhere... =/
 

Tthecreator

Your Creator!
To add to the conversation.
I see some people think that YoYoGames implementing a UI will cause every game to look the same.
While there will definitely be some lower end games which look the same (every ui widget needs some default texture), as long as you make a simple and clean yet customizable system you can this problem shouldn't occur for more advanced games.

This is what you can build with an negligible chance of creating a "default look or feel"
* a parent-child system
* an more advanced positioning system
* a generic skinning system (very important)
* create your own ui elements

This is what you can build with an medium chance of creating a "default look or feel"
* default widgets like buttons, checkboxes, text fields, etc...

This is what you can build with an medium chance of creating a "default look or feel"
* Complete menu's like pause menus, inventories, etc...

So if they just implement all items from the top list and conservatively add items from my medium list they should be able to pull of a pretty good system. They also should take care in preventing people from having their ui constraints. When making games, you want buttons to have certain effects. Maybe some breathing effect, or rotation. A good animation system is mandatory, but is going to add a lot of complexity. I think my asset lacks a little bit in this regard.

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
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.
I probably also fall a little bit in the "too complicated" category. Not by a lot, a good manual gets you quite far). I felt though like I needed to create tutorials on how to use this. (see: https://www.youtube.com/playlist?list=PLsLUTEpFp6ryglXhtJQeXBkEEMR7yjL57) Is that considered too complicated when your system needs a tutorial? I'm afraid that if we need a good alround system it is going to fall into this category. Not hard to learn, but you do need to learn it. I honestly don't think that's a problem at all. And I also think that for basic usage, my framework is not too complicated, even though you do need to lookup the manual before using any of my pre-programmed widgets. I feel like I'm being quite negative about my own system here, but I'm just trying to be honest. On a positive note, when my documentation is updated and I release this thing I'm going spend some time to properly demo it and get people interested. If anyone wants to see what I can do, see my git wiki: https://git.tthecreator.win/TtheCreator/uiz/-/wikis/home.

That said, when thinking about UI, you should think about windows, buttons, etc. Not health bars, hearts, etc... The last stuff should be custom and not included in the UI system, it's just the menu's that count.

And @Nocturne If there are at any points ideas to make a GUI system, consult me please. Really, I can give a good rundown of all the positioning and inheritance systems I use and what problems occured while actually programming such a system. There are some pitfalls.
 

Kezarus

Member
To add to the conversation.
Mate, I agree with you. But GM will not make anything about it until 2021.

The best that one can do is to use something from the Marketplace.

Btw, I saw your uiZ before, pretty nice! I took some inspiration from it to make mine. But mine is definetly not as complete and through as yours. =]
 

kburkhart84

Firehammer Games
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?
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.

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.
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.

Mate, I agree with you. But GM will not make anything about it until 2021.
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.
 

FrostyCat

Member
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.
 

kburkhart84

Firehammer Games
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.
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.
 

Posh Indie

That Guy
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.

... advertising something as a replacement for something missing in the engine can look bad. ...
That is a moot point. No engine will ever have everything. That is the whole reason they have marketplaces to begin with.
 

kburkhart84

Firehammer Games
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.
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.

That is a moot point. No engine will ever have everything. That is the whole reason they have marketplaces to begin with.
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.
 

Kezarus

Member
problem with the way novices are on-boarded
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.

(things I will not talk about: the fact that Unity is free and GM is paid and have to pay AGAIN for things missing... yikes! but I am NOT saying anything...)


advertising something as a replacement for something missing in the engine can look bad
Let's say it's already not looking great.


To sumarize: go to the marketplace, people. There are good things there. Paid and free.
 
Last edited:

Tthecreator

Your Creator!
Hey guys I'm thinking and I might need some advise. Sorry if I'm getting a bit off track.
I've been working on my ui asset for 3 years now, put in probably hundreds if not thousands of hours. I've only made ~$500. It's nice, but definitely not worth my time. At this point it doesn't really matter to me that much anymore, I just want my work to be appreciated. But I do love the satisfaction of every person making a payment to me. Not because it makes me rich, but because it feels like a great reward.

Anyways, I was thinking, maybe I can open source my project. For free. The problem is that I lose making money.
On the plus side, making it open source will hopefully give me more users. That has the downside of giving me more support tickets and questions. However, I may also get more collaborators to help me fix things. But then again, this is quite a bit code base so that might repeal collaborators.
What do you guys think I should do?
Would you pay for my ui system and do you think other people would do so? (mine's currently $10)
Would you use my ui system if it was open source and do you think other people would do so?
Would you use my ui system at all and do you think other people would do so?

My solution was to maybe dual license it so one the one hand I have a pretty copyleft GPL. Then people working on close source projects can just use a simple proprietary license for a small fee.
 
Top