No comment :-)

Oh yeah, I forgot we did that press release. Cool!

I'm still not allowed to talk about it, though, because this is exactly what I'm working on at the moment and there's still a lot of stuff the marketing people are busy figuring out when and how to announce. You know how it goes, they don't want developers going and randomly spouting things in an uncontrolled fashion...

Good point. In that case I certainly won't tell you that XNA is going to prove the power of our platform by demonstrating a Visual Basic port of Halo 3 running on a mobile phone.

I've seen the DOOM RPG on a phone. It's rather interesting.

Shawn: Now you'll be telling us that your companies next game doesn't feature motorbikes!

I suppose I can see the appeal of making a library rather than a game.
As long as you are having fun I suppose!

That's actually very much how I approached game development in any case: I spent way more time building tools and reusable components than working on the actual game code! I always figured if we got the tools right, it would then be trivial and quick to slap a game together at the end, plus we'd be able to reuse the tools once we'd built them.

The nice thing about XNA though is I get to build tools for a much wider audience than just a couple of teams inside one company.

I find it fun, anyway!

In some ways, yes: things need to be much more robust and flexible and have good error handling and so on, where internally people could just come ask me if they couldn't figure it out.

In other ways this is easier, though, because I'm not so directly responsible for delivering an actual product. So there's a lot more room to say "sorry, that's just not something we support", where on a game team you don't have any wiggle room to not bother supporting exactly what the game needs!

Hugely. I learned an incredible amount during my years at Climax, about how to make games, about teamwork, and about general software design.

Plus there have been so many advances in languages and naming conventions and design patterns and abstraction techniques over the intervening years, it's so much easier to make a nice usable API these days!

I'm finding a lot of the stuff I'm doing for XNA is much simpler than the code I wrote at Climax. Or at least has a simpler surface area. At Climax I got very into using advanced functional templatey C++ tricks in my tool code, which was very powerful and not always easy to understand :-) But fine as long as I was the only one who had to use the resulting API! For XNA we're targetting a completely different kind of developer, so I'm having to do a lot more thinking around what at first glance seem to be more superficial kind of usability issues like exactly what a method should be called, or giving related methods alphabetically related names so they sort next to each other in the class viewer. Little stuff that if we get it all right, makes the final product so much nicer to work with.

'fraid so. I'm an American living in Seattle these days...

Many things. It's an umbrella marketing term for all the work MS are doing to make developer tools for games.

That include stuff around build systems for game content ("XNA Build"), and Visual Studio customization for managing game assets ("XNA Studio"), and depending on who you talk to, might also include DirectX and the Xbox SDK. It also includes making managed code work for writing games (the "XNA Framework"), which is the part I'm working on.

Afraid that's one of the things they haven't announced yet...

.GNU and Mono are free and cross-platform. They're not exactly the cross-compatible and feature-filled equivilent of .NET 3.0 since they don't exactly have the resources, but they'll get there sometime.

I don't know about Java, but in the desktop version of the .NET CLR the implementation of allocating a new object on the heap is literally as simple as:

void *addr = gHeapPtr;
gHeapPtr += sizeof(typeBeingAllocated);
if (gHeapPtr > gHeapEnd)
    CollectGarbage();
return addr;

In the case where no GC is triggered, this is exactly the same cycle count as a stack allocation! (assuming that your compiler switches are set to check for stack overflows, which almost all modern apps are built with for security reasons).

Of course it's not as fast as stack allocation when a GC is triggered, but even then it is pretty fast. This is one of those things that in theory sounds like it could be slow, but in practice I've never seen GC overhead even show up on a profiler for well written code. In fact I find myself spending way less time optimising C# to avoid GC overhead than I did in C++ to avoid malloc() overhead. It pretty much "just works" and runs fast. Heap allocating short lived objects (things that don't last long enough to get promoted out of generation 0) is really very similar to the performance of stack allocation in C++. But with stronger correctness guarantees.

Yeah, Java sucks :-) C# on the other hand has true generics built into the runtime, not just as compiler trickery, so a strongly typed list of ints does not require any boxing. Which is as it should be.

Really? I find myself using reflection all the time. It is an immensely powerful way to step outside the statically typed universe and do cool Pythonic tricks: gives you a big chunk of the goodness of dynamically typed languages while still keeping static typing for all the places where that makes sense.

Reflection is particularly invaluable for writing unit tests. We have very high automated test coverage for all the code in my current project (probably more test code than actual production code), and this would be almost impossible to achieve without reflection. How else could you poke around in the guts of a running system to check everything is working as expected, or to simulate obscure internal error cases?

I'm actually really impressed with Mono - it works great and is surprisingly close to the MS feature set. I don't know when they'll get the .NET 3.0 features online, but after .NET 2.0 was announced, they actually had generics working in Mono way before MS got around to releasing a beta of their implementation!

How would you eliminate pointer calculations? Would you cut out inline assembly also because that would allow modifying pointers and data on lower level than the language might.

There are various schools of thought on pointers.

1: The C++ approach. If you do it right it will work. If not, it won't. It's your problem.

2: The Java approach. Pointers are unsafe, therefore don't allow them.

3: The academic approach. Figure out some kind of code analysis algorithm that can verify whether pointers are being used correctly. Nice idea but unfortunately nobody has figured out how to actually do it yet :-)

4: The C# approach. Pointers are unsafe, therefore you shouldn't use them very much. It should be possible to write the vast majority of day to day code using constructs that are guaranteed typesafe and cannot corrupt memory. But sometimes you just need to do something low level and icky, or you are writing performance critical code, so you should still be able to use pointers when you really need them. Code that uses pointers will have less safety guarantees than code which does not, so it needs to be clearly labelled, making sure you can spend extra time reviewing these few risky areas. The language should encourage gathering up the unsafe pointer usage into just a few reusable functions, rather than scattering it all over the main body of the code.

How this works in practice: