Michael B. McLaughlin

Michael B. McLaughlin mikebmcl

Niner since 2011



  • Building Games for Windows

    @EvoFxStudio: Currently Microsoft has not announced anything about indie development on the Xbox One other than this: http://kotaku.com/microsoft-vows-to-support-indie-developers-on-xbox-one-510129167 . Since that statement comes from Don Mattrick (head of IEB (the division that includes Xbox)), and no one more senior than him has said anything different, there's really no information beyond that. Your statement makes it seem like it's impossible for indie games to exist on the Xbox One, which simply isn't true. There currently is no self publishing story for indies for Xbox One, but indies who have a publisher could target the Xbox One (as long as their publisher is good with it). And who knows what the future holds.

    The Build conferences have always been about Windows (and Windows Phone and Windows Azure) development. Game development is part of this, of course, but game development for Xbox is a separate thing and as Ballmer said in the Day One Keynote, this conference isn't going to be about Xbox (or Office 365 or Skype).

    I too hope that Microsoft will have an indie developer program along the lines of XNA Creators Club/Xbox LIVE Indie Games. I would be amazed if such a program started out anytime earlier than 2014. Why? Because there is only so much time and so many people so they need to prioritize their goals. Launching the system and ensuring that the launch titles are as awesome as possible is undoubtedly the highest priority right now. Once launch begins to wind down (and remember that launch won't happen in parts of Asia until 2014), there should be more resources for adding something like XNA/XBLIG. Remember than XNA/XBLIG didn't launch until a couple of years after the Xbox 360 launched.

    So be patient and remember that there are 70+ million Xbox 360s out there right now. Those systems won't all disappear the day the Xbox One launches and it'll probably be at least 1-2 years before there are more people regularly playing the Xbox One/PS4 generation than there are people regularly playing the Xbox 360/PS3 generation. So develop great games for those millions of people playing their 360s now using XNA Game Studio and hopefully in a year or two Microsoft will have a similar program ready to go for Xbox One, which would mesh quite nicely with when there will likely be enough Xbox One owners to create a good market for indie games. That's just my personal take on it, though.

  • XInput PInvoking your XBox 360 Controller

    DirectSound is only meant for legacy code; modern games should use XAudio2 and/or Microsoft Media Foundation for audio. DirectInput is deprecated and should only be used for legacy joystick and gamepad support (any controller that you can use XInput with you should use XInput, and keyboard and mouse should be used with standard Win32 messages, .NET classes, or Windows Runtime functionality.

    Otherwise, great article and sample!

  • The Windows Runtime Library (WRL)


    My understanding of it is that WRL is a handy way to bring legacy COM libraries forward to be used in Metro style apps without needing to rewrite them completely. It's also a way for people whose companies forbid the use of exceptions (I personally don't know why people do this, but there are places that do it and I'm sure they have their reasons) to write new Metro style libraries and apps without violating their company's internal policies.

    As far as motivations behind COM and the Windows Runtime (and WRL, which is basically a very thin layer on top of WinRT itself), the core purpose is to be able to write some code in whatever language you personally prefer and then let others use it from whatever languages they prefer. I can write a WinRT component in C++, C#, or VB that someone can then use in a Metro style app written in C++, C#, VB, or JavaScript without needing to do anything special. In fact, unless they specifically looked into it, they wouldn't have any idea what language my component was written in. The WinMD metadata file makes it just work (without any interop code) and so now my library is easily available to many more developers than it was before.

    C++ developers should default to using C++/CX to write WinRT components and Metro style apps. The reason for that is that, as you pointed out, WRL (like COM) has a lot of repetition and boilerplate code. But there are those situations where some people will want/need to avoid C++/CX (whether for portability reasons or for exception avoidance or whatever) and in those cases there's WRL.