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.

screen1

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.

Tales from the Dev Side: Unity in a Splintered Industry

As word hit that XNA was being faded out, non-developer me was curious where else the community that I’ve downright fallen for with would turn to next to create the games I both love and loath.  And the community has responded.  First, the guys at MonoGame hit me up with a semi-well-received, semi-controversial editorial touting their platform as the next big thing.  While a direct response to that from the mad bastard behind FortressCraft is still coming, industry veteran-turned-indie Scott Tykoski wanted his chance to sing the praises of Unity.  As always, I understand almost none of this.  But Scott’s a gifted writer and not prone to panic, so you should give him a read.

UNITY IN A SPLINTERED INDUSTRY

by Scott Tykoski

As the death knell rings for XNA and my Xbox Indie pals pay their respects on twitter, a question hangs in the air – “Where do we go next?”

And by we I mean the group of developers that got excited at XNA as an inexpensive multi-platform solution. We bet YEARS of development energy on a system that looked so promising, yet let us down in so many ways.

“Where do we go next, now that XNA is dead?”

We also have to deal with the “gold-rush” mentality that has come along with the mobile gaming boom. Indie/Hobbyist game developers are everywhere, and worse, most of them are making very similar games (take hit game, change the theme, rinse, repeat), intensifying player dissatisfaction with titles that don’t push any significant boundaries.

“Where do we go next, now that the world is oversaturated in unsatisfying games?”

And heres another challenge to overcome: our industry is undergoing HUGE, seemingly random marketplace shifts. Phones streaming games to tvs. Consoles putting games on the backburner to focus on movies and television.

“Where do we go next when there are so many platforms and nothing is certain?”

The honest answer? We go away. We give up and we move on.

Goodbye, friends.

 

 

 

 

 

UH…WE’RE NOT REALLY SCREWED, RIGHT?
No, sorry, I’m kidding…we’re totally fine. 🙂

Actually, being in the Indie gaming scene has never been more exciting – even with app stores overflowing with crappy titles (we’ve fought that battle before, right XBLIG guys?). You see, every studio – from the one-man operations to the largest gaming conglomerates – is facing the exact same conundrum: “What platforms do we focus or development energy on?”

This universal need for multi-platform tools means we now live in an ecosystem ripe with ‘Make Once – Play Everywhere’ solutions. Unreal for the big spenders. Adobe Air for the Flash experts. Gamemaker Studio, GameSalad, Stencyl, & Construct for folks unfamiliar with code. And of course the mega-versatile MonoGame for anyone fully invested in XNA (Rest In Peace, sweet prince).

But while all these solutions have their disadvantages, be it price or flexibility, one toolset has them beat on all counts: UNITY.

What once was a fun little tool for prototyping, Unity (now at v4.0) has matured to the point where you can make some pretty amazing games, like the beautiful Kentucky Route Zero or the 4x Epic Endless Space.

Kentucky Route Zero

With Unity, developers can now rest assured that core engine systems are covered and they can focus on the most important task: DESIGNING A GREAT GAME!

But first..

THE BASICS OF UNITY
At its core, Unity is a 3d game engine where the developer can script using C# or go straight into scene creation using the fully featured editor, which feels a lot like using 3DMax or Maya (where you move game objects around in 3S space). While it may seem daunting at first, the toolset gives a great entry point for either artists or developers to start working on their game.

While the amazing editor would be reason alone to use Unity, the real selling point is the admirable cut of its cross-platform jib (ie: it can export games for every friggin’ platform). Titles for PC, XBox360, Wii, Web, Android, and iOS have all been made and released using the Unity, proving itself on multiple devices many times over.

It should also be noted that you can make a Ouya game RIGHT NOW using Unity. That’s pretty amazing cross-platform support, if I do say so myself.  Which I do.  Obviously.

SO MUCH 3D GOODNESS
While modeling, texturing, and animation have to be done in a traditional 3D program (3DMax, Maya, Blender, etc), Unity does all the heavy lifting when it comes to importing and rendering those assets. Lighting, post processing, shadows, and animation are all available out of the box.

