For years, Sandra and I have wanted to make a 3D indie MMO in our off-time (those weekends and off days between the contracting gigs we do to pay the rent).
Unfortunately, making a full 3D MMO on just a few days a week is very hard. We’ve tried it a few times in the past, but when it comes time to make the timeline projections, we always shelve the idea. The problem is, we have a lot of experience in the industry, which keeps us from trying to do things that are “stupid” and “irrational” and “never going to work”. Industry-naive developers can sometimes pull off amazing miracles by sheer insane doggedness — and by not knowing that what they’re doing is impossible — but we know the actual amount of time each feature is likely to take, and we know from experience that by the time you finish the “engine” parts, you’re so focused on technology that you don’t have any mental room left to make the game itself.
The thing is, players don’t give a crap about the technology. They care about the game mechanics, the graphics, the atmosphere… but not the tech. So what we need is a way to skip the “engine” part and get to the part that matters.
So naturally we keep a close eye on all the MMO-capable “engines” (or engine parts) as they showed up. Mostly these are pretty useless. There are dozens of MMO engines that sound great on a website somewhere, and then you download them and realize that step #1 is “write 75% of the engine” (such as Project Darkstar, which is not much more than a handful of low-level server-side architecture primitives) or “refactor the engine to be usable” (such as Ryzom engine, whose code is an utter mess at the moment). These projects have ongoing developer support and some day they may be amazing. But that’s not helpful now.
But one product has stood out to us as being a viable client-side 3D platform: Unity. Not only does it have a really powerful development environment, it has a web-player that lets people play Unity games in a browser. That’s huge for indie games because it removes one of the biggest hurdles: convincing people to download your product and install it. Combine Unity’s network-friendly architecture and primitives with a simple server like SmartFoxServer, and maybe you’ve got something workable after all.
Unity 2.5: Not Good Enough
Sandra and I played with Unity 2.5 back in April of last year. We were very impressed with what we could accomplish in just a single week, and we were totally jazzed about going forward with it. But it defeated us: Unity 2.5 wasn’t really usable for MMO development.
Although Unity said that Cartoon Network’s Fusion Fall MMO was written with Unity, that was a lie of omission. Sure, Fusion Fall used Unity. They just used a special version with all kinds of cool powers you couldn’t replicate in Unity 2.5. We were quite frustrated when we couldn’t do the same tricks that Fusion Fall did. For instance, we couldn’t really stream character assets the way Cartoon Network’s game managed it: the features just weren’t there. That meant we would have to be really picky with our assets, because the options for streaming were very restrictive. That was pretty depressing.
But what really killed Unity 2.5 for us was the crashes: Since Unity 2.5 didn’t support typical version control products, we had a hell of a time managing our work between two programmers. (The entire project was stored in proprietary binary files.) And sometimes when it crashed, those binary files got corrupt, and you lost all your work since the last manual backup. So we hung up the Unity project and went back to doing actual lucrative work.
Unity 2.6: Huge Improvement
Well, a couple months ago we got that itch again. Unity 2.6 has been out for a while, so we dove in — and it was a huge improvement. In fact, yesterday we bought the first of at least two Unity Pro licenses. At $1200 each, that’s not a snap decision, but we believe that this time our MMO can really happen.
We’re happy with the product, and we’re amazed at what we’ve been able to accomplish in about two hundred hours of development time: we have an entire working proto-MMO, complete with melee combat, projectiles, inventory management, skill systems, shops, harvesting, and more. By letting us spend our time on these game systems instead of the nuts and bolts of 3D displays and asset streaming and so on, we have been able to do a ton of game systems very quickly. We’ve got an indie art team making art for us and things are happening at a rapid pace, given that it’s a side-project done in our spare time.
However, working with Unity 2.6 has a down side, and that down side is that Unity is only magical when it’s magical. But first, the good stuff:
It’s got everything Unity 2.5 should have had.
Unity 2.6 inherited a bunch of nice features that were originally written for the Cartoon Network folks. You can now stream any kind of asset, and there are a lot of powerful mechanics for managing streamed data. This is a lot more like it — making a tiny lightweight game is actually possible now!
Plus, Unity 2.6 has support for actual version control systems (instead of just their overpriced proprietary solution). When enabled, Unity creates a binary data file that stores the “compiled” data for each original asset (be it a source-code file, a JPG, an animation, whatever). So to version things, you put both the original asset and the binary Unity file into your SVN repository. Ta da!
Perhaps most importantly, it’s a lot less crashtastic. Well, it still crashes plenty (mostly when your code dereferences a null pointer in a fragile state such as during a screen refresh) … but it doesn’t crash completely randomly. And when it crashes, it almost never corrupts your assets anymore. And if it does corrupt your assets, you have several ways to fix it: you can reimport the single damaged asset or you can reload stuff from your SVN repository, for instance. You aren’t just stuck with a corrupt project forever.
As an added bonus, Unity 2.6 has a built-in animation editor! (You would be forgiven for thinking that came with Unity 2.5, as I initially did. It was in earlier versions, but they actually took it out for Unity 2.5, and put it back in for Unity 2.6.) While you could theoretically animate anything in this animation-editor, it’s really designed for background animations, special effects, and the like. For instance, the fish in our lake swim about on an animated path. Certain special effects cause creatures to pulse a glowing red color, which is also done as a Unity animation. It’s a great tool for little snazzy tricks. It’s a bitch to figure out how to use it, but it’s still a million times easier to understand than 3DS Max. So that’s good.
So Unity 2.6 is a perfect tool of development wonderment, right? Well, once you get over the learning curve, yes, for the most part, it is. But outside of the product itself, things get scary.
Uh … Support?
When I was first using and learning Unity last year, the forums were abuzz with feedback from the Unity team. Unity employees actually helped people figure out problems and worked with us. That seems to have stopped. There’s one or two posts a week where QA will pop in and say, “Is that still happening? Send me a proper bug report,” but that’s it. For a young product, support is essential. Bug fixes are essential. There should be patches to the development platform every few months, not one per year. What the hell is going on over there?
In fact, I was pretty annoyed when they made Unity Indie a free product. I wasn’t upset because I’d already paid my $200 for an Indie license — I was upset because of the subtext: when you make your product free, your support quality goes way down. When the barrier to entry was $200, there weren’t very many 13 year olds trying it out on a whim. Now that the introductory product is free, though, there are so many newbies using the product — and let’s be quite frank, most of them are complete newbies to programming — how could Unity possibly keep up with their friendly forum support?
The answer, of course, is that they haven’t. They created Unity Answers where developers can help other developers. This works great for easy questions (newb questions and the like). It doesn’t work at all if you are having an unusual experience or trying to do something esoteric. Best case is that you will get an answer that restates the documentation, sometimes slightly more clearly. Normal case is that tough questions are ignored. Worst case is that some Internet Super Hero will ride in and tell you how you’re doing it wrong anyway (at a philosophical level that ignores the actual problem, such as “Unity isn’t ideal for manipulating textures; you should have the artists do this in Maya”), and then ride off into the sunset.
And speaking of Internet Super Heroes… there’s a lot of them now. While there are still a good number of really smart developers on the Unity forums, and I still search there when I have a problem, the fanboys are also a lot more prevalent now. For example: I found a fairly annoying bug in Unity 2.6′s streaming loader, but when I asked for a workaround or confirmation that it was a bug, a fanboy told me that I just needed a better webserver. (A better web server to keep my client from crashing?) I pointed out that Flash player’s streaming loader doesn’t have trouble on the same server (when streaming much larger files), so that ruled out my webserver as being the primary culprit. To this, I was told that I was clearly wrong, or I didn’t know how Flash worked, and there are no Flash games anywhere near as big as Unity games, and anyway Flash doesn’t cache files (!), and so on.
Basically if people bothered to talk to me at all, it wasn’t because they had advice to offer. It was because they felt they needed to stick up for Unity since the employees can’t manage to even read all the threads on the forum, let alone respond usefully to them all. Gee thanks, guys.
The kicker is that I eventually found a couple of blog posts in a corner of the internet discussing the bug, where Unity’s developers acknowledged that it was a tough issue because the fix was very browser- and OS-dependent, and that they are still trying to find a clean fix for it. That’s all I wanted to know — that, and maybe a time estimate. I understand that it’s a hard problem, and I wasn’t demanding a hot-fix that afternoon. The last thing I needed, though, after hours of banging my head on a problem, was to be considered a troll.
I’m not a troll. I’m a developer who hates spending hours and hours of his weekend researching undocumented functions because the docs are shit and the forums are unsupported. The docs are adequate for easy stuff (now), but once you leave the friendly happy land covered by the demos, the docs become more and more skeletal. You just try making a complex graphical Editor plug-in, or doing fancy things with the “headless” command-line client, or adding GUI features like focus-management to your game. (These all require using undocumented functions and techniques. At least in the latter case, the forums have a few clever people who found the undocumented functions and showed how to use them.)
For these sorts of things, I would be happy to pay a nominal fee for support. Let me give you a few hundred bucks for you to answer my damned questions, PLEASE.
Unity for iPhone: Completely Dead or Just Mostly Dead?
Unity has been focusing a ton of their effort on iPhone support. It gets more updates than the main Unity product does, and obviously a lot of Unity’s attention is on it. The reason is obvious: developers are paying for Unity iPhone licenses.
Well … the writing is on the wall for Unity for iPhone. The next big iPhone upgrade explicitly disallows most kinds of third-party development tools, and explicitly states that:
Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).
Wow. Bye-bye Unity for iPhone. The forum users are hoping this somehow doesn’t apply to them, but come on. It’s pretty darn clear. It says iPhone programs have to be originally written for the low-level Apple APIs. No matter how you phrase it, Unity apps are not written “originally” for WebKit or Objective-C. They are written in Unity and transliterated into Objective-C. This is clearly no longer allowed.
Steve Jobs weighed in on why he did this: it was to kill Adobe’s new Flash-to-Objective-C compiler product. Now, many of his arguments are bull (such as Flash not having multitouch support, or all that talk about how important “rollover” support is). But I saw Flash running on an iPhone at a conference a couple months ago, and it was really, really slow. I can see him wanting to ban products running this poorly. Unfortunately, this also quite clearly covers Unity, too. Steve goes on to say:
We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps … we cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.
This becomes even worse if the third party is supplying a cross platform development tool. The third party may not adopt enhancements from one platform unless they are available on all of their supported platforms. Hence developers only have access to the lowest common denominator set of features. Again, we cannot accept an outcome where developers are blocked from using our innovations and enhancements because they are not available on our competitor’s platforms.
Flash is a cross platform development tool. It is not Adobe’s goal to help developers write the best iPhone, iPod and iPad apps. It is their goal to help developers write cross platform apps. And Adobe has been painfully slow to adopt enhancements to Apple’s platforms. For example, although Mac OS X has been shipping for almost 10 years now, Adobe just adopted it fully (Cocoa) two weeks ago when they shipped CS5. Adobe was the last major third party developer to fully adopt Mac OS X.
This applies to Unity too. Third-party layer? Check. Cross-platform development tool? Check. Now it’s true that Unity apps perform a whole lot better on the iPhone than Flash does. But that doesn’t seem to matter here; Jobs’ same arguments clearly apply, in principle, to Unity. If Unity finds a technical way to weasel around this, you can be sure Adobe can do the same. And if Apple just selectively bans only Flash but not Unity that would seem to open them up to lawsuits.
Unity’s CEO has posted about this on the Unity blog, saying, in a nutshell, that Apple hasn’t explicitly told them personally that they are screwed, so they are optimistic. That sounds crazy to me, but what the heck do I know. Maybe they will be fine. Maybe they have a crazy hail-Mary plan. Maybe the Department of Justice will save the day. I just know that if I were making iPhone apps, I would be exploring new platforms right about now.
I don’t mean to say they’ve been ignoring non-iPhone development. They seem to be working hard on a new major revision, Unity 3. But if Unity’s iPhone support is killed, there is a silver lining: 1) I don’t want to make iPhone apps anyway, and 2) maybe they will start working on the web player more aggressively again. Partnering with somebody to increase the installed browser user-base would be great.
Unity 3
Very little is known about Unity 3 — which is terrifying since it ships in a few months. We know if you buy a 2.6 license now, you get a free upgrade to Unity 3. That sounds awesome! But in practice it seems to mean that they have stopped bug-fixing Unity 2.6, so we’re probably going to need to upgrade. Will that be hard? No idea. Is the API mostly backwards-compatible? No clue.
They showed off some cool GUI features on the blog. The features are cool. But what I want to know is: will I have to rewrite big chunks of code (such as my GUI code, rife with those damned undocumented-function calls)? Or will I just need to spend a day or two in code-upgrade hell? This is a pretty important question for me. If you’re worried about it, you should probably wait to buy until Unity 3 comes out. Although if you do, you will lose out on the pre-order discount pricing …
So do I hate it or love it?
If I come across here as schizophrenic in my opinion of Unity, it’s because I am. First, I love it. It is the only way a couple of developers like Sandra and I can realistically make a full 3D MMORPG on a part-time schedule. There is no other product that can realistically do this given our limited time constraints. And I am pretty confident that the performance and stability can reach satisfactory levels.
On the other hand, the lack of good docs are a severe hindrance, their sluggish bug-fixing pace is irritating, and their lack of web support presence can be infuriating. Add in my other fears: that Unity 3 will be a hellish upgrade or that Unity the company may actually go out of business if the iPhone product dies. So maybe it’s not such a good time for you to be following in our footsteps and making your own Unity MMO.
And anyway, we really don’t need the competition …
