digitalsoapbox's Forum Posts

    > I would say that getting this community more involved would be a great start. Conducting direct polls and really having a way for supporters to give feedback.

    >

    This has worked against us in the past. The multiplayer feature was massively voted for, but from the data we look at, very few people actually use it. So the hype effect is a big distorting factor in polls. I don't regret it, it was a super interesting project to work on, but it's something to bear in mind, and is the main reason I have avoided polls since then.

    Having said that, we do have a feature-voting system planned anyway but I am going to strongly caveat it with warnings that "votes are not a guarantee of implementation", for exactly the reason we had with multiplayer. Also I can easily imagine things like 3D becoming #1 voted features, and there are a wide range of reasons why we're holding off on that.

    There's a big difference between listening to all of your users - including those who haven't created a finished product in Construct - and those more "serious" (as the OP titled this thread) users who are looking for more quality-of-life features than anything new that will hardly be used by most users like multiplayer or unrealistic requests for 3D in a tool designed specifically for 2D. There's only a handful of more advanced C2 users because (I think) of some of the limitations in the engine that theoretically make features easier to use, but which annoy us more advanced users because we're hitting hard feature walls we can't work around like globally-shared images for tilemaps (if this was optional, it would be a heck of a lot easier to set up dynamically loading tilesheets and tilemaps), forced spritesheeting (which causes issues with seams, no matter how you spin in it, so it'd be nice to turn off for desktop builds where they provide little performance benefit), setting variable values without being forced to select the variable through a dropdown, real If statements (that also don't require using a dropdown for values or objects), etc.

    lamar

    > 1) You feel you were advertised the exporters instead of support of being able to publish to the platforms for Construct 2.

    >

    Just because it was advertised that it would work with the platform

    *(with third party exporters)

    doesn't mean they have to fully 100% support and make sure each platform's exporter works flawlessly with all features provided by Construct.

    In fact Scirra has worked together with many of the wrapper projects to improve the project so Construct games can work even better in the environment but for each console the wrapper devs have to recreate the wheel and that needs a lot of time/skill/money. (Which is why it's good MS is doing their Xbox browser support stuff)

    People didn't dev for Linux and Mac due to lack of support and we'd have a more stagnant dev environment if not for Valve and other companies throwing their weight into OpenGL/Vulkan to destroy the reliance on DirectX, but with consoles instead of just 1 environment (Linux/Unix-likes) you get multiple proprietary environments with not as wide of range of operating system/coding environment support.

    I bet Scirra probably has some interesting stories trying to work with Nintendo if they were not under a NDA.

    ---

    Now I do agree that there was a lack of support in regards to the exporters in terms of documentation that lead to additional confusions, as well as hopes that the parties making the wrappers would improve them more than they were.

    As we see with Construct 3's cloud based service they're obviously getting an automated flow working to compile them for mobile, but I doubt the majority of the technology involved is Scirra proprietary. This means that it's possible for them to document majority of the process and then share with everyone so people can follow the steps and go through the process with their exported project.

    No. If they're advertising platform support, that means the features of those platforms should work. Period.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • What waits? It shouldn't wait at all - the UI should respond immediately.

    It seems to delay right now. This was across multiple PCs I tried it on.

    I can't believe people are still here having this convo after all this time. You can argue and point things out all you want, but it's not going to change anything. JayJay and I have learned from our mistakes and we've moved on. This is not and can not be a serious development tool (C2), and yes it was advertized as such and those of us who are serious devs have paid for the software and may not have gotten what we wanted out of it. That's life.

    But you've blindly put your faith in something that isn't going to change, even after being told time and again that it won't. After being shown that your problems have fallen onto deaf ears. There have been enough signs to show people that if they really want to make a game and port it for that matter, this is not the tool to do it.

    I love the editor to death, but the engine can't be taken seriously. And the bottom line is, it's not your engine to change and they don't have to do it.

    If you don't like what it is, it's time to move along.

    I think many of us have already moved on to using other tools, though we still hold out hope that Scirra will start listening to what's being said to them at some point because we like the idea of how Construct works, and we understand what's possible with that way of working. I know my favorite part is getting to skip a lot of the setting up of functionality, and other than that it just feels like any old game development tool, with (most of) the kind of features I'd expect.

    People are stubborn, and the kind of people who gravitate towards both game development and tools for game development are, I think it's safe to say, never short in the stubbornness department. If Scirra were more straightforward and a bit more honest with both their marketing and themselves in relation to what their tools can actually do, this discussion would never have happened in the first place. But here we are, and even though some of us feel we've been sold a bill of goods that's yet to be delivered, we're still holding out hope. Which I would think is exactly the kind of passionate community any of us posting on the topic would kill to get for our games...if more people could play them.

    digitalsoapbox

    12 years of experience as Dev working in companies in Montreal is not experience enough? I'll be damn then.

    I went through a long process of the whys I would need to change and even if it cost time = money still my best solution in the long run is to switch to another engine. Its simply a matter of risk and reward. Business are also made of that, it seems.

    Then you understand that working as a developer isn't the same as being the person selling games commercially, correct? Or that when a company such as Scirra says their tool can do something, it should be able to do them, and not do them in the most half-assed way possible, if they actually do them in any way that is commercially viable at all?

    > I don't understand why are you guys still talking about the Wii U since :

    > 1- It didn't sell pretty well.

    > 2- Everybody is talking about the Nintendo Switch.

    >

    > So It won't be any surprise if Nintendo decides to drop support of the Wii U next year.

    >

    > Scirra should be focusing on the Switch since most engines are preparing exporters for it.

    >

    Switch has no browser yet (available to the public at least) so we don't know how well it will/wont run.

    However WiiU is still a valid audience, theres a lot of people with WiiU who won't upgrade to Switch any time soon. It's an audience starving for good games

    It's not a valid audience for C2 developers, sadly. Somewhere upthread Ashley mentioned something about it "not supporting WebGL," which, like many statements Scirra makes, is only true in the vaguest sense. As Nintendo typically does, they rolled their own graphics acceleration solution that IS supported in NWF (pretty sure that's public info, so I'm comfortable saying it publicly). Scirra chose not to support it and went with their usual "this is non-standard so we won't support it" line of defense that I've never heard any other engine developer use because no product sticks 100% to the mythical idea of "standards" to succeed. I mean...C2 can't even move a single sprite across the screen smoothly on Wii U. That's not an issue with the console. That's an issue with the underlying engine technology.

    Even if you do a research about x game engine, there's always bumps in the road. 2 years ago for a release in the previous studio I was working for, when Unity switched version to 5, a lot of plugins specially for rendering were broken in the process. There's always issues that you can expect and there's always a way or workarounds. In the case of engines like Unity and Unreal there's a reason why you can obtain source code now.

    But to be honest, personally I don't see the issue, I mean, if Scirra can't offer export to consoles, then you change projects. In the world of indie dev you can't just stay with one product just because you are an artist and can't code. I'm an artist and yet I learned to code. Necessity pushes you to it, that's all. is not the first time a dev quits Scirra to change engine.

    Slain which saw a major release was a C2 project and yet was forced to change to Unity. Engine was simply too limiting.

    I...don't think you understand how game development works as a commercial interest. If you start working on your game in an engine that claims to have X features, and then after working on a project for a year or so it turns out that the claimed features are a total fabrication, you've just cost yourself potentially tens of thousands of dollars in lost time, not to mention sales revenue. You can't always just "change your products." Maybe if you're making games on the side or just for fun you can, sure. But not if you're developing commercial products.

    Agree with —

    But the main thing is...If you want to do Console Games, why do you chose, C2?

    I think Construct is it's own nemesis sometimes. It's so easy to do a basic game that pretty much anyone can do it with a little bit of learning how the event sheet works. The problem with this is, do the games run well? I can only speak from my own experience trying to develop for mobile. At first I thought, bleehhhh performance sucks, but it turned out it's my own code/events that sucked. It was easy to make the game do what I wanted, but it's so hard to make the game do things efficiently.

    I'm sure there is a lot of talent on this forum, and a lot of people have great ideas, but just because you can do things, doesn't mean it will perform great on your desired platform. I've been struggling on and off with my first game for about 2 years. Often I put my main project to the side, and just mess around with C2 and it's capabilities, doing small test projects, just to try out some features/plugins whatever, and learning.

    But one thing I noticed, is that it's much harder than you think, very similar to my previous job developing for consoles. When I worked at DICE, we had a very very limited memory budget for UI, for Battlefield: Bad Company. You have grand ideas of what you wanna do but is set back by technology and what you actually can do....

    Developing for Consoles is more to it than just pushing out a game. Every console has their own QA department making sure things are up to par, and performing well. It's not like Google Play store where any "developer" can upload their clones and shovelware. You have to make sure on screen elements for buttons follow UI guidelines, and is clearly visible for a variety on TV screens and resolutions. Your game is not going to pass, if it's not up to par, at least that's what it's what like working on AAA title a couple of years ago. I don't know if it's a bit different if the console has an indie dev section.... but anywho

    So even if Scirra provided console export, you have a lot more working against you that just creating a game. Even if html5 games were supported better on consoles. It's gonna be pretty hard I guess.

    TLDR:

    When you have a game you want to develop, I think it's better to chose the tool right for the job, than expecting your tool to adopt to your needs. Your best bet is to chose an engine that is specifically designed for your purpose and does it well.

    So back to my first question. If you want to do Console Games, why do you chose, C2/C3?, it's not designed for it. And consoles are generally not designed to run HTML5 games.

    It's like choosing MS paint to do advanced photo editing like what you would do in Photoshop.

    Maybe people chose C2 for console because they claimed Wii U support? And over a year ago, announced XB1 "beta" support, and again recently announced XB1, to the point where it's listed as a supported platform for C3? Wii U export was more or less unworkable and WebGL shader support in Edge (which would have to be depended upon on XB1 export) is almost entirely broken, so claiming "support" for those platforms is misleading at best, purposely vague overstatements that are known by Scirra to be not entirely true at worst. Combine that with those of us who've already had their games approved for release on Wii U & XB1 not being able to do so because of the engine not being able to do anything close to what's event remotely been promised platform-wise, and you're headed pretty deeply into the territory of misleading marketing. Consoles don't need to be designed to run "HTML5 games." Games built in HTML5 need to be using HTML5 tech that can run on consoles - all of which are capable, spec-wise, of doing so. Scirra's complete lack of desire to support consoles in such a way that the HTML5 games it exports run well on consoles is the issue. The "we're sticking to standards" approach falls apart when nobody else, including web browser developers on PC/Mac/Linux/Android/iOS, sticks to standards. It's an oft-repeated excuse used to dismiss criticism of engine performance and feature set. With C3 just being an editor update on top of the same engine, I think the length of this thread points to the more experienced devs trying to make money by releasing games built in C2 being over the excuses.

    You're basically ignoring those facts to tell everyone who wants to port to the platforms that Scirra has claimed are supported by their engine that they're wrong for expecting the tool set they landed upon to do what's advertised, as are those of us who are well aware of what's required to get a game running on multiple platforms or as wide a range of hardware as possible on a single platform like PC. I certainly didn't spend time hacking resolution switching - even if it's just the canvas, it helps with performance on lower-end GPUs, however many times Scirra may say it doesn't matter (they're completely wrong) - into Sombrero for my health. Reading UI guidelines isn't a big deal for me or others who use C2, since we've spent decades having to do exactly that for UI design for other types of software products. Experienced used are what Construct needs to grow beyond a userbase of hobbyists and students - unless, of, those are the target audiences for Construct moving forward, in which case experienced users will move on and the showcase for C3 will end up looking pretty sparse. Well...more sparse.

    I built Sombrero in C2 because I dug the idea of the event sheets. Heck, I switched from Unity to C2 because at the time Unity didn't really have very good 2D tools. The issue isn't the editor/interface/whatever, though don't even get me started on how every concern I had with going to a browser-based IDE has proven true in a single week of stress testing. It's the woefully out of date or missing features of engine itself. Scirra saying "no, we're the best with a super-advanced HTML5 engine" is kind of nonsense after a certain point when the games can barely run on PCs that can handle games made in other engines just fine. Nobody cares - especially those purchasing games - how many times graphics drivers are blamed, when it's not an issue with other engines. I'm pretty over that excuse when I can run advanced games that came out a month ago on a tablet PC like a Surface Pro 4, but just about any complex C2 games is choppy as all hell, and they blame a graphics chip that can run advanced 3D games (even if at lower resolutions). "It's just as fast as native" is such a bold-faced lie that I don't know how Scirra keeps thinking they can get away with claiming it, outside of a mostly inexperienced user base. Being "the best tool for 2D games" involves more than just saying a tagline. It involves results. That we haven't seen.

    A more proactive approach might be to start challenging the consoles to add html5 support.

    That might work, if it's done as a community.

    The HTML5 game developer community doesn't represent enough dollars to invest in html5 as a main development platform for consoles when compared to other game development tools based on more console-friendly tech. Not just C2's community - the entire community developing games on HTML5. Considering the market for console games and what's expected out of a console game, HTML5 as a platform just doesn't have the maturity.

    That said, I'm with NotionGames on this one.

  • It's from the Unity 5.6 Update.

    However like newt said, we already have that in C2.

    We don't though - 9-patches don't rotate properly, and it's impossible to edit their collision polys so they're always square. 9-patches are meant more for GUIs than objects in-game.

  • I am wondering if there's a way to detect the layout edge? Anyone got a quick tip?

    I see we have is on screen and is outside layout, but no touching layout edge? Seems like a really simple feature that should be built in.

    There's the "Bound to Layout" behavior, to keep objects in layout, but agreed having something to reference to see if you're near the edge would be handy.

  • Pretty self-descriptive, but you know, adding rotation properties for individual particles to the particle plugin, rotation speed, angle (and rotation speed) randomisation and all that stuff. This could really improve Construct particles.

    And while we are at it, let's go nuts, why not animated particles too?

    Seconded. Construct particles are pretty behind the times.

  • glerikud

    You just hit at least half of my issues. This is a good list. Usability improvements are needed to better compliment the existing functionality.

  • Tackla

    It would be easier and less events if you just make all the bubbles one object and change the animation to set the color of the bubble if they all have the same behavior.

    Like so:

  • Congrats2u

    1- Put the GUI objects you want to fade on their own layer

    2- In the layer properties, set "Force own texture" to yes for that layer

    3- Set the blend mode for the fade sprites you have at the edge of the screen to Destination Out

    4- Make sure the fade sprites are the top objects on the layer