AOI feature?

[chilly]

as we all know, in every networked game, there should always be an area of interest (AOI) for any given player to only see whats is around him in the specified AOI radius.
reason is we dont want to see all the world networked items , specially in a medium or large size world., since it will choke up the server and client, resulting in a very bad performance gameplay.

my question:
is this feature already implemented in TNET?
if not,    is this something the TNET creator willing to facilitate to the end users?

[ArenMook]

As with your other posts, AOI is highly game-specific. Only very few select types of games (mainly MMOs) need this feature, and 99% other games do not. TNet is meant to be a generic easy-to-understand-and-modify library, and adding AOI would not be a wise decision.

[chilly]

thank you Aren,

so meaning TNET is not meant for medium to large scale networked games?

so just for casual gaming?

is this what you trying to say?

[ArenMook]

Depends on your definition of "medium". Medium to me implies up to ~3000 CCU per server spread across hundreds of channels, which is something TNet will handle just fine. 50,000+ CCUs? No, it most certainly will not.

TNet is a library that's meant to be molded into whatever the developer wants it to be. As is with the development of every library, the more complicated it is, the more difficult it is to understand and modify to suit the developer's needs. I chose to make TNet as flexible as possible, and that meant choosing not to implement some fringe-case systems that apply only to a very few set of game types.

In your case you seem to be looking for a MMO back-end solution, and unfortunately no, $65 TNet is not going to do it for you out of the box.

[chilly]

i see,

well, i am looking to convert my existing rpg game to multiplayer, mrpg, and not mmorpg.
 i am not looking for 50,000k ccus, but mostly for 3k to 10k ccu server scaling if necessary and not be stucked with 1 physical server with max 3K ccu all bottle necking and lagging if reaching max capacity server hardware  and bandwidth can handle



so, you saying that maybe i should be looking elsewhere?  ie:
uLink? to handle a real authoritaive server , hardware node scaling and server collissions/physycs aware?

is this what you saying, ill be better off?

[ArenMook]

I am not familiar with uLink to give you that kind of advice. Isn't uLink using instances of Unity on the back end? If so, you are highly unlikely to be able to get more than a few hundred users before hitting some performance/memory issues due to server-side physics.

I'd try to rethink the design if I were you. You say 3k to 10k CCUs per server, but as you know hardware will prevent you from having that many CCUs on a single server, so it has to be a cloud by that point. As far as I know, what WoW did is it had 1 server per continent. Azeroth had one, Kalimdor had another, and since the soft cap on servers was roughly around 3500, each server was handling no more than roughly 2k -- which, when spread among different zones, was quite easy to handle. TNet can easily be used to do the same thing -- but you will most likely want to implement logic that would send packets based on proximity, not just "everyone in the same channel".

[chilly]

ok, well, the wow example makes logic, but that is if your server can be spread across multiple hardware nodes, right?


i mean, i can have my world split into several zones, where each zone can be a channel, and if max ccu per channel reached then instantiate another instance of the zone, but the question is , ill be doing all that in the same server, so still not viable since will be in the same hardware node and will still be hardware dependent to accommodate ccu.


i think the best approach can be as ulink, i mean i havent played with it much, but so far i know it can be configured to use a scene as a zone, having several scenes which will make the world.  and out of the box ulink has a uZone feature which will instantiate the zones automatically when the max ccu capacity of that zone has been reached, also, each zone can be in a separate hardware node, ie; in other hardware node where they will talk to each other , ie:
a player is in zone 1 in datacenter hardware box 1 with max ccu user limit set to 50/zone instance, if more than 50 users requesting that zone, the node will automatically instantiate a second instance of zone 1 etc..., then player goes to portal , portal will handover the player to zone 2 which hosted is in another hardware node/datacenter etc...

so, so far, ive learned that ulink can handle zoning to talk ot each others to handover players across datcenters/ hardware nodes to load balance.

now, you can setup a hardware node to be used for just zone 1 by itself, and set each zone instance to handle 50 ccu max, but have a max of 50 instances ran at a time in that particular node.  meaning now i can handle 2500 ccu using zone 1 of my world in 1 hardware node, then another 2500 ccu in zone 2 in another hardwere node/datacentr, and scale up my world massively. accross datacenters/hardware nodes.

that is so far i have found out about ulink.


so wanted to know  if TNET had something similar to scaling up .

[ArenMook]

Automatically based on the number of players? Nope, TNet doesn't have that. That logic is up to the dev, and is rather simple:

On the client, when considering joining a channel you can check the number of players inside, and if it's above a certain threshold, join another channel instead. Too many people on the server? Check the lobby server's list for a more empty server, and go there instead. It's a few lines of code at most. No server modifications necessary.

Again, keep in mind... instances of Unity on the server mean the limit of players per server is going to be severely reduced. But if that's not a concern and you have the budget for all the added processing power, then uLink sounds like it will be a better choice for what you are trying to do.

[chilly]

ok, well i think i am understanding your point.

but my only concern is this:

1- if too many ccu in one physical server , the main server/lobby can check on that and connect player to a less populated server, right?, is this process automated by the server/lobby by default? if not how hard can it be to add such a thing?

But....
my main deal is to have a centralized db for world persistence, i see that tnet already have that, but per server basis, but i wanted a global persistence, perhaps the server/lobby can do that?
i mean that player will have the same persistence info in any given physical server?
i hope you understand my point here.

if tnet cant do a global persistence world, how hard will it be to do such a thing with tnet, hmmm... maybe to use mysql? instead.

2-this concern is the authoritative server,  as your statements, you mention the very first host that joins the channel will be the authoritative host.  i dont like that at all, since it will be prone to its own cheating malicious mods if that it its intentions of the first host that joins in.
any way to force tnet to have its own authoritative host, instead  a public one/ first connect host to be??

3- server side collisions, is this a really functional feature when a first or host is connected, all the other players will obey by its collisions rules automatically, or do we need to do some mumble jumbo coding checks to make this happen?


 

[ArenMook]

One of the TNet users used the following approach for an authoritative server. He built the game with TNet in it in a headless mode (no graphics). The server executed TNet server instance right away. Clients would connect, and instead of requesting to join a specific channel, they would PM the server bot, who would then spawn a new instance of the server-side player, who would then enter the channel, thus becoming the authority. This server-side player would then message the original client player, letting them know that it's ok to join the channel. Since the server-side player instance was first to join, it would be taking care of all the physics as well. Whether you would need this kind of approach or not, I don't know. As I always say, first make a game worth hacking, then worry about hacking.

Keep in mind the client's code has full control of what happens, so it will do whatever you tell it to. You want it to not allow joining a channel that has too many people in it? Then don't. You want it to prevent connecting to a server that's "full"? Then prevent it.