Sign in to follow this  

Preparing for a 'XBox one' code stream

This topic is 487 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi all,

I was just thinking, since the Xbox one is 'windows based' and can also 'run' direct3d11, what would it take to be prepared for delivering your game/ engine as an Xbox one game?

 

What I mean is;

- say that you're in the situation where you're starting a game/ engine from scratch, using d3d11, what things could you do to be able to 'deliver' a Xbox one built when you're done with your game?

 

This way you can prevent having lots of changes to do afterwards.

Thinks I'm thinking about:

 

- what libraries/ API's are/ are not supported on Xbox one?

- will all Windows SDK classes, libs, headers work?

- how about audio, FMOD always seemed platform independent, is this also the case for the Xbox one?

- input: you could have 'PC input' using mouse and keyboard and also support gamepads using the XInput library?

- IO: will normal fstreams, fopen etc. work?

- what else?

 

I know the above probably sounds 'too easy', but maybe it is, depending on the answers :)

Edited by cozzie

Share this post


Link to post
Share on other sites

thanks, so basically what you're saying is:

- build modular, try to make as much non-rendering components 'exchangable', so when you get to the point you have the NDA aan dev kit, it should be relatively easy to adapt/replace parts of the codebase

 

Any other advice of libraries, API´s, approaches etc. to use or to avoid? (which are known as 'not usable'/ giving issues on XBox one)

Share this post


Link to post
Share on other sites

Assuming that NDA means "don't tell anything to anyone", I think the best course of action is to ask about platform portability with the owner of the dev kit. You will probably have at least to sign an NDA I guess, but at least you can make an informed decision based on facts.

Share this post


Link to post
Share on other sites
I find it awkward that supported API's, libraries etc. are part of the NDA. This would mean studio's always have to get the Microsoft dev ID, NDA etc. Before they even start developing.

Share this post


Link to post
Share on other sites

It's not that bad. Most of your key dependencies are either standard/cross-platform (in which case, no problem) or obviously not cross-platform (in which case, you probably know you need to wrap this for now).

 

If you're not sure about a dependency's availability on Xbox One, read its docs or speak to their sales people. FMOD was an example given above where that information is in the public domain. I don't know of any centralised list of authorised or unauthorised libraries for each platform.

 

There are some strict platform specific things, but mostly you don't need to worry about them. Once you've written code for one gamepad, you see how to port that to another platform in a day. (For example.)

Share this post


Link to post
Share on other sites

Thanks, so basically the following guidelines would work as a starting point:

 

- staying with the Windows SDK (8.1 and eventually maybe 10) for 'common' things, like IO, string handling, vectors etc.

- rendering using direct3d11 (and eventually 12)

- FMOD for audio (just checked on the website)

- XInput for game pad input, besides the regular input path for PC (mouse/keyboard)

 

With this keeping in mind that when the moment comes, it helps if the codebase is built up 'modular'.

That way specific changes like d3d 11.1 or other things can be changed relatively easy.

 

Would it be an idea to mention other libraries/ tools which are known as supported or not supported/ compatible with Xbox one development?

Ofcourse only for public knowledge/ non NDA bound information.

 

That way others could benefit from this topic if they consider going this path (sounds like the goal of the GD forum :cool:)

Share this post


Link to post
Share on other sites

You wouldn't use the Windows SDK for string handling or vectors - that's just standard C++ stuff. Same for most I/O, although the C++ standard stuff might not be as effective as per-platform specifics. Not something you need to worry about to begin with however.

 

Everything else sounds reasonable.

 

I can't comment on libraries or tools as I don't know and it's not been an issue. It's not that there's an NDA forbidding us from saying which ones work (at least I never saw such an NDA), more that it just doesn't come up. If it's portable code, it will probably work on consoles. If it uses console-specific APIs, it'll be limited in terms of who can distribute it to whom (as Hodgman said about FMOD) but that's not going to be a factor in your day to day work.

Share this post


Link to post
Share on other sites

You can use the Windows 10 SDK to make UWP apps, which work across PC/Xbox, but as an "app", not a native game. That's probably closer to XNA / XBLIG on the Xbox 360.

 

The Xbox uses Direct3D11.x and Direct3D12.x, so you'd have to carry out some small amount of porting still.

 

If you mean to take the 'I don't have an AAA publisher' route, you have only two paths to get software running on other people's XBox Ones -- you have the open "UWP Apps on Xbox One" program, and you have the ID@Xbox program.

 

