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

  • After working with Construct 3, I realized that there is a huge gap regarding GUI creation. Although there are several plugins/object types like spites, tilemaps, sprite fonts etc, but this engine really lacks any power regarding the creation of a gui. This is a 2D engine and we all know the huge important role of a GUI when it comes in games, especially 2D games.

    My first attempt was to create a small inventory menu. I wanted it to be dynamic (number of slots) and I wanted to have some sprites for each slot in order to create some effects. I got really disappointed. I ended up using spites, grids, buttons, pins, lists, sliders, timeline animations, tweens, canvas and the result was an awful looking inventory menu that was buggy, slow and unresponsive.

    My second attempt was supposed to be much easier. I tried to create a (dynamic size) leaderboard like those we see in Facebook Instant games. Each row would have rank, profile picture, name and score. I Used Valeryppoff layouter plugin (which has many bugs) in order to create some dynamic rows and columns. The result was of course the same. Many bugs, wrong sizes when it comes to labels, buttons, picture and border sizes.

    If there is something that is really needed here, is an official stable plug in like the Valeryppoff layouter. With a good plugin like this, that helps the developer create dynamic grids, it would be possible to implement many ideas (even without really good buttons and other gui-based objects).

    I have checked on Construct 3 ideas and suggestions and I see no-one really posted any feature like this. I was shocked...! I mean.. really? We use an engine that is supposed to create 2d games and no one cares about gui system? Even the basic stuff that this engine provides (like buttons, slider, list, text input) as almost useless and ugly. Some guys are talking about CSS and HTML implementation, but this has nothing to do with Construct 3. If I wanted to create an HTML with CSS for a menu, I would do it. This has to do with the power of Construct. Development team needs to listen to their user base.

    Java-script addition is a very powerful one.... ok... no is anyone here really using it? You need to start a java-script course (and learn many things that are completely irrelevant with the engine) and then try to figure out how to use Java-script for this engine (as the API is a mess). Maybe in the future Java-script will help Construct 3 but for the time being, there is no useful tutorials, no scripts from other users (maybe some functions that would help other users) from "advanced users" who claim that Java-script addition is superb. I have seen no progress in plugin development. If you check add-ons page for Construct 3, it seems like a depricated page that no-one really uses.

    This engine need to implement features that users really use. There are many 2d games that are completely based just on gui elements.

  • This sounds like you tried to create a UI and got frustrated at your own bugs so now you want a UI template? You can probably find some premade files somewhere. I tend to avoid using html elements and use sprites, much easier to handle. Also you can't blame Construct 3 for your own bizarre approach to making an inventory UI. I made an inventory with a background image, a sprite for the slot to display an item, and an array.

  • What you are describing is pretty easy to do, depending on what exactly it needs to do it may take a day or two to complete and test, but it is definitely within Construct's grasp and easy to do.

    What scirra should listen to is making it easy to monetize games. The only ad plugin they have is admob and there is almost no way to make money with html 5 / web games which is absurd ( unless you code your own ).

  • This sounds like you tried to create a UI and got frustrated at your own bugs so now you want a UI template? You can probably find some premade files somewhere. I tend to avoid using html elements and use sprites, much easier to handle. Also you can't blame Construct 3 for your own bizarre approach to making an inventory UI. I made an inventory with a background image, a sprite for the slot to display an item, and an array.

    I don't think that having GUI object types is a Bizarre approach. There is no programming language, scripting language or game engine that doesn't have a panel/grid/layout object type. I am not asking for easy solutions, I am asking for something that is very standard. Having a layout/panel or something similar in order to create dynamic placements is not gimmick, its a standard. This would also give the opportunity to create some mobile apps. I am pretty sure that there are many developers that would like to use the power of construct to create some simple apps. After all, this engine exports in HTML and Javascript which is the "standard" for web apps and web games. Don't forget the hundreds of frameworks that exist out there that use Javascript to create UI. This is not an alien concept especially for an engine that exports and supports HTML and Javascript.

  • This sounds like you tried to create a UI and got frustrated at your own bugs so now you want a UI template? You can probably find some premade files somewhere. I tend to avoid using html elements and use sprites, much easier to handle. Also you can't blame Construct 3 for your own bizarre approach to making an inventory UI. I made an inventory with a background image, a sprite for the slot to display an item, and an array.

    Let's see you create something like this with just sprites...

    objectlistview.sourceforge.net/images/fancy-screenshot.png

    I got a better challenge for your sprites. Create the editor.construct.net using editor.construct.net. Nevermind the underlying code, just duplicate the layout. Hell, I'd applaud you if you could just recreate the properties bar!

    You're going to find out REALLY quick just how difficult that is because of the lack of basic UI elements in construct like list views, and resizable panels.

    Here's the problem as I see it. The team at Scirra have a locked-in mindset that Construct should only create mostly mindless graphic oriented games like platformers. The problem is, Scirra has never deviated from that mindset. Look at how many platformers and similar genre games there are on the market now. Millions. Trying to create a platformer and make it successful in today's market is akin to facedesking. It's painful and you rarely accomplish anything.

    Now look at this game:

    scorzy.github.io/IdleAnt

    It's an old style text based strategy game. It starts out easy but as it progresses, you start to see the challenge. Trying to create a game like that in Construct would be nightmarish. I know, I'm attempting a game in a similar genre. Because of the lack of GUI elements, I'm having to create the entire GUI out of custom HTML and CSS. Let me give you an example:

    codepen.io/Fengist/pen/oOjgBw

    That's a skill tree I'm working on before 'importing' it into C3. And even there, it doesn't work half the way I want. And, I'm having to use plugins because something as simple as an HTML panel doesn't even exist in Construct.

    Construct has the ability to create so much more than just games. It has the power to create full blown web apps. Everything except the user interface that is...

  • Construct has the ability to create so much more than just games. It has the power to create full blown web apps. Everything except the user interface that is...

    Potentially, but the focus is on games. It's game making software.

  • A game engine whose forte is rapid development should have a solid gui system.

    It's not like these things aren't a regular thing in programing:

    en.wikipedia.org/wiki/List_of_platform-independent_GUI_libraries

    Hell half the "Hello World" tutorials depend on them.

  • Potentially, but the focus is on games. It's game making software.

    I´d argue that GUIs are part of games and some games can also be rather GUI heavy. Not every game is your everyday platformer/shmup/flappybird clone #2983481. I agree with Fengist here, great examples.

    So from my side: Yes please, give us a way of layouting. Valerypopoff layouter thingy is ok-ish but I think this could be vastly improved upon by Scirra (considering they aren´t limited in what they can do with their engine)

    As I sort of imagine it: A layouter object that behaves like flexboxes (flex container), with the ability to drag&drop sprites, text objects, etc. into it and have them align like items (flex items) and also the ability to put flexboxes into flexboxes. Of course with actions to add/remove/etc. items at runtime.

    Or in other words just make flexboxes for Construct. This would be very convenient imo!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I have to agree with the OP, karenzos on this. Creating a gui is hard in C3. This is partly because C3 covers both things with keyboards and mice, and things without. A Gui for my android is not going to be the same plugin as one for my PC.

    But I don't want to derail the thread. I just agree with the OP.

    yours

    winkr7

  • One of the problems with designing game-specific GUI features - particularly inventories - is every game does it differently and needs something customised to the particular game. This makes it really hard to design a general-purpose feature that covers it adequately. Even if we tried I am sure we would then be dragged in to a rabbit hole of endless customisation and extra bells and whistles that everyone would want for their game. GUIs are a vast and complex area just by themselves - enough so that there are entire companies out there whose sole product is a GUI library. 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) and risk (what if after all that work it still doesn't do exactly what your game needs?).

    Construct's philosophy has always been to provide the building blocks to make your own games, and not just hand you "cookie cutter" features that are basically the only way you're allowed to do things. For example there isn't a "Turrent Defense Game" object that handles the entire game for you - instead there are a series of individual features (pathfinding, turret behavior, etc) that can be composed together to make a turret defense style game. This is a much more flexible and powerful approach.

    There are already several options for building GUIs, including using sprites/9-patches/etc on a GUI layer, using HTML in an iframe object, or using the new JavaScript feature. If these are inadequate I think the best approach would be to identify the kinds of building blocks necessary to make it easier to design your own GUIs. I do think it would be madness to try and invent custom layout systems in the Construct engine when HTML already has lots of mature and sophisticated options for doing that (e.g. flexbox, grid layout, tables etc). So maybe the focus should be on how to best integrate HTML with games for the purposes of GUI. I have to mention though one of the risks of the "show custom HTML" approaches is that you have to be very careful with handling user input otherwise you create an XSS vulnerability that allows attackers to hijack user's logins, private data etc. from your site/game. This is the main reason we focused on the iframe object for displaying custom HTML, since if you sandbox it it's safe to show untrusted user content in. As ever that shows there are many other aspects to think about and the obvious thing to do isn't always necessarily the best idea.

    There's also the feature suggestion platform where you can post ideas and see if they collect votes, which would indicate broad support amongst users and make it more likely we'd consider it. As far as I can see from a quick look there isn't anything highly voted there that already covers this. However I would emphasise that you need to consider all of the above when posting a suggestion - if you just post "make a GUI feature" that is far too vague and vast in scope to consider.

  • I agree the Gui tools can be improved. I would stay away from a cookie cutter Ui system though. Right now the html Controls exist on top of the canvas where the game is actually eing rendered. Trying to line things up become a real pain when u need it to be percise.

    I am not sure leveraging the html on top of the canvas can solve this issue. Maybe an approach how other game engine handle Ui would be worth Considering.

    It's like op mentioned we also need some type of grid system to layout elements in a predictable way. Like flex box or bootstrap grid system.

  • The List object is one of those building blocks that can really save a ton of time. It can solve the issues of sorting, scrolling, limiting overflow, and many other things.

    But it's a dom element.

  • I think the List object is too generic to be considered a 'building block' like any DOM element, and it lacks customization.

    I think we could have something like a 'grid object'. A object where the user could customize things like number of rows/lines and its respectives width/heigth, and background texture like 9patch. And the user could attach sprites and text/spritefonts objects inside the cells at runtime. And it would handle scrolling, with the option to customize its sensibility and speed.

    I think it would help in 90% of UI complex issues. Would be a powerful building block that could be used in things from simple leaderboard tables to complex inventory systems

  • For years a small core of users have been pushing for greater DOM control via Construct - the web alredy has data presentation languages, they're called HTML and CSS. Where Construct embraces the web in every aspect (from the hosting of the IDE to the literal backbone of the engine) these two aspects remain locked off.

    Deeper integration with this fundamental web technology is my literal dream for Construct. We've got Scripting, last beta we got better support for CSS - I would love for Construct to break free of the canvas and iframe approach and embrace real DOM manipulation.

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

    Keep in mind that many features such as scaling, scrolling, ordering, etc are not trivial things to set up, even for seasoned users.

    Having to set those things up every time is very taxing.

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