The absolute need for GUI system/plugin

0 favourites
From the Asset Store
The I18N (Translation) is a Construct plugin created to translate text in game.
  • Couldn't you do this mapping in events? Kinda of how you map strings to function you can map dom element events to c3 functions. You would just need a bit more information such as the element ID and the event you want to map?

  • Couldn't you do this mapping in events? Kinda of how you map strings to function you can map dom element events to c3 functions. You would just need a bit more information such as the element ID and the event you want to map?

    How would you access event parameters like the button or key that was clicked/pressed? I wouldn't want to have to try to cover every kind of possible event and event parameter that exists in JS, that's a lot of work just reimplementing what JavaScript already does.

  • > Couldn't you do this mapping in events? Kinda of how you map strings to function you can map dom element events to c3 functions. You would just need a bit more information such as the element ID and the event you want to map?

    How would you access event parameters like the button or key that was clicked/pressed? I wouldn't want to have to try to cover every kind of possible event and event parameter that exists in JS, that's a lot of work just reimplementing what JavaScript already does.

    Isn't that the whole point of the event system though? To reimplement what you can do in conventional coding?

  • I think this idea in general is fairly close to something workable, but I'm just trying to find a way of doing it that doesn't oblige us to do a lot of wrapping around low-level JavaScript APIs. Construct is generally much more high-level than that, for example giving you Sprite objects, not just an OpenGL vertex buffer to fill out.

  • Isn't that the whole point of the event system though? To reimplement what you can do in conventional coding?

    This. Exactly. Ashley, every reason you've presented so far for NOT doing something is because it can be done in JS or HTML. Wasn't the original purpose of Construct to insulate the end user from the vast majority of that? If I'm going to have to write half my project in JS anyway, what's the purpose of buying Construct? Why not just download Unity, which is free for development and a lot more powerful and it works with both JS and C#. I've seen so many answers lately that say, 'oh, just do that in JS now.' Well, the whole purpose of me buying C2 AND C3 was so that I didn't HAVE to screw with JS (much).

  • I don't have any big gripes about copy, and pasting code, if they want to make a library type thing available as a solution, but I don't think that is feasible with how Construct is set up as Ashley already pointed out.

    It seems to be the same issue as copy and pasting events.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Hey! I just made a suggestion in the C3 idea website for the 'grid object' that I proposed above.

    https://construct3.ideas.aha.io/ideas/C3-I-1043

    I don't know if is too vague. So if someone here have any new details or ideas to share, let me know, so I may edit the suggestion text with more info.

    Please vote!

  • I think there will be tradeoffs. The more something is abstracted out and made more high level, the more you lose the ability to customize it at a granular level.

    I remember products like Dreamweaver back in the day that was a wysiwyg web page creator. They had drag and drop html elements.

    Even with something like that there is still this tradeoff that happens. And to fully customize what you were making you had to dig deeper. If you use the high level tools you lose some control. And i feel like that leads to cookie cutter solutions.

    If you think moving to unity because you have to write a bit code in construct is going to speed up your development time you gonna be in for a surprise...

  • Hey! I just made a suggestion in the C3 idea website for the 'grid object' that I proposed above.

    https://construct3.ideas.aha.io/ideas/C3-I-1043

    I don't know if is too vague. So if someone here have any new details or ideas to share, let me know, so I may edit the suggestion text with more info.

    Please vote!

    That's similar to an element I'd like to see, which is a basic UI element in most other IDE's, call a panel. I mentioned this in another post a couple of months ago in yet another thread about the GUI.

    https://www.construct.net/en/forum/construct-3/general-discussion-7/life-saving-suggestion-144108?kws=panel#forumPost975906

  • If you think moving to unity because you have to write a bit code in construct is going to speed up your development time you gonna be in for a surprise...

    I spent years working with Unity and yea, it's a huge pain in the ass. Especially when the latest version comes out and breaks half the crap you created in the previous version. The reason I chose Construct for my latest project over Unity (and this was weeks of internal debate) is because of the plethora of code and finite details I'd have to wade through in Unity to accomplish the same task. That and the fact that the Scirra team actually communicates with it's customers, something Unity has yet to embrace without charging for it.

    However, if I'm going to have to wade through code anyway finding workarounds to a limited set of UI elements...

  • Fengist - I think you missed the bit where I wrote this:

    ...I'm just trying to find a way of doing it that doesn't oblige us to do a lot of wrapping around low-level JavaScript APIs. Construct is generally much more high-level than that, for example giving you Sprite objects, not just an OpenGL vertex buffer to fill out.

  • My experience with RPG maker is that everyone spends all their time writing their own GUI because they don't like the GUI the engine comes with. Most of the addins (like Yanfly) start by undoing the GUI. If you look at what is requested on their boards it is about the same here--they want a user interface--just not the one they get with the game engine.

  • Fengist - I think you missed the bit where I wrote this:

    > ...I'm just trying to find a way of doing it that doesn't oblige us to do a lot of wrapping around low-level JavaScript APIs. Construct is generally much more high-level than that, for example giving you Sprite objects, not just an OpenGL vertex buffer to fill out.

    No... I was writing the reply, got distracted with a customer, came back, finished and posted it and then saw your reply. I decided to leave it so you'd know at least what's in my head.

    It's good to know though that you haven't strayed from your original concept.

  • My experience with RPG maker is that everyone spends all their time writing their own GUI because they don't like the GUI the engine comes with. Most of the addins (like Yanfly) start by undoing the GUI. If you look at what is requested on their boards it is about the same here--they want a user interface--just not the one they get with the game engine.

    UI's should be unique across games and apps. The UI is the first thing the user sees and therefore makes the first impression. No plugin or hard-coded UI element is going to satisfy everyone. However, there are basic elements to any UI that are severely lacking in Construct. These elements, like panels and scroll boxes form the basis of UI's. As it stands, we only have the simplest of controls, buttons, text boxes, etc., controls that are related mostly to user input. Nothing exists to help manage the placement of these controls and, in my case, I have to run through every single control each time a layout is shown or the browser gets resized and manually move and resize them to what I want.

  • I feel like we went a bit off on a tangent there with iframes, DOM elements and whatnot...

    The main issue I see here is the lack of a simple way of layouting various elements. A better way of controlling their placement. (As Fengist also pointed out)

    I do not want to use any kind of iframe, native DOM, javascript shenanigans. That´s exactly what I´d wanna avoid, I want to keep it purely in Construct/Events!

    I made this pen as an example, it´s basically a Legend of Zelda health bar. (Give or take 5 minutes of work)

    codepen.io/anon/pen/Xvjwqd

    So what does it do: All of the hearts are neatly aligned, you can add/remove hearts and it has multiple rows. Also you can move the container anywhere, the hearts follow automatically.

    How about Construct in this case?

    wackytoaster.at/parachute/hearts.c3p

    Ok so we want the hearts to move with a container, so I used a tiled background as reference point. It´s basically the flexbox. But here is the first thing: It (kind of) requires a setup function at runtime, that is not the biggest issue though!

    The main thing is to have the hearts neatly aligned and wrap automatically. It will require some mental gymnastics...

    Look at it... none of that was required in the pen I made, because flexbox does all that shizzle for me. To be fair, it didn´t take much longer than writing the pen for me, but one should consider that this is not only a really really simple case, but also I had to deal with this exact issue beforehand and I have a couple years of experience on my back. A newbie probably will sit there without any clue where to even begin, and that´s just the tip of the iceberg.

    I mean... if you have an easier way of doing it, please tell me! (And no, I wouldn´t consider using arrays easier or reasonable for such a case)

    Almost forgot to mention. This is pretty hardcoded now and I´d have to go into the code to change how many hearts are shown per row etc. For flexbox, nothing required, just change the width of the container and you´re done. Especially fun if you intend to do such a thing at runtime :^)

Jump to:
Active Users
There are 2 visitors browsing this topic (0 users and 2 guests)