Concerns from a "Serious" developer

    It's also a bit ironic that it's not the webgames (with the exception of There is No Game) or mobile games that they're using to advertise Construct but larger "made for desktop" games whos developers have all left because the product didnt support what they needed for those games to be a bigger success. Yet it's the mobile/web games that they seem to be making Construct for and focusing all their efforts?

    Barzoukasj

    You get me wrong. I wish C2 would've been able to export to console and same for C2. I've been asking for this for years. But C3 did not include it.

    I agree with you that devs should 've been asked about their needs.

    Agree with FraktalZero

    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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

    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.

    It's a fair point, but I think it comes back to Construct having a bit of an identity crisis - perhaps partly because of its legacy with Construct Classic. I'm developing purely for Windows desktop, and you'd think it would be simple right? Nope. What is C2 actually good for exporting to? Not desktop, not mobile. Browser games, but who plays those? It's like having a Rolls Royce but only being able to drive it up the drive way. I think what the devs are failing to realize is that people are here because of the workflow, not the tech. People aren't attracted to Construct because it's html 5 based - it's the great workflow.

    I know the difficulties of exporting to consoles. Been in the gaming industry for more than 12 years here in Montreal and for the past 4 years working in local indie companies.

    So I know the struggles from every perspective.

    Now, why I chose C2? Well, after doing so much crunch you end up with little time to develop games on your spare time, so it was the obvious choice at that time. hence is no longer the right option and I'm moving to Unity instead. At some point I was opting for Haxe but at the end I prefer what Unity offers so far.

    People aren't attracted to Construct because it's html 5 based - it's the great workflow.

    I might be in the minority, but I was (and still am) attracted to Construct 2/3 because it is HTML5-based.

    My target audience prefers browser-based interactives (education). I do see the point for those who are trying to make money strictly off of games, however. It is hard enough to make a living off of games, and to choose a tool that restricts you to only a small fraction of your potential market is financial suicide.

    That being said, I would love to see a great 3D game built in Construct 3 that showcases HTML5's capabilities. The key is that enough people would need to play it and become inspired by it to encourage more developers to shift over to the platform so that more great games would be built using the tool. A lot of stars would need to align for this to happen.

    In the end, I love HTML5 because pretty much every kid in school is carrying around a device with a browser, which makes the web such an awesome way to democratize the art form of games. I think Construct 3 has the potential to get there, but am worried about the financial risk to developers.

    signaljacker

    So actually, Scirra would probably do way better by doing an event sheet plugin for other editors, since they can't cater for the other needs by many of the developers here?

    The event sheet is the only reason I chose C2 and still sticking with it. I don't have time, energy, and willpower to learn any coding language. So I kind of have to live with the limited export options in favor doing any game at all... lol.

    > People aren't attracted to Construct because it's html 5 based - it's the great workflow.

    >

    I might be in the minority, but I was (and still am) attracted to Construct 2/3 because it is HTML5-based.

    My target audience prefers browser-based interactives (education). I do see the point for those who are trying to make money strictly off of games, however. It is hard enough to make a living off of games, and to choose a tool that restricts you to only a small fraction of your potential market is financial suicide.

    That being said, I would love to see a great 3D game built in Construct 3 that showcases HTML5's capabilities. The key is that enough people would need to play it and become inspired by it to encourage more developers to shift over to the platform so that more great games would be built using the tool. A lot of stars would need to align for this to happen.

    In the end, I love HTML5 because pretty much every kid in school is carrying around a device with a browser, which makes the web such an awesome way to democratize the art form of games. I think Construct 3 has the potential to get there, but am worried about the financial risk to developers.

    HTML5 is the reason why I'm interested in Construct as well. Especially now when new platforms like Facebook Messenger are starting to embrace HTML5 games. I think this could possible be a new opportunity for smaller casual games almost like app store was a decade ago.

    In an ideal world, Construct would be an IDE for another engine.

    I don't think it's a stretch to say that the majority of Construct developers use the software for it's event sheet system rather than HTML5.

    Scirra is unmatched with regards to visual coding. It baffles me that none of the bigger players haven't produce anything even close to this; even similar tier future products like GMS2 and Fusion 3 are laughably behind Scirra in this regard.

    Construct is miles ahead of the competition with regards to input, but the output simply doesn't scale and despite technologies being cross-device friendly , quickly falls apart in the real world.

    I trust Scirra, you don't make software this good without knowing what you're doing. HTML5 is the future, AWP and instant apps are proof of the ever shifting progress away from native. I'll stick around for this ride, but I'd love Scirra's thoughts on what's been brought up so far.

    signaljacker

    So actually, Scirra would probably do way better by doing an event sheet plugin for other editors, since they can't cater for the other needs by many of the developers here?

    The event sheet is the only reason I chose C2 and still sticking with it. I don't have time, energy, and willpower to learn any coding language. So I kind of have to live with the limited export options in favor doing any game at all... lol.

    They would probably do very well I'm sure, but they've built up a nice empire here and are obviously very ambitious and talented. I would like for them to succeed with their own product, but I also think that to do so listening to the community is very valuable. I'm in the same boat as you, without the time or inclination to properly learn to code. I'm comfortable with the event sheet and would love to continue to use it. I can forgive Construct a lot, even having to jump through the many hoops because of its quirks. But to see the dev team so out of touch with its core community really worries me.

    It's hard to adequately respond to a 6-page forum thread that springs up over the weekend, but I'll do my best. Also these threads often turn in to everyone throwing in their own different concerns and it's pretty exhausting to even try to address everything - often I reply to the OP and then everyone piles in afterwards with "what about X? Y? Z?", and this happens a lot even when I do try to address everything... so anyway, here we go, focused on the OP:

    HTML5 on Wii U: the main problem here is Nintendo's weak support of HTML5. Technically we're under NDA so I don't think I can go in to too much detail on this, but I think by now it's common knowledge that the NWF doesn't support WebGL, and that's really just one of several aspects. It's possible to publish smaller scale games on the Wii U, but larger scale stuff will run in to these limitations. There are similarly-specced mobile devices that can far outperform the Wii U due to having better browser tech. Things like this are really frustrating because they unnecessarily make HTML5 look bad. If Nintendo used modern web support, it'd have been far better. Yes, this is a shortcoming of HTML5 that we get stuck with browser engines like that sometimes. Yes, users don't care whose fault it is and just want it to work. But I honestly think it would have been impossible for us to write a native engine with the size of team we are within the timeframe of the Wii U being replaced by the Switch. In other words, it was that or nothing, really.

    Wider console support: it's an interesting time to complain about console support, because the only reason we don't already have Xbox One publishing (which does use a modern browser engine!) is we've been busy with the C3 launch. See this Microsoft announcement which specifically mentions Construct 2 from early March.

    Wider HTML5 reliance: I would actually credit Scirra's entire success to our reliance on HTML5. Sure, it has some downsides, but no technology is perfect. We've seen other competitors with native tech fade in to irrelevance with limited features and dragged down by difficult bugs and development inefficiencies. I'm actually really glad we went this way. Also HTML5 was laughably bad when we started in 2011 (and some people literally laughed at us for choosing it over Flash). Originally, we never even expected to support mobile at all. Things have come a long way and it's still going strong, so I think HTML5 still has a bright feature.

    I also have to wearily point out again that graphics drivers are a concern everywhere, and we have direct experience of that given we've worked on native tech in CC and the C2 editor. It's actually worse in native than it is in HTML5. It's so bad, it has actually ruined AAA game launches in the past. Most indie game developer's post-mortems I read, when they used native tech, almost always involves some kind of section excoriating the woeful situation with graphics drivers, to the extent they say things like "I wish I just had never even tried to release on Mac because the OpenGL support is so bad". Big companies can usually (even then not always) muscle through it by putting several engineers permanently on the problem, but when you're small, HTML5 probably actually makes this better than it would be otherwise.

    Not listening to customers: this is pretty hard to take, as the original company founder with over 23,000 posts on this forum, as high as a constant 10 posts a day on average in some cases. How many companies can you go on the forum and talk about something directly with the original founder of the company? We try to make ourselves available to customers, and I do my best to read all the posts and feedback on the forum, but it's pretty tough to respond to everything with hundreds of posts a day. I do in fact hear everyone's concerns loud and clear. There's a lot of reasons why we can't always immediately do something, ranging from the technology to overall direction of the company, but I am here, and I do listen, even when that involves quite a lot of criticism. Sometimes even when I explain the case, it doesn't stop the criticism. For example some users hit graphics driver related issues and then say they wished we had native engines; these people would be in for a very nasty surprise if we actually did that! But it's never stopped the criticism, so I think to some extent I've just come to accept that some users are going to be unhappy and won't understand some things we do or the reasons behind it, and that's part of the nature of running a company.

    In an ideal world, Construct would be an IDE for another engine.

    I don't think it's a stretch to say that the majority of Construct developers use the software for it's event sheet system rather than HTML5.

    Scirra is unmatched with regards to visual coding. It baffles me that none of the bigger players haven't produce anything even close to this; even similar tier future products like GMS2 and Fusion 3 are laughably behind Scirra in this regard.

    Construct is miles ahead of the competition with regards to input, but the output simply doesn't scale and despite technologies being cross-device friendly , quickly falls apart in the real world.

    I trust Scirra, you don't make software this good without knowing what you're doing. HTML5 is the future, AWP and instant apps are proof of the ever shifting progress away from native. I'll stick around for this ride, but I'd love Scirra's thoughts on what's been brought up so far.

    I think you put the nail on the head there, or how they say....

    Input - super easy to create games - output, a nightmare sometimes depending on what platform you target. They have nailed the input, so now they need to nail the output, everything in-between, like plugins and behaviors can pretty much be handled by the community until they sort the output out. So they need to focus on the editor capabilities and export options in my opinion, so you don't end up there with a finished game, but nowhere to publish it.

    Put in regards to plugins etc. Community supplies a lot here.

    I like the way BrashMonkey and Photon Cloud does it for example. They provide their own plugin, and they do it well with great support. Pushing different plugin support over to Scirra's table is not the right way to go, then blaming scirra for not listening to customers. Chase down the ad network instead because they probably have way more money time and developer resources to provide plugins than Scirra has.

    As I'm also mostly interested in mobile, I'm very curious about the build service. If it's hassle free working great, it's a big big step for scirra, and the mobile dev crowd here. But monetization plugins for different kind of ad networks and platforms.... meh.... I don't think that's what scirra should focus on right now. It would be better if the ad networks provided their own plugins.... and we still have the option to make our own if we really want to, with SDK's and a bit of know how, willpower, brute force or cash.

    If you need a specific plugin for you project, why not hire a dev to do it? Or get together a couple of people in need of the same plugin and crowd fund it together?

    Here's a non rhetorical question.

    Would an exporter sdk still be doable? This was one of the promises of C2 as part of its "modularity" if they ever finished the html5 framework.

    Ashley

    I think (personally) the point that is making me move from Construct is that I feel that C3 is offering a lot of features that for some people might be gold (like the graphics editor) but personally I would see more of an interaction with software like lets say Aseprite. I know in the past the SDK allowed developers to add new plugins, but personally I think it would've been great to work with some devs to have a few plugins whether they would be free or paid available.

    When C2 came out, I remember it was far from perfect, but kept improving at a steady pace for several features. But C3 should be the continuity of C2 and not a total radical change and almost start from scratch.

    Personally the browser idea is not my cup of tea. And I think a lot agree it would've been better as a stand alone.

    I think another problem is indeed HTML5. Although I agree with you that Native is not always the solution, but HTML5 is a big limitation for consoles. Also dependency on NW was a mess. I remember struggling for months because of the lag on a small demo.

    I was recently using Haxe, and I liked how it was (not that easy but feasible) to do builds in HTML5 and also for Desktop. Couldn't C3 be at least more open for devs so we can actually have more accessibility?

    I would've been totally open to the idea to pay much more for a solution that its more accessible or contain features exclusive for console, etc. HTML5 is great but a bit limiting as well if you are targeting consoles as well?

    Anyhow, one thing that I always loved about Construct is the event system. Its quite elegant and can be easily compared to programming. Using Haxe felt almost like the same. Except Construct in overall is faster to work with. And when you need time to work on projects, its the ideal solution so far.

    But I would say that its still missing those extra features that would make it be amazing.

    Here's a non rhetorical question.

    Would an exporter sdk still be doable? This was one of the promises of C2 as part of its "modularity" if they ever finished the html5 framework.

    I love an update on the state of modularity - I'm taking it as a nice idea, and definitely one that has the userbase backing, but one that Scirra was never quite engaged with due to the underlying architecture change it would present.

    Given that the editor SDK won't be around until after the full C3 launch (September?) I think we can cross off any other SDKs

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