Tales from the Dev Side: Screw XNA
March 3, 2013 17 Comments
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.
Indie Gamer Chick 
Good article.
I started out with BASIC as well… actually QBasic that came with DOS 5.0 on my 386. The first “real” language I learned was Java when I started college. I always tried to stay away from C Sharp, since it was a proprietary language and not multi-platform. However, I gave C Sharp a try last year and it has really grown on me after writing my first game. I’ll admit that I would have probably never tried it or XNA if the compiler wasn’t available for no cost. I wrote a few C++ programs back in the day, but it always just seemed to be hacked up C. Java’s method for defining classes just always seemed to be cleaner to me. These days Ruby is really my favorite language, especially since Oracle seems to be doing everything they can to put the death nail in Java since they bought out Sun Microsystems.
That’s pretty much my take on Unity as well. I’ve played with XNA since the beginning, though as more of a casual hobbyist (only released two XBLIG games in all that time). But I can get so much more done in Unity that I can focus on what makes a game unique. It keeps things fun. Plus you still get to code in C# and not just in a traditional “scripting” way either – you can still build full classes. I no longer have to mess with the super complex systems like 3D collision detection, physics, dynamic shadows, light mapping, and yeah, all those built-in shaders. You can still do quite a lot of code-oriented stuff. More than is apparent the first time you fire up the editor.
The really big appeal of XNA was the ability to self-publish on a popular fixed platform, though (Xbox). That’s obviously not the case with PC or Mac or even really the now-fragmented iOS and Android world. The Ouya is kind of interesting, but it’d be nice if Unity could be used on “real” consoles for us hobbyists. The idea of targeting PC’s and mobiles devices with such a wide range of resolutions, control schemes, and capabilities is a bit daunting, but at least there are tons of options.
Well, I’ll say it- if I get into a game programming job, I prefer coding tools or engines more than the actual rules of the games. I love working out things for reflections, or shadow maps. Everyone has their affinity and preference towards certain areas and that goes for game developers too.
From what I’ve noticed, blogging programmers that whip out indie games left and right write to an audience more on the gamers than programmers, so they speak a lot about game features than technical details. The “luminance-based edge detection” articles tend to not co-exist with “new level packs” articles. There are programmer blogs that do have a game coming out, but they see to take a “slow churn” approach in comparison.
Your weapons of choice ultimately depend on how close you want to get to the metal, and for me, XNA has been pretty satisfying but without the blowing your legs off risk of unmanaged C++. That said, I’m still giving Unity a look, and would enjoy it more if it does allow programmers to fine tune low level stuff if they prefer.
It seems a bit much to write an article like this before you’ve finished a full complicated game – the sub game looks awesome btw but obviously simple in concept: the point is that anyone whos been working with XNA for the past four years probably already has an existing code base and it shouldn’t take much longer than 5 days to write that engine (however the art is impressive for 5 day turn around!)
I’m wondering what you would run in to if you tried to write fortress craft in unity though? I’m not dissing unity, I have not tried it. Nor have I tried monogame yet. I know a few developers who use unity professionally (are employed to do so) and they seethe with rage when I ask them to talk about, some things really seem to upset them about unity and they go on about problems I only ever listened to with half an ear because its never seemed like it would ever effect me.. guess its time to listen properly! But I would be interested Dj Arcus to ask you your opinion on unity in say 6 months time.
Just seems a bit hasty to write this right now – although its good as a “what my first impressions have been” 🙂
That’s a good question. How long would FortressCraft take in Unity?
In any case, it was an interesting article. I usually avoid very progammer-ish ones because I don’t understand them, but I got the gist here.
Pingback: How low-level should you go? | Electronic Meteor
Would you say that Unity is good for learning to code your own games? Easier or harder than previous coding languages?
Typically with Unity you aren’t going to be “coding your own games” in the same sense as you would be with XNA, since the engine does so much for you out of the box, though you can “roll your own” components to a pretty deep degree. If your goal is to really learn programming, it might not be the best choice, since it may be a bit *too* easy to get by without all that much scripting. Unity is a game engine, not a language. You can code in C# using an open implementation of .NET called Mono (or a variant of JavaScript – yuck). It’s hard to imagine it being much easier to learn and have fun developing a game than Unity, but that might not be your main goal. Sometimes getting down and dirty and writing your own low-level stuff can be gratifying. Eventually you may want to just get on with it and build games though.
I’m really dissapointed with all these articles trying to brain-washing us, making us believe that we all at XBLIG are screwed. It’s like an ill-gossip that aims to soil Microsoft’s name, just for the fun of it.
* The XNA as a technology is no longer in development. Granted.
* However, that does not mean that it is no longer working, or that there are no longer plans to name a successor for the new XBOX 720.
* As of this date, the only way to publish a game for the XBOX console as an independent game developer is through XNA.
* In other words, if you give up XNA, you give up the XBOX as your market.
* True, you could use MonoGame for XBLA. Good luck with that investment.
* So many technologies are no longer in developoment. However, they are still working.
Now, the jucy bit:
* The actual code is just a part when it comes to video game development. Most players tend to valorate graphics, and even sound effects are more attention grabbers than the actual code.
* This same site is full of editorials remarking that the true value of a video game is not in its outstanding code: It is in how much fun the player gets when playing it.
* Not because you want to change your technological platform, it means that your games will be better.
I’m one of the lucky ones that got paid for the games I’ve published. True, it was a small amount, more like a symbolic one. But I didn’t have to spend a dime in marketing. I just published it, and waited for it to generate revenue.
What is the true value of XNA? The XBOX Market, of course. Am I concerned that XNA is no longer in development? Not really. I did my own shaders, my own graphics, my own game engine, and just as easy I can export it to any other platform. Will I migrate to the other platforms that are in fashon these days? It depends on what they’re offering, from a market point of view. As of now, I’m staying with Microsoft. Am I a fool for it? Maybe. However, as of now, I’ll bet my programming skills on the XBOX 360 and 720 consoles.
Just my two cents.
The whole hatred of XNA not being under development is definitely overblown. Certainly we all would have liked to see a DirectX 11 update, but XNA is still available and certainly not “dead” any more than Winforms or Webforms are dead.
Indies should be gravitating away from XNA, generally, as more mature game platforms and engines are becoming available… not necessarily because they are cross-platform, but because we need to be spending our time making games, and not building the engines.
The article alludes to this, except the conclusion is misleading. The article points out how getting on top of an engine or platform is the fast way to prototype and finish, but the article points its finger at XNA when it is really making a good statement about building your own engine from scratch in general.
But there are already engines available for XNA like Flat Red Ball and QuickStart. So it’s not a valid assumption that you must create your own engine if you’re using XNA.
Besides, some developers enjoy doing that sort of thing. What’s wrong with putting emphasis on what you enjoy?
Well, the article is trying to make a point about using already existing game engines. Still, I agree with you: It’s ok if we like creating our own engine. As you mention, there are other game engines out there that we can use, regardless of the technological platform we choose.
Here is a link to another article on this same site, published not so long time ago:
https://indiegamerchick.com/2012/07/01/tales-from-the-dev-side-what-xbox-live-indie-games-have-meant-to-me/
It’s good to see conflicting stories. When we see two different point of views, we get an objective opinion.
Just my two cents ^_^
It is true that you can make games faster in the Unity Game Engine but just to be clear; XNA is not a game engine and that’s really just common sense. I don’t have any problems with people calling it a game engine but that doesn’t fully make sense. XNA is not a game engine, it’s a framework. What I mean by that is, XNA essentially is a set of Helper Classes to help game developers save time programming their games. Those classes are saved into .dll files which are a set of library files. This is where I think Microsoft slipped up some on the “tools” part but I am starting to understand why I am confused when people are saying XNA is dead and turn to Unity. Although Microsoft Abandoned XNA, I chose to create my own engine in XNA primarily to learn every aspect that goes into a game. I chose to create my own engine in XNA so I could have full rights to whatever I create, to have a game engine I can call my own, to have something that can serve as a backup if I use another engine and to save money.
Yes it is taking me longer than most but although Unity is free, you have to pay for additional features. Unity does majority of the work for you. XNA does not come with features like tilemaps, particles, scripts, physics, level editors, etc. but if you are a XNA Community Member, you can go to their forums and download sample projects created by Microsoft to help you primarily learn about these things and save time creating your own. So you have to either create your own or use an existing engine built upon the XNA Framework. Unity is entirely a separate game engine of its own with its own physics engine, its own graphics engine, and its own support for multiple platforms, its own level editor… I think we get the picture.
People ask me all the time why am I creating my own engine because I would just be “re-inventing the wheel” but that’s not necessarily true. Again, its primarily so I can educate myself about game engine programming. I wouldn’t learn as much if I used a tool or an existing game engine that does the work for me! There is nothing wrong with using other game engines but if you are serious about becoming a game developer or more specifically and engine programmer, try creating your own tools. Game Development is not about choosing the easier route. That’s primarily why so many people moved away from XNA to switch to Unity and Unreal Engine because they don’t want to put in the work! There are game engines built upon the XNA Framework that support multiple platforms like the Delta Engine created by Ex Dream, but they created it themselves and they have full rights to it. They hard-coded the engine to support multiple platforms whereas many just moved away from XNA because the framework didn’t support as many platforms.
I am developing my first game as an Xbox Live Indie Game for 360 because you can self-publish on Xbox 360. I would have to get a publishing deal with either Microsoft or a 3rd party publisher to get my game(s) on Xbox One. Due to this, I am also looking into PS4 since they are starting to support Indie Developers slightly more. Although the Indie Game section on Xbox 360’s Marketplace is not as ‘lucrative’ as the Arcade section on 360, this will be a great learning experience for me. Because I am an indie developer, it will be tough for me to compete with major game companies and that’s why I am sticking with PC and Xbox 360 for now. I chose to compete with titles under Xbox Live Indie Games for now because this seems realistic and will help me build up some experience. With my first game, I know there might be many bugs and glitches. Xbox Live is great because they allow game updates.
This will allow me to learn from my mistakes, create patches and fix any bugs. My biggest challenge once the game engine is more fleshed out is meeting the indie game distribution restrictions on Xbox Live Indie Games that many players are unaware of. To develop a game on 360 for indie, your game must be no larger than 500MB which is not a lot of memory (especially for 3d games). Originally it was 150MB. Games larger than 500MB are to be priced at 240 Microsoft points. Also, an eight minute trial period is enforced on Xbox Live Indie Games. I don’t thing 8 minutes is long enough! I am aware of the next-gen console’s hardware and that it allows developers to increase their poly count with the available amount of RAM. I don’t want the Cyclone Game Engine (my game engine) to be too dependent on hardware specs to have the level of graphics that many games on store shelves have. A prime example of such a game that pulled of such graphics on lesser advanced hardware was a game called Project Offset.
The first footage I saw of Project Offset was back in 2005. The team created their own game engine called the Offset Engine which was truly ahead of its time and games today are still trying to look this good graphically and run this well technically as far as performance. The team was looking for a publisher and Intel bought them. Intel’s company strategy changed and the cancelled the team’s project. The team could no longer work on Project Offset or keep their game engine because Intel owned the rights to it all. So they had to start over again from square 1. Now they are a game company known as Fractiv and they are working on mobile games. The Offset Engine had similar features long before Unreal Engine or Cry Engine had such as cinematic motion-blur, SSAO (Sub-Surface Scattering Ambient Occlusion), and the ability to render hundreds of characters on-screen to create large scale battles with no problem. The game was going to be the FIRST Epic Fantasy Shooter. I hate to see things like this happen in the industry. Its crazy that Intel didn’t give them their engine back! They made it from scratch. Its a sad story but also very inspiring. My point is the Offset Engine was running at Cinematic Quality with no problem on Dual-Core CPUs! Most next-gen games would struggle to run such quality on Dual-Core technology.
I am trying to program and design the Cyclone Engine in such a way that it takes the Xbox 360’s limitations in mind. The .NET runtime implementation on the XBOX 360 is not perfect. For starters, it only performs level 0 garbage collections; that means it performs the collection in all the game data and that is terrible for performance and frame stability. Moreover the arithmetic implementation is not fast. I am trying to make the Cyclone Engine ‘garbage free’ and for the engine to take in consideration the arithmetic performance. Furthermore the XBOX 360 only has 512Mb of shared memory. So I am getting the engine to reduce memory consumption, especially in render targets. The EDRAM (a cache for render targets) of the XBOX 360 has only 10Mb of memory. As a result the G-Buffer is confined in this area (forcing the user has to use the recommended resolution). And of course there are other XBOX 360 hardware limitations that I am getting the engine to consider.
If I can get models with more polygons to run on Xbox 360 without any rendering or slow performance issues which is another challenge, then the games will be more than capable of running that same level of detail if not more on next-gen platforms. My goal someday with the Cyclone Game Engine is the have it capable of rendering Unlimited Detail not just on next-gen platforms but on platforms whose hardware may not be as advanced. Sorry for such a long reply.
Jdawgg 😀
Give it a rest Jordon. Gameplay and not the engine makes an indie game successful. The most pixelated games can capture players for hundred of hours, and there are plenty of examples around to support this statement. You’re gonna spend so much time on your engine until you’ll burn out eventually. You’re just wasting time. You should brainstorm a few ideas instead, spit them out as fast as possible on an engine that would give you as much market penetration as possible, watch it grow or move on to the next idea in case it was a bust.
Reblogged this on jordonmcclain.