Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - chilly

Pages: [1] 2
1
TNet 3 Support / Re: Load balancing concept.
« on: January 10, 2015, 04:27:31 PM »
ohh man,

that sucks,

no AOI feature,

its ok, dont worry, i purchased Bolt network engine from fholm,

this nice little gadget has more advanced features for mmo or open world style kind of game.

dont get me wrong, tnet is ok, but very raw barebone base features, so one will need to code all the specifics for any genre type of game.
seems like you finished your windward project hence you stopped enhancing tnet, just what you needed for windward , so seems that tnet has peaked since last year.
hopefully youll rethink and keep on adding more couple of game genre specific features to make it more robust.

maybe in my other next project in a couple of years, hoping tnet gets more mature as i thought it would, but seems to be still the same from last year, i mean genre feature wise.


thanks, have a great 2015

2
TNet 3 Support / Re: Load balancing concept.
« on: January 09, 2015, 11:03:33 AM »

Next feature I'll be adding to TNet is proximity-based TNObjects. Ie: when creating an object, you can choose the "radius" value, and the object will be created when players enter the radius (along with all the RFCs), and will be destroyed when the player leaves the area. I figure it will be needed for Windward as well -- as there is no point in sending frequent packets of far-away ships.

@Aren
long time no see,  happy 2015 to all

ive been away for almost a year letting tnet to mature before i work on my tnet project.
but seems that the features i was expecting or in the roadmap were never added.
:-(

maybe i am wrong,  but  Aren:
is the feature above regarding AOI or TNet is proximity-based TNObjects  you talked about last year you mentioned it was going to be added 2 weeks after in march 2014?


i looked the release logs and did not see anything related to AOI or proximity feature you talked about.


or maybe is under different feature name?

so my question is did i waited in vane a year for tnet to have its own aoi(area of interest)  or proximity feature you talked about?


please tell me you already added it.


please let me know.

regards

3
TNet 3 Support / Re: Load balancing concept.
« on: March 21, 2014, 07:23:09 PM »
Awesome,

that is what i was talking about long time ago, regarding AOI/network LOD   support

Aren,

when will you be releasing this new feature?
weeks or months?

4
TNet 3 Support / Re: Server Itself become Authoritative Host
« on: March 21, 2014, 07:17:12 PM »
ohh, yeah,

i knew that it can run standalone without unity ,
but what i was referring to if used in unity instance to create an authority host as a (authoritative server)
then it will be capped at max ccu that unity can support in 1 single core hardware since it is a single threaded unity instance.

is this correct?

5
TNet 3 Support / Re: Server Itself become Authoritative Host
« on: March 20, 2014, 03:07:39 PM »
I'd like to clarify what Aren says.
So basically, in TNet, the actual physical server application is nothing more than a middleman for routing messages (it's a bit more complicated than that, but it helps to think of it that way). That's pretty much all it does, and it has zero knowledge of Unity at all.
In my game, I needed a dedicated server model, and the way you do this in TNet is by having a special build of your game which acts as the "game server", by starting up a TNet server instance and immediately joining it. Therefore your "server" is technically a player (as far as TNet is concerned) and because it joins first, becomes the host. This is what I'm doing in my game (since I needed server authoritative logic) and works like a charm.

I see your point, but...

isnt unity instance a single thread application?  meaning it can hold as much activity as a single core can handle?


so if you use 1 unity instance for dedicated host(to have authoritative server) in tnet.  woudnt that mean that you server may get very unresponsive and laggy with say over 50 online players in that particular unity instance?

which you may need to create another unity instance manually to hold another 50 players?


i am not sure yet, but sounds like unity networking cap is due of its single threaded capacity, so if more that 50 ccu in the instance the single core will get maxed out therefore gameplay ruined?

regarding ulink networking docs setup, they tried to to overcome this nasty cap of unity instance by doing a uZone witch will automatically fire up another unity server instance once it reaches certain number of ccu and assigns cpu affinity to the new fired up instance to avoid cpu saturation.

their philosophy sounds like :
if you have a multicore hardware for server, the assign affinity to a unity instance per core and have a master server that will check if one unity server instance is full the connect to the next in line

ie:
hardware with 8 cores, you can run 8 unity host (authoritative)  instances
max players per instance 50 (depending on your gameplay features, physics, server side collisions player checks etc...)
Like Aren said, if you use tnet in a unity instance fopr server side then your server resources will get eatup bu unity very quickly, therfore support less ccu.

= 8 x50 = 400 players in a 8 core hardware node.    sounds very little ccu for that hardware machine?  not sure.  but in theory that is it.

I think every networking tool that requires a unity instance to become a server will always have that cap due of the single threaded limitation.


would you care to explained on  how you overcoming this?  hopefully will help us to escalate the server setup.

thanks

6
TNet 3 Support / Re: Mecanim over Tnet
« on: June 02, 2013, 12:29:09 AM »
animation synchronizations over the network using mecanim

7
TNet 3 Support / Mecanim over Tnet
« on: June 01, 2013, 11:25:38 AM »
since mecanim over network hasnt been that much clear over in unity forums,

was wondering if Tnet will make this process a little easier of clear to work with.

any plans on a sample video tutorial on how to work with mecanim and Tnet?


8
TNet 3 Support / Re: AOI feature?
« on: May 28, 2013, 10:06:10 AM »
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?


 

9
TNet 3 Support / Re: AOI feature?
« on: May 27, 2013, 01:33:12 PM »
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 .

10
In regards to "isnt speed hacks and walk thru walls concerns in pretty much any type of game?"

I created a game called Starlink: http://starlink.tasharen.com

In Starlink, there are no colliders, no walls, and no "going through" anything. How would such checks apply for this kind of a game?

space games only, i dont see any other way, so meaning only 1 genre , ie: space games are the exception.

but other than that all other none space genre games require collisions. you have a terrain/platform  and world object you will collide with.

so i dont see a relevant answer you space genre example,  since you implying because space genre collisionless example, means all the rest should be the same.

bad example bro.

11
TNet 3 Support / Re: AOI feature?
« on: May 27, 2013, 01:03:11 PM »
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?

12
well, i was expecting a more concrete replys in my posts.

so basicly tnet is just like photon server a socket based/room based which will be relied as authoritative server to the first host that connects to the lobby, right?

unless you have a static host un the net/cloud to be the authoritative at all times?
so if this host is offline then the first player that connect to the lobby will be authoritative  like photon cloud? but without the cloud service here?


hmmmm...

so in other words is like photon networking cloud without the cloud service offcourse,  but just simplier to use?

i mean, anti cheating i do agree is custom to each game, but isnt speed hacks and walk thru walls concerns in pretty much any type of game?
so i would not say those 2 main concerns are game specific. i mean at least from my end, maybe be not yours.




13
TNet 3 Support / Re: AOI feature?
« on: May 27, 2013, 12:36:21 PM »
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?

14
TNet 3 Support / AOI feature?
« on: May 27, 2013, 11:51:26 AM »
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?

15
TNet 3 Support / Authoritative server and server side collisions
« on: May 27, 2013, 11:39:52 AM »
ok, here is another concern which i cant get a definite answer by reading forum threads.

tnet server is just a socket server , right? meaning is not aware of physics or collisions from unity right?

so, how can one handle this sort of thing?

reason is avoiding the nasty and typical walk thru walls deal.

as per reading the tnet server is just a socket server which acts as a lobby, is this correct?

now, how can we run an authoritative server to avoid nasty cheats and server side collisions?

will appreciate if someone can elaborate on this topic.

thanks.

Pages: [1] 2