Ashley's Forum Posts

  • Please file issues here following all the guidelines, otherwise it is impossible to investigate the problem.

  • The free edition is limited to 2 effects. Your project uses 3: 'Lighten' effects on PRESSSpace, PRESSShift, and ButonFake.

  • Support for specific gamepads is usually determined by whether a driver for the gamepad is installed on the system. Different systems come with drivers for different sets of gamepads preinstalled, so if it doesn't work you might need to find an additional driver.

  • Sorry, I missed this first time around. I've added a AddCommonSceneGraphACEs() method for the SDK in the next release, which is currently what determines scene graph support. Note to support scene graph your plugin must be prepared to have its geometric properties controlled by the runtime when it's attached to a parent, and it must support all the possible transforms like position, size and angle.

  • It must be something listed in the comparison table. I can't tell which without seeing your project.

  • This sounds an awful lot like: "being at the mercy of Microsoft", if any new major issues occur. I know that NWjs and Electron aren't perfect but with those bloated wrappers, developers can at least stay or up/downgrade the version at any time, to workaround any new major issues.

    On the contrary, I'd say NW.js is actually the cause of most such issues, and avoiding using it will avoid these issues. The unmodified browser engines go through very stringent testing, including testing labs, and broad release on the canary, dev and beta channels with active use by global developer and tester audiences, before arriving at stable. NW.js makes various modifications and doesn't go through that testing process (or not as thoroughly), resulting in a regular series of of NW.js-specific issues where things actually work fine in the unmodified browser but are broken in NW.js. Therefore I think using an unmodified browser engine, which is what WebView2 does, should actually be more reliable than NW.js. As I mentioned before, many web exports have been working fine for years, so I think historically the compatibility has proven very good.

    It's also possible to distribute WebView2 with a fixed browser engine, but you lose the size advantage, and have to go back to shipping your own updates. Given how good web compatibility has been historically, I think getting browser engine updates for free is actually a benefit.

    I think Android's webview implementation, is already a prime example of webview not being the best option.

    Android is a whole other operating system so I don't think this has any particular bearing on Windows. I'd add that on the whole I think the Android Webview does work well. People don't tend to write forum posts saying "everything worked fine", so you can get a skewed impression from the forum sometimes.

    WebView2 feels more like an opportunity to improve Construct 3 Desktop to me.

    My goal is to not have to have a Construct 3 Desktop at all, and do everything in the browser. I think we're actually quite close to achieving that, especially since the editor can use file access now.

    (Maybe this is also a great time to look into Electron as another option for desktop distribution but that goes a little off-topic.)

    Electron is architecturally the same as NW.js (Chromium browser engine + Node.js), so I wouldn't expect anything to be materially different with that. The point of this experiment is to remove a significant amount of complexity, maintenance complications, and release management, and go as far as possible to having a minimal lightweight wrapper. Having nobody else involved between us and the WebView actually makes things a lot simpler and, since complexity always adds bugs, more reliable. That's part of what this WebView2 experiment is aimed at. The fact it makes different tradeoffs also makes it a more interesting alternative to NW.js - for example if you really want a tiny file size overhead, Electron is not particularly interesting as it has a similar overhead to NW.js, but WebView2 is as it has a tiny overhead.

  • There are several free edition limits other than the event limit. You can see the comparison table here.

    Subfolders are not allowed in the free edition, so if your project has a subfolder, it exceeds the free edition limits.

  • Could the WebView2 auto-update feature ever break games?

    Just like with publishing HTML5 games, it's possible that browser updates can break projects, but it's generally rare. There are old Construct 2 exports from years ago that still run just fine AFAIK.

    Avast currently recognizes the file as a threat

    That's a concern, but there's probably not much we can do about it - generally all unsigned executables are viewed with suspicion by both the OS and antivirus software. Usually if you are a serious about publishing to Windows you'd digitally sign the app, which increases the level of trust. Without signing trying to evade antivirus is a losing battle - there are probably dozens of security tools out there, and lots of malicious people have spent years trying increasingly clever ways to evade them. The best approach is probably to report false positives to the antivirus vendor. One of the under-appreciated benefits of web publishing is you never have this type of problem!

  • If it works on a different computer, it's probably not related to minification. If it was the minification breaking your project, it would be broken on all computers.

  • We're experimenting with a new way to export to Windows with a lightweight wrapper based on the Microsoft Edge WebView2 control. Similar to Cordova, it's basically a system webview that runs your project, but using a Windows system webview.

    Try it out

    This is now built in to Construct 3 r237+. Choose the "Windows wrapper (WebView2)" export option.

    What is Microsoft Edge WebView2?

    Microsoft Edge WebView2 is a Windows system WebView based on the modern Microsoft Edge, which is now based on the Chromium browser engine (the same one Google Chrome uses). This means native Windows apps can display web content using the WebView2 control. This experimental wrapper just creates a window with a WebView2 in it, and loads your project in it. You can think of it as working similarly to Cordova, which loads your project in a system webview. This allows for very lightweight exports, as your project is basically a standard HTML5 export, with a small wrapper app to load it.

    Features

    This wrapper is built with the philosophy that it should do as little as possible. Ideally WebView2 will do everything. If it cannot, or some feature needs a bit of extra code, then the goal is to use built-in features of Windows instead. This avoids bloating the wrapper app with libraries, frameworks and other code, since much of what Construct games need is already built in to Windows.

    Having said that, the points of interest are:

    • Uses a fully-featured modern Chromium-based browser engine - i.e. it can do everything that also works in Microsoft Edge/Google Chrome
    • Tiny overhead (wrapper app is about 250kb compressed)
    • Should work on Windows 7 and newer (note it's currently only been tested on Windows 10 - we're keen to hear from you how it works with earlier Windows versions)
    • Supports DevTools - like in a browser, press F12 to open them
    • Automatically approves permissions without prompting, e.g. camera
    • Most features that require a user input event in browsers work unrestricted, e.g. starting audio playback immediately (but note requesting fullscreen seems inconsistent - see report)
    • WebView2 automatically updates, so you don't need to distribute updates just to update the browser engine
    • Links open in the default system browser
    • Browser 'Close' action can exit the app
    • Invoking downloads works, since it supports the download UI
    • YouTube videos can play, since it supports full proprietary media codecs the same way Microsoft Edge does

    Distribution

    One caveat is that for it to work the system must have the WebView2 runtime installed, and not all systems have it pre-installed. However this could change as Microsoft's documentation states:

    In the future, the Evergreen WebView2 Runtime plans to ship with future releases of Windows.

    So in future it may be reliably built-in to Windows. In the mean time the wrapper app is capable of identifying if the WebView2 runtime is not installed, downloading the WebView2 runtime installer, running it, and then continuing to execute the app. So assuming the user is online and has permission to run the installer, it should be a fairly smooth and reliable way to automatically self-install the runtime. This only needs to be done once per system, and then it's available to all apps and auto-updates itself.

    Comparison to NW.js

    NW.js differs in a few key ways. Overall it can be characterised as a more heavyweight but also more feature-complete export option for Windows (at this time, anyway). Here are some of the key differences:

    • With NW.js, you distribute a complete copy of the Chromium browser engine and the Node.js runtime, with your project. The WebView2 wrapper does not include either, relying on the system webview (and if necessary installing it for the user on startup). This makes the exported file size far smaller - an empty win64 NW.js export is around 80-90mb compressed, whereas WebView2 is about 250kb compressed.
    • WebView2 auto-updates. With NW.js the app never updates the browser engine, unless you re-export with an updated version and publish that.
    • NW.js includes Node.js, a JavaScript framework that provides lots of features not normally available in browsers. Currently the NW.js plugin relies on this, and so none of the NW.js plugin features will work in WebView2. However many now have web platform equivalents, e.g. accessing clipboard and files, so it could conceivably be ported to both browsers and WebView2, even without Node.js.
    • For similar reasons, Steam integration with Greenworks is not supported in WebView2.
    • WebView2 probably uses less memory, especially when using multiple apps, since they share a common browser engine instead of each using their own unique copy of a browser engine.

    Future work

    The provided download is not yet production-ready - there are several more key details to sort out before then, such as providing a configuration file. If this experiment proves successful, there are several options we could explore:

    • Polish: finish some remaining features like a configuration file similar to NW.js's package.json; identify bugs and missing features and resolve them
    • Support for Windows 32-bit and Windows ARM64
    • Integrate with Construct 3 so you can directly export to WebView2 from the editor, similar to NW.js
    • Supporting things like file system access in WebView2, perhaps with some new plugins
    • Potential Steam integration with the official Steamworks SDK
    • Potential development of a macOS equivalent wrapper, since macOS has a built-in system webview (WKWebView)

    Please note as highlighted above, we cannot guarantee any of this will happen at this stage. This is just illustrating what ought to be possible.

    Feedback

    We're keen to hear your feedback on this. Try out the download above and see if it works for your project. Here are some questions we'd be interested to hear your answers to:

    • Does it work well?
    • Are there any bugs or important missing features?
    • Does it work on Windows 7 and Windows 8?
    • Would you consider exporting real projects with this? What kinds of situations would you use it for?
    • Would you consider using this instead of NW.js? If not why not?
    • Do you think this should be something we focus on?

    Let us know your thoughts by replying to this thread! We won't accept bugs for this on the main issue tracker yet as it's still experimental - just let us know about any issues here (but as always if you can provide the same information as the bug report guidelines, we'll be much more likely to be able to help). But please do share your thoughts and feedback!

  • As far as I'm aware, all official features work with all kinds of minification. Problems are normally caused by third-party addons, or your own JavaScript code in your project. If you do not think those are the problem, please file an issue following all the guidelines.

  • It should be much faster for large projects, because it only writes updated files. It's designed for much larger projects, e.g. 100mb+. In that case if you change say a single layout and save, it writes a single updated layout file to the project folder. With a single-file project it would have to write all 100mb of data and then compress it in to a zip.

  • I don't think Google's payment process has anything to do with the scripts type. As I said, these questions are best addressed to Google, it's their system.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • That dropdown is to select the minimum supported version. Typically you want that to be as old a version as possible to support the most devices possible.

  • See the blog post Sunsetting Construct 2 where the quote dop2000 mentioned is from. You'll be able to import C2 projects indefinitely, providing they are compatible (i.e. you don't use third-party addons that are only available in C2).