Unity 2.6 for Indie MMOs? Yes! (But…)

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 …

This entry was posted in Production. Bookmark the permalink.

18 Responses to Unity 2.6 for Indie MMOs? Yes! (But…)

  1. Jason says:

    Great post.

    I’m doing much the same – using my “spare” time, evenings and weekends, to work on a little boutique MMO.

    I’ve done it before (last year) with a Flash frontend on a Java backend and have now for this project switched to Unity. Unity is pretty fantastic from an engine viewpoint.

    I am not entirely happy with the somewhat gimpy C# support (no namespaces? Really? Eww.) But other than that, it’s a near perfect front end engine. Especially with the full on .NET socket support.

    My major task right now though is the server – the client has some challenges but the server is where the pain is right now. What are you guys doing for server tech?

  2. Eric says:

    We use SmartFoxServer as a thin shell to put our Java code in. We transmit everything as pseudo-binary data using SFS’s “string” transfer mode, and don’t use a lot of the other stuff (like auto-propagated attributes) because it’s too bloated. So it mostly just gives us a simple “zone” architecture and a place to stick our code. And it has a few free features (like a Flash admin client you can log in to) that save time, too.

    What sort of problems are you running into with your server? Is it that you need a physics model server-side?

  3. Jason says:

    Not right now no – but we need smart serialization for one. We’re using Externalizable and Serializable to do binary serialization of objects over the wire, and I just finished rewriting a big chunk of that code to do the serialization nicely (more easily implementable in C# than the standard Java serialization).

    One of the other things I’ve written (both for my old MMO and this new one) is a DTO code generator – it inspects the Hibernate entities for DTO annotations and then whips up DTOs for them. I was doing it manually for the first few months of my first project and then after I lost a lot of hair I finally automated it. That also allows you to automatically generate the Externalizable code as well.

    Once I’m well and truly done this serializable stuff, I just have to implement it on the C# side and make a little RPC wrapper thingy so that the C# client can call services on the Java backend.

    I am really not at all a fan of SFS – for my money it gives us basically nothing. In fact both for the work project here and my own little MMO we’d independently evaluated it and given it the thumbs down. The design is bad, the code is bad, and at the end of the day all you have is a decent performing chat server.

    I’m looking forward to playing with scaling up the server side zone managers – since my day job is all about massive scalability, a lot of that is leaking over to the side project. Probably a bad idea, but I have a hard time doing things the quick and dirty way sometimes. :)

  4. Glenno says:

    Hi Eric,

    Very informative post. Im currently evaluating Unity for our company. Ive done all the tutorials and it seems too good to be true. Now youve made me wary..well, i was already, as I have to get this recommendation right to my boss.

    For me.. its selling point, is that the game engine that i’d have to spend a few weeks/months writing. Its already done. It IS the game engine. But bigger, as you said more esoteric game play/techniques is what we will want to be doing, no-one wants to churn out reskins of the tutorials(which will be flooding the internet soon, unfortunately).

    But is it really as bad as you say? The deeper, more powerful side that i’d just assumed is there when i get to it.. youre saying is a bit thin on the ground?

    btw Jason, Ive used SFS for a mini 3D chat game in shockwave(of all things), almost exactly as Eric described it. I wouldnt go so far to call what Ive written an MMO, but SFS works fine for us. If I wrote it again, or wrote another one.. SFS might be slightly too bloated as you described it for a simple 3D chat. But the future plans, meant we wanted something slightly beefier to handle more functionality later.

    Our 3D chat is a facebook app(unfortunately), here
    http://apps.facebook.com/yoglobe
    if you felt like having a look.

    Cheers, keep up the blog..
    Glen

  5. Jason says:

    I’ve done commercial work with SFS. I’d say it’s just as I described it as well. if you want to chat, it’s probably fine for that. But it really is junk for anything more.

    Everything it does can be replicated by a good server side Java programmer in a couple of weeks and not suck. For instance, you know what SFSs scalability solution is?

    Answer: They don’t have one. They use Terracotta.

  6. “Very little is known about Unity 3″
    This has been announced: http://unity3d.com/unity/coming-soon/unity-3 It does not contain all the stuff that will be in 3.0, but major stuff is in there. What else do you want to know?

    Is the API mostly backwards-compatible? No clue.
    “Mostly”, yes.

    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?
    Depends on how many undocumented stuff you’re using. We ourselves usually spend about a day to convert a full, existing game project. Most areas of changes that we expect: custom shaders and lighting. Otherwise, not much change in behavior.

  7. Eric says:

    Jason – ah, we are doing it by hand, more or less. The Serializable interface has been very slow for me, so we don’t use it for much (except saving characters in a transient state when they go between “zones”).

    In general we are wary of doing any infrastructure work that takes more than a few hours, because every hour that isn’t “making the game” is an hour less of features that will be in the game. So I made some simple wrappers for manually serializing variables and common game object to the socket stream, and I made identical ones in C#, and we manually update both code bodies whenever we add a new network action. It hasn’t been an issue so far, and we have scores of message types. If we get to the point where there are hundreds, we’ll have to reconsider.

    In places where we DO need automation, I’ve had good luck using Unity’s editor-scripting functions to generate data files (and even Java code) for us. For instance, when we place spawners on the landscape in Unity, we simply attach a special component to them, and a Unity editor script emits their relevant data to a JSON file that the server can read.

    So when it comes to data-management, some simple tools save a ton of time. But having used (and written!) many automated serialization systems before, I don’t feel that the cost-to-benefit ratio makes it worthwhile for us in that instance. But obviously YMMV :)

  8. Eric says:

    Glenno – it’s a mixed bag. Some things just end up working great even though the docs aren’t really good. For instance, the streaming technology is really neat, and we had it working great without extra docs. (They also released a demo app that shows a different, very clever way to stream parts of characters. That demo is really complex for simple streaming uses, however…)

    The physics system is also not very well documented, but it “just works” for everything we’ve needed, even some weird special things.

    On the other hand, we use headless clients (that is, graphics-less clients that have no GUI, just attach to the server and do logic) for various things such as load-testing, and making that work well has been a mess. In “headless” mode, the client behavior changes in lots of subtle undocumented ways… very frustrating.

    On the other hand, I haven’t yet hit a point where I simply can’t do what I want to do at all… sometimes I’ve just had to dig around for a solution for a long time, and a few times I’ve had to rewrite an entire system when I hit a dead-end, but so far I’ve not been completely stumped. So that’s good.

    I guess If I were you, I’d try to list out all the areas that might be considered “complex”, and see if you can find APIs and functions that handle them. If there’s something that you can’t see how you’ll be able to do it, odds are you will end up needing to spend a fair amount of time to figure it out.

  9. Eric says:

    Aras Pranckevičius – thanks, yeah I’ve seen that page. Your experience with upgrading is very good news to me!

    One thing I’ve wondered, will it be shipping with the .NET System DLL? Currently if you want to use sockets, you end up needing to include this 1mb DLL in your downloadable program. It makes it harder to get file sizes down small.

    I have a lot of technical questions… I guess I am just surprised that they don’t have an ongoing Q&A to talk about Unity 3 in more detail. It’s all been very closed.

  10. @Eric: there is a plan to have sockets built-in in the web player install, yes. Whether that will be System.dll or via some other means, I don’t know.

    Why we aren’t talking about more details: because of bad past experience. Every time we said “we’ll try to make this work, but don’t hold your breath”, people read into that as “this will definitely ship”. So we’re trying to talk about the things we’re 190% certain will ship.

  11. Andy Korth says:

    I’ve been using Unity3D for about a year and a half now. We’ve made 3 large webgames as contract projects and we’re working on our own self-published title in Unity. Our saying is: “Unity makes a lot of hard things easy, and a lot of easy things hard”.

    It seems you share our experiences exactly. While the demos work great, and Unity is fantastic for artists to see their models in action, it falls apart when you are finishing an actual game. We do run into crashes and bugs on a daily basis, including some very painful data-loss issues with prefabs loaded into a scene. We run into scaling issues in nearly every project, and sometimes the functionality to fix them just isn’t exposed by Unity. I have a bunch of issues open in Unity’s bug tracker. Sometimes they are fixed, sometimes they are closed without comment (which might mean they are fixed), and sometimes they just stay open forever.

    I don’t mean to bash on Unity here, since it is a fantastic product. I am just coming to believe it’s better suited for mockups and tech demos than actual polished products. Documentation in the product is good for beginners, but it’s too light on the advanced features. The actual GL classes have to be figured out by trial and error.

    I had the opportunity to try out Unity 3.0, and I agree with what Aras says. We were mostly able to convert our project in half a day of work. There were a few changes here and there- places where the API isn’t backwards compatible genuinely needed the API improved anyway, so I don’t mind there. Unfortunately, it seemed like some key drawing features might be removed and not replaced. I asked Samantha how final those changes would be, but they never got back to me.

    I’ve also heard a few other Unity old-timers lament the decay of the quality of the community…

  12. Marshall says:

    Eric,

    You probably heard that Ryzon has released its engine under a GNU license and art assets under a Creative Commons license. I don’t know much about the game itself, but releasing a commercial (i.e. generally functional) 3D MMO as an open-source alternative does seem like a potential windfall for indie MMO development. What do you think?

  13. Marshall says:

    Oops, spelled it wrong (Ryzom) and forgot the link:

    http://dev.ryzom.com/news/13

  14. Porter says:

    I wasn’t aware unity even had the ability to program an indie MMO, pretty neat. I’ve only messed with flash myself, but I found this article pretty interesting. I completely agree with the support issue, making it free basically destroyed your quality support for good. Hopefully 3 is top notch and pulls things back together, I’ve heard good things, I would hate to see it die off.

  15. JasonM says:

    @Porter: It should be clarified that Unity3D does not actually have the capability to be an Indie MMO. It merely has the capability to be HALF of a MMO, the client-side. You would still need a Server-side component to go with it. It can do multiplayer networking, but that isn’t the same as an actual MMO, that is simply smaller scale networking (peer to peer).

    @Marshall: Everything I have heard about Ryzom indicates that the code would be considered spaghetti and poorly documented. Now, making it open source could allow some dedicated and hard-working folks to clean it up perhaps and turn it into a decent product. And that would definitely be exciting for the Indie community.

  16. Christian says:

    I would be interested in seeing the MMO you are building.

  17. Mike Hillyer says:

    Any chance you could do a little write-up on what’s involved in bending Unity into an MMO? I’m interested in doing a small indy project myself and would greatly benefit from knowing what’s involved.

  18. Joe says:

    I think for all but those with professional experience, the 2D route is superior for an Indie MMO. I’m anxiously awaiting the 1.0 release of NetGore.