With that crappy support uLink seems to give, id be against continuing with them down the line. id suggest something open source and well proven to be honest.
I don't have experience with Unity but it seems it runs C# code? i assume it compiles to CIL and can use the .NET libraries? and if thats not the case, Unity will still have basic socket access somewhere, which isn't as important on the Client side.
so we know absolutely nothing about the server side of Rust right? does it use UDP? client is made with Unity/C#, i can only assume the server is written in C# too?. both client/server using uLink at the moment (a proprietary protocol?) scrap that IMO and optimize along the way with something new.
a quick google doesnt show me a whole lot of .NET 3rd party network libs (unlike Java that has netty & mina) i can only assume thats because the .net networking api can do everything quite well? i assume all XNA games use it. why not build it from scratch and optimize over time? with all the cash building up as of recent, why not fund a top of the line .net programmer to work on the IO and optimize as much as possible?
my thoughts, if anyone has any suggestions put them here!
[QUOTE=Handsome Matt;43328934]I said in another thread about this already, but if Garry intends to rebuild the networking I suggest he uses [URL="https://code.google.com/p/lidgren-network-gen3/"]Lidgren[/URL], it's not built for Unity but it's a lot better then any solution made for it.[/QUOTE]
Yeah should do that for the server, especially since its open source. for the client just use Unity's built in networking library to talk to the server.
The server uses Unity as well, it just runs in batch mode (without a window and rendering). Both the client and server use uLink, as it provides a protocol and an abstraction on top of that.
Unity supports C# and all of the Rust logic has been coded in C# (it's all mono, even on windows - but only up to .net 3.5). This means any .NET assembly 3.5 or lower can be used. It also means all standard .NET types are exposed to Unity (as you mentioned, Sockets and stuff are available).
The problem is uLink is quite high level. An alternative can easily be built from the ground up using a library such as Lidgren to abstract away some of the low level socket stuff, but for a proper networking solution, we're talking weeks if not months here - this might be too long term if the DDoS doesn't stop.
[editline]28th December 2013[/editline]
[QUOTE=xEnt22;43329015]Yeah should do that for the server, especially since its open source. for the client just use Unity's built in networking library to talk to the server.[/QUOTE]
If the server uses Lidgren, the client must do to. It's a two-way library.
There's also Photon, but nothing as drag-n-droppy as ulink. I don't know enough about it, but it seems like choosing something that has the full source available (like lidgren) would be the best way to go so that you're not relying on third parties to get their shit together.
[QUOTE=thomasfn;43329110]The server uses Unity as well, it just runs in batch mode (without a window and rendering). Both the client and server use uLink, as it provides a protocol and an abstraction on top of that.
Unity supports C# and all of the Rust logic has been coded in C# (it's all mono, even on windows - but only up to .net 3.5). This means any .NET assembly 3.5 or lower can be used. It also means all standard .NET types are exposed to Unity (as you mentioned, Sockets and stuff are available).
The problem is uLink is quite high level. An alternative can easily be built from the ground up using a library such as Lidgren to abstract away some of the low level socket stuff, but for a proper networking solution, we're talking weeks if not months here - this might be too long term if the DDoS doesn't stop.
[editline]28th December 2013[/editline]
If the server uses Lidgren, the client must do to. It's a two-way library.[/QUOTE]
even still, theres nothing they can do, and even if uLink fixed their shit now you'd rather not rely on them down the line. i think the only option is to build their own so they have full control of it.
let the client use Lidgren too then!
Sorry, you need to Log In to post a reply to this thread.
