Thndr's Forum Posts

    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.

    I am just hoping Scirra does not abandon C2

    You could've said just this.

    Which of course while they have answered individual posts about it, its sunsetting plan could be in a well placed FAQ somewhere as the communication problem isn't them not listening, more of the information about the concerns are not apparent/easily accessible enough.

    I think pretty much everyone knows C2 and C3 are HTML5 based engines so I am not sure even what you are saying?

    You did not answer the question?

    There are many reasons people have said they do not want a browser based engine and #1 is it is browser based and relies on Chrome and Chrome has many issues.

    Why do you want a Browser based subscription engine?

    There are many reasons people do not want a subscription including you do not own the engine and if Scrra goes out of business or stops renewing subscriptions for any reason you will not be able to edit your games.

    Rephrasing questions:

    Are you not worried about bugs that pop up with Chrome and Chrome Updates?

    I am not worried about Chrome issues as they are the same issues you would get with Construct 2 for your exported games. If you're worried you can get the Desktop wrapped version when it's out, or in the meantime download Chrome Portable and use that as an instance. I actually recommend it for testing exports too.

    You could disable auto-updates on Chrome too.

    With Construct 2, Scirra notified us and fixed many issues that did pop up so there is confidence in that happening. Plus if you look at Chrome versioning you will see that the canary and beta builds are far enough ahead of stable that any issues will be known well before they affect the general populous.

    Why do you want an app that is a cloud based program with subscription for it's monetization?

    I can't really say much about the monetization method but I do prefer my own fully featured offline client. But while I do prefer it, other methods may be more feasible for them as a company and it's their job to make sure it inconveniences me as little as possible like any other distribution method/DRM. Chromes Persistent App feature makes the cloud based nature less of an issue on both desktop and android in terms of offline access.

    What if Scirra suddenly just disappears?

    For the Scirra disappearing thing there's 2 scenarios:

    1) Website offline due to outage // User takes computer offline

    How long can they use all features? Is it 30 days like Steam Offline mode?

    2) Scirra stops existing

    In the end if Scirra has to disappear, what is their sunsetting plan? Do they even have one?

    This is something that we should have Ashley answer and have them put into a FAQ since there is much uncertainty over it.

    For the scenario if Scirra exists and your sub ends it's less complicated as you own the code, but due to the model you don't own the right to access the full features of the engine. I have no opinion on that myself as of yet.

    No one is saying Scirra shouldn't produce C3 for people like you but that is a small minority of people and they appear to be moving to a browser subscription format the majority of people that have supported Scirra with our money, making plugins and promoting them in our games do not seem to want.

    So how is it a good business decision for Scirra to ignore what the majority of their base wants to focus on a small group of people like you?

    The problem is in any discussion like this both sides say they're the majority or the target for the software. You're turning it into an Us vs Them discussion and that's not productive at all. What I'm trying to do is to get the points articulated without that sort of divisiveness.

    You have valid complaints and concerns, but your assumed solution to those complaints and concerns are not the cause itself.

    Where did I say anything about HTML5?

    What else do browser based programs run on?

    We all know C2 and C3 are HTML5 based and if someone does not want that format why would they get an HTML5 based engine?

    You are trying to put your words in my mouth and we are NOT asking for special features. We are asking for exporters that were advertised when we bought our licenses and the bugs to be fixed and the features Scirra has been promoting that now are only included in a C3 Browser subscription engine that very few C2 users seem to want.

    Why do you want a Browser based subscription engine?

    Are you a Mac or Unix user?

    I have been following these thread for months now and I have heard from less than a handful of people that want a browser based subscription engine and many many C2 users that do not want that so I would like to know specifically why you want that format and how you think that is a solution for your game design?

    It sounds more like that you have 2 issues

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

    2) You do not like the monetization model (subscription) Construct 3 is going towards.

    I already addressed my opinion on #1 in my prior post.

    For #2 because you're getting the cloud based automated wrapping as part of the sub is still cheaper for many people than the other engines, and it addresses you concerns with Construct 2's process due to the issue with #1 (at least for mobile exports, which is a large demographic)

    Is this correct? You keep repeating Browser Based Sub Model when the browser based part seems like a non-issue from you very own statements, so I hope you can forgive me for trying to clarify the issues rather than relying on the monolith of "HTML5 isn't good enough yet" as the reason to not even use HTML5. I'm not trying to put words in your mouth as I do understand the pains, but wish the core issues can be better communicated.

    Pretty much misses the point completely!

    If Scirra is listening you would have heard most of the C2 users do not want a browser based subscription engine.

    ome of us like that the direction they chose is HTML5.

    "Some don't like a browser based engine" is not a problem on the developer listening, but more of what you the consumer wants and is demanding they go towards. Scirra has made it clear for many many years that HTML5 is the direction they're going.

    From your further complaints you even admit that you don't care what kind of engine it uses, only that you want specific features:

    We paid for a C2 license based on the expectation those exporters worked and they don't and you have been making promises to fix bugs and exporters for how many years now?

    Instead you spend lots of time and get a new team to develop features and fix the bugs and make exporters for a subscription engine that very few C2 users even seem to want.

    Your complaint is really that the options provided did not meet a standard you wish that they would have. This is independent of the engine itself and more about the ecosystem.

    Yes, there is an ecosystem problem with HTML5 games in regards of compatibility/accessibility as it's a new ecosystem compared to Windows/Mac/Linux native libraries that link to already existing solutions/dependencies. Back when Construct 2 was first started it was seen as a fools errand, just like before Valve put into the effort to support Vulkan and Linux making a cross platform game for linux was also a fool's errand.

    (and Linux is a native platform)

    If you look at the state of HTML5 technology now as well as their offer of cloud-packaging C3 apps for mobile export what can be done now it has vastly improved. Games run faster on the same PC using more recent versions of Chrome. I'm on a Phenom II X4 925 which isn't the greatest CPU but I've had little issue outside of browser/driver support, which thanks to Vulkan we have better Open/WebGL support now than ever.

    (kinda like linux!)

    I do agree that with the confusion surrounding the best way to export for a platform and the issues that the Construct 2 side of things should've been a simple process, but I don't agree that Scirra should be ultimately responsible for optimizing every platform wrapper. They should provide a flow that allows a simple export process, even if it involves just shoving an exported zip file into a third party compiler/wrapper program. They seem to have an automated flow setup on their end for C3 projects, so documentation on that could be adequate.

    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.

    he Wii U did have some pretty good HTML5 support at launch so I can see why there was hope it'd be pretty easy to have it work.

    If you want a Native VS HTML5 example of the Wii U the YouTube app was garbage and ran slow, but using the Wii U Browser the website YouTube ran a lot smoother and faster.

    I'm not sure about later on but I do know the Wii U browser didn't see too many updates/optimizations and custom wrappers always seem to end badly

    Native isn't always faster than HTML5, but HTML5 isn't always fully supported or maintained once added.

    Hopefully the Switch will get a good wrapper sometime, but time will tell.

    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.

    o we know if it'll have similar support for features as Edge/using Edge itself?

    Edge is a bit behind even though Microsoft is at least attempting to support HTML5 with updates here and there.

    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.

    've seen HTML5 gotten a lot better and more optimized, but it does have the problem on relying on a notoriously unoptimized rendering platform (a web browser).

    There are some desktop wrappers that work without a lot of the extra browser crap, but they are unintuitive to setup, or have some obscure issues. Thankfully those kinds of issues are getting rarer but they apparently still do happen.

    I've heard fears of "What if my browser updates and breaks something" for the editor in HTML5, but one thing I do recommend for testing things is Chrome Portable but many might not think about this solution right off. I also use different Chrome Portable versions to test my projects as well.

    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.

    While I don't think it's entirely the issue in terms of the 'not listening' issue, I believe there is some of a communication problem in regards to the engine's performance expectations and that there should be more published communication on the subjects for improvements and performance. Not just blog posts stating how good it's running now as many people are not gonna scroll through every blog post to see that kind of information.

    For major projects like trying to push for a console export a status page listing the exporter and it's supported level (unsupported, in-progress, NDA, working) and a link to the project page would work wonders. It seems that from marketing it works great on many export options but they're not all viable for many projects so easy to access Construct relevant feature support lists and performance details would be very beneficial.

    A page with Scirra tested benchmarks for each platform

    (PC/Mac/Linux with PC specs, Android/iOS with model, wrapper vs browser

    ) with a Construct 2/3 version of the exported test file would work wonders in giving people an idea of how relative their current devices are to the test devices. If the benchmark demos even had an option to "submit your results to Scirra!" on it that would help aggregate consumer side data for a wider range of devices than the ones you can afford

    (but I do recommend having an official list of test devices that you can have physically)

    I will say that the debug mode added into Construct 2 years ago was a godsend in providing this kind of data for my projects, but having a standard repo of test projects with their performance ratings would provide a good guide on how fast something should run, and for the more advanced demos how fast the type of game should run (

    since I assume all Construct templates and demos are optimized for best performance )

    Now I understand why if you consider marketing it wouldn't be good to advertise sub-quality numbers, but from a developer point of view you would want all the resources you can get to judge each engine and to omit that can be a disservice to the community (even though the community could make a resource, it'd be more beneficial if there was an official resource.). Plus with HTML5 tech being a lot better now than when you initially started the technical details will be more flattering than years ago as many of your recent blog posts have been showing

  • The public beta will be available to everyone, and we're aiming to have it out by April. We're not charging anyone for earlier access!

    That's fantastic news. How long do you expect the public beta to last?

  • > I do wish Scirra would introduce some sort of pixel-perfect collision or something similar as an optional alternative.

    >

    I don't remember exactly which behaviors use it, but definitely the platform behavior does even better than pixel precision - it goes down to 1/16th of a pixel, IIRC. So it's actually kind of sub-pixel-perfect.

    Well from what I remember and was able to test using grid placement in the platformer template, it still requires a 32x32 player to be either slight smaller than 32x32 for it's collision box to fit in a 32x32 hole or have the hole be slightly bigger. You can adjust the player size to 31.9x31.9 or so to have it smaller but relatively the same size so it can fit in.

    It's just a limitation on how the polygon collision system is designed when focusing on lower resolution projects and it has great benefits for high resolution games where traditional bitmap collision masks would be too cumbersome.

  • I've had collision issues before and even played around with making a custom 8move to fit some needs of mine due more control over it and how it handles pushing it out of the blocking object, but it's more of a hazard of how it actually does collision vs ticks with polygons rather than pixel-perfect collision. I can't say how many times i had to make an object slightly smaller to fit into a gap that in a pixel-perfect environment would fit perfectly (gap of 8 pixels wide, object of 8 pixels wide, polygons of 7.96 or so) or make sure it's sprite stops perfectly against the wall rather than going over the edge slightly.

    Most of the time it's only an issue depending on tickspeed and movespeed of the object it's tracking. There's always room for optimization and isolating edge cases so they don't drag down the system, but it's just a limitation of the engine.

    I do wish Scirra would introduce some sort of pixel-perfect collision or something similar as an optional alternative. The pixel rounding they do in the optional settings for it simulates it visually but the collision box itself is still a polygon.

  • Well with the Phone/Tablet use of the program it's not really much of a focus as it's a consequence of using the HTML5 technology for the basis of the editor's itself. It just goes to show you how flexible web technology is at this point.

    I doubt they spent more time on making sure it works flawlessly on those niche environments VS the rest of the features they have yet to reveal. So far the only real major reveals they had this week were

    1) Sub model

    2) **Big News** It's all HTML5 (So it works on every desktop OS) and works great!

    3) It also works on mobile HTML5 too.

    Now in order for it to be 100% usable they'll have to tweak a few things here and there, but these optimizations will probably enhance desktop use as well (since mobile devices are less powerful). The touch interface these devices needs wouldn't just be a mobile focus and would use what they developed for Win10 touch since that's an actual desktop environment with great touch support (which they already support with their own plugins that we already use for games we make)

    One of the most major things is hidden in #3 where it shows off some upcoming Chrome features that will make making web-apps for Android less of a hassle.

    The features they prioritized to spent more time on (other than making it all HTML5) will be announced in the following weeks

  • Since Construct 3 news has been released there has been some confusion over what exactly it can do or is planned to do.

    While going over the news articles and reading the dev posts you can gather the information needed, it would be best to add bullet points/sections to Construct3.com to list the features already revealed.

    [quote:3vqbstq1]

    • MultiPlatform Editor!

    Using web technologies you can use the editor from your Web Browser* on any platform! Win OSX Linux**, Even Android!

    *Needs Chrome, Firefox support soon

    [link to features needed by a browser]

    **In browser, standalone desktop app planned

    And and so on.

    This way we have a nice official and constantly updated list of what's promised, with a message at the bottom stating

    "More features to be revealed soon, pay attention at [link to Scirra Blog]"

    And list when the beta is set to start so they know how long the news will go on for (Q2, specific month, or day)

    This would cover all of what Scirra has revealed and also inform the users who tend to be quick to the gun in assuming things like a desktop app is not planned, or at the very least provide a quick reference so people don't have to dig through the news posts and releated dev posts for every detail.

  • [quote:24ajvp39]A lot of people seem to be upset that there's the option to run it in the browser or on the mobile. Even if it's not something you're going to make use of, can you not understand that others might see benefits from it and it's a nice to have feature?

    Sounds kind a ironic coming from you — How many times did you shot down a feature request simply because you couldn't see/understand the benefits that it brings? I remember the number quite well. And I too was like "oh gee what problems do you have this time with adding such a small bit".

    For the record - I have nothing against adding new features. I am all in for it. But I'm baffled and borderline insulted to hear you using this argument now. A very valid argument, as I've said. But apparently it sounds fine only when leaving your lips. Not someone elses. Double standards or what?

    The same could be said of your post.

    Tom's message is stating that it seems people are saying they do not like that with the way the engine was developed and -that showing off a neat consequence of that decision and how powerful optimized HTML5 programs can be- is something that was unnecessary. The loudest of users so far since the announcement have complained that Scirra is putting their money where their mouth is in order to accommodate the years of request for multi-platform rather than making native applications for each OS, or they believe that a mobile version they will never use is taking too much time from Scirra to make (which is the opposite case)

    Many people even skipped over that there will be a desktop app so you don't have to always visit a webpage to use it, thinking it will not be supported on the desktop.

    Ultimately Tom at this point isn't talking about a request for a feature that may take tons of work to even get working correctly (Multiplayer came after a very long time), but a consequential feature that they could do due to the engine they used to create the product.

  • WKWebView isn't too bad. At least Chrome and Opera are better browsers overall. Safari itself is a terrible browser and doesn't even do the same things as well as either of those on iOS. I keep having to have customers use Chrome or Firefox on their iPads if they're having issues with Safari only because how the engine itself is handled.

    The only way around WKWebView's restrictions is to make a wrapped application, or wait for Apple to update it once again to include new web technologies.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Scirra threw up a site to announce they're making it and why C2 won't be a 100% main focus so we knew it was coming. With C3 being the same runtime they could easily keep updating C2 with many features as they did (rather than working on 2 engines).

    Like GMS2 and Fusion 3, Scirra is going to be giving news for weeks until the beta, and then until the release later this year. They're doing the same thing the other companies did.

    Give them time to actually execute their marketing plan rather than say it failed when it literally just started.

  • Tom

    Ok so we can run C3 with no browser at all just as a desktop app?

    I ask because now you said its an option which means you don't need Chrome at all. If so you need to clarify that with the community in your main post because thats why there is an uproar.

    There are plans for an offline desktop version, yes.

    Much like how you can export Construct 2 games to the desktop rather than a webpage.

    C3 running in the browser however would be a non-issue about updates because

    1) Any breaking updates will be known months in advanced (on the beta Canary build) and fixed by the time the update goes official with chrome

    2) You can always tell Chrome to never update if you're concerned.

    3) You can always get a portable installation of Chrome just to use C3 in (If they don't have the desktop app out yet)

    4) If by chance (a very very very low chance due to #1) Chrome somehow does release a breaking update that got past Canary and into the official Chrome app, Scirra will update C3 quickly. This is something they have a good track record for in C2 releases.