See what I did there?

That’s right, for those of you following this whole project, you will realize that Mort is being rewritten. Again. This will make the third code change for the game – it began life as a Flash game, moved on to XNA, and now I’ve decided to port it over to Unity. The decision didn’t come easy, and it was only spurred on by the idea that I wanted to have a version of Mort on mobile platforms. Just as a curiosity, I started playing around with making the game in Unity just to see if I could make this mobile version, and suddenly I realized why Unity’s game engine is so much better suited for the task at hand.

So why the switch, you ask?

Multiplatform

Mort, as an XNA game, was limited to be Windows only. While there exist tools to port XNA games over to Mac, and possibly even Linux, the little I’ve read about them seem to indicate that there’s a strong chance of poor performance on those platforms. Unity, however, supports not just Windows and Mac straight out of the box, but the soon to be released Unity 4 will have Linux support as well. But wait, that’s not all – a game made in Unity can also, with very few adjustments, run in a browser. Or on mobile devices. The main reason I decided to use Unity came about from toying with an idea I had for a mobile version of Mort, so it fills this solution perfectly.

The only negative side to this is I now lose the ability to launch the game on XBLIG. However, while having a game on there would be pretty nice, it’s not that much of a lose. My understanding of the XBLIG marketplace is you get lost amongst a sea of other games, a lot of which are not much better than shovelware. The few people I would lose in the XBLIG market, I’ll more than gain by being able to produce a browser version of my game.

In short, with Unity, more people will be able to play Mort. And that’s a very good thing.

Automatic Game Adjustments

Currently, the version of Mort that is out there runs at 720p. However, not everyone is capable of running that kind of resolution. Some may want to run the game at 1080p, while others may need to stick to 640×480. I was going to need to write all the code to handle the myriad of resolutions myself. With Unity, this isn’t the case. Unity simply handles screen resolutions absolutely problem free for me. There’s still some tweeking to do, since Mort is a pixel platformer, and there are considerations to be had, but with a much smaller amount of effort, Mort will be able to run in as many resolutions as you can dream of with relative ease.

This is the same for key bindings. Unity handles key binding code natively, with little to no fuss from the developer. I knew that not everyone would want to use the X and C keys, as I did, and that I would eventually need to support the functionality to change these keys. With Unity, I simply let it handle the remapping.

Coding either of these options would have been boring, dull work. And I’m happen that I no longer need to do it.

Better Physics

There was an odd bug that I’m sure a lot of people missed. If you stood next to a wall and tapped the left key, you would see Mort continuously move back and forth one pixel. The framework on which Mort was originally built, Flixel, seemed to have some issue with collision resolution, so that if you held the left key, it would make Mort move over one pixel more than he should. I don’t know if it was an error on my part, or on Flixel’s part, but it was something that happened in both the Flash version and XNA version. When I first noticed this, while it annoyed me, I thought it wasn’t something worth taking the time to solve. That is, until I realized that if you slide down a wall that had an object embedded in it, you would stand on the embedded object so long as you held the left or right key. The minute you let go, you would fall.

This is no longer a problem in Unity. Because Unity resolves collisions differently, or maybe I just didn’t bring this error over in my code, Mort can now slide down walls without unintentionally colliding with anything. But that’s not all!

Easier Code

In the XNA version of Mort I was working on, I introduced slopes. I felt the slopes really brought a lot of character to the game, but they were also hard to program. The code I wrote to handle slopes was an entire class, handling all the exceptions. It was a lot of pain, that took a lot of debugging, and even then I didn’t work out all of the kinks. Do you know how much code it took to account for sloped tilemaps in Unity?

Probably less than ten.

Because of the robust set of tools Unity has – it is primarily a 3D engine after all – determining if I was standing on a slope was a rather easy affair. You simply add a collider around the sloped tile that roughly fits it’s shape. Then the automatic collision engine Unity has will resolve the collision automatically. Need to know the steepness of the slope? Simple cast a ray downwards, and check the normal of the resulting collision. It was easy, and took no time at all to implement.

Better Rotations

Just for reference, here’s how Mort looked when you rotated him 45 degrees in the XNA version. Beside him is how he looks rotated 45 degrees in the Unity version. It’s pretty obvious which one is the better one.

Now, aside from aesthetics, why is this important? Well, it opens up vast new opportunities. For instance, because of how poorly rotated things looked, I was stuck with making spikes be either horizontal or vertical. Once I added slopes, however, I realized how nice it would be to have spikes running up and down slopes. However, the problem I ran into came from the fact that Flixel seemed to handle it’s collisions with boxes that could not themselves be rotated. So, while I could have spikes that ran up slopes, even if they looked like garbage, it would be increasingly difficult to detect when Mort hit those spikes. With Unity, this isn’t a problem.

But that’s not all. I can rotate more than just spikes. I can rotate whole masses of land, like below, and Mort will still interact with it the way you think he should with no extra work on my part:

What does this mean? I could have rotating rooms, for one. And that’s just the first idea that pops in my head. There’s plenty others that get me more than excited.

Level Editor

Last but not least, I was using the amazing Ogmo Editor to make levels for Mort. While it’s a great editor, it’s also designed for very general 2D map creation work. The problem is, in order to get it to work with your game, you sometimes need to do some hacked, non-user friendly things. Since I planned on eventually releasing the level editor for Mort, that meant that the less user friendly things would drive the already small community of level creators even further away. What kept me from making my own level editor, however, was the amount of boring GUI work I’d need to do in order to get it up to speed.

However, Unity offers an Asset store, in which you can buy packages other people have made. So, looking around, I found NGUI would take care of a number of the boring stuff I didn’t want to handle, getting me that much close to making a more streamlined and robust level editor.

What does this mean for the alpha supporters?

Making the transition to Unity in the middle of alpha funding raises an interesting issue: if I upload the new version, what happens to the old version? Luckily, I can have both version up on Desura at the same time, and until I have the new Unity version to a high level of polish than the older XNA version, I will keep both on there. No need to lose the little bit you’ve already paid for!

Conclusion

The switch to Unity may set me back a little bit in making my game, but I have absolutely no doubt that in the end, it’ll pay off. I’m very excited by the prospects of it.

As usual, you can purchase Mort while it’s in alpha from Desura:

Also, please go upvote the game on Greenlight.

Stay tuned, I hope to post a video soon of my progress with the level editor.