Search Unity

  1. Unity 2019.1 is now released.
    Dismiss Notice

Making Unity into a powerful seamless MMO engine - behind the scenes

Discussion in 'General Discussion' started by Christian_Lonnholm, Mar 11, 2011.

  1. Christian_Lonnholm

    Christian_Lonnholm

    Joined:
    Mar 9, 2011
    Posts:
    128
    As you might have noticed, we have made:

    1. uLink - a network integration showcasing the future of network development
    2. Pikko Server - a server layer that scales Unity servers into a dynamic cluster
    3. Tank vs Robots - 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 Pikko Server

    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. One solution might had been to make an object oriented script language that extended into functional scalable code. This would open up, in theory, that you could port game code back and forth.

    RocketScript

    Our team made shock waves within the Erlang community, when we were the first to have made a complete object oriented language, RocketScript, that extended into functional Erlang. It had been something of a Holy Grail for a group of code hipsters and academics that saw it as a way to popularize functional programming. However, we also saw it for what it was, and we actively discouraged people to use shortcuts such as RocketScript, as it turns out to be an awful way to produce functional code. This generated even more shock waves. People saw us throw away their Holy Grail, but it was a well grounded decision. RocketScript was simply not the way forward to make the future of network games. The still unmade games of the future deserved better.

    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 Tanks vs Robots working with Pikko Server 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...

    The world record game is not a simple PR-gimmick but the last step in a long series of tests that defines the new frontier of MMO technology. We have added a lot of busy sleeps in the server and we have bloated player states just to make sure that this is as far from an ideal lab experiment as possible. So, without these extra loads, we could of course handle a lot more players, but then it would have said very little about how a typical game would behave together with Pikko Server. I guess I am trying to say that Tanks vs Robots does not demonstrate the outer limit of our technology, but rather defining its starting point. If you want, you can take part in changing how MMO works. Our failure or success will only be a few clicks away in your browser.

    ...
     
    Last edited: Nov 2, 2011
  2. Christian_Lonnholm

    Christian_Lonnholm

    Joined:
    Mar 9, 2011
    Posts:
    128
    Here is a perfect place to mention how generous Jacky Mallett at CCP was and how she helped us polish the framework and the theoretical foundation of Pikko Server. Because it often doesn’t matter how great your technology is if no one can understand it but yourself. She is one of the greatest engineers we have encountered in our professional lives and we have been very fortunate to have got to know her.

    We have made a lot of effort in trying to educate our users in how our tools work but even more time have been spent on making the tools so usable that they often do not need much explaining at all. For example, if a Unity developer would like to make an MMOFPS such as Tanks vs Robots, all the developer needs to do differently is handle mainly four new RPCs. There is no reason why performance and usability are so often pitted against each other. Why choose when you can have it all?

    ...

    This post became much longer than I expected. If you made it all the way down here, you better let me know what you think with a comment. I will gladly answer any questions even though I might be a bit slow since there are a lot of things that needs my fingertips. Eventually, I will answer them all - don’t worry.

    Christian Lönnholm, CEO Pikkotekk / Unity Park
     
    Last edited: Nov 2, 2011
  3. larvantholos

    larvantholos

    Joined:
    Oct 29, 2009
    Posts:
    668
    So >.> I'd like to help you out, but you forgot to link to this mmofps which sounds pretty awesome. These products you've developed are so neat, I hope it goes a long way into continuing to make unity a standard fun easy to use game engine many of us have come to enjoy working with.
     
  4. Christian_Lonnholm

    Christian_Lonnholm

    Joined:
    Mar 9, 2011
    Posts:
    128
    Last edited: Nov 2, 2011
  5. vortexilation

    vortexilation

    Joined:
    Sep 25, 2009
    Posts:
    285
    woot erlang is a great language that are mostly unknown to the masses, i have to agree at first functional languages scares me aways till now lol, i don't have the courage to continuing study it, my intention was just writing simple demo server on erlang after i read an article on gamedev, other problem was i don't find ease to use tools to compile erlang code into a bytecode or did i missed something?, anyway if your product become succeed will you sell it? at what price range?, how about the server source code? i assume you also haven't found the solution for erlang bytecode?.
     
  6. galent

    galent

    Joined:
    Jan 7, 2008
    Posts:
    1,070
    Ok, you've got my attention :)

    So your solution has both client and server elements, with the client side capturing the Unity network IO (presumably then expanding on the limited Unity Mono runtime, using the erlang VM, language, and incremental GC (et al). and handling all the server side as well as the client side IO, sync, etc. Is that correct?

    I'd be interested in knowing how the erlang vm differs from "realtime" Java VM, but perhaps that's a question for Ericsson.

    When you say you automatically handle MMO/Network, do you mean you automagically detect the Unity runtime and insert your solution between Unity and the native IO?

    what platforms does your solution run on?

    hehe, these and many more questions :)

    Cheers,

    Galen
     
  7. Christian_Lonnholm

    Christian_Lonnholm

    Joined:
    Mar 9, 2011
    Posts:
    128
    Hi Stellar!

    To compile it into bytecode you could for example use the module "compile" or the erlc binary. We simply use a makefile that gives the compiler a list of src files to compile but you can find everything you need here.

    We are fortunate enough to already have the interest of a few companies wanting to buy our Pikko Server. The price is negotiated and depends on a number of factors but I guess that there is no way around the fact that it is very expensive. But we have more innovative technologies coming soon that is much more affordable. You will be able to find everything we offer here: www.unitypark3d.com

    The Pikko Server code is normally run and hosted by one of our hosting partners together with the game deployment. We make exceptions to this sometimes but this is the normal case of how we go about installing Pikko Server.

    I didn't understand the last part of you comment about a solution for Erlang bytecode. Would you mind trying to explain it to me one more time?
     
    Last edited: Mar 13, 2011
  8. Christian_Lonnholm

    Christian_Lonnholm

    Joined:
    Mar 9, 2011
    Posts:
    128
    Galent,

    Actually, Pikko Server works much smoother then you think it does. It works as an Application Level Gateway (ALG) on the server side only, where it reads the uLink protocol and then do some fancy magic that is explained here. Basically, what it does is that it divides the virtual world between different Unity servers (cell servers) and then return the result to the clients as if it was only one Unity server that the clients was connected to.

    All of our technology support all the same platforms that Unity support.

    If you have more questions - just fire away!
     
    Last edited: Mar 11, 2011
  9. zumwalt

    zumwalt

    Joined:
    Apr 18, 2007
    Posts:
    2,204
    Who's teeth did you have to pull to get the packet definition from UT? I have been trying to get them to release the packet definition information for 2 years now so that I could make something native to support a back end server and load balancer, at some point I have an email that it will eventually be released as soon as it is fully documented, but that was sometime last year before 3.x was released. That packet structure is key to solving many issues including setting up a full blown stand alone server interface, I guess it takes a lot of power or 'know the right people' to get that information? Or did it simply boil down to $$$
     
  10. Christian_Lonnholm

    Christian_Lonnholm

    Joined:
    Mar 9, 2011
    Posts:
    128
    Dear zumwalt,

    We didn't use Unity's packet definition. We built our own network integration, uLink, from the ground up. You can learn more about it here.

    You seem to have had pretty cool ideas that looks like a bit like what we have done. Care to tell me more?
     
    Last edited: Mar 11, 2011
  11. galent

    galent

    Joined:
    Jan 7, 2008
    Posts:
    1,070
    @Christian_Lonnholm - ok, so basically you use the native Unity networking, but replace the server side with a clusterable (vertically and horizontally) custom server. Fair enough. The only thing I'd be missing is decoupling the Unity game from the network IO on the client side (again, because of some Unity implementation issues), just to speed processing on systems where dual processors and memory space above 32bit are available. As for game dev using Unity, I like it :)

    @zumwalt - I see 2 possibilities:
    1) they packet sniffed out the details
    2) there is much to be said for being able to pile a couple of cases of Polish Vodka into an unmarked van and hanging out in the pub near the Unity headquarters :)

    Cheers,

    Galen
     
  12. galent

    galent

    Joined:
    Jan 7, 2008
    Posts:
    1,070
    Another question arises, so ... that works fine when the clients do conflict resolution, etc... as in the best way to leverage the built-in Unity networking. But how's that going to work with server side physics, conflict resolution, etc... am I able to couple a Unity server implementation with the cells?

    Thanks,

    Galen
     
  13. galent

    galent

    Joined:
    Jan 7, 2008
    Posts:
    1,070
    Hmm, I think the doc just answered my last question... really interesting read (I really should finish to see who did it :), but it creates some interesting questions). Cells look like a grid computational model, with the Pikko server doing many of the things I see in virtualized environments (like VM ware). How are the virual worlds mapped so you can do the overlays (ie cell tower analogy)? Is it straight Vector3 mapping/gridding or some other mechanism?

    Sorry for so many questions... new shinny thing syndrom I'm afraid :)

    Thanks,

    Galen
     
  14. Pelajesh

    Pelajesh

    Joined:
    Dec 7, 2009
    Posts:
    363
    This looks interesting :p
     
  15. Christian_Lonnholm

    Christian_Lonnholm

    Joined:
    Mar 9, 2011
    Posts:
    128
    Galen,

    Just to clearify, we have made uLink, our own network integration in Unity so Pikko Server does not work with Unity's native network. I realize that I have been unclear about that. The Unity/Raknet integration is something we are happy that we have stayed away from. Even though we made our API pretty much the same so that it would be easy to move projects and so that we didn't have to do so much documentation in the beginning.

    We actually had uLink multi-threaded until 3.X when we got better performance out of it as thread locked.

    If you have seen us hanging with cases of vodka outside Unity's HQ - then that was just because we happen to be there by chance and we had no idea that it was vodka in those cases. But if you didn't see us there and was just speculating - then I can tell you that we would never try to bribe people at Unity. =D
     
    Last edited: Mar 12, 2011
  16. Christian_Lonnholm

    Christian_Lonnholm

    Joined:
    Mar 9, 2011
    Posts:
    128
    Galen,

    I missed your last questions as I was answering the earlier one. Well, we have made a new world partitioning system called "the Mast Algorithm" which allow the cell servers (that are shaped in a hexagon fashion) to adjust its size and even move with players if that seem to be the most optimal way to balance the load. I have already promised to post a movie that explains it much better then I can do in words... Anyhow, the Mast Algorithm make the server side behave very organically to player activity and recalculate the most optimal world partitioning five times every second.

    It is great with questions! Keep them coming.
     
  17. zumwalt

    zumwalt

    Joined:
    Apr 18, 2007
    Posts:
    2,204
    Looking at your uLink Manual that you have posted, but the bottom line is that Unity with RakNet utilizes a single instance server / client from the start, what they did is really straight forward. Jenkins code is setup so that you can run multiple instances of the client talking to multiple instances of a server or load balanced as it were. All UT did was start a RakNet static instance before the client starts, from what I can tell, 2 of them actually, one as the server and one as a client. The downfall is that the client can only “connect” to a single server instance, you can create an array of clients[x] on start and have an array of servers[x] on start natively but not within Unity. I actually had a request back when they first setup RakNet to work with Unity to do just that, but it never happened.

    So then, they have a structure setup that they place all objects in, so the broadcast is the entire serialized data structure of which ever viewed object it is attached to, the thing is, that structure definition is unknown, the thought is, switching up the client.connect to talk to a full blown raknet server, not just another client that is running as the server and be able to do stuff with that information. Simplified discussion of this topic only, but say I write a raknet cluster, if I had a client.connect[member#] (not allowed in Unity at the moment) if server A disappears, server B already knows about what is going on and the player continues and I can deal with the information broadcast to other players or store in a database or whatever I wanted to do.

    This goes further though, since programmers can only do a client.connect(single instance), having my own game server, or business logic server, better yet a traffic cop, I see the player come in, look at available shards that I have created and look for the least busy server and attach the player through the traffic cop to that server and that server is a ghost client to all the other servers so all players know about each other regardless of shard (ok my term, but shard is just a member server in the bank), I can only do this if I have the packet structure, at the moment anyway.

    I have already done this with native raknet in the past but not with Unity Raknet implementation. Problem at that time was that the player would randomly disconnect from the server during a game loop, never could figure out what was going on, on top of that, my code used custom plugins I wrote which as you know do not work on phones or web, but native Unity with RakNet does work across platform, thus my dilemma.
    The network loop resides outside of the game loop, raknet is running before the client game loop begins, it has to work that way for a solid state connection and on each game loop they control the heartbeat to the server. As far as I can tell, they are using delegates to pass how many connections the server should accept out to the network thread and they are running raknet single threaded when it can run multithreaded, to add pain to punishment, I used Intel’s parallel processing routines to load balance across CPU’s and hyper threading. I wanted to add scalability not only to the server but to the player, another point in that process was to allow for Amazon Cloud along with 1AND1 Cloud to be able to instantly scale based on a cloud change in processes.

    So if the load in the cloud increased, with the parallel processing plugin going, it immediately and seamlessly took advantage of the new processing power which ultimately allowed for additional connections.

    Which was the reason why I purchased into Photon by ExitGames, it is very powerful, straight forward, scalable, although manual reads like stereo instructions, has a strong support staff with very knowledgeable employees.

    You see, there is ultimately a dilemma, all other forms of networking happen AFTER the client has started, all from a script object in code which has one apparent problem, every switch from level to level, you have to reconnect the client, if the networking server was started prior to the game starting, the game then is waiting on which position in the stack that the network component lives prior to start which is a problem because game objects could easily exist prior to the network interface unless you code to avoid that problem with a global ready state and manually instantiate all objects past that point.

    The only “fix” to this was to create a single script master EGO that controlled all other scripts, then on each game loop update validate network state and move on, which tends to lend to lag. Otherwise you are stuck with starting your binary to begin your network interface first, then having a plugin inside the game project that talked to that alternate program through p-invoke or native call, then you have a 2 part problem, is that running and is it monitored, and is your game able to talk to it without issue.

    Ultimately the best solution is to begin network code, then begin game code, after game code terminates, terminate network code.
    Ya, that is the simple high level conversation from the 10,000 foot level.

    Thus I thought you had talked someone at UT into giving you the packet definition so that the native interface could be used with other entities. I would rather use the bitstream interface for raknet anyway instead of the bytestream.
     
  18. DavidB

    DavidB

    Joined:
    Dec 13, 2009
    Posts:
    530
    Wow looks like you guys really have some hardcore stuff going on. Forgive me if I missed this though... but you've posted it in the Unity forums (primarily hobbyist with some indies kicking around here), I'm just curious if you guys are planning on somehow bringing this technology to the hobbyist-indie game developer and what those plans may be?

    Regardless you guys have kicked some serious butt here and the technology looks interesting! Great work.
     
  19. Christian_Lonnholm

    Christian_Lonnholm

    Joined:
    Mar 9, 2011
    Posts:
    128
    zumwalt,

    I feel your pain. Accessing the ability to parallelize is a cause worth while though. As you mention, you get very nice features if you manage to cluster your server side with redundancy being an important one. I hope that you can draw inspiration from how we solved it with Pikko Server. It is hard to give more specific feedback since I know very little of exactly how you are going about this problem but please e-mail me and my team will take a closer look at it and see what we could help with.

    On a side note, I was really happy to hear that you are impressed by Photon and the team over at Exit Games. I have met them a few times and they have been working hard on getting their solution to where it is at. Even though we are, at some level, competitors, I have the deepest respect for the people making tools for network programmers. This respect extends, of course, to you too zumwalt.
     
  20. Christian_Lonnholm

    Christian_Lonnholm

    Joined:
    Mar 9, 2011
    Posts:
    128
    Thanks DavidB!

    We are surely putting our technology in the hands of indie guys. We have already given indie developers about 200 000 € worth of licences and we are constantly looking into how we can help out even more. Though, this is done as we get the opportunity to do so, as we think it is important to make sure that people don't waste their interest and talent (= lives) on solving problems that have already been solved a million times. It hurts deep inside me when I think about the inefficiency...

    Thanks again for the kind words!
     
    Last edited: Mar 12, 2011
  21. larvantholos

    larvantholos

    Joined:
    Oct 29, 2009
    Posts:
    668
    The link is cool. Looks like an exciting attempt. So uh... When is this attempt taking place? I notice a lack of dates on the website - is this closed setup, IE you have the thousand people already for this, or are you getting a buncha people to log in for this attempt?
     
  22. Frank Oz

    Frank Oz

    Joined:
    Oct 13, 2010
    Posts:
    1,561
    He aint joking either *hugs his awesome new license*

    Deceptively simple to use too, considering what it's really capable of. Feels well built and sturdy. You'd expect something like this to be completely out of bounds tech wise for anyone but the most experienced coders with months to spare studying it, but even I can understand quite a bit of it already, lol.


    Ever since Unity 3.x came out, it's like the quality of third party plugins and extensions have gone through the roof. This, node based shader editors, node based state machines, advanced GUI builders, pathfinding and A.I. plugins, the list goes on. Anyone else beginning to feel a bit spoiled? (and loving it) :)
     
  23. Dreamora

    Dreamora

    Joined:
    Apr 5, 2008
    Posts:
    26,601
    Wanted to thank for this great writeup on the "where it came from" and "what path it took", very interesting to read and see where others are drawing their inspiration and drive from.
     
  24. n0mad

    n0mad

    Joined:
    Jan 27, 2009
    Posts:
    3,732
    I'm feeling too small in front of such data knowledge to say anything but :
    Thank you too for creating this highly technical and professional experience sharing on these forums.
    It's been a long time since there wasn't any.
    *shuts up and learn*
     
  25. the_gnoblin

    the_gnoblin

    Joined:
    Jan 10, 2009
    Posts:
    722
    Thank you for these informative posts!

    Oh, Erlang... ;)

    The language seems to become as popular as Unity itself.

    I am very happy that you, guys, started using it for networking middleware.

    Please, don't stop!
     
  26. DavidB

    DavidB

    Joined:
    Dec 13, 2009
    Posts:
    530
    This sounds really great. Can I ask what you had to do to qualify for the use of their system? I'm a hobbyist by most definitions and was going to develop a small networking backend of my own.... but something like this sounds great. But with the current price tag this is clearly beyond anything I'll be able to purchase :p It's great to hear there is indie/hobbyist penetration, but is it just on a first come first serve basis? Or are there negotiable prices for smaller studios?
     
  27. Discord

    Discord

    Joined:
    Mar 19, 2009
    Posts:
    1,002
    This honestly sounds great. I'd love to be able to check out some documentation or something along those lines.
     
  28. Dreamora

    Dreamora

    Joined:
    Apr 5, 2008
    Posts:
    26,601
    Manual and API docs as well as trial can be found on the website actually to give it a run through :)
     
    Last edited: Mar 12, 2011
  29. the_gnoblin

    the_gnoblin

    Joined:
    Jan 10, 2009
    Posts:
    722
    "Technology overview" parts of unitypark3d.com are hard to notice (in my opinion) - these pieces of text are shown via javascript and need the user to click LMB on something which looks like a link (and I'm used to opening links by hitting mousewheel so it opens in another tab - in this case "link" leads to the same page).
    And inside those you have another similar menus.

    I noticed the info on uGame SQL only when I got especially interested in it, and started searching the website for additional info as it seemed suspicios that there was only one mention of it.

    Hope it helps ;).
     
  30. Christian_Lonnholm

    Christian_Lonnholm

    Joined:
    Mar 9, 2011
    Posts:
    128
    Anyone how want to join the world record attempt will be able to play it at the site together with the 999 other people. We have not yet announced the date but if you keep an eye out at Rock, Paper, Shotgun or simply be-fan us at Facebook, you will be sure to get informed.
     
  31. Christian_Lonnholm

    Christian_Lonnholm

    Joined:
    Mar 9, 2011
    Posts:
    128
    Thank you!
     
  32. Christian_Lonnholm

    Christian_Lonnholm

    Joined:
    Mar 9, 2011
    Posts:
    128
    Our challenge is trying to not be an asshole to new people that want to use uLink and at the same time not be an asshole to the people that already are using uLink and need our support. How this is achieved is not a science but rather a humbling and continuing dialog. Next week, we will have put a more transparent indie licence system up there but right now it is all about convincing me that you for one reason or the other deserve uLink for a price that you think it is worth.
     
  33. Christian_Lonnholm

    Christian_Lonnholm

    Joined:
    Mar 9, 2011
    Posts:
    128
    I am super happy to hear that you got interested in uGame SQL. We have the great fortune to currently develop new database products together with Basho and Uppsala University. We will put more and easier to find information about them, up on the homepage, in the near future.

    Thanks for letting us know! And thanks for all the questions that you posted in our Q&A. But most of all, thank you for answering the question I had put there!
     
  34. Christian_Lonnholm

    Christian_Lonnholm

    Joined:
    Mar 9, 2011
    Posts:
    128
    And thank you for reading it!
     
  35. DavidB

    DavidB

    Joined:
    Dec 13, 2009
    Posts:
    530
    Sounds great, when I get the project to a point where something as strong as uLink may be required, I'll approach you guys and see if you think so too :p But until then (and of course after!) good luck, the product seems extremely interesting. I'll be watching it's growth with great interest.
     
  36. Christian_Lonnholm

    Christian_Lonnholm

    Joined:
    Mar 9, 2011
    Posts:
    128
    Thank you! I have had the chance to learn that you are a great asset to the Unity community and I am honored to see you give feedback to uLink and uGame DB as well. Do you mind if I ask you from where you draw your inspiration from?
     
  37. Christian_Lonnholm

    Christian_Lonnholm

    Joined:
    Mar 9, 2011
    Posts:
    128
    You are very welcome, I am already looking forward to learn more about your project!
     
  38. galent

    galent

    Joined:
    Jan 7, 2008
    Posts:
    1,070
    So, your client code is running inside Unity, partially or wholly? I've been quietly designing a multi-player engine for my own purposes down the road. Your "cell tower" approach is very interesting, as the one piece I've sort of avoided thus far was the Unity game server integration.

    Interesting (again :) ). do the zones (Masts) stage/prioritize (tiered or weighted) the updates, or are you pushing all non-static data on each broadcast?

    Personally I was looking at ... hmm.. how to describe, message (possibly topple space based) data warehouse with data mart like masking, pre-crunching, etc.., based on prioritized tiers that would be multi-cast to federated local "mini-server" instances. Unity would then communicate locally as opposed to via network (with the exception of priority push events). The advantage of the federation is to step the communication outside Unity (no disrespect intended, but Mono has an antiquated GC, and misses on some other of my favourite points), from there I can do a couple of things:
    1) step up to the full OS and hardware processing
    2) create proximity P2P virtual zones (based on geo-locations and virtual proximity) with the servers fielding RPC and lower threshold updates (much better PvP in my opinion)
    3) push the RAM threshold based on hardware and OS, not 32bit Mono
    4) off load some processing to client machines, save me some server power :)
    5) better fault-tollerance
    6) etc...

    I"m also interested in the erlang implementation... First pass of the docs say they are still byte-code (write once, debug everywhere :) ) based with a incremental GC. How do you find that performs? IBM uses multi-tier aging object pools with incremental GC (on AIX and OS/400 anyway), by default it's "stop the world" GC mark, sweep, and compaction cycles but you can switch it to concurrent (just not as stable at higher volume loads). Problem I have with that is the basic GC algorithms still aren't fast enough for 64 bit memory addressing. Incremental is fine, but not ideal. I had the opportunity to torture both IBM and Sun (now Oracle) JVMs extensively a couple of years ago, and both ran better in 32bit mode, with lower heaps producing better results (once you pass the min heap mark for a given app). What have you seen in Erlang?


    Ahh, a man of good business :) Fair enough, as I understand it "what happens in Denmark, stays in Denmark" unless some *$ brings a camera... then a new corporate policy is born :D

    Cheers,

    Galen
     
  39. xenbiosis

    xenbiosis

    Joined:
    Jan 28, 2011
    Posts:
    49
    You, Sir, are epic!
     
  40. AnomalusUndrdog

    AnomalusUndrdog

    Joined:
    Jul 3, 2009
    Posts:
    1,476
    Can this technology also be used perhaps for heavily instanced MMO games where players can create a match/room/instance and only 1-10 other players can join him in that match/room/instance? Or is this only for the type of MMO that has one massive world?
     
  41. 2dfxman1

    2dfxman1

    Joined:
    Oct 6, 2010
    Posts:
    1,065
    Yes yes it can.
     
  42. Christian_Lonnholm

    Christian_Lonnholm

    Joined:
    Mar 9, 2011
    Posts:
    128
    I have now made a post here that explain how small studios and hobbyists can get an affordable licence. Let me know what you think!
     
  43. Christian_Lonnholm

    Christian_Lonnholm

    Joined:
    Mar 9, 2011
    Posts:
    128
    Hi again!

    For you tech-curious guys that really want an insight in how the integration of Pikko Server look in uLink, you can now have a look at the new section in our manual that explains it.
     
  44. Darknuke

    Darknuke

    Joined:
    Jan 31, 2011
    Posts:
    223
    wait, so has that tanks vs. robot thing already happened or not? I would love to see/participate in that!
     
  45. AnomalusUndrdog

    AnomalusUndrdog

    Joined:
    Jul 3, 2009
    Posts:
    1,476
    So the way I understand it, the guys who made uLink are not the same guys who made Pikko Server, but the two are cooperating to make their products work together in the form of a demonstrative network game made in Unity?

    So is the Pikko Server technology available to the public yet? and how much is the licensing for it?
     
  46. tatoforever

    tatoforever

    Joined:
    Apr 16, 2009
    Posts:
    3,726
    I've tried your uLink tutorial and just wanna tell you that this tech simply rocks, easy and fast.
    One question, what kind of object state can i sync over the net using uLink Network view?
    Cheers,
     
  47. Christian_Lonnholm

    Christian_Lonnholm

    Joined:
    Mar 9, 2011
    Posts:
    128
    Awesome!

    We are announcing the date soon. Keep an eye out on our facebook page our just read RPS. =)
     
  48. Christian_Lonnholm

    Christian_Lonnholm

    Joined:
    Mar 9, 2011
    Posts:
    128
    We are the pretty much same guys. UnityPark (uLink) is a sister company of Pikkotekk (Pikko Server). We wanted to revolutionize the way MOG/MMOG were made and to show that we needed to do both uLink and Pikko Server. Looking back at it, it seems like a crazy idea - but there you go.

    Licensing of Pikko Server depends on several different factors and something that is negotiated. All you need to do is e-mail sales@unitypark3d.com and you will have taken the first step to get Pikko running with your game!
     
    Last edited: Mar 28, 2011
  49. Christian_Lonnholm

    Christian_Lonnholm

    Joined:
    Mar 9, 2011
    Posts:
    128
    Thank you for trying it out and letting us know what you thought!

    You can find the answer to your question and more useful information here in our manual.
     
  50. jonbonazza

    jonbonazza

    Joined:
    Nov 6, 2010
    Posts:
    453
    Christian, is it possible to give me a rundown of the benefits that this tool has over SmartFox?