The future of Greenworks addon

1 favourites
From the Asset Store
Data+ is the best Data Management solution for Construct 3. It contains 4 Addons (Plugin & Behavior).
  • In theory it would be possible to have some kind of plugin model for WebView2. But I don't think it makes sense to consider that any further until it's clear we can solve the aforementioned issues for Steam.

  • Phew long time no posting in this forum!

    Been awa from Gamedev for a while but recently got back into it. I tried out the Webview/WebWK or whatever on Mac export option and it‘s really beautiful how small the file is. I can literally feel the weight of Nw.js bloat taken off my game. It‘s a huge shame that certain Steam features don‘t work with it. Also, as one of the 0.1 % of developers developing with (and for) a Mac, it would be obviously a shame to lose the export option. However i think in the long run Ashley‘s suggestion is probably the way to go and a pure, lightweight Construct 3 tailored wrapper would be really cool…. Hope that Steam stuff gets solved somehow or maybe there‘s a havk that would work in the meantime i dunno…

    Personally i find this is kind of an essential thing to future-proof Construct so i don‘t mind a Feature slowdown if it benefits this project.

  • Compare that to WebView2 where we already have our own simple, minimal C++ wrapper, which we could directly integrate with the Steamworks API - no middle layers and it wouldn't need updating with every version. IMO that's a much nicer architecture and puts us in full control of the Steam integration.

    I had no idea that Webview2 comes with a C++ wrapper. I'm personally still a bit skeptical since Microsoft decided to pull the plug on UWP in the past but overall I would also be in favor of Webview2. It's still going to be a challenge for devs and their node plugins to be ported over to the C++ wrapper.

    It's common for game engines to at least partially provide access to supporting the SDK/API's below:

    Quick overview:

    (*supported through Node plugin in Construct 2/3)

    In theory it would be possible to have some kind of plugin model for WebView2. But I don't think it makes sense to consider that any further until it's clear we can solve the aforementioned issues for Steam.

    Ashley Could this be simplified by providing an "execute c++" feature similar to the existing "execute JS" action inside the browser plugin?

  • Ashley Could this be simplified by providing an "execute c++" feature similar to the existing "execute JS" action inside the browser plugin?

    No - C++ is a compiled language and also needs to be configured with the necessary SDKs, libraries, etc.

  • > Ashley Could this be simplified by providing an "execute c++" feature similar to the existing "execute JS" action inside the browser plugin?

    No - C++ is a compiled language and also needs to be configured with the necessary SDKs, libraries, etc.

    Oh yeah, it's been a while since I used a language which isn't interpreted.

    Really appreciate that Scirra would be up for adding proper Steamworks support for Webview2 down the line. Sounds like it's up to Microsoft to add something similar to the single process feature in NWjs or Valve to update their overlay.

    To get back to the main topic. I personally don't see a big issue with Greenworks as it stands. Steam is backwards compatible and Valve doesn't force developers to only publish with more recent versions of their SDK. Sure, we won't get support for any new groundbreaking Steamworks features in our games but that should be the only downside for now.

  • Sure, we won't get support for any new groundbreaking Steamworks features in our games but that should be the only downside for now.

    I don't agree. Steamworks SDK is quite extensive and the only feature we have access in Greenworks now is achievements.

    There is Greengrind addon by Mikal which provides access to a few more APIs, but it's still based on outdated official plugin.

    Besides, Greenworks may not work with recent versions of NWjs. Which means that we are forever stuck with old NWjs versions and their bugs.

  • dop2000

    Greengrind addon by Mikal which provides access to a few more APIs, but it's still based on outdated official plugin.

    I don't understand. Do Greenworks and Greengrinds use the same official plugin?

    I love Mikal's Greengrinds, it has many more features. but I don't currently use it because I'm so wary of using non-official plugins.

    I would like to know the architecture more as I have multiple games releasing on Steam soon.

    I'm very excited to hear an interest for more Steam and possibly Epic support!

  • Do Greenworks and Greengrinds use the same official plugin?

    As I understand from Mikal's comments, the addon is based on the same abandoned Greenworks JS library as the official Greenworks plugin.

  • > I don't agree. Steamworks SDK is quite extensive and the only feature we have access in Greenworks now is achievements.

    I forgot to mention that I use the official plugin for importing the modules and access the rest of the features through executing js. The plugins by themselves might not support all features (yet).

    The point was that Greenworks itself (not the plugins) support most Steamworks features up to a certain point and Steam is backwards compatible with those.

    As I understand from Mikal's comments, the addon is based on the same abandoned Greenworks JS library as the official Greenworks plugin.

    The Greenworks node module exists as a "communication layer" between web and native tech. Construct plugins just make it more convenient to use those features.

  • nwjs 71 is still the best one to use unfortunately. The linux export is still broken on all versions after that.

  • Chiming in on the topic of 3rd part developers taking some of that weight:

    I've been contemplating making a brand new Steam NW.js plugin around the new steamworks.js which seems to be much more actively maintained.

    My main issue right now is that I have never used the lib before and I don't have much time to learn it, and don't think I will have much time for it for at least a few months.

    That being said, if someone else has time for it, we've recently set up an Open Collective to crowdfund Free Open Source 3rd party stuff for Construct with some folks in the Construct community.

    I invite any dev that would be up for the challenge to reach out and we can set up a project for them (we've already funded one project and others are on the way)

    opencollective.com/construct-community

    That way everyone could chip in to fund the development of this new plugin and it could resolve that issue, while also avoiding long term issues that come with important addons like these being closed source and abandonned after a few years.

    On an unrelated note, I would also like to add that indeed the lack of File System access for the WebView2 export is sad. I already advocated for Tauri as an alternative to a custom export maintained by Scirra as it would make developing addons for it much easier. Tauri has the same benefits as the Cpp WebView2 export, but also has full File System access (as well as a bunch of NW.js equivalents) it also has cross platform support, and lets you write Rust which means extending the app with native stuff (like steam support and such) much easier for 3rd party devs.

    I understand that using Tauri might also come with a bunch of challenges of its own. Also Tauri suffers from the same issue Ashley's WebView2 wrapper has with Steam overlay.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • On an unrelated note, I would also like to add that indeed the lack of File System access for the WebView2 export is sad.

    FWIW I submitted a WebView2 suggestion to fix that. I think a relatively small addition to WebView2 could potentially allow full file system access without prompts using the existing browser File System Access API from JavaScript.

    It's technically possible that we could hack in unrestricted file system access ourselves via the WebView2 wrapper, but it would probably mean maintaining two entirely separate file system APIs. We've been round this process a few times over the years and it's always a nightmare doing that. It's by far the best solution to get everything to work consistently cross-platform from existing browser JavaScript APIs.

  • FWIW I submitted a WebView2 suggestion to fix that. I think a relatively small addition to WebView2 could potentially allow full file system access without prompts using the existing browser File System Access API from JavaScript.

    Ashley Do you know if there has been any progress with this issue? We were planning to use WebView2+FileSystem in our next project, but that picker dialogue is a deal breaker.

    Also, it will be impossible to set up Steam Cloud sync if players are able to pick the location of save files.

  • > FWIW I submitted a WebView2 suggestion to fix that. I think a relatively small addition to WebView2 could potentially allow full file system access without prompts using the existing browser File System Access API from JavaScript.

    Ashley Do you know if there has been any progress with this issue? We were planning to use WebView2+FileSystem in our next project, but that picker dialogue is a deal breaker.

    Also, it will be impossible to set up Steam Cloud sync if players are able to pick the location of save files.

    Scirra released this addon for webView2, this solves most file system issues. construct.net/en/make-games/addons/1104/file-webview2

  • fedca Oh, I missed that. There've been so many changes lately. Thanks!

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