Ultimately, the direction things are going in is that Xbox will become, more or less, just another Windows form-factor. Still, though, the two programs I mentioned are different, and have different intentions behind them.

 

Currently, the UWP on XBox program that's completely open to anyone is for Apps, not games -- this is a policy decision, not a technical one. As a developer you can write a game using the tools made available, and you can deploy and test on your own Xbox. You cannot, however, put that same application on the Store where other people can buy it. This could change, but its not how it is today. Furthermore, the apps you create using these tools don't have full access to the hardware (All 'apps' on Xbox work this way, e.g. Netflix, etc) -- You're limited to 1GB of RAM (and you have to be able to enter suspensions using only 128MB quickly), your app shares 2-4 CPU cores with the OS and other apps, you have the vanilla DirectX 11 API, but only at feature-level 10_0 (e.g. no async), and you get only 45% of the GPU when your app is in the foreground.

 

For games, the ID@Xbox program is what you want, but its not open to everyone. If approved, you get the same level of access to the hardware and to XBox Live that AAA games get. 

 

 

As far as setting yourself up for an easy transition, you've gotten good advice. Basically, create a Windows 10 UWP game, and stick to the new APIs as much as you're able to (not the legacy/Win32 ones), assume until further notice that you'll have Vanilla D3D11 (not D3D12 or 11.x), assume that libraries that work under Windows 10 UWP will work under XBox UWP (or that support will be added quickly once things open up).

 

Design-wise, the Xbox is not just a PC with a controller -- Do design for first-class controller input (Look at 7 Days to Die to see what happens when you don't), but that doesn't just mean gameplay input. UI best-practices are completely different for gamepad vs. Keyboard/mouse, and you design just differently for a 40" screen at 6-10 feet than you do a 24" screen at 18-30 inches.

 

Here are some links:

Games and DirectX (UWP), especially the Windows 10 game development guide and Game technologies for UWP apps.

ID@Xbox program page or check out what indies are making.

UWP on XBox One

Share this post


Link to post
Share on other sites
Thanks, this sheds quite some new light on it. To be honest, so far i've never done anything with UWP (and was trying to keep it that way :)) I just use the win 8.1 API because it's the default/ last one with vs2013. And since I'm not targeting dx12 yet that should be fine. Or should I go for the win10 SDK, just to be sure?

Either way I'm not planning to leave win32, because I believe that my targetgroup will decrease rapidly when I go for win10/UWP apps.

Share this post


Link to post
Share on other sites

I would say say that that your perception is off with regard to market share if you're talking about new style apps using the Windows 8.1 SDK -- Windows 8.0/8.1 combined account for only 11% of OS market share according to the Steam hardware survey. Windows 10 currently accounts for 46% (with only 3% of those 32bit) and Windows 7 accounts for 36% (with 20% being 32bit). In other words, you don't gain much by addressable market by setting Windows 8 as your minimum bar -- it seems to me that if you're going to go through the trouble, you'd want to go back to Windows 7, not 8 -- and by not fully embracing Windows 10 UWP over Windows 8, it costs you being able to reach XBox (assuming you were accepted into ID@XBox) which is one hardware configuration with a 20+ million install base.

 

That said, those are the July survey numbers and the Windows free upgrade offer expired at the end of July, which probably prompted a final push for people to upgrade (anecdotally reinforced by the panic on my facebook feed). I'm really interested to see august's survey, I expect a larger than usual decline for both Windows 8 and for windows 7, and I would expect Windows 10 to reach perhaps as high as 60%.

 

After that, Windows 7 will remain a relevant, if ever-shrinking, market for probably another year or two. Windows 8 will be even less relevant than it already is.

Share this post


Link to post
Share on other sites

I think you're absolutely right on the marketshares and thoughts around that.

Maybe I should explain my assumptions:

 

1. Aim at windows 7 and higher, using

- win32 (not UWP apps)

- win 8.1 SDK (not using UWP stuff, just 8.1 because it came as latest with VS2013)

- directx/d3d11

- libraries that are assumed 'compatible' with XBox one for future usage

(accepting that relatively small changes are needed when this moment arrives)

 

2. Aim at windows 10, multiple windows platform, using

- UWP applications

- win10 SDK

- .. etc

 

I choose to follow the path of 1, keeping in mind that my codebase (engine + game) is flexible enough and sort off prepared for future releasing on XBone.

My plan is not to deliver UWP apps in a windows store for mobile phones, mobile devices etc..

Edited by cozzie

Share this post


Link to post
Share on other sites

This topic is 487 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this