INDUSTRY ANALYSIS SPONSORED BY
OPINION | ALPHA
COMMENT: OPINION
Caught in .NET by Allan Murphy, Microsoft
B
en Board has left his keyboard for a moment, so I thought it’d be a great time for a confession. Working as an engineer in Microsoft’s Advanced Technology Group, it became a bit embarrassing that I couldn’t write a competent Windows application. While learning to do that, I figured I should do it with the all new – to me, not the rest of the world – .NET framework and C#. As a console coder of some 17 years I regarded this as a necessary evil, and an unwanted and ideally brief departure from the wonderful grinding world of console optimization in C++, and frankly as far beneath C++ as I can get without having to actually make any hardware. In common with all good coders, I fear change. So to be frank, I kind of didn’t want to learn managed code, and I certainly didn’t want to like managed code. Unfortunately, managed has a lot to like about it; like a goth gradually accepting dark purple as a gateway drug to other brighter colours and ultimately smiling, I did grow to like it. It’s just that the .NET framework provides swathes of useful functionality you’d normally have to at least fiddle with in C++, if not outright engineer from scratch, or kludge/steal/copy/borrow. And I grudgingly admit to not worrying about who owns what memory is liberating; my fingers normally start to shake when I type ‘new’ and I often reflexively delete the whole line without thinking, while wondering why I feel dirty and used.
TALKING INTELLISENSE But what broke me was build times and Intellisense support – I mean, it’d be easy to hate if it wasn’t so bloody helpful. I freely admit that at first I thought I had my dependencies all wrong and wasn’t building stuff correctly – managed builds are unfeasibly quick. Having VS insert stubs for methods I’ve just dreamt up on the spot, re-ordering parameters project wide, resolve missing references for me, suggest parameter sets and names for overloads, and pop one-line descriptions of function usage as I type them in is an enormous productivity boost. It’s like trying to hate Twiki off of Buck Rogers – you might want to, but you just can’t stay mad at the little guy. Sure, you like the idea of Colonel Wilma Deering, but she is quite high maintenance. DEVELOP-ONLINE.NET
Why am I telling you this? Our team has been doing some work with Windows Phone 7 and mobile developers recently. Windows Phone 7 development is managed only in C#, via XNA Game Studio, and supported by the XNA Framework. The word ‘only’, raised a lot of developer eyebrows when we first presented it, and I can completely understand why – most phone development is native, for a start.
Performance issues have been pleasantly easy to tackle. Managed code has some different performance areas to watch, but those are well understood and titles have no problems reaching 30fps. Our experience as developers, racing towards finishing the first WP7 games, has been those initial fears of nightmarish rewrites and hard graft having been allayed. And most developers have come to like managed code, for the reasons above, but also because the XNA framework provides a great deal of functionality, sitting on top of the .NET Compact Framework. Compact in this case is relative – the full Windows .NET framework distribution weighs in at 82Mb. We’ve had several reports of swathes of mobile code being replaced with a couple of lines of C# or calls into XNA framework classes. The framework provides a built-in, easily extensible content export pipeline that handles sprites, textures, geometry, sound effects, music, movies and so on. The Windows Phone 7 flavour of the framework includes support for touch input, accelerometer, geolocation and Xbox LIVE services, too. PERFORMING MIRACLES Performance issues have been pleasantly easy to tackle, so far. There have been some different performance areas to watch, for sure, but those are well understood and titles have no problem reaching 30fps. In the main,
monitoring garbage collection is the most unfamiliar to native programmers; however, this is no difficult task, and also a very small price compared to the cost of handmanaging memory in a traditional native situation. If you are accustomed to avoiding allocating at all during gameplay, you are already home and dry. There’s no avoiding that translating existing C++ to C# for WP7 can only be automated to a certain extent (and that ignores codebase maintenance issues in the longer term). However, here’s a dangerous idea: C# to C++ is completely automatable. MSIL recompilers can spit out C++ easily.
Above: Windows Phone 7 development is managed in C#, via XNA Game Studio
Allan Murphy has worked in the game industry for over 17 years, and on consoles since the early ‘90s. He has shipped several titles and worked on a wide variety of engine technology, and currently works for Microsoft in the Advanced Technology Group (ATG) where he helps developers create games across a range of Microsoft platforms. SEPTEMBER 2010 | 15