The absolute need for GUI system/plugin

Post reply
0 favourites
From the Asset Store
I18N - Translation plugin
$7.99 USD
The I18N (Translation) is a Construct plugin created to translate text in game.
ForConstruct's avatar
ForConstruct

  • I kinda agree with you, but building UI widgets in webgl is not trivial, that would be a huge undertaking. plus why rebuild all those widgets when you kinda already have them in html and css, it seems like there needs to be a better way to incorporate html and css with the canvas.

  • It comes down to what you believe Construct to be. It's marketed as a game engine, but I wholeheartedly believe that it's a web engine that's been focused on games.

    By no means should Construct become a "website builder", a handful of users often try and make websites and that is a fundamentally bad idea (however please show your support for better customisation of export HTML if this interests you).

    Interactive web experiences are the future, and with the entry point to standard web development getting lower every year, being able to make advanced experiences that go beyond the norm will be the must have thing for businesses to stand out.

    This website (http://www.rleonardi.com/interactive-resume/) must be 10 years old at this point, and it is repeatedly referenced as a highly creative web page. To recreate this in Construct would be laughably trivial.

    ...Wow, this went off on a wild tangent...

    To bring it back to reality, please let us have good support for making something as simple as a sta table or leaderboard in our games.

  • I'm all for additional CSS support.

    A <span>/<div> text object and class tag support would be great.

  • i think the issue with those native dom elements would be the positioning? how do you position them? drag and drop? and use absolute position? that would be very hacky and depends on the ratio of the consumers windows.. relative positioning? you lose the ability to position the ui elements in the game window, and what you see might not be what you get in the end.

  • The current positioning for form elements works accurately as far as I've seen. Construct overwrites any positioning done in CSS, and event based positioning with those objects remain accurate as well. I believe Z order is the biggest obstacle.

  • If we were to move away from direct integration the DOM, Construct has some pretty powerful layout tools.

    You can use the anchor and pin behaviours to simulate percentage based layouts; hell you can even recreate media queries with layout expressions.

    Thinking about it from a building block perspective, I guess some kind of grid object so you can assign objects/data to cells? It's hard for me to scope it without simply reciting the CSS grid spec - named areas, flow direction, gutter and track control.

  • Data structures is another issue.

    For example: try making a highscore list with badges, times, highscores, names, etc, and then sort it by something other than high score.

    You can't do it unless you store it in instance variables. Array's, and dictionaries are pretty much useless, and I don't even wanna dare try to try to figure it out in Json.

  • It's easy to sit back and say "they should just do XYZ!" but I think this would really be a huge project with significant opportunity cost (displacing multiple other major features)

    Ashley You mention opportunity cost and the small size of C3's team a lot. Have you considered expanding your team?

  • There are already several options for building GUI, including using sprites/9-patches/etc on a GUI layer, using HTML in an i-frame object, or using the new JavaScript feature.

    We have to understand that GUI limitations is not an extra feature that is missing from Construct. 1/2 of all games are heavy GUI-based (even the casual games nowadays have strong GUI mechanics). We have never asked for sophisticated and specific inventory systems or GUI systems.

    From what we are asking, if we had 1% we would already be glad. A layout panel/object like "Valeryppoff" but more stable would be a SUPERB addition to this engine. Just a layout mechanism for placing different elements... nothing else. You can even check "Valeryppoff" plug-in source code to get some ideas on how you could implement it and improve it.

    As for i-frame, HTML and Java-script lets see what we have here:

    1) i-frame is for displaying HTML sources, inside your window. It was never created to solve problems like GUI or even for different components even on web-pages.

    2) HTML and construct events system could only communicate through Java-script with a messy way (half things implemented on Java-script code lines, some HTML files loaded, CSS files to customize HTML files and even systems staring at them like a monkey hit from drugs.

    3) Java-script is a huge issue for Construct. We haven't seen anyone creating anything special for the time being with Java-script. The lack of in-depth documentation + the lack of real beginner tutorials results in a huge feature that is yet to be discovered. Even the guys who used to create plug-ins for construct (and effects) created nothing for. We have see 10-15 plugins and that's all for the add-on community.

    I am very happy to see that you are releasing updates regularly but you have to stay focused on which mindset you wish to follow. I am pretty sure that "Construct" could be used for creating better GUI games and apps. Opening the way for rapid-app development would widen your market spectrum. Even the name doesn't suggest and game development (its construct, which is so generic that could mean anything regarding development).

  • My issue with the dom, and html elements is that they are always on top, and not rendered at the same time.

    We need a webgl equivalent.

    This is inconceivable - form controls are actually incredibly sophisticated and have many deep integrations with the browser and OS (e.g. IME inputs for non-English languages). Rebuilding the form controls themselves in WebGL amounts to writing a significant portion of a browser engine. There's no way that's a feasible approach.

    You mention opportunity cost and the small size of C3's team a lot. Have you considered expanding your team?

    We already did. Moving to the subscription model for C3 allowed us to sustainably expand from just one developer (it was only ever me working on C2) to three, and that's helped us get way more done. Right now we don't have the resources to go further. I think "just hire more people!" is just another case of the "they should just do XYZ!" problem I mentioned in the first place.

    Just a layout mechanism for placing different elements... nothing else.

    Well, that's pretty much what the iframe object can already do, but securely by default. Is there any particular reason that doesn't do what you need?

    3) Java-script is a huge issue for Construct. We haven't seen anyone creating anything special for the time being with Java-script.

    Construct 3 was released in 2017, two years ago, and we only just announced the widespread availability of the JavaScript coding feature 3 weeks ago. The only reason nobody's created much with it yet is because it's still very much a new feature that was only just released! It may well be a good avenue for implementing better GUIs and I think that should be explored - but it's too soon to draw conclusions already.

  • Well, that's pretty much what the iframe object can already do, but securely by default. Is there any particular reason that doesn't do what you need?

    But isn´t iframe a weird approach for this? How would you create something like this?

    [/img]

    You would make an own html/css/js website, with the functionality you need, load it into your game via iframe, then write some javascript to shovel data back and forth between your game and iframe? Sure it´s possible but... rather overcomplicated?

    Java-script is a huge issue for Construct. We haven't seen anyone creating anything special for the time being with Java-script.

    What would you consider something special? I´ve tinkered around with implementing tensorflow (with minor success because that´s complicated :V) and also I´ve implemented firebase authentication and firestore with it.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Well, that's pretty much what the iframe object can already do, but securely by default. Is there any particular reason that doesn't do what you need?

    Lots.

    One of the reasons I've been promoting the HTMLElement plugin is because it allows users to click on various HTML elements and pass those clicks to Construct functions. THAT alone is a HUGE step above a simple Iframe. HTML is a coding language in it's own right. It took me 2 days to get the code in Construct to work and display 2 layouts, make Ajax requests, parse Json results, etc. It took me over a week just to get the HTML for ONE GUI element working well enough that I was satisfied and, as you saw in the link above, I had to create that on codepen.io. Customization requires extensive knowledge of CSS and JS and even CSS is becoming a massive nightmare trying to keep up with all the browser specifics. If I want to display HTML, sure I'll use an Iframe. If I want to create a GUI, the Iframe is damn near useless.

    I have mentioned that I still program in an ancient language called Pascal. Delphi is the IDE I use to develop in. Delphi is called a RAD (Rapid Application Development) platform because you can quickly build an app with simple controls. I have literally 1,000 elements that I can drop on a form, everything from visible buttons and scroll boxes to encryption methods and pie charts. The publisher of Delphi only created a handful of these. The vast majority were created by the community. The reason there are so many of these plugin modules is because they too are created in the Delphi environment. Once you learn how to code in Delphi, you can create these plugins.

    I know how to code in Construct but I can't write a plugin. I took a brief look at how to write plugins for Construct and threw my hands up in disgust. Even a basic 'hello world' plugin was going to take a huge amount of effort just to learn JS beyond the basics.

    Delphi and Construct have one thing in common that attracts me to both. Rapid development. I didn't have to learn the intricacies of any language to begin building with Construct. I only had to rethink some syntax.

    My suggestion is something I understand you've already considered. Make creating plugins easy. Make it so that if I have a knowledge of how to use Construct that I can create my own. You give me that power without having to spend months learning JS and OOP and callbacks and not only will you see me creating GUI elements, you'll likely see the plugin collection expand massively.

    YOU do not have to reinvent the wheel here Ashley You only need to give your Construct users the ability to create their own wheels with a limited amount of facedesking and I'm fairly certain that the work that's being suggested here will be handled by your community.

    Here's the proof of the concept.

    wiki.delphi-jedi.org/wiki/JVCL_Component_Overview

    They currently have over 600 'components' for Delphi in their open source library. All of them created by the Delphi community.

  • [/img]

    You would make an own html/css/js website, with the functionality you need, load it into your game via iframe, then write some javascript to shovel data back and forth between your game and iframe? Sure it´s possible but... rather overcomplicated?

    In theory, I could possibly build this in Construct. The effort it would take would be... well I don't want to think about it. The easiest way would be to pass the data off to a website, have PHP build the HTML and then pass it back to the client via an Ajax request.

    In Delphi, which I mentioned above, assuming I had the data and images, 30 mins to an hour.

  • Just as you would expect a rapid development engine to have a good gui system, you would expect an engine geared at non coders to not have to code.

    Nobody wants an html element floating over their content, and nobody wants to dig through the web to style it since there no documentation on the vast majority of possible css functions.

    Did I mention the non coder thing?

    I would rather try to hack something together from the mismash of parts than have to deal with a box with a z I can't control, and a refresh rate that makes it look like you are using Windows Xp.

    Edit:

    If you need to hand that off to a third party then fine.

    Offer a subscription for an good implementation.

    Do a GUI Jam, get creative.

  • But isn´t iframe a weird approach for this? How would you create something like this?

    [/img]

    Well, I was thinking you'd generate a string of HTML representing that layout, and set that in the iframe. I'm not sure why you were talking about making a whole website.

    Inevitably with either an iframe or a HTML element you will need JavaScript to be able to link events to DOM elements. Given your example, presumably you'd want some kind of capability like attaching a click event to an <a> element inside a <div> representing the third column of the fourth row, and have an event that triggers from that. It's not clear to me how that could be solved in events alone - you could use <a onclick="...">Link</a>, but what would you put in the onclick? And by that point you're writing JavaScript anyway. This makes me think the JavaScript feature is probably a more appropriate place to address this. You can use the standard DOM APIs to find elements, use elem.addEventListener("click", callback), use the callback to call event functions, and so on.

Post reply
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)