In Construct 3 r371 we added a new Xbox UWP (WebView2) export option, providing a basic ability to get your game running on Xbox. However it doesn't quite yet cover everything we want. I spent a few weeks doing research and development on this, and in this blog I'll outline the situation: what's supported, what's not, and why.
WebView2 on Xbox
In November Microsoft announced WebView2 support for Xbox. We're big fans of WebView2, as it provides a great way to embed web content in apps with a high-quality browser engine. Obviously Xbox support is important for game creation software like Construct, so I jumped right on to it and started trying it out.
My initial tests show everything working very nicely! Construct is a powerful HTML5 game engine, and modern web technology is extremely fast and capable. Initial impressions were that it worked great. But there's more to do - notably integrating Xbox-specific features.
Construct's 'Cave bridge' demo running on an Xbox One at a silky smooth 60 FPS.Windows & Xbox development
The situation of Windows and Xbox development is complicated. Microsoft have been on a "journey" with its SDKs and app support over the past decade or so, and the result is a bit messy.
There are all sorts of approaches to Windows development, and to keep this blog to a reasonable length, I won't go in to all of them. For our purposes there are two main options:
- Win32: the good old fashioned low-level access to the OS, based on a C-style API, that has been around since at least the 90s. It has broad access to the system, which is problematic for security, but remains that way largely for backwards compatibility reasons.
- UWP: the Universal Windows Platform, introduced with Windows 10. These can also use WinRT (Windows Runtime) which aimed to be a modern replacement for Win32, and are usually distributed as sandboxed "packaged apps" that have more strictly controlled permissions.
These two technologies more or less existed in separate worlds for a long time, so you couldn't use Win32 features in UWP and vice versa. However now the Windows App SDK (formerly "Project Reunion") is now aiming to unify them and allows for interoperability.
It turns out when Microsoft released support for WebView2 on Xbox, it's only for UWP apps, which is significant.
Xbox publishing
For independent developers, there are two public publishing options for Xbox. (There may be other options, but console makers are notoriously secretive, usually requiring an NDA even just to look at documentation.) In summary these are:
- Xbox Creators Program: imposes minimal requirements but your game is published to a separate area of the store.
- ID@Xbox: stricter requirements but allows self-publishing to the main store.
For some reason, there are also technology requirements for each option. These are that it seems (from what I can tell) that the Xbox Creators Program can only use UWP apps. Meanwhile IDpqi@Xbox appears to support both UWP apps, and Win32 with the Microsoft Game Development Kit (GDK). (It's hard to figure these details out from the publicly available information, but this page appears to imply UWP support with ID@Xbox, so I guess it supports both options.)
The GDK GitHub page states:
Using Win32 + GDK is the primary, supported app model to build games for Xbox console, Xbox Game Pass (both Xbox and PC), and Xbox Game Streaming
So it sounds like Win32 + GDK is the option Microsoft recommend. However there's no WebView2 support for Win32 on Xbox - so it seems we can't use that option for Construct. We'd definitely support it if we could use WebView2 there, but as WebView2 is currently only supported in UWP, that's the option we have to use.
The GDK GitHub page also states:
UWP apps and games are community-supported only; partners inside Xbox managed programs (Xbox, Xbox Game Pass, Xbox Game Streaming) should use Microsoft Win32 + GDK.
Community supported
"Community-supported" seems to mean: we won't provide support for it, but we're not taking it away either, but hey, good luck! The UWP libraries they provide for Xbox integration do not appear to have been updated since 2018 (like this one), and it also seems they only build with Visual Studio 2017. So... not ideal. But as we can only use the UWP option, this is our only option for Xbox integration.
I did professional C++ development for several years through the entire lifetime of Construct 2, where the editor was written in C++; prior to that I worked on Construct Classic which was fully written in C++. So I have a decent amount of C++ coding experience - but trying to get the Xbox Live UWP libraries to even compile has been extremely difficult. It was so difficult that for a few weeks, I thought it might be impossible. Just recently I figured out a very specific combination of settings for Visual Studio 2017 that seems to build. So I think we will be able to get it to work. More needs to be done though. We've ported the same wrapper extension system we have for WebView2 on Windows to Xbox in UWP, and we will probably open source whatever we come up with, and the extension system allows other third-party developers to integrate any other code they can get working. So there should be scope for "community support" of this option as Microsoft suggest. It doesn't feel great relying on old software and libraries though - it would be much easier if this was a properly supported and maintained by Microsoft.
Supporting the GDK
As I mentioned we'd be very happy to add Construct support for the Win32 + GDK option that Microsoft recommend. However it doesn't appear to be possible at the moment. For a capable and high-performance HTML5 game engine like Construct, we need a full browser engine to power the games; WebView2 gives us that, but is only available on Xbox in UWP apps. WebView2 is already supported on Windows with Win32. All the pieces of the puzzle are there, but not the Win32/Xbox combination we'd need for GDK support.
The Windows App SDK ("Project Reunion") appears to unify Win32 and UWP, and allows mixing and matching, such as calling Win32 APIs from UWP apps. However it does not appear to cover Xbox. So for our purposes it does not usefully unify anything. We could try hacking around some code and see if it works on Xbox anyway, but I'm dubious about doing that as I don't know if it'll pass console certification, which could mean it's wasted effort.
Here are some ideas we could probably make work if Microsoft supported them:
- Add support for WebView2 on Xbox with Win32. Then we could do a full port of Construct games to Win32 + GDK. We have a specially-designed architecture to integrate web content with a wrapper app, and this would mean we could call the GDK from JavaScript. We're happy to write all the integration ourselves. Win32 WebView2 is already supported on Windows. UWP WebView2 is already supported on Xbox. Maybe it's not too much work to bring it to Win32 Xbox too?
- Properly support UWP games on Xbox. If we had up-to-date, fully supported Xbox libraries that work in UWP apps, it would be much more straightforward to implement Xbox integration.
- Allow mixing and matching technologies. If we could call the GDK functions we need from UWP apps, we could combine UWP WebView2 with Win32 GDK integration. The Windows App SDK appears to provide exactly this technology, but it's not clear if we can use it on Xbox. Alternatively if the UWP WebView2 could be loaded in a Win32 app and communicate with it, we could achieve the same thing.
These are all things that only Microsoft can do. So if you want better Xbox integration, or GDK support, in Construct - please ask Microsoft, as we need them to provide us a workable option.
A call to console makers
Construct is a fully web-based game engine. It's exceptionally fast and highly capable, with good support for integrating HTML, CSS and custom JavaScript or TypeScript code. We regularly have impressive indie titles coming out, with recent or upcoming releases including Mosa Lina, Astral Ascent, Small Saga, Bilkin's Folly, Moonstone Island, Pepper Grinder, Creature Keeper, and many others past, present and future (apologies if I missed out your game!) It's high time consoles had proper support for HTML5 games!
People's assumptions about web technologies are often a decade out of date. Modern JavaScript JIT compilers have incredible performance, benchmarking 5x faster than proprietary languages like GML. Modern WebGL 2 is fast and fully capable of powering indie game titles, and WebGPU support is raising the bar further. Construct has been around for over 10 years and has a maturity that makes it a robust tool for developing impressive indie games. Web technology is used on spaceships. It is now beyond doubt that the technology works well.
Why don't we make separate console ports with different technologies? Firstly, it shouldn't be necessary: web technology already does a great job. Secondly, it's technically infeasible to make high-fidelity ports that support all the HTML, CSS and JavaScript that Construct supports without using a full browser engine. Thirdly, it's an infeasibly costly project for a company our size - we'd probably need a team at least the size of the existing company solely to do a console port, and we are especially averse to the risks of this if it's not even going to be a fully compatible port.
Many modern AAA titles already integrate a browser engine for things like the menu system or UI. It's in demand enough to support companies like Coherent Labs and Ultralight to provide partial browser engines on console for these purposes - but they are not complete enough to support Construct games. So the demand is already there, and supporting a modern browser engine could well prove useful even to non-web games.
The pieces of the puzzle are there. Microsoft have WebView2 supported on Windows with Win32 and Xbox with UWP, and it runs Construct games beautifully. There appears to be an actively maintained WebKit port for PlayStation. But the pieces have not yet been put together to properly support HTML5 games. All we need is a modern browser engine - which includes JIT-compiled JavaScript, GPU-accelerated WebGL or WebGPU, and Web Audio support, and seems to already exist for consoles (WebView2 ticks all those boxes) - and a way to message the app, where we can do all the platform integration ourselves.
Currently all these Construct-powered titles have to go through third-party porting companies to get on to console. This may get the job done, but I've heard it's sometimes slow and can be costly, and the companies can only take on so many jobs. With proper support for browser-based games we could have much better support with high-fidelity ports out of the box. Without it console makers are making life more difficult and costly for indie developers. Construct support for UWP on Xbox should help, but it doesn't cover the GDK, nor other consoles.
I think one of the lessons of the Unity runtime fee debacle is that diversity of game engines and technologies is important. As an industry we shouldn't be putting all our eggs in one basket. Supporting a wider range of engines and technologies increases competition, improves resilience, and provides more options for up-and-coming indie game developers to create the next hit.
So it's high time we had proper console support for HTML5 games! We're so close, with all the technology there in one form or another, but we need the console makers to connect the dots. If you're a Construct user and want to see better console support, please ask Microsoft, Sony and Nintendo - they are the ones who can make this happen, and the more game devs they hear from, the more likely they are to act. And Microsoft, if you're reading this, for now we can probably get by with UWP, but if you give us a viable option for using WebView2 with the GDK on Xbox, we'll be right on it!