Almost a year ago I wrote an explanation of  what we were up to for the Unity community. It explains the thinking behind it all and what we thought was the challenge of making a game such as Man vs Machine. I have now posted it again down below and updated it with name changes and shortened the text to increase readability:

Making Unity into a powerful seamless MMO engine.

As you might have noticed, we have made:

1. uLink – a network integration showcasing the future of network development.
2. PikkoServer – a server layer that scales Unity servers into a dynamic cluster.
3. Man vs Machine – a browser 1000-player FPS game.

For most people, we might seem to have popped up from nowhere so I thought I’d take this opportunity to explain a little bit about who we are and why we did such a crazy thing. And to take the opportunity to mention the main technological challenges we encountered.

As it happened, our team got the chance to spend a few years on whatever we wanted to do and we decided that we wanted to change the way networking for games was done.

Network development in games used to be a disaster from so many angles and it suffered from both technical and organisational problems. It was very unforgiving to be a network programmer and the task did not work well with the “crunch n’ patch”-development culture. In this stressful environment, your tools need to be just as your best friends: reliable, helpful and direct. They should be able to handle that you happen to have a bad day, support you when you get that crazy idea you want to show the world and they should just be there, making those boring everyday chores joyful.

We had been talking to CCP about a great way to demonstrate what our group thought would become the future of network and server software technology. We agreed that if we could retrofit Unity and make it into the most powerful MMO engine in the world – and show that you could play a fast paced MMOFPS-game with it, it would be the ultimate proof. Since there is a small but significant trade-off between a little more latency for a lot more CPU-power in the Pikko architecture, a massive FPS seemed like a great idea.

uLink

We already had a small crush on Unity long before we started developing these products. However, we thought that it was only half of an amazing engine since it had very rudimentary networking capabilities. At first we didn’t think we would build a complete network integration but after learning that Unity was pushing network developers out of their editor, we realized that something needed to be done about it. That something was uLink.

The more we worked with uLink, the more we fell in love. First with uLink itself, then with Unity and then with uLink, again. We built a special network torture chamber for it (using the automated testing tool Tsung), in which its every little aspect got hammered to the extreme, over many months. We put it in the hands of 3D artists with no real network experience as well as in the hands of veteran network programmers. The more we abused uLink, the closer to perfection it became. I would be very surprised to hear someone do something horrible to uLink that we had not already done in cubic-metrical-dimensions worse. We simply wanted uLink to be that friend that you always could count on. So we tortured it like a sadistic little kid.

But having built a network integration from the ground up was necessary because we needed to know every little row of code and every little package in the network in order to be able to do what we were about to do next.

The road to PikkoServer

We come from a pretty small Swedish town, Uppsala, that is most famous for its university. Our professors decides who will get the Nobel Prize but in general nothing really exiting happen here. Surprisingly, Uppsala University had become the scene of a small but stubbornly growing community of telecom programmers that used and developed Erlang. Erlang is a functional programming language originating from Ericsson and it has some truly amazing properties for networking. It is scalable, concurrent and very reliable. We dreamt of making a game engine’s server side behave as if it was programmed in this network optimized programming language.

We were not alone in thinking along these lines. Our friends at Artplant went for the straightforward approach when they made the Battlestar Galactica MMO with Unity as the client, and their entire server side in Erlang. I met their CEO, Jack, not long ago and he told me that they had not had one (1) server crash since they launched. He smiled. I smiled. He smiled more. Then we said the word we were both thinking out loud together. “Erlang”. (I imagine there are quite a few guys reading this and nodding in recognition of the similarities between the Erlang community and a religious sect). Even though Battlestar Galactica is a great game, and even if we have been helping out Artplant a (very) little bit with both the database and software design issues for their game, we do not believe that game developers should be forced to learn functional programming and have to throw away all the hard and excellent work that have already been put into their game engine.

Being a tool

I often bore my surroundings by regularly finding reasons to tell them that we as humans are defined by our tools. You and me are genetically the same as our cave crawling ancestors but as we look at our civilization and our human capability today, it is all there thanks to our tools. It is usually at this point that the other people in my team starts hiding away the red wine and clear the room of fragile minds and stuff. What if making tools made you into a tool? Or even stranger, what if you could take the idea of a tool and then use that tool in such a way that you could change one tool into another tool? Well, it doesn’t make that much sense but this is actually what we did with Pikko Server. We took the idea of Erlang and made a server layer that made the rest of the server side behave as if it was all done in Erlang even though the game programmer didn’t have to type one single row of functional code.

But we didn’t stop there. No, we had just opened the door into something that held much more potential than simply solving scalability over the CPU. We could now deal directly with the traffic between the client and the server, which enabled us take a broad and serious grip on addressing bandwidth management, network LODing and other optimizations.

One thing is many things

We have of course done many brilliant and stupid things along the way that would most likely deserve to be mentioned, but really, most things are better experienced rather than talked about. Still, one thing that have made people understand the potential in the technology we have been working on, is worth mentioning. That is our load balancing simulator demo MastSim.

I’ll post a video about it later.

A world record

We made an early prototype of Man vs Machine working with PikkoServer and Unity, pretty fast. But at the very moment we had made it we understood that it was pretty pointless. Of course, we had made an MMOFPS and it worked just as we wanted it to do and that was pretty awesome. But it was a little bit like being the first to climb Mount Everest and finding out that all the people you wanted to celebrate it with was still down at base camp. Or at home. So we either needed to spend a lot of time explaining how wonderful it was on top of the highest mountain in the world – and still not be able to make the feeling justice. Or we could build an escalator up to the mountain top and make it so damn easy to be there with us, and we all could party together like furry animals! You already know what we did…