|
You basically just theorized a bunch of improbable scenarios that no RSPS will ever reach, and even then, it's an unneeded optimization
this thread is so full of fuck i can't understand if this is discussion about an instance system or server realms like WoW.
if it's the latter then this can already be achieved by instantiating a new World object in servers like apollo/scapeemu
why do u just say this without providing any reasoning as to why it would break anything?? there's definitely over 40k npcs registered on each game world on RS.
Well AFAIK every server that exists has a global index assigned to a npc, and doing so simplifies a lot of things. If you used local npcs list indices you would have to find the correct index for each player when sending for example a projectile that follows a npc, or to make a player face a npc.
I'm sorry, I got lost after the first paragraph. Please explain just what this whole thing is truly about, because it seems to me you are trying to build some giant management system for a server because of the possibility you would get 2k players all wanting to fuck the server over at once in a joint effort.
I am not trying to disrespect your proposal but what purpose would this have to be actually completed and put to use in a server? Correct me if i'm wrong but it seems like you just need to find a better way to handle the number of npcs instead of managing realms and regions and whatever else you were talking about.
I think I found that the main world could be up to 16384x16384 tiles, while dynamic maps were limited to 16384x8192 (1 bit less) due to the game protocol in 637.
I've successfully implemented this though, I called them "Maps" - Two kinds. Standard & Dynamic. Standard is the world you play in, dynamic is one that you can edit or is generated, such as POH and dungeons.
I wrote my server from scratch (That is, actual scratch) and that's why it was possible. I haven't implemented saving/loading/unloading yet though, but it works conceptually!
My implementation sucks on RAM (50-100MB of RAM is required to allocate the main world), but is much faster than most implementations computationally (Since I went for a single threaded architecture, this is definitely a justifiable choice). EDIT: [For when one of these children with the programmer title try and snark at me, that's 50-100MB per 16384x16384 tile map, obviously it's minuscule on a POH/dungeon]
Taking things into account? You would probably fall into a coma if you attempted to do this on any source that already exists. Imagine how many location checks in code there are (eg, nearby, item delete/pickup, attack, use, AOE spells, anything!) - They would all have to be updated to check your "Realm"/map system somehow.
I successfully did it though, and I'm pretty proud tbh.
well the way rs does it is simply cuts the "whole world" (16384x16384) in two and allocates the left half to the real world (0-8191, 0-16383) and the right half (8192-16383, 0-16383) to the dynamic allocation zones. that way it's all in the same "map" and you don't need any special handling for each "kind" of map (dynamic/static); you just spawn stuff in them as you would in the static half of the map with absolute coordinates.
The closest thing I can think of that would relate to this would be the system that Blizzard uses with World of Warcraft.
However, they are actually running a server that abstracts from the world server, I'm not sure what the name is, but I like to call it a 'jump' server.
Essentially a Jump server is an empty world, that's just sitting there waiting for something to be provisioned to it.
When, let's say, 5 people are matched up and ready for a dungeon, one of the world servers will find a jump server that is as close to each of the world nodes as possible.
When the jump server is resolved (selected for the dungeon), each of the world servers will shoot a packet over to each of the players and tell them to either connect to the jump server directly or tunnel through their current world server (I could figure this out easily if I still played WoW, but don't anymore).
The players will connect to the jump server only after each or one of the world servers tells the jump server to provision a unique phase for all of the players to be placed in.
The players will now be directly handled by the jump server instead of the world server, unless the world server is acting like a proxy for the player. If the world server is acting as a proxy, it will just simply mirror all of the packets over to the jump server.
The rest is self explanatory...
The key notes here are:
- Jump Servers are always running and pre-provisioned. They do not get started on demand. They just simply 'wait'.
- This is a system you ONLY want to use if you have a LARGE structure, and for scalabilities' sake
- This is extremely efficient and fast acting for the player, only if built correctly though.
- The Jump servers handle more then 1 thing. If you're building a system like this, you want it to be extensible, Ie. jump servers run battlegrounds, dungeons, raids, etc...
- This requires a lot networking knowledge and preparation, ie. being able to use your friends list to talk to friends, seeing the world friends are on from inside a jump server or when they are connected to one or a different one, etc..
- This is resource intensive, and again, it's meant to have jump servers running on separate machines
I could go on, but don't want to type up much more in a single post x.x
« Previous Thread | Next Thread » |
Thread Information |
Users Browsing this ThreadThere are currently 1 users browsing this thread. (0 members and 1 guests) |
Tags for this Thread |