Friday, September 16, 2011 9:16 PM
I can't help but notice a few contradictions within the "game development story" for Metro style applications.
In the main keynote, it was explicitly pointed out that games are a huge market opportunity for apps - I can't remember the exact number, but they comprise a huge percentage of the apps sold on competing touch platforms (both tablet and phone).
The majority of these applications are not "AAA" games - they're relatively simplistic, easy to pick up and play apps. You could make the argument that processor and graphics capacity restrictions are limiting the depth of the games on competing platforms, but at the same time these devices are being used in mobile scenarios where users typically want quick distractions - games that can be played for a short period of time and can be easily paused or put down until a later time. Look at the top selling apps and you'll get a good idea.
That's fine for an AAA title, but for the majority of smaller applications it's complete overkill. Ignoring portability to other non-Windows devices, it's hard to justify the additional cost of rolling out a full C++ application on DirectX compared to something like C#.
XNA is being dropped, but what is taking it's place? One of the major advantages of WinRT was the fact it could be used on any platform - yet DirectX seems to be dropped in using "legacy APIs" and heavily locked into a single-language environment.
It's a terrible story for rapid game development, for simpler (cost effective) games, and for the few companies that have been investing in the Windows Phone 7 platform. .NET already has COM marshalling, so I still have trouble understanding the C++ entrenchment. It's one thing to say "But the AAA titles built on Unreal Engine all use C++", but the entire market in the middle is being ignored. XNA for the "basement kids" and C++ for the larger teams with an investment in large, existing codebases. Would you make the same arguments for C# development? "Sorry, we're not going to allow web development in .NET because there's a huge existing codebase using ISAPI plugins". It's illogical there, so why is game development any different?
In summary -Are there any plans to extend WinRT over top of DirectX as well, making .NET a first class citizen?
- Changed Type Rob CaplanMicrosoft Employee, Moderator Thursday, October 13, 2011 9:32 PM discussion
Sunday, September 18, 2011 12:26 PM
Objective-C is native code, and that's what almost every game written for iOS is in- or C or C++ themselves. Relatively speaking, managed languages have not made significant inroads into the games market, even in the non-Unreal Engine kind of space. Not to mention the fact that there's frameworks like SlimDX for .NET, or you could just do most of your logic in C# and then interop with C++ for the core rendering needs, nor the fact that you can get plenty of supporting frameworks like OGRE or SFML for C++ if you don't want to have to deal with DirectX itself.
DirectX itself is just not that hard to learn and get going with with some basic tuition, and crossing the language barrier between C# and C++ simply isn't hard enough, considering C#'s poor suitability for the task at hand, to justify expending a lot of money into this. And C# is a very poor choice for games. Game development is different because, fundamentally, there are serious performance issues at hand here, even for pick up and play games, and some other language features of C++ like deterministic destruction are virtually essential for writing high quality rendering code- whether that code renders a simple flipbook animation or Crysis 2.
More than that, you're vastly overstating any rapid game development advantages of C#. Maybe in 1998 when C++'s smart pointer classes hadn't really been invented or tuned yet, and compilers hardly supported half the language features, but anyone with a basic grasp of C++ in Visual Studio 2011 should be able to develop plenty quickly in it.
C# is just not the right language for games, and if you're very desperate, do some interop- it's really not that hard.
Sunday, September 18, 2011 1:41 PM
I'm all together with Shadow Chaser on his comments. AppStore approach has opened a gigantic door to reach the maximum amount of auidance and it's a fact that Games do have a big place in those online stores. What brought success to those platforms, in gaming wise, is the indie developers. Microsoft saw the need for indie approach both in Xbox 360 and Windows Phone 7 thus created a very modern and easy to grasp framework called XNA, with one of the best language called C# (also VB.Net which is another great language). I can't tell how much helpfull this was once we were adopting our games we developed for iOS and Android. We even wrote our framework on top of it to make our porting easier so now we are at a situation where we can nearly port any of our games line by line from one platform to another.
Windows has always been primarily about AAA games so I understand the raw power of C++/DirectX to maximize the performance. With the new Metro UI, the approach is to simplify the UI and adopt Windows to become a 1st class touch friendly OS. This simplification will have the same effect in games as well, there'll be many easy to play games get developed into Windows 8. Yet the opposite, the development gets the different threatment in here where things get harder and locked into one choice. It could be possible that XNA/C# would never get developed at first place and we would had to stick with C++/DirectX ever after but for the needs to have a lower level of entry barrier into game development world, it has been developed. Also, it worked really great if you check XNA games, for example all games in Windows Phone 7 :).
I still hope that this decision is going to be re-evaluated. Yes, we can re-develop our games using C++/DirectX since this is our primary bussiness but it'll be pretty annoying that while we'll be able to run our games on XBox360/Windows Phone 7 with the same code base, we'll be forced to port once again to C++/DirectX to make our game run under Windows 8. We can use the same codes across iPhone, iPad and OSX just to give you another example.
Also one last thing, I don't know if you heard but the recently announced PlayStation Suite SDK choose C# as their language for development, where the devices, including PlayStation Vita to their Android powered phones/tablets, that those games will be run do not have any relation with Microsoft OSs, go figure! :)
Tuesday, September 20, 2011 1:52 AM
considering C#'s poor suitability for the task at hand
I respectfully disagree. While "native" languages such as C++, C, and Objective-C have historically been used for game development, there is nothing inherently wrong with C# that would prevent you from writing a high quality, well performing game.
Some of the largest, scalable systems in the world are written in .NET.
That said, it is true that C++ offers extremely fine-grained control over memory management and the ability to use assembly to call SIMD instructions. I would be foolish to argue that C++ would be a bad choice for AAA games.
But that said, .NET takes of a great deal of the "plumbing" that can be extremely tricky to implement in an unmanaged environment. For smaller developers (or even creative mid-size developers) the 80/20 rule comes into play. I'd rather spend 80% of my time implementing high quality gameplay and content, rather than using that 80% implementing low level plumbing such as thread instancing, memory management, and other basic platform requirements.
Of course, commercial frameworks such as Unity help with this issue. But I strongly believe that over time skilled developers will build up a solid base of reusable components and bootstrap new .NET game development, the same as anything else. Just look at how passionate the ALT.NET community is.
I believe the issue probably has more to do with time than anything else. The WinRT APIs went through an intensive design phase to make sure they were easy to use. Given the large surface area of Direct3D and the complexities around performance, I can see why that wouldn't be a trivial task.
But that said, DirectX remains the last major holdout from the managed world.
Tuesday, September 20, 2011 10:28 AM
If you spend your C++ time implementing memory management, then you're doing it wrong. Seriously. The Standard provides more than enough resource management classes that are extremely flexible and containers that manage their own resources, e.g. shared_ptr, unique_ptr have that covered- even for non-Standard uses like COM. A five line custom deleter and shared_ptr becomes ComPtr. And thread instancing? That's what the Concurrency runtime is for. These aren't things you have to pay for or look for- they ship with the IDE in question, not to mention the extras you can find in Boost. Maybe you would have had to spend 80% of your time implementing memory management- in 1998.
The simple reason that C# isn't suitable isn't just about performance, it's also about resource cleanup. GC might seem like some wonder-solution, but it's only going to work for GC memory. Good luck using it to clean up your COM instances, GPU memory, and such. When you're talking about cleaning up an ID3D11Device, then you're back to malloc() and free(), which is hideously error-prone. using is hideously deficient for a large number of reasons. C++'s Standard resource management classes are more than flexible enough to deal with COM instances seamlessly- even if the IDE didn't ship with ComPtr. That's why when you talk about implementing memory management, it's actually going to be more effort in C# than in C++, because C#'s memory management solutions just won't work with anything that didn't originate from .NET. Not to mention the fact that in C++, many things don't even need memory management, because the stack serves them just fine.
That's not even mentioning some of the other things about C++, like templates, which are vastly more powerful than C#'s generics, and other subjective language features.
And, I would say that the WinRT APIs went through an intensive design phase- to make sure that they matched WPF. They have a hideous design, I've seen better from first-year OOP students. Just look at the XAML's Button class. It's default-constructible. Does it work if you default-construct it? Maybe set some text and a click handler and voila, you have a working Button? Of course not. At the very least, it would need a Window to be rendered on. The same holds for many Metro classes- they simply don't offer good interfaces at all. And they tried to port Object to C++. Really. I wish I was kidding about that. I could go into a lot of detail about why WinRT's APIs are horrendous.