Jump to content
  • Advertisement
Sign in to follow this  
cozzie

Preparing for a 'XBox one' code stream

This topic is 703 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
Advertisement

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
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!