Unity 2.5: The Fast Track To an Indie MMO?

The Need To Make An MMO

Sandra and I worked in the mainstream MMO industry for a long time, but a couple years ago, we stopped. We stopped because we better understood what we wanted: neither of us was real happy making MMOs. What we wanted most of all is to run MMOs. Unfortunately for us, running an MMO tends to require you to make one first. This is tricky, because the traditional AAA MMO takes three or four years and 50 people, and has a 50% chance of success at best. These are not odds we like.

So we’ve done other things — consulted on MMOs, web games, and all sorts of other things, and it’s actually been a lot of fun. But in the back of the mind there is still The Calling. So we tried to make our own indie MMO on the cheap. These were 2D or text-based, and we just couldn’t get into them. We needed our MMO to be 3D. We’re spoiled like that. And for practical reasons, we needed it to be web-based, because we can’t imagine being able to get a boxed product on the shelves.

But making an MMO is a huge undertaking. It’s not just a fancy 3D client; it’s also a scalable server, tools to develop and maintain it, and infrastructure to run it. But Sandra and I are experienced server engineers; we believe we can use off-the-shelf tools and some cleverness to make a reasonable little game server. And we are becoming more comfortable with various infrastructure approaches. But how do we get a 3D game on top of it? One that’s web based, too, and one with powerful development tools already made for us?

We tried various client applications, but they sucked. However, there’s a new contender.

Enter Unity 2.5

I’ve been watching Unity for a year or so now. It’s been frustrating to watch, because the numbskull developers created their first versions only for the Mac! (The resulting applications could run on any platform, but the development tools required a Mac.) When you’re an indie, it’s hard to justify doling out a few grand for a Mac in order to test-drive a piece of software you’ve never used before. This restriction didn’t stop Cartoon Network’s Fusion Fall from using the Mac-based version of Unity, but it kept most small developers, including us, on the sidelines.

However, two weeks ago they finally got around to making an accessible version of their program, one that runs on Windows or Macs. Finally! Sandra and I reorganized our schedules so that we would have a full week to experiment with Unity and a simple off-the-shelf server product called SmartFoxServer. Basically, we spent a week prototyping an MMO. Successfully.

What makes Unity special? Three things, in order of importance:

  1. An enviably powerful tools pipeline, 
  2. A rendering engine that works on any platform (and can run on web pages), 
  3. And a very reasonable price tag. 

Let’s go over each one.

1. The Development Pipeline

“Development pipeline?” you may be thinking. “Who cares! How many polygons can it push? How many draw calls does it take to render things? Where are the technical stats?!” That’s basically irrelevant for us. We can design our game to run well under whatever conditions the engine allows. This is fortunate, because tech-wise, the engine just doesn’t seem that amazing. If you’ve played Fusion Fall, you may have noticed the low framerate for relatively simple scenes. It’s just something that has to be worked around.

There are lots of free or cheap 3D engines out there, and many of them are far more powerful than Unity in terms of rendering. But those were completely useless to us because they had no tools pipeline. A real MMO needs a client program, sure, but it also needs dozens of man-years worth of tools to build the content for the client. Indies don’t have the resources for that.

This is where Unity 2.5 shines. The Unity development environment integrates directly with Maya, Max, or various other 3D clients, plus code editors, sounds, and Photoshop files, to make a really compelling development environment. Import your 3D characters and drop them right into the scene, then start scripting them to respond to animations. Create terrain in Maya or directly from within Unity. Configure the built-in physics engine, position lights in real time, and then run everything together, watch it work, and fiddle with things on the fly. This is a great way to prototype stuff. It’s fast, it’s efficient, it’s … pretty alien to most programmers. If you’ve learned to develop in Flash, it’s sort of that mindset: it’s more resource oriented than scripting oriented.

Placing an asset on some terrain

Placing an asset on some terrain I just made

This can take some time to get used to, but it’s plenty powerful and elegant when you do master it, and it’s sufficiently versatile that you can use it for a whole lot of games.

On the other hand, this complex development environment makes it harder for programmers to manage lots of code. For instance, scripts are attached to assets and then the script’s variables are individually configured. This is done automagically and makes for a very cool customization experience. But if you decide that you need to change the values of a variable, you may not be able to find all the uses of that variable with a text-editor search: the user may have overridden those variables in the project itself, leaving you with no way to find the values programmatically.

