MMO Architecture and PUN

Hi,
I am new with both unity and Photon. I am sorry for any question that might already have been answered but at least I couldn't find it.
I am currently doing my final project for university and decided to go with a computer game. Since no final project has excelent marks unless it addresses current concerns and features "state of the art" technology I ofc had to go with a massive multiplayer online game. I realise it is a gigantic endeavour, but I just need to design the system and provide a small working prototype. After a few months trying to work with JMonkeyEngine3 and getting really discouraged by the bugs of its tools (not the language itself) I, with my teachers council, decided to try my hand at Unity and boy am I glad I did because it's amazing how much it can do with a few clicks of a button.
So the first thing I did was research wether it's a viable option for an mmo and after a while I came upon Photon. I have been reading how it works and so far so good but I would just like to flat out ask if my architecture is possible to be implemented using unity and Photon.



Each zone in my game will work in a seperate authoritative server but I still need to have a general chat server so that people can comunicate with their friends playing in another zone. In each zone the player can find any number of dungeons they can play on, either alone or with 3 other friends. The Dungeons are also run by an authoritative server (nothing is ever hosted on the clients). Another important requirement is that all game servers (zones and dungeons) be able to access a webhost that deals with database access.

So my question is: Is this whole lobby > rooms structure able to adapt to this architecture. I was thinking maybe having a lobby that when the user logs in imediatelly checks the database for what zone the player was last playing in and imediatelly connect him to the/a server that runs that zone(100 player lobby? room?) and then when a player enters a dungeon connects him to that new 4 player room.
Or do you have any sugestion how this can be achieved with PUN?

Thank you for your atention,
AtomR

P.S: The architecture is an adaption of an IBM article found in http://www.ibm.com/developerworks/library/ar-powerup1/
Although, for now, the objective is academic, the plan is to keep working on it and hopefully make it a comercial project.

Comments

  • PUN will not work for MMO, you really want to focus on using the MMO photon application & the regular Unity .NET SDK

    The IBM articles there are nice but it only works on torque cause torque has the best scope - sync range handling in the industry, it does not do room based syncing but something similar to the InterestArea handling in the MMO and thats the very base for doing any kind of MMO with more than a few dozen actors (npc or human) in a zone to work at all
  • :shock: now i'm slightly confused.
    I may have been wording it wrong. I have downloaded the server SDK to make the server and the Unity Client SDK for the client. Is this what you meant with "MMO photon application & the regular Unity .NET SDK".

    I have been reading about this Interest Area and was thinking I would have to be the one implementing it regardless of which networking solution I got.

    Upon further research I've read that using the photon server we won't be able to have a fully authoritative server because the server will have no information about the geometry of the scene and thus won't handle colision detection.

    [edit]
    However, realistically speaking, I suppose it's better to have a solution that nativelly handles the InterestArea if not physics.
  • You likely worded it wrong yeah :) PUN = Photon Unity Networking = a special solution offered on the asset store explicitely for Photon LoadBalancing / PhotonCloud that replicates the Unity Networking way of working and commands in larger parts.


    And Interest Area is so much more important than physics. If you can't limit and scope the network traffic reasonably you will not even reach MO and even less MMO as you can't afford a 10TB upstream line to handle a few thousand players due to no presence of scoping.
    Also it would require a multi ten thousand USD server to even process the amount of messages that will start flying around when you do that ;)


    The physics part is a limitation that you can overcome by implementing an own solution in server and client.
    Alternative you can do what some others did too and use unity headless clients as 'world simulation nodes' directly connected to the photon server from within your server cloud / cluster. These nodes would be explicitely developed for this purpose and thanks to being headless they require not remotely as much resources as the regular unity builds :)
  • I guess you don't want feedback on the choice of your project topic, right? Still:
    Creation of an MMO is not a single topic but if done for big scale (which the name implies), it's the sum of all kinds of difficult problems. Networking (number of connections, bandwidth), performance (authoritative server), scaling (concurrent user spikes, low interest phases per day), persistency (databases), etc.
    These problems not even really touch the client and neither are they all the problems to solve.

    Well. Sorry for that :)


    About your questions: Yes, it's possible to do in Photon but it requires a lot of work. The features we have for MMOs are not feature complete and maybe not even fitting exactly. The "MMO Application" from the SDK is about scalability and interest management but with it's fixed grid of areas, it still does not cope with edge-cases like "all players get into one place to get some giveaway". As the areas are fixed, all players could still get into the same area and kill bandwidth.
    Rooms, on the other hand, send updates to all other players in the same room. The number of players is quickly limited by the bandwidth this way. Also, if a room is used as "area", the boundaries to neighbor areas might be open but players don't get updates from the adjacent area, cause they are not in that room, too.

    As you already read, the server has no way to know your level architecture and physics. This would need exports from Unity and implementation on the server-side.

    Usually, MMOs could get away without real physics. In the end, you don't mind how a crate falls but you want to know if a shot hits a monster. This means, you are more interested in collision detection. This system could be replaced in Unity and client and server could use the same one.
    You still need level geometry server-side. This could be exported from Unity to any format you can implement on the server, too.


    I am not really sure how we should help you at the moment, aside from this very general input. Photon is not a MMO out of the box solution and "doing an mmo" is a too broad topic to help with. If you could concentrate on either subtopic (first), we could give better feedback, too.
  • dreamora wrote:
    And Interest Area is so much more important than physics. If you can't limit and scope the network traffic reasonably you will not even reach MO and even less MMO as you can't afford a 10TB upstream line to handle a few thousand players due to no presence of scoping.
    Also it would require a multi ten thousand USD server to even process the amount of messages that will start flying around when you do that ;)

    I realise interest area is more important then physics, however wouldn't it be simpler to implement? At least from the description on this site it's a fairly simple concept.
    dreamora wrote:
    The physics part is a limitation that you can overcome by implementing an own solution in server and client.
    Alternative you can do what some others did too and use unity headless clients as 'world simulation nodes' directly connected to the photon server from within your server cloud / cluster. These nodes would be explicitely developed for this purpose and thanks to being headless they require not remotely as much resources as the regular unity builds :)

    How do you make them headless? is it possible to set Unity to perform only game logic with drawing anything?
    This does sound like an interesting solution. Could the traffic from this superclient to the server potentially become a bottleneck, even considering they are both running on the same cluster?
    Tobias wrote:
    I guess you don't want feedback on the choice of your project topic, right? Still:
    Creation of an MMO is not a single topic but if done for big scale (which the name implies), it's the sum of all kinds of difficult problems. Networking (number of connections, bandwidth), performance (authoritative server), scaling (concurrent user spikes, low interest phases per day), persistency (databases), etc.
    These problems not even really touch the client and neither are they all the problems to solve.
    Well. Sorry for that :)

    Aren't those only problems when they arise? LOL joking ... sorta. ;)
    Tobias wrote:
    About your questions: Yes, it's possible to do in Photon but it requires a lot of work. The features we have for MMOs are not feature complete and maybe not even fitting exactly. The "MMO Application" from the SDK is about scalability and interest management but with it's fixed grid of areas, it still does not cope with edge-cases like "all players get into one place to get some giveaway". As the areas are fixed, all players could still get into the same area and kill bandwidth.

    But that is good enough for now. That problem just needs to be properly reported and as a suggestion to a solution propose variable sized areas of interest with the extreme case of 0 interest for very extreme cases.

    By the way, when we talk about dividing the world in a square grid, for instance, what is an acceptable size for each grid? If we make it the size of the camera range then we risk having too many "objects" in our grid space and no way to reduce the area of interest, if they are too small then interest management can be too slow. Is there a rule of thumb or is it determined by trial and error.
    Also, is this grid open to dynamically change or is it always fixed size and only the area of interest that can be changed?
    Tobias wrote:
    As you already read, the server has no way to know your level architecture and physics. This would need exports from Unity and implementation on the server-side.
    Usually, MMOs could get away without real physics. In the end, you don't mind how a crate falls but you want to know if a shot hits a monster. This means, you are more interested in collision detection. This system could be replaced in Unity and client and server could use the same one.
    You still need level geometry server-side. This could be exported from Unity to any format you can implement on the server, too.

    Yeah, I'm not thinking of creating any kind of dynamic world where everything can be moved or destroyed so basic colision detection between movable "objects" (players and npcs) and level geometry would be more then enough.
    Tobias wrote:
    I am not really sure how we should help you at the moment, aside from this very general input. Photon is not a MMO out of the box solution and "doing an mmo" is a too broad topic to help with. If you could concentrate on either subtopic (first), we could give better feedback, too.

    I just find it strange why do all these networking solutions brag about being MMOG solutions and sell plans for thousands of users. Or are the limitation in this case specifically because I'm using Unity?
  • AtomR wrote:
    But that is good enough for now. That problem just needs to be properly reported and as a suggestion to a solution propose variable sized areas of interest with the extreme case of 0 interest for very extreme cases.

    True, that's possible.
    AtomR wrote:
    Is there a rule of thumb or is it determined by trial and error.
    Also, is this grid open to dynamically change or is it always fixed size and only the area of interest that can be changed?

    I don't know rules for that and would say it's up to the game and some testing. Each game sends different data and organizes updates in another way. Also, the overhead of constantly changing visible areas should be considered. The view-range depends on these technical points and needs load testing for your usecase.
    AtomR wrote:
    I just find it strange why do all these networking solutions brag about being MMOG solutions and sell plans for thousands of users. Or are the limitation in this case specifically because I'm using Unity?

    We are pretty open about the fact, that Photon is not a "out of the box" MMORPG engine a la WoW (or similar). There are Hero Engine and others for that. On the other hand, our stuff is performing well and flexible and is probably a good startpoint and framework, to get your MMOG going. It's just not out of the box.
    Unity doesn't limit you in any way in terms of MMO games. The engine is just a viewer. It doesn't do a lot and unless the socket API in a game engine is broken, you won't be limited by the client.
  • One more thing: I'd expect (for a thesis / university project) that it tackles at least one problem thoroughly. None of these projects has to solve all problems at once, but at least one. So in your case, i'd pick a focus. This could be anything from scalable DB synchronization or smooth shopping experience or interest management. Either will do.

    Your question if "interest management isn't relatively easy to implement" shows you didn't think about the issue where 2 players are in adjacent areas and fight each other. Of course areas are nice, as they can be distributed across machines but then this fight over the border of two areas (and servers) gets a lot of lag and maybe could use special treatment.
    Afaik, this is not a trivially solved case. If so, combine this with variable-sized areas ;)
  • I need to point out I didn't mean any offense when I made the remark about "braggin to be mmog solutions". You probably didn't take offense but i needed to clear that out.
    Of course areas are nice, as they can be distributed across machines but then this fight over the border of two areas (and servers) gets a lot of lag and maybe could use special treatment

    Is this assuming I am going for a contiguous world, or am i missunderstanding? Because I am thinking for my game, loading times between zones(servers) is perfectly acceptable. Also, no player vs player is being considered.
  • You probably didn't take offense but i needed to clear that out.
    No offense taken - thanks for being clear about it in any case, which is very polite.
    Is this assuming I am going for a contiguous world
    I assumed that this would be an option or likely even.
    For me, the term "MMO" implies an open, seamless world and that means some (non-obvious) problems. Of course, many games don't really need a seamless world but then I wouldn't brand them MMO.
  • Final Fantasy XI was very much an MMO and although each area was enourmous it was not a seamless world. It may not be state of the art.
    It all comes down to each of our perception about mmos.
  • That will not work solely with rooms.
    Even thought it used zones it still had Interest Area management to handle the network traffic.
    Its focus on areas is more for artistic reasons (continous worlds are filled with boring nothingness and bad boring environments. Every game that tried it flopped due to it) and the fact that they did a absolutely crap job at optimizing their art (the game had hardware requirements that were totally out of scale for its lacking art)
  • Yeah, I know ffxi still had to deal with trafic but my point was that it was zoned and still counts as an mmo, in reply to Tobias remark that mmos (in his opinion ofc) should feature seamless worlds by definition.
    (continous worlds are filled with boring nothingness and bad boring environments. Every game that tried it flopped due to it)
    World of Warcraft? :P