I remember trying to get a distance blur effect hooked up for battles in Galactic Civilizations II but it was a huge pain and never happened. In Unity.. it’s as simple as dragging a effect script onto the camera object. Most effects are drag-and-drop ready…it’s simple to the point of sickening.

And lets talk for a bit about asset pipelines. The amount of raw data that goes into defining meshes, bones, UVs, and animations is staggering, and have given rise to third-party frameworks that manage this deluge of data. The fact that Unity makes the asset import and management process a two click process is a testament to the overall ease-of-use the editor provides.

THE JOYS OF C#
Anyone familiar with XNA is also familiar with the beautiful C# coding language. I won’t pimp that here, but Unity uses it, and it’s awesome.

Coding is as simple as writing your code, making a few public variables to use as dials, then attaching that script to your game objects. Those variables can then be tweaked in the editor, so writing modular code is buttery smooth.

The editor also has its own scripting API, so you can easily extend the editing tools as necessary.

THE ASSET STORE
Another notch on Unity’s belt comes in the ‘Asset Store’, where you can buy or sell anything game related.

Lets say you want a ‘Plants vs Zombies’ look to your game and need to animate several of 2D characters. You can go into a separate 3D program, rig and bind 2D planes, export the data, then use a 3D animation object to render your characters. OR you can purchase SmoothMoves, an in-editor 2D animation solution for 75$.

It’s the best 75 bucks you’ll ever spend, I assure you.

Chances are, if you need a game-related subsystem, someone already has a solution available on the asset store: just purchase, plug, and play!

NOW FOR THE BAD NEWS
Instead of a proper point-counterpoint, I decided to bottle up ALL the negative stuff to dump on you at the end. I know…I’m an a-hole.

First and foremost, the cost. Good news here is that a free version can be used by most Indies. Once you start making more than $100,000 a year, however, it’s time to go PRO, which will cost you $1500. Exporting features come in the form of add-ons, so exporting to iOS from the free version will run you $400, from PRO it’ll cost $1500.

Unfortunately, all the R&D testing I did was with a PRO version with a PRO iOS exporter, so some of my exuberance may come from using a super-slick $3000 version. You can dig around in the Unity Store to get some charts comparing features of the different versions.

Also, debugging was a bit more painful than in XNA and traditional IDEs. My testing of the tool was mostly on the art side, however, with a full-time developer testing out the coding front, so my pains could have simply been lack of experience. My fear is that you’ll be spending more time with print statements and less time with breakpoints.

Another issue, for those of us that love our retro graphics,the 3D environment can make 2D game creation tricky. It’s doable, but definitely less intuitive than making a proper 3D game.

The biggest drawback to Unity – as with any third-party engine – is the lack of control you have on the last 10%. You’ll always encounter areas where you want the engine to do something that’s just not possible (for one reason or another). While the main 90% will be smooth sailing, compromising on the last 10% of your vision may be too steep a price.

UNITY & MAKING GAMES WORTH PLAYING
So I started this editorial with that stupid ‘we should give up’ gag. It was mostly for fun, but there’s a legitimate feeling of helplessness that comes when your platform of choice is discontinued. There were too many crunch weeks spent on games using XNA to shrug it off as a necessary loss.

And while it sucks to see an amazing framework put to pasture, we are now drowning in possible alternatives. Alternatives that not only allow you target multiple platforms, but that alleviate the burden of creating the subsystems that your game will depend upon.

It’s for the sake of quality gameplay that I fully endorse Unity, and really any 3rd party engine. The overwhelming majority of your audience could care less about the underlying engine.. all they want is a new experience, something that’s not ‘Angry Birds with Zombies’.

Creativity on the Indie scene is a talk best left for another time , but always remember: originality is your key competitive advantage over the AAA studios. Use it! The less time you’re making engine systems that never excite the player, the more time you can devote to making original gameplay systems that will excite yourself, the player, and perhaps even our entire industry.

%d bloggers like this: