Xbox One HTML5 Game Dev

[stay]

I've been having some fun playing around with Xbox One HTML5 game development the last few days.  Is anyone else doing this?

I thought I'd share what I've experienced so far.

* Setting up my retail xbox as a dev kit was not too bad.  Following the online docs rather than the on-xbox prompts worked better.  I already had a windows developer account.

* I've signed up for the Xbox Creators Program, but that hasn't mattered so far - I think it'll only matter if (A) I want to access more xbox-specific APIs, and (B) if I want to release a game in the Xbox store.

* Making a universal windows app out of an existing HTML5 project was OK - The way I like to arrange things means I have to wrestle with VS2017 a bit to keep it from thinking it is in charge of my project from now on, but actually getting the game running is straightforward.  I found this to be true with Win8/Win10 html5 development as well.

* With Windows app development these days, HTML5 and Javascript are first-class citizens.  I can do anything I've needed to do, including all the regular HTML5 stuff I'm used to (fancy canvas stuff, gamepadAPI, etc.) as well as system-specific things like user account info.

* After setting up the project, the process of launching on Xbox One was a little fiddly and flaky, but it's working well now.  My game runs, displays everything correctly...

* The development setup is actually pretty slick.  You can point a browser at your newly enabled dev kit and get performance charts, memory usage, screen captures, etc.  (It's a little inconsistent and not always functional, but when it works, it's neat).

* I followed some documented instructions for turning off (in code) overscan and scaling, which was not as easy as expected (some API object names have different upper/lower case than documented), and I can run at 1920x1080.

* I'm running at 60fps normally, though I found some cpu-intensive calculations slowed the system down to 10fps at one point.  Everything looks smooth, though I'm suspicious of a tiny little hitch in one evaluation I did that seemed like it might be a regular garbage collection issue I used to see in some other Xbox-related work I did a while back.

* I'm doing all this work in a custom engine of mine, and most of my engine is working great on the Xbox, including a ton of custom canvas stuff, audio, gamepadAPI, some server interaction with POST calls, and pretty much everything I expected to work.  It's very much like an Edge-hosted web page, with some extra APIs.

I'd love to compare notes with anyone else doing this!

Lots more info on various pages connected to this page: https://docs.microsoft.com/en-us/windows/uwp/xbox-apps/getting-started

[bruno_]

Thanks for sharing.

[jedimasta]

Hi Stay,

I'm about to jump into this, more or less headfirst, and I'm hoping I can pick your brain as I move forward. Thus far, I've created a basic browser driven card game. My first iteration was for a physical, kiosk style execution, but I decided to try and take it up a notch by giving players control using their smart phones as an interface, while having a larger "main stage" screen up on a TV (ever played the JackBox games? Like that.). Combining the EaselJS APIs, NodeJS, sockets and TweenJS, I've got a decently workable game. When I try to load it up in Edge on the Xbox One things start to fall apart. There's an immediate and obvious lag whose cause I haven't nailed down. Either the combined assets are just too heavy, even on local network, or there's a communication breakdown between my node server and the Xbox to the point that it's just unplayable.

When I first started reading about UWP, I thought perhaps I could take advantage of the console's native APIs to get things running more smoothly, so I've got VS2015 installed and ready to go, but haven't quite started down that road yet. I'm reading through the MS docs now, but can you give any other guidance to getting started, knowing that I've already got a browser-based app functioning, is it a pain to import and convert all the work I've already done? Are there any specific APIs you've learned to avoid?

[stay]

Hi jedimasta,

Cool.  I'm happy to try to answer any questions I can!  I'm just going to spew some things that might be relevant.  If you need more details in an area, let me know.

Answering the last questions first:

APIs to avoid:  Nope, I didn't have any notable trouble with any of the usual browser-oriented APIs.  In the last few days I've really been banging my head against the wall trying to get some Xbox-specific APIs (Xbox Live sign in) working, but that's a whole new layer on top of the core game.  And some Xbox-specific APIs to control scale/overscan are not exactly as documented.

A pain to import and convert the work you've done?  In general, no.  If you do things the way Visual Studio expects, it's really easy to import your whole existing JavaScript setup into VS and just run.  Amazingly easy.

