Monthly Archives: March 2013

Deploying to iDevices

I spent a good chunk of my day yesterday doing the prerequisites needed to deploy a Unity test build onto my 2 iDevices (iPod Touch 4 and iPad 2). This was a lengthier-than-expected process, which included…

  • Finished registering for an Apple Developer account. Paid the $99 the night before. For right now, it’s set up as an individual account so I could start without delay. Sometime soon, I’ll have them convert it to a company account for my LLC, but for the time being this will work.
  • Upgraded OS X to the newest version. At least it was pretty cheap, only $20. Considering that Apple’s hardware is pretty expensive, I was pleasantly surprised at the low cost here.
  • Waited quite a while for the above’s download and installation to finish. The broken progress bar (“-5 minutes remaining,” etc.) was a fun touch.
  • Downloaded XCode, synced my devices, and built and deployed one of Apple’s sample projects as a test.
  • Built and deployed a Unity project to both devices. It worked! But deploying is super-slow. Did some research to find out that if I update the device OSes, this process should be faster.
  • Updated both devices, and deployed again on both. Much faster!

As an aside, I am primarily a Windows user; I only have a Mac to facilitate app development. These 2 OSes have a lot of subtle differences, but the one that bothers me the most is the fact that on Macs, you use Cmd (Command, or the Windows key) + [whatever] instead of Ctrl + [whatever] for shortcuts. I have nothing logically against the Mac way, but 15-ish years of doing it the Windows way… I’ll just say that each time I had to scrunch my pinky over to hit that Windows key after first hitting Ctrl, I would cry a little on the inside. So after doing this one too many times, I finally dug into the Mac settings and found the way to change it — now I can use Ctrl for my shortcuts!

Unity workflow: expectations vs. reality

By this point I’ve gone through tutorials for both Unity and 2D Toolkit, and I’m really pleased about my decisions to use both. Unity is a solid engine and editor, and the fact that it can output to so many platforms with minimal hassle is really impressive. And 2D Toolkit is a fantastic extension — it essentially lets me forget about the fact that Unity is a 3D platform, which for this project is a big help.

But, working in Unity is a lot different than what I’m used to. Sure, it lets me use C#, which I already know. But I’m used to something like…

void main()

…and within that I would build a state machine and start making the game. Using that method, game logic is pretty straightforward (at least as much as a given game design will allow), but asset- and display-related issues (loading, drawing, animating, cameras, etc.) require a decent amount of work.

But Unity is not like that. I knew Unity was somewhat different than what I was used to — I had seen editor screenshots and skimmed a video or two — but honestly, I thought it was more or less the above but with something like 3D Studio Max built in for doing level layouts. Though my expectation of the scene editor was pretty close to reality, I was wrong about the coding aspect. There is no main(), at least not one that you have direct access to.

In short, to contrast the above, with Unity the asset- and display-related issues are essentially free — you don’t worry about loading things via function calls, just make sure they’ve been dragged into the appropriate scene and they’ll display. Same for audio: if a button needs to play a sound effect upon tap, drag the sound file onto that button — no loading required. Now, you’ll still need to write code, but not in the way I was used to. I don’t control the main loop. Instead, I write code files (“scripts”) that I attach to objects in a scene, and each object’s script is run each frame. It works, and honestly I believe this set up will end up being very efficient, but for now it feels very foreign.

I’ve resigned myself to the fact that — particularly because this is a new paradigm for me — I’m going to be doing a lot of things the “wrong” way on my initial implementation of Project Smart Birds. But in order to finish the project relatively quickly, I must. It will pain me somewhat, but I must! After the game is complete and I have learned enough to realize that I made some boneheaded implementation design decisions, I can go back through and fix things as warranted.

Not Corona

So I chose Unity, but my runner up was Corona. For iOS and Android games, Corona is certainly a solid choice. From what I gathered, 2D game development seemed more straightforward than on Unity. And it’s capable of great results — the polished Major Magnet for iOS was made with Corona and proves that point. But a few aspects helped push me to Unity:

  • Corona is multiplatform, but only for mobile devices. No PC, Mac, or console support. Those platforms aren’t my priorities, particularly not immediately, but I want them to be options.
  • Corona builds are made “in the cloud”. You can run your code on a simulator without building, but if you want to build, it has to happen via their online process. There’s a benefit: they update the SDK often, and you don’t have to worry about constantly downloading SDK updates. But if either you or they have network problems, you can’t build. And if the company ever goes out of business, effective immediately you can no longer make builds — unlikely, but still a risky position to be in.
  • Corona requires a yearly fee to keep using it. The per-year fee is less than a similarly-featured Unity license, but the Unity license is permanent for that version of the software. If this works out for me, I intend to do this for at least a few years, so the larger up-front cost ends up being a better option.


I’m using Unity to develop Project Smart Birds. Why Unity?

The game will be initially for iOS, but after that initial release I want to port to Android, PC, and Mac — and later on, perhaps other platforms too. To increase my chances of success, it’s important that I reach as many potential players as possible with as little extra work as possible. So using some sort of multi-platform SDK was a given. I researched my options, and Unity won out for these reasons:

  • It uses C#, which I have experience with from using XNA.
  • It supports a LOT of platforms, including web browsers and consoles. They support more platforms than any other SDK I could find.
  • Since it is already on the PS3 and 360, chances are good that it will be supported on the PS4 and 720 as well. Not that I’m anticipating going to these platforms anytime soon, but good to know that they’ll likely be an option.
  • Unity the company is established and successful. They’ve been around since 2008 and continue to grow. Sure, any company could tank unexpectedly, but all signs I can see point to this company to continue to exist and support the technology that I’m tying myself to.
  • A lot of companies are looking for Unity programmers. If my indie stuff fails, experience in Unity could help me land a job elsewhere.

The main con for me is that — right now at least — I’m making a simple 2D game, and Unity is more complex than it needs to be for 2D-only games. But luckily, Unity’s asset store has some solid 2D systems that are pretty inexpensive (I’m going with 2D Toolkit), and these help make this issue mostly moot.

All told, I believe that of the available options, I have the best chance of success — both immediate and longer term — with Unity.