Indie Gamer Chick

Tales from the Dev Side: Screw XNA

The last month on the XBLIG scene has been an interesting one.  Since word broke that XNA would be phased out, I’ve been witness to public mourning, disbelief, and nostalgia.  XNA created a community out of dreamers, some of whom wonder where their future will be.  Others have been looking to the future.  At Indie Gamer Chick, we’ve had the guys behind MonoGame offer their version of a lifeboat to the marooned XNA development community.  This was followed up by a pitch that Unity is the way to go.  DJ Arcas, the man behind the million dollar-generating FortressCraft, is throwing his hat into the Unity ring.  And, almost uniquely among his fellow XNA developers, he’s not exactly grieving for the loss of the platform.

Screw XNA

by DJ Arcas

I’ve been programming for a very long time, and almost all of it was writing games. I cut my teeth on BASIC, went onto compiled Basic, learned Pascal, then started to use x86 assembler, to squeeze every erg of performance out of my games. Mind you, that was on a 486.  There wasn’t a great deal of performance in there! That was the way you had to do it; you sacrificed a control, flexibility and development pace, but gained a lot of performance. That was 1992.

When I professionally entered the industry, it was during the death-throes of the PS1, and the rise of the PS2. For the PS2, everyone was using the new-fangled C++. Many of the old-hands decried the use of this language – “It’s too slow!”. And, in a way, they were correct.

Poorly written, massively-inherited C++ is slower than a sloth covered in treacle. Well-written C++ has a tiny margin of difference. The real difference, of course, is how much you can achieve in the same time frame. We never went back, by the way. C++ stayed. Admittedly, you had to change the way you worked; you gained a lot of flexibility and control, but you were sacrificing performance. Still, the Xbox was a 700mhz machine, and we needed a game written in one year, not three!

I first saw XNA during the development of Burnout 3; there was an amazing demo doing the round, showing a car crashing into a wall at high-speed and crumpling. We were impressed, but dismissed it, as it was a PC-only technology. Microsoft promised Xbox, PS2 and GameCube versions. They never appeared, however.

I started with XNA shortly after the launch of XNA for XBLIG, or “Community Games” as it was called back then.  Can you believe it?  It took me seven days from first getting my hands on XNA, to my game being available for download on XBLIG. FallDown, it was called. I believe it was the 74th game on the service.

This is FallDown. Rats. I was hoping it would involve Michael Douglas somehow.

From then on, I reveled in C#; whilst I had to use the much sleeker, yet clunkier, C++ at work, at home I could write code at a rate five to ten times quicker than I could at work. C# allows you to create working systems much quicker, but at a slight cost in CPU time. You gained a lot of flexibility and power, but you had to work the way that C# wanted you to. Sound familiar? Of course, there was no way that a AAA studio was going to consider using C# on a AAA game. It’s far too slow, surely? The fact that you could write the same game in half the time; or a game that’s twice as good in the same time; never seemed to cross anyone’s mind.

I released many XNA games onto XBLIG, eleven in total. Some did very well (FortressCraft), and some did very badly (Steam Heroes). But each game was a step forwards; I took what I’d learned in the previous games, and applied it to the next one. Particle engines were written. Wrappers for physics. New and improved shaders. But these things took time, so much time, and weren’t always optimal. For instance, in FortressCraft, I developed a way of drawing meshes on the GPU, as opposed to uploading them at render time; many hundreds of times faster. If I’d known that whilst writing Stunning Stunts, I would have released a much better looking game; or the same game in a shorter time frame. Who knows how much better things might have gotten if I’d spent another four years working with XNA?

And now we move onto the end of XNA. What’s next? Quite unsurprisingly, many people are sticking with what they know, and are moving onto MonoGame, which is basically XNA all over again. When asked why, well, anything more advanced would be slower, wouldn’t it? and you’d lose control, and would have to do it the way they told you? All these things, sound awfully familiar to my ears…

Always been one to try out adventurous new things (You should see the bottom drawer in my bedroom!), I decided, at the end of last year, to try this new-fangled Unity everyone had been going on about. It had just gained Linux support, and was destroying the competition in the mobile arena.

Five days later, AndyRoo and I had put together an underwater deathmatch game, in steam-punk, animated submarines, where you could fire physics-based torpedos through thick foliage, and dive in and out of shipwrecks, in a game that has full configurable controls, massively scalable detail, and would ‘just work’ on almost every platform under the sun.

Now. let’s just write that again. I wrote a game with the approximate gameplay complexity of Doom, with substantially better graphics, in 5 days flat, in an engine I had never seen before.

Now, XNA could most certainly have done that, barring the multiplatform stuff (MonoGame solves that tho), but I really can’t begin to imagine the timeframe it would have taken me write it. And in that timeframe, who knows what Unity would have added? Having a tech team of a few hundred people writing amazing new features for you really does help you stay on the cutting edge!

The real beauty of Unity, to my mind, is that you can try out advanced tech, and see if it fits your game. For instance, should your game have edge detection? In XNA, you’re looking at a few days of different ways of writing the shader, considering normal or luminance-based edge detection, optimizing, and then deciding that, actually, it looks crap.

In Unity, you simply drag the shader onto the camera, and comes fully configurable.. It comes with dozens of shaders like this, allowing you to quickly prototype up how it should look.

So you’re talking about several days of work, played off against several seconds. I already know where my vote is heading…

This is the usual point where people leap in and go “AH HAH! Whilst Unity is better for prototyping, it’s no quicker for writing a full game!”

This sort of comment is really self-evidently false; if you have a fixed timeframe in both systems, you’ll either finish in a 20th of the time in Unity, or end up making something substantially better looking in Unity. The fact that, in Unity, everything inherits from a generic object, meaning you can manipulate everything quickly; re-use of scripts, code and objects in Unity is truly incredible; from having actually used both systems, I can say that writing gameplay in Unity is much, much faster. I’ve never heard this from anyone who has ACTUALLY used both XNA and Unity, mind you.

“Oh, but it’s slower!”

True! Unity is slower. Is a LOT slower? No. A few percent, perhaps. Are you confident that your cascading shadow engine, which you wrote from scratch, is faster than Unity’s one? I wouldn’t be. Will your physics engine be faster than PhysX? Almost definitely not. Will you be able to optimised your graphics engine for the iPhone better than the Unity guys did? No chance.

“Ah, but once you try to do something Unity doesn’t want you to, it’s way easier in an API like XNA!”

I’m glad to say this isn’t true. If you try to do something Unity doesn’t want you to, you end up in exactly the same boat as you’re in with XNA; having to write it yourself, and wishing it was already written for you. You can even interface with C++ DLLs, meaning that, WORST CASE, it takes exactly the same amount of time.

That’s what really does it for me; if I want to mess about with their state-of-the-art lighting engine, I can. I don’t have to spend 3 years writing it first. If I decide that I need to implement some new, hitherto unheard of technique in my game, then that will take the same amount of time; but every other facet of my game will be done faster.

But I think the main thing I love about Unity is that if you make a variable public, a designer can then edit that from the WYSIWYG interface. That right there is a mountain of work in XNA.

For me, it boils down to a simple choice. Do you want to write a good game, or a good engine? FortressCraft was, really, a good engine, designed with the future in mind, and the much more complicated and in-depth Chapter 2.

But I managed to write this in 4 weeks:

And this in a few days :

Why would I want to order a bunch of parts from a garage, when I could pay someone to fix my car for me? Fixing your own car only has 2 real reasons; either you love it, or you’re trying to save money. If your goal is to have a car to actually drive on the road, you’d pick the garage option every time.

And that right there is the only – only – advantage I can see that XNA/MonoGame has over Unity. It’s free. (as the old adage goes, anything free is worth what you paid for it). Mind you, Unity has a free version; you miss out a bunch of the extras, but you can decide it’s for you (Slender was written using Unity Free, for instance)

If your game isn’t going to make $1,500, then Unity Free or MonoGame might be more suited for you. Go for it. Great stuff was written using free tools. But if they don’t work, or you need help? There’s almost  no support for free software, and you need to rely on the community.

If you want to spend a huge amount of your available dev time re-inventing the wheel, go with XNA. Go with MonoGame. Enjoy scratching your head about calculating tangents for reflections, wondering how cascading shadows work, and if you should implement A* or Dijkstra’s for route-finding. Me, I’ll be busy getting on with writing the game.

Fuck XNA. Long live the future.