What I mean is this:  Visual Studio thinks it's the boss of your project, so it expects to live in the top folder, and to explicitly know about all your files.  So generally you make a new VS project (JavaScript blank UWP app) at the top, add all your files (which you can do in large groups), and VS thinks it's in charge of them now.  E.g. if you simply delete a file from VS, it deletes it from disk.  So be careful.  If you want, you can add things in a different way where VS is a lot less grabby, but it's more work.  Let me know if you care and I can share details, or write another article or something...  I would expect it to be pretty easy to get your project running inside Visual Studio, even using 3rd party engines or libraries.  Also, I'd personally use VS 2017, though I doubt it'll matter much in this case.

There's a lot to do after that if you want it to behave differently on the console (e.g. gamepad API, display differences, other xbox features...), but that's future stuff.

Edge on the Xbox One.  Hmm...  yeah, if it's having trouble, I'd guess you'll run into the same trouble building in VS, since in my experience it's about the same - when I looked into what environment my game was running in (when I built it as a UWP in VS), it was reporting itself as the Edge browser.  You have to start accessing some other global APIs (like Windows.whatever) to even detect that it's not a browser.  So, that might be bad news.  I think there's a good chance you'll run into the same issues when building an html5 UWP, though I can't say for sure.

Is the game running OK on Edge on a PC, then?

Is the frame rate of the game OK, but network traffic takes several seconds?  I'm afraid I'm only doing a very small amount of network traffic in my game, and it's all outgoing, and not time sensitive.

There are some notes on port ranges that are supported on the Xbox, but I would expect a problem there to reflect as the game not working at *all*, not slowly.

I'm sorry I can't be of more specific help, though I'm happy to keep discussing all this.

On a separate note, I like the sound of your game!  Very cool use of the big screen.

Edit:  Another quick thought I had after skimming your separate post about the networking technology:

The Xbox One does network throttling in some cases.  I don't know what those cases are, but it's something to consider!  Ideally your network code is written to be sending data only when needed, not constantly at full speed!  That's the kind of thing I would expect to cause "chugging" on the Xbox.  Random guess.

[jedimasta]

This is all great information. I really appreciate you laying this out. I'm gonna try and get this all into VS. At the very least, I'll learn a little bit for future projects. I have a feeling that the combination of sockets and nodes and all that is gonna get me all gummed up since I've never used VS before.

Not sure on the framerate. I didn't build in any sort of display for it, so that might be a next step as well. It seems to be fine on the PCs browser, whether it's Edge, Chrome, FF or Safari. I think the safe assumption is that its the Xbox communicating with the socket server, but my understanding is that there are website dedicated to Xbox compatible HTML5 games, multiplayer ones at that, and they don't have any issues. They also don't have much of a community to chat with.

At any rate, the more I read into it, the more I agree that a VS execution of the code might not be the magic bullet I'm looking for.

As paranoid as it sounds, I'm hesitant to share the code. Despite my absolute novice-ness at all this, if there's even a slight chance to market this, especially on the console, I don't want to start giving out all my code. The concept isn't entirely unique, but it's not out there for people to already play either. I repeat though, thanks for taking the time to help.

[jedimasta]

I'm really pleased to report that just basically pointing to my local server in the app manifest and changing a couple of settings has proved to actually BE the magic bullet. My console has to be in dev mode and I have to run the debug on the remote machine, but wow, what a difference in speed!

I'll continue experimenting, but I did have one question you might be able to answer: How do I get rid of the mouse cursor on the screen? I've read that adding

navigator.gamepadInputEmulation = "gamepad";

will do it, but I'm not sure where it's supposed to be added and if it has dependencies. Any thoughts?

[stay]

Good to hear!  Also note that having a debugger attached at all will have a surprising impact on frame rate on the Xbox One as well.  If you ever worry about measuring frame rate, definitely test without the debugger attached.

For mouse cursor stuff:

navigator.gamepadInputEmulation = "gamepad";

is correct, and doesn't have any dependencies that I know of.  I just set it directly, just like that, when my project first starts up (in my init code).

(Actually, I set that value to "keyboard" for complicated reasons:  It seems the B button by default suspends the app and goes back to the Xbox One Home screen, which is not what I wanted, but seemed to be committed to by the UWP host before I found out about the press through the gamepad API.  If I set gamepadInputEmulation to "keyboard", then I also get keyboard events on gamepad button presses, which I can preventDefault() on, in order to suppress that. And the gamepadAPI still works in keyboard mode.)

I also turn off scaling and overscan as they propose in the docs ( https://docs.microsoft.com/en-us/windows/uwp/xbox-apps/disable-scaling and https://docs.microsoft.com/en-us/windows/uwp/xbox-apps/turn-off-overscan ) though notice that sometimes the docs don't give you real JavaScript and you have to fix the case.  For instance, that second one is really:

var overscanDisabled = Windows.UI.ViewManagement.ApplicationView.getForCurrentView().setDesiredBoundsMode(Windows.UI.ViewManagement.ApplicationViewBoundsMode.useCoreWindow);

Good luck!

[jedimasta]

19 minutes ago, stay said:

For mouse cursor stuff:

navigator.gamepadInputEmulation = "gamepad";

Perfect, but WHERE does this line go? Does it get placed in the manifest somewhere or in the JS of my actual app? And if the latter, what includes do I need in order for it to makes sense to the app?

[stay]

Oh, my apologies!  It goes in the actual JS code for your client-side app.  Somewhere, anywhere, that gets called once.  I don't know how your project is arranged, so I'm not sure how to recommend anything in particular, but if you started with the standard JavaScript Blank UWP app in Visual Studio, then it could go in main.js or default.js, maybe outside their placeholder code, or inside their app.onactivated function, but anywhere that eventually gets run should work!

And no includes are needed.  "navigator" is a global object and you can set that gamepadInputEmulation property (which is Xbox One specific anyway, I imagine) to whatever you want.

Hopefully I still haven't missed your question.  If you're using something like typescript that cares more about types and declarations, maybe this is trickier, but I'm just writing raw JavaScript and setting the value.

[jedimasta]

Just throwing another log on this fire. I added the lines like you said (cuz I re-read it and you actually said to put it in the app's JS). Additionally, I used npm to get winjs and added that the page's HTML file thusly:

<script src="/node_modules/winjs/js/base.js"></script>
<script src="/node_modules/winjs/js/ui.js"></script>

but when I load up Chrome, I'm getting: Uncaught ReferenceError: Windows is not defined

 

Edit: The error is throw when I tried to add the Overscan variable. The Navigation snippet works just fine.

Another Edit: I changed that line to be 

var overscanDisabled = WinJS.UI.ViewManagement.ApplicationView.getForCurrentView().setDesiredBoundsMode(WinJS.UI.ViewManagement.ApplicationViewBoundsMode.useCoreWindow);

and it gets a bit further. I looked in the base.js and it all calls itself WinJS. Even still, now the error I get is 

Uncaught TypeError: Cannot read property 'ApplicationView' of undefined

[jedimasta]

I should maybe also mention, that as far as VS goes, I'm not developing it there. I have a completely working web app and within VS, I'm pointing the Start Page to my locally hosted URL. Which, I'll grant, may complicate things further, but it was the quickest way to get things rolling.

[stay]

Ah, yeah, that code needs a little more checking.

So, Window.whatever is only available when you're running in a real UWP (Windows or Xbox) App.  So, you just need to check if it exists first.  You only need that code inside a UWP anyway, so, something easy like:

if (Windows)
{
    Windows.UI.ViewManagement.ApplicationView.getForCurrentView() ... etc!
}

You could be more thorough and check that namespace all the way down, like:

if (Windows && Windows.UI && Windows.UI.ViewManagement ... )

But if you've got the Windows global object, you should have the rest, especially in the work you're doing.

So, in a normal browser environment, that Windows global won't exist, and you'll skip that code, which is what you want anyway.  Note that in a UWP, it'll seem a lot like you're in an Edge environment (e.g. same navigator.userAgent value).  So, that check for the Windows object is a good way to find out you're in a Windows/Xbox app environment, in case you want to do something special.

WinJS is cool if you want to mess with traditional Windows application features like menus and whatnot, but for an Xbox game, you don't need to include WinJS in your project.  I got pretty far without adding any extra libraries.  At *some* point you'll theoretically need to enable Xbox Live features (evidently the Creators Program requires at least Sign In support), and that's harder, and requires more Visual Studio project changes.

Pointing the VS start page to your locally hosted url is interesting and cool.  Definitely easier to get started with.  Eventually I expect you'll need to put everything in a Visual Studio project, though maybe that's not true if your ultimate user experience is *all* hosted online?  It's a different approach I haven't messed with.  In any case, I do 95% of my development outside VS as well.  I just use VS to test actual Windows or Xbox functionality.

 

 

[jedimasta]

That's makes sense. So I ditched all the WinJS stuff I was doing and tried what you suggested, but I still keep getting errors in the browser. Same thing too, "Windows is not defined". I tried doing a check like this:

if("Windows" in window){

And the browser does skip over it, but the UWP doesn't see it either. So I tried a "typeof" statement and same thing. The very last thing I tried was

if(window.Windows != undefined){
	Debug.writeln("I found windows");
	var overscanDisabled = Windows.UI.ViewManagement.ApplicationView.getForCurrentView().setDesiredBoundsMode(Windows.UI.ViewManagement.ApplicationViewBoundsMode.useCoreWindow);
}

Which, again, allows the regular old browser to work, but when I test it in VS, I get nothing written to the console (unless, it wouldn't since it's not on the Xbox? I dunno)

I feel like I'm really close and your help has been amazing thus far. Thank you.

[stay]

Hmm...

Working with that last case there, it may be a problem with how you're running from a locally hosted site, rather than including all your code and assets in VS.  If your appxmanifest has a start page that's not like the default, e.g. if it's something like "ms-appx-web", then by default the Windows runtime API isn't available to your (external-to-VS) website.  You have to explicitly enable it, through something like this:

http://developerpublish.com/uwp-tips-tricks-2-how-to-enable-windows-runtime-access-from-javascript-in-the-windows-10-hosted-web-app/

Sorry I didn't think of that earlier.  My project is not like yours - I include my whole game in Visual Studio and use the standard setup.

[jedimasta]

That doesn't seem to work either. Oh well. I'll post over at StackOverflow too, maybe I'll get a hit there.

[jedimasta]

So naturally, I spend more time asking the wrong questions and attempting unrelated answers that I totally gloss over the ACTUAL solution.

The correct way to do this is first:

if(typeof Windows !='undefined'){ blah blah blah}

That way the browser skips right over it and goes along its merry way like before.

The second, and more important step is to actually tell Visual Studio, by way of the appxmanifest, to LOOK FOR Windows Runtime objects, otherwise it's gonna skip over them just like the browser does. Second URI in the attached screen shot did the trick (at least as far as outputting the Debug message to the console, I havent checked on the Xbox yet cuz I'm not home).

 

[hereshoping]

Hey! Wondering if any of the folks on this thread still use this approach for HTML5/JS dev for XBOX. it looks like Visual Studio 2019 has dropped JS UWP support. There seems to be an emphasis on PWA now, but the documentation is a big infinite loop of things you can do, but not how you can do them.

I'm trying to gauge feasibility of rebuilding an old suite of JS based games in more modern JS. It's my ideal since I can build much more rapidly in JS and HTML, than if I had to use something like Construct 3, Godot + GDScript, or to learn C# for Unity ?.

Thanks!

 

 

[stay]

Unfortunately, no, I haven't tried to do any Xbox JS development lately, but I'm very interested in what you discover.  Could you report back?

Building a PWA for Xbox seems promising.  I've read that getting a PWA in the Windows store is not super difficult.  This article https://debuggerdotbreak.judahgabriel.com/2018/04/13/i-built-a-pwa-and-published-it-in-3-app-stores-heres-what-i-learned/ even mentions Xbox in passing.

If I were to dive back into this, I'm sure I would look at PWA first.  The thing I'm most worried about is that PWAs aren't fully embraced yet on some platforms, so how much respect will they get on Xbox?  It would be nice to find out.

-- Steve