What is TNet?
In short, TNet is a networking framework using TCP (and optionally – UDP). It has a simple and straightforward design and thoroughly-commented code, making it easy to work with. As some individuals noted, “TNet for Networking is like NGUI for UI”, although personally I think that’s setting the bar a bit high there for a new product.
Just like with NGUI before it, I plan on supporting TNet as long as people use it, and I will add more features to it as the time goes on, so if you don’t see a feature you really want – request it! If it makes sense, I will add it. Just keep in mind, TNet’s goal is to be the easiest to grasp networking solution. If you need out-of-the-box features like encryption or anti-hacking, TNet might not be what you’re looking for.
If, on the other hand, you just want to add multiplayer to your game with simple server discovery, hop-in hop-out gameplay and persistence, you will find TNet very useful indeed.
So what does it offer?
It’s Open: written in C#, comes as full source code for you to modify as you see fit.
It’s Readable: The code was written for others: it’s clean and thoroughly commented.
It’s Flexible: Server can be stand-alone, or started on another thread right within Unity.
It’s Adaptable: “Host” disconnects? Choose another. The game doesn’t end. Everyone disconnects? Save the state (if you want).
It’s Persistent: Not only can remote function calls be saved for future players, but you can save the entire server’s current state and then restart it. When you start it back up, it will be as if you’ve never shut it down (Auto-save anyone?)
It’s Powerful: Written to take advantage of high efficiency sockets (IO completion ports).
It’s Spacious: Each channel on the server is a separate area with its own rules (and save file), letting you host as many simultaneous games as your bandwidth can handle.
It’s Private: Playing by yourself? Put a password on the channel, or just flat out lock it. Others will still be able to PM you, of course.
It’s Consistent: You don’t need to put “if” statements everywhere. Same code that works for multi-player will work in single-player. The callback order is always the same. For example, players always get “left channel” notification before a “disconnect”.
It’s Efficient: You can optimize your frequent remote function calls by specifying a byte ID instead of a function name. Less data will be sent.
It’s Straightforward: Remote function call syntax and number of parameters are up to you. Arrays? Sure. Binary data? No problem. A hundred parameters? Uh. Well, sure, if you want.
It’s Elegant: You can even broadcast messages to players on the same LAN or wireless network without requiring them to connect to the server. Perfect for announcing local servers, for example.
It’s Useful: You can save files directly to the server, and load them later, letting players save their avatar thumbnail, inventory, or even an entire game map for others to load.
Platforms
TNet supports all platforms except Unity Android Basic and Unity iOS Basic. Flash supports TCP, but not UDP.
I’m a bit confused, i wanted to start with the example scenes but there was no connection info in all except menu, from what i understand you go from the menu scene, connect, and then go to the other scenes but when i’m in the menu scene, i can create a server (and view it from other instances) but then clicking on any of the “exemple 1. . .3” or “exemple chat” does nothing, i expect it’s supposed to load those scenes but for me it does nothing, regardless of if i’m trying in editor or on standalone.
Aaaaaand nevermind, posted to quickly, simply didn’t add the other scenes to the build (didn’t think it would matter in editor so had discarded that too early).
Free bump i guess
Yes it supports the web player, but you can’t host a server from the web player. You can connect and play just fine though – Unity Web Player | WebPlayer ← web player build.
NGUI is 50% off right now until the end of the year, and that’s a pretty hefty discount.
TNet is for communication between clients through a server, and doesn’t know anything about databases, so nope. The code is open for modification, however – so if you already have something that needs a database back end for which simply keeping saved data on the server isn’t desirable, you can just add it in.
Any future plan for adding Database support in your framework ?
I opened a link of webplayer provided by you. I already have tnet desktop demo. I opened that desktop exe and started as local server. From that webplayer link i just clicked on connect to 127.0.0.1 and its showing “connecting…” message since last ten minutes. So how to connect it?
Actually as someone who purchased, and who isn’t a first post, but who hasn’t had the time to test it, i’d love to see answers to a few points by this troll for clarification as some seem unbiased (he may be right or wrong, but it seems he did his research)
Points i don’t care about:
Comparison with built in
Usage of binaryformater
Comments on usage
Points on which i’d like to see you reply
Performance (and a quick talk about expected performance) of the library over internet, both TCP and UDP
Confirmation about receiving the same packet multiple times
Having to use IDs for methods, i didn’t go to that point so i’m clueless, and also his statement about being limited to 256 such methods
Thanks!
wow, ive been browsing the forums for some time now, but just had to sign up for this.
First, a bit of a background - i have been looking for a solid networking solution for a few weeks for a project. i started with unity’s networking like most people i guess, and ran into so many problems with it i dont know to even where to start. anyone can do a search on the networking forum to see the many issues with it i think so no point in going over them i thnk.
Next i tried photon, and its actually pretty good, but seems to be a little unstable? may have been just my luck with their cloud, i dont know. i had many random disconnects. the code was a little difficult to work with too, although the auto-conversion from unity networking to photon was great.
I looked into lindgren and ulink a bit, but both seem to use only udp which doesnt work on ios basic and flash. we dont need reliable udp at all, tcp is fine.
tnet seems to be the only one that offers all that, and is cheap too. code is great, very easy to follow, and examples are simple and easy to understand - all thats needed to learn how to do things quickly. there is no auto conversion script like in photon, but it only took me about an hour to port the prototype from photon to tnet to try it out, and amazingly all the issues seemingly went away. i have only been playing with it for a few hours but i have to admit i am impressed. easiest and most stable networking package i have tried yet. the code is openly available too, so if something goes wrong i acn fix it if needed.
and now for this thr fellow: i dont know what your deal is with the aronmook but i too think that you are trolling here. maybe you are an author of a competing package who doesnt like competition, but i say you put your money where your mouth is:
tnet is not using reliable udp that you seem to think it should - where did you even see it mentioned? reliable udp and basic udp are two different things. udp packets can arrive in the wrong order, but with often updates this does not matter at all. its also very easy to add your own number to the packet and discard out of order stuff if you care - just an extra parameter to pass to your rfc. and if you dont, you say its a major problem? have you evern written a single networkd app?
tnet does not mention NAT punchthrough anywhere - again where did you even see this that you are complaining about?
you complain about adding items you need to create to a manager class? lolwhat - clearly you have never tried other packages as they all need to do this
binarywriter is in efficient? not any more ineficient than any other mono class. do your research.
the library gives you nothing over unity networking? are you high? have you even tried using it? lol apparently not
you complain about specifying a byte identifier which is optional and limited to 256? if you plan on having more than 256 remote function calls on a single network view then you are a fool. and you claim its the only way to get performance? again lol what?
this package was released on christmas eve yet you are already here the next morning complaining with a “comprehensive” review? i call bs.
now its important to note that i was only playing with tnet for a few hours now, and i have never had a reason to post anything good or bad, but the thrs post was just too full of bs to pass up
I’ll have to side with thr there, while his review was “harsh”, it doesn’t sound like a troll to me at all, he definately purchased it, a troll wouldn’t purchase to troll, and he raised points that may be issues on his side (things that he expected and weren’t marketed etc), but i don’t think he’s being handled properly there, he didn’t insult anyone or anything like that and he did raise a few questions that i said i’d like (as a “certified non troll”) answered that have been eclipsed by the “troll vs nontroll” superbattle that is starting.
