I'm trying to create a proof of concept MMORPG using a "Flash" like game system that is scalable. This problem has got me stumped though. I know for a game like WoW, they go from a big sign on server to a world server then an area server and so forth. The players in the game know exactly how to go into each zone and WoW can scale from that area.
The thing is, for my proof of concept, I would like a person to login and start playing. A few days later, another friend starts playing. A while later, another friend starts playing. Every time, as the friend list grows bigger - each friend discovers each other. Is there some technically scalable way that all of them could meet automatically without playing the server/world/area selection game and creating an architectural mess? Oh, I can't guarantee connection persistence either so everything has to be recoverable if the connection is dropped.
In short, from the players point of view - everything is a gigantic world they can play with each other in.
I have a few homegrown ideas but they end up being a giant architectural mess. Can anyone help point me in the right direction?
Thanks for any help you guys can provide.
Scalable Flash MMORPG Architecture?
Are you familiar with systems that use channels instead of worlds? In this type of system there is only one 'world' for the whole game, to which all players belong. This is not the physical world where players walk around, it is the system that keeps track of everyone currently logged in and all items in the marketplace and mail, also all avatar data and items stored in inventories and banks. Physically there are channels, which are instanced copies of the world. A player only sees other players and monsters in their own channel. Players entering the game are dropped into whichever channel has the lowest population at the moment; you could modify this to put players into whichever channel contains the most people on their friends list, if any. A player can change channels whenever they want provided they are not in combat. Changing channels is a process that usually takes 10-30 seconds. The game can, if desired, alter the number of channels to fit the number of players logged in - auto-merging the two least populated to reduce the number, or spawning an empty world and dumping all entering players into it until it is up to the average.
The thing is, for my proof of concept, I would like a person to login and start playing. A few days later, another friend starts playing. A while later, another friend starts playing. Every time, as the friend list grows bigger - each friend discovers each other. Is there some technically scalable way that all of them could meet automatically without playing the server/world/area selection game and creating an architectural mess? Oh, I can't guarantee connection persistence either so everything has to be recoverable if the connection is dropped.
What is the specific part that you have problems with?
My questions:
First, how do you know if a new player is a friend of some older player?
Second, how big will this be? If there will only ever be, say, 10,000 players online, and the game is not a 3D physics simulation, then you can likely simulate it all on a single server in a single world instance.
Even beyond 10,000, you could split the world into smaller units, each of which has 10,000 players, for some particular area. That way, you can easily go to 100,000 or more online players without sharding/instancing the world, only partitioning it.
Third, how important is it that I as a player get *all* my friends in the same session? You could conceive of a system that picks a shard for me based on where the most of my friends are online right now when I log in. However, friend networks will probably fully connect most of the player base over time, so if there is no partition tolerance, you must have a single world.
Author
[color="#a0522d"]While channeling might work, I'm trying to do my best to avoid any "work" on the users end - if that is technically feasible without creating a giant headache for me. .
What is the specific part that you have problems with?
My questions:
First, how do you know if a new player is a friend of some older player?[color="#a0522d"]
Ok, it looks like I have to give the long explanation of what I'm trying to do. Here's the basic idea. In the real world, people go around and look at stuff. All of a sudden, when they find a friend by chance, they can go over to them and say "hi". I would like to replicate that same feeling.
As for the world itself, it's real life. Think of it like a farming community moving into a township into a city into a major metropolis. As more people go in an area, the zone starts to get crowded naturally so people might figure out ways to live together in that zone or they might just go to the middle of the country where nobody is and start a new life there.
As for the friend of a friend knowing each other, haven't thought too far into it yet. Maybe a "Linked-in" type system where hovering over an icon next to a friend show's that friend is linked to another friend?
Second, how big will this be? If there will only ever be, say, 10,000 players online, and the game is not a 3D physics simulation, then you can likely simulate it all on a single server in a single world instance.
Even beyond 10,000, you could split the world into smaller units, each of which has 10,000 players, for some particular area. That way, you can easily go to 100,000 or more online players without sharding/instancing the world, only partitioning it.
[color="#a0522d"]I haven't actually done any performance testing or anything like that so I'm not really sure how much a single box can handle. 10,000 sounds about right for a basic system. Right now I'm trying to understand the theory behind what's required to expand this world from something like (10k simultaneous players to 100k players to 1M players to even 10M or 100M players) so please forgive my "newbieness".
[color="#a0522d"]That's one of the homegrown ideas I have. That is to have each "location" have it's own server. [color="#a0522d"]The messy part is trying to figure out a good way to "expand" an area. Let's say I have an arena and it get's so popular that it needs an expansion. So I'm planning an expansion then all of a sudden I need to "attach" another server to the first. The goal is for me to just to buy another box and just attach it. No reprogramming the entire world. At least with a channel selection or world selection, people just select from a drop down list of where they want to go making it more straightforward. Here, I have to somehow split an existing world into a smaller world pieces.
One idea I have is to have a head server of the area have a master list of all the sub locations of that area and manage all the subareas of that location hoping the head server doesn't get bogged down. Somehow, when I first design that location, I have to have an idea what areas may be subdivided and hope that my users don't find a tiny area of great interest to them though that's going to be hard.
Likewise when players start getting interested in a "country" location and all of a sudden start moving into that area - then I have to figure out how to add more computing power to that area so that the players can enjoy it more. And if a whole lot of players start liking that area, then I have to figure out a way to move a whole bunch of resources to that really popular area.
Of course, then comes the question of what to do with those servers during downtime, do they just sit idle or can they somehow be repositioned to other more popular areas? I'm guessing this is another big problem in itself.
Third, how important is it that I as a player get *all* my friends in the same session? You could conceive of a system that picks a shard for me based on where the most of my friends are online right now when I log in. However, friend networks will probably fully connect most of the player base over time, so if there is no partition tolerance, you must have a single world.
[color="#a0522d"]It's extremely important everyone is on the same session and a single world.
[/quote]
[color="#a0522d"]Again, please forgive my "newbieness" on this subject. [color="#a0522d"]Right now, this is more like a hobby project of mine seeing what kind of solutions there are to this type of problem and seeing what kind of proof of concepts I can make out of this.
[quote name='MicroDesignerDev' timestamp='1305089969' post='4809272']
The thing is, for my proof of concept, I would like a person to login and start playing. A few days later, another friend starts playing. A while later, another friend starts playing. Every time, as the friend list grows bigger - each friend discovers each other. Is there some technically scalable way that all of them could meet automatically without playing the server/world/area selection game and creating an architectural mess? Oh, I can't guarantee connection persistence either so everything has to be recoverable if the connection is dropped.
What is the specific part that you have problems with?
My questions:
First, how do you know if a new player is a friend of some older player?[color="#a0522d"]
Ok, it looks like I have to give the long explanation of what I'm trying to do. Here's the basic idea. In the real world, people go around and look at stuff. All of a sudden, when they find a friend by chance, they can go over to them and say "hi". I would like to replicate that same feeling.
As for the world itself, it's real life. Think of it like a farming community moving into a township into a city into a major metropolis. As more people go in an area, the zone starts to get crowded naturally so people might figure out ways to live together in that zone or they might just go to the middle of the country where nobody is and start a new life there.
As for the friend of a friend knowing each other, haven't thought too far into it yet. Maybe a "Linked-in" type system where hovering over an icon next to a friend show's that friend is linked to another friend?
Second, how big will this be? If there will only ever be, say, 10,000 players online, and the game is not a 3D physics simulation, then you can likely simulate it all on a single server in a single world instance.
Even beyond 10,000, you could split the world into smaller units, each of which has 10,000 players, for some particular area. That way, you can easily go to 100,000 or more online players without sharding/instancing the world, only partitioning it.
[color="#a0522d"]I haven't actually done any performance testing or anything like that so I'm not really sure how much a single box can handle. 10,000 sounds about right for a basic system. Right now I'm trying to understand the theory behind what's required to expand this world from something like (10k simultaneous players to 100k players to 1M players to even 10M or 100M players) so please forgive my "newbieness".
[color="#a0522d"]That's one of the homegrown ideas I have. That is to have each "location" have it's own server. [color="#a0522d"]The messy part is trying to figure out a good way to "expand" an area. Let's say I have an arena and it get's so popular that it needs an expansion. So I'm planning an expansion then all of a sudden I need to "attach" another server to the first. The goal is for me to just to buy another box and just attach it. No reprogramming the entire world. At least with a channel selection or world selection, people just select from a drop down list of where they want to go making it more straightforward. Here, I have to somehow split an existing world into a smaller world pieces.
One idea I have is to have a head server of the area have a master list of all the sub locations of that area and manage all the subareas of that location hoping the head server doesn't get bogged down. Somehow, when I first design that location, I have to have an idea what areas may be subdivided and hope that my users don't find a tiny area of great interest to them though that's going to be hard.
Likewise when players start getting interested in a "country" location and all of a sudden start moving into that area - then I have to figure out how to add more computing power to that area so that the players can enjoy it more. And if a whole lot of players start liking that area, then I have to figure out a way to move a whole bunch of resources to that really popular area.
Of course, then comes the question of what to do with those servers during downtime, do they just sit idle or can they somehow be repositioned to other more popular areas? I'm guessing this is another big problem in itself.
Third, how important is it that I as a player get *all* my friends in the same session? You could conceive of a system that picks a shard for me based on where the most of my friends are online right now when I log in. However, friend networks will probably fully connect most of the player base over time, so if there is no partition tolerance, you must have a single world.
[color="#a0522d"]It's extremely important everyone is on the same session and a single world.
[/quote]
[color="#a0522d"]Again, please forgive my "newbieness" on this subject. [color="#a0522d"]Right now, this is more like a hobby project of mine seeing what kind of solutions there are to this type of problem and seeing what kind of proof of concepts I can make out of this.
[color=#A0522D][size=2]As for the friend of a friend knowing each other, haven't thought too far into it yet. Maybe a "Linked-in" type system where hovering over an icon next to a friend show's that friend is linked to another friend?
My question was actually intended to be read as: How do you, the system implementor (or the system itself) know that people are friends? You can't make those link-ups until you have some way of knowing. Do you log in using Facebook, and use the Facebook social graph?
Regarding scale, there are really only three ways to scale density (lots of people in the exact same space):
1) Shard/instance the space. Multiple overlapping "worlds" that are independently running in the same graphical environment.
2) Reduce rule complexity, increase latency tolerance, and improve single-server capacity to meet demand. This may need advanced algorithms in the area of lock-free synchronization etc to work out right. There is a hard upper limit (typically determined by the memory bus of the CPU/s), but this limit does increase every year.
3) Spread simulation for the same space across multiple machines, and use messaging to distribute updates. This means that simulation must be tolerant of a one-turn latency in other objects it's dependent on. As long as you can live with this, you can go very far in this mechanism, but the overhead of the messaging will end up being a problem in the end.
Note that all of this assumes that there is some simulation going, where each object needs to be aware of, at a minimum, the static world around it and the nearest X meters of dynamic actors. That information is input to the simulation step for the object, and then out comes new state, which is distributed to everyone else. Repeat :-)
Author
[quote name='MicroDesignerDev' timestamp='1305226974' post='4809899']
[color="#a0522d"]As for the friend of a friend knowing each other, haven't thought too far into it yet. Maybe a "Linked-in" type system where hovering over an icon next to a friend show's that friend is linked to another friend?
My question was actually intended to be read as: How do you, the system implementor (or the system itself) know that people are friends? You can't make those link-ups until you have some way of knowing. Do you log in using Facebook, and use the Facebook social graph?
Regarding scale, there are really only three ways to scale density (lots of people in the exact same space):
1) Shard/instance the space. Multiple overlapping "worlds" that are independently running in the same graphical environment.
2) Reduce rule complexity, increase latency tolerance, and improve single-server capacity to meet demand. This may need advanced algorithms in the area of lock-free synchronization etc to work out right. There is a hard upper limit (typically determined by the memory bus of the CPU/s), but this limit does increase every year.
3) Spread simulation for the same space across multiple machines, and use messaging to distribute updates. This means that simulation must be tolerant of a one-turn latency in other objects it's dependent on. As long as you can live with this, you can go very far in this mechanism, but the overhead of the messaging will end up being a problem in the end.
Note that all of this assumes that there is some simulation going, where each object needs to be aware of, at a minimum, the static world around it and the nearest X meters of dynamic actors. That information is input to the simulation step for the object, and then out comes new state, which is distributed to everyone else. Repeat :-)
[/quote]
The friend part is still in concept. Right now though, I'm just thinking of a simple buddy list where people add in their friends name and that information is pulled and stored in a DB.
The "Spread simulation for the same space" sounding rather complex and is definitely not a trivial system to implement. How often has that been used in production? Is this similar in concept to how EVE Online works?
The "Spread simulation for the same space" sounding rather complex and is definitely not a trivial system to implement. How often has that been used in production? Is this similar in concept to how EVE Online works?
Military simulations run each simulated entity as its own system -- sim tank, sim fighter plane, sim dismounted soldier, etc -- and tie them all together in federation using a network. Their latency requirements are somewhat different, though, because the interactive part (controls, graphics) are in the same spot as the simulation, and all simulations are, generally, "close" on the network (although these simulations have been linked up across continents, living with the dead reckoning from the latency).
EVE Online, AFAICT, shards each "system" -- each "system" runs in its own (conceptual?) process, and can be allocated to any simulation server that has capacity. I don't know if their allocation is static, or dynamic over time. This is very similar to how EverQuest and a bunch of other MMOs do it -- each "zone" has its own process, and you "transition" between zones; the connection is not usually seamless.
The difference between EVE and EverQuest is that EVE then throws all players and all systems into a single unified game world, whereas EverQuest and friends have a gameplay based design limit of some number of thousands of simultaneous online players per world instance, and then replicate/instance those world instances.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