It also presents some co-authoring issues: you’re all working on the same assets, after all. Unity did a decent job of letting you merge projects together, but that’s only if each developer is working on completely separate parts of the client. If you’re each fiddling with the same prefabricated object, you’re screwed. You can’t merge the binary assets: somebody’s work is going to get lost.

So this pipeline is ideal for small teams, or for larger teams who have spent some serious planning time figuring out how each person is going to avoid stepping on other people’s toes.

But let me just quantify this toolset’s value: Sandra and I were able to download the demo version, learn how to use it, and then create a 3D zone with mobile, animated avatars that talked, punched things, exploded, lit on fire, and so on — in a week. We also had to learn how to use the server library we picked, too. Fortunately for us, SmartFoxServer actually comes with a demo that shows you how to synch up multiple Unity clients. We achieved pretty amazing results in a week, but we took advantage of a lot of demos and free assets to make it happen.

Still… this is an unsurpassed prototyping tool. Even if you don’t use it for the final client, just imagine that you could get your next prototype up and running in a week, then iterate on the design every day after that. Now you can. I wish we’d had this when we were trying to prototype Star Trek’s space combat.

2. Web Based 3D Out of the Box

Another important advantage is its flexible runtime environment. It runs on Macs and Windows. It can be a stand-alone program or embedded in a browser. And it isn’t hampered by the “you must support the lowest common denominator” mentality that Flash has. For instance, your game can support multi-button mice, even though Macs may not have them. Conversely, you can program for that weird meta-key (the Command key, I guess?) even though its analog on PCs is the Windows key — and when you press the Windows key in a web page, the web page loses focus. But I’m very happy that they just gave us all the obvious capabilities and left us to figure out how to sanely use them, rather than oversimplifying.

The compiled files are nice and small, for what they are. I was able to get a pretty complex scene, complete with lots of scripts, animations, and networking, into an 8mb file. (Of course, users also have to download and install the Unity plug in for their browser; that’s where the “engine” code lives.)

It also has some complex tools for data streaming, which we didn’t get around to testing out yet, but they seem pretty robust. They also require a lot of planning, but that’s still a whole lot easier than coding it ourselves from scratch.

3. Cheap Price Tag

The price is very reasonable. It’s a couple grand for Sandra and I to each get professional licenses. That’s it; no percentage cut or anything scandalous like that. You even get free minor version upgrades added in (which is good, because that’s the only way they do bug fixes).

It’s not dirt cheap, but let’s be realistic: 3D games are still expensive. Sandra and I made an off-the-cuff budget that cost $40k for 3d artwork. That’s peanuts compared to a mainstream MMO, but puts it well out of the reach of the very smallest of indies. If you can’t afford a couple grand for an engine, you can’t afford to make a 3D game just yet. Maybe in five more years it’ll be at the cheapness level that 2D games are… but it’s just not there yet.

(There is also a cheap “indie” license that costs $200. This is a good way to get started with development, but the restrictions mean it’s not too practical for developing a complete commercial MMO. It should work okay for other 3D games though.)

What’s the Down Side?

So the good news is that this is a realistic way for a small team to cheaply make an MMO. Fusion Fall already exists: it proves that it’s possible. But Unity is not without it’s painful side. Once again there are three main issues:

  1. Bugs
  2. Language Issues
  3. Documentation Flaws

1. Bugs

The primary down side is that Unity 2.5 crashes a whole lot. It’s essentially version 1.0 of the Windows line of Unity, and it shows this in its lack of stability. As the military would say, its “mean time between failure” is about one hour. This is not good. You’ll have to get used to saving every few minutes. But worse still is that two of our crashes caused the project to become corrupted. Maybe if we’d been more advanced with Unity we could have repaired and moved on, but as newbies, this was devastating. We lost many hours of work when this happened. We eventually instigated a “back up to a new folder every few hours” policy.

Obviously this needs to get fixed. Unity 2.5 has only been out a few weeks, so I am reasonably hopeful that they won’t leave us hanging for too long.

2. Language Issues

Unity has a schitzophrenic relationship with programming languages. Officially, it supports three languages: C#, JavaScript, and a variety of Python called “Boo”. But this is basically a lie.

It supports C# because it’s written in C#. This is the language you should probably use if you’re a team of experienced developers. However, none of the examples show how to use the code in C#. You will have to muddle with it for many hours to get the nuances.

It supports “JavaScript”, and this is the preferred language. The demos are all in JavaScript, and the code examples are in it, too. However, this isn’t really JavaScript. It’s an upgraded version that takes a bunch of ECMAScript features that aren’t in JavaScript. Then it tosses in some special functionality specifically for Unity. And then… it doesn’t document any of it. There is no language reference for their made-up version of JavaScript.

The support for “boo” is entirely mythical. I’ve seen no code for it ever, nobody on their forums uses it, and it goes without saying that there is not a lick of reference to it in their help. You’d be really stupid to decide to use boo for your project.

More annoying still? The languages are poorly interoperable. We were pulling in code from lots of different demos, and needed to use both JavaScript and C# code in the same project. It turns out that when you have two languages in use, there are dependency issues that can only be worked out by sticking your code in special “load me first” directories. Very kludgey. At least it can be done. 

3. Documentation Flaws

The “Unity Manual” is a tiny wisp of a thing. There are no real docs on how this stuff works. What there is, is a massive step-by-step tutorial that teaches you how to make a platform game in Unity. This is awesome… if you’re the sort of person who learns by doing. I am the sort of person who prefers to absorb all the data available and then start exploring. I simply can’t do that with Unity. Those docs don’t exist. For a commercial product they are significantly under-documented.

Expect to spend days just screwing around with the demos in order to have any clue what’s going on. Expect to search frantically through their forums in the hopes of understanding the syntax for their scripting languages and complex GUIs. Expect a few sudden jarring inconsistencies in what is otherwise a smooth and orthogonal interface.

The docs looked especially paltry when compared to SmartFoxServer’s luxurious documentation. Yes, SmartFoxServer is a much simpler piece of software than Unity. I don’t care though. Fickle that way. Need docs.

The Bottom Line

If the question is “can Unity be a viable MMO client?”, then it’s been answered by Fusion Fall: “yes”.  But the neat thing about Unity is that after spending a week with it, you would easily come to that conclusion on your own.

It’s not for everyone, of course. If you can’t deal with the relatively paltry graphics level allowed, or if you need your tools to conform to your existing pipeline, then you’re not going to like Unity. You have to be agile enough to work with it instead of against it.

But after a week of using it, I’d have to say that Unity feels pretty good. Maybe this program is the missing piece in our indie MMO plans.

This entry was posted in Design, Production. Bookmark the permalink.

8 Responses to Unity 2.5: The Fast Track To an Indie MMO?

  1. John says:

    That’s amazing. I’ve seen shots of Fusion Fall, but no hands on. Looked clean enough for an MMO from CN.

    So does this mean you will be going ahead on a new game? If so, any plans on development updates, such as via Twitter or prod diaries?

    Would love to keep track.

  2. Paul Darcy says:

    A refreshing review model you have here. Actually using the software rather than telling us what the web site or PDF’s sent from the company say. Well done and thanks for taking the time.

  3. CaesarsGhost says:

    Did you ever gander at Panda3D? It’s also viable (and free) for MMOs as proven by Disney’s ToonTown Online and Pirates of the Caribbean Online.

    Unlike Unity, Panda3D Source comes with it. Making it easier to alter.

    The Engine is made in C++, but the scripting is done completely in Python. There’s, literally, hundreds of tutorials for it.

  4. jason says:

    This is exactly the path I’m planning to take. I heard about Unity right around when they announced the Windows version and instantly got excited by the potential (in browser 3d!!). Now I’ve got a copy, and I’m heading up and over the learning curve. It’s pretty amazing how quickly you can dive right into game logic with this engine!

    Thanks for sharing your thoughts.

  5. Wayne says:

    Sounds like a pretty neat tool. Now get a game out there for us to test! :)

  6. Tim says:

    I have to say I’m far more interested to know how well your integration with Smart Fox Server went. There are clients by the hundreds (good, bad and ugly), but the number of MMO-worthy server technologies is about zilch.

  7. Alvin says:

    That is amazing. I’ve seen shots of Fusion Fall, but no hands on

  8. Pingback: Elder Game: MMO game development » Unity 2.6 for Indie MMOs? Yes! (But…)