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 :)

It's hard to answer console questions due to NDA's and such...

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.

FMOD works on the consoles, but you have to contact them to get your hands on the console version (again, NDA)... you can download the UWP version though :)

I would treat all low-level API's, OS calls, XInput, IO, networking, etc, in the same way that you would for any cross-platform game. Keep your implementations segregated and easy to replace with a different implementation if required. Maybe you'll get lucky and be able to use your code verbatim, but don't assume so.

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)

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:)

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