Messages

1

TNet 3 Support / Re: Client side movement prediction

« on: May 10, 2014, 07:55:30 PM »

Client Side Interpolation and Prediction is something I covered extensively in my thread over here:

http://www.tasharen.com/forum/index.php?topic=5788.msg30798#msg30798

Of which you can find my interpolation and network time synchronization scripts.
I also developed client input prediction as well to handle player movements, but I never released it publicly as I felt it were too much of a pain and didn't work as nicely as I wanted it to. Mainly due to the fact that Unity is not capable of rolling back physics states and checking collision without time passing or progressing to the next frame.

But if you want interpolation my example work fairly well. Aren and a few others suggest different methods by only sending update packets when something important happens like a collision and maybe an update packet twice every second or so. Then "lagging" the renderer behind the physics object. Now this will work for a lot of games, but if you have a very physics precise game then my solution will work better. Just remember though that it has it's own pro's and con's and that anything in networking can always be a mighty challenge to overcome.

2

TNet 3 Support / Re: TNObject send parameters

« on: May 07, 2014, 02:39:48 AM »

Coppied from Line 240 from UnityTools.cs

1. static public bool CanBeSerialized (Type type)
2.         {
3.                 if (type == typeof(bool)) return true;
4.                 if (type == typeof(byte)) return true;
5.                 if (type == typeof(ushort)) return true;
6.                 if (type == typeof(int)) return true;
7.                 if (type == typeof(uint)) return true;
8.                 if (type == typeof(float)) return true;
9.                 if (type == typeof(string)) return true;
10.                 if (type == typeof(Vector2)) return true;
11.                 if (type == typeof(Vector3)) return true;
12.                 if (type == typeof(Vector4)) return true;
13.                 if (type == typeof(Quaternion)) return true;
14.                 if (type == typeof(Color32)) return true;
15.                 if (type == typeof(Color)) return true;
16.                 if (type == typeof(DateTime)) return true;
17.                 if (type == typeof(IPEndPoint)) return true;
18.                 if (type == typeof(bool[])) return true;
19.                 if (type == typeof(byte[])) return true;
20.                 if (type == typeof(ushort[])) return true;
21.                 if (type == typeof(int[])) return true;
22.                 if (type == typeof(uint[])) return true;
23.                 if (type == typeof(float[])) return true;
24.                 if (type == typeof(string[])) return true;
25.                 return false;
26.         }
27.  

These are all the types you can serialize. Things like game objects or transforms are too complicated and have references to things that are explicitly local to your simulated game.
If you want to identify a gameobject or send an object reference to a client, I recommend sending it's TNObject Unique-ID. And then searching for it locally on the player.
Or alternatively syncing your own ID system.

3

TNet 3 Support / Re: Preventing Cheating

« on: May 03, 2014, 07:57:54 PM »

Cheating is always a big issue and it affects every game on the spectrum from industry to indie. There's no easy solution to fix it, and the fact is that no matter how much you "cheat resist" your game, a user with enough technical skill will always be able to get around it in someway.

Now that we understand that completely preventing cheating 100% is impossible we can look at some things we can do, and some things we should do. For an authoritative server, cheat prevention can be easy as simply adding a :

1. if (!TNManager.ishosting)
2. return;
3.  

statement to some server-only logic, to ensure the client doesn't run the same thing or send anything to the server that it shouldn't be.

Keeping small things like this in mind when you code is a very basic but very efficient "future-proofing" method. Just iterate through you head "Who should be allowed to change this? should I have a check on to make sure that it changes right? What happens if the client sends this?" Etc.
Although wanting a complex long-term solution sounds like a logical idea, planning ahead right. It's really not worth it. My best piece of advice is to first make a game worthy of cheating in and then wait until people start cheating in it to make solutions for it. Otherwise you're stabbing in the dark because what if you create this complex anti-cheating system that took months of productivity and time only to turn out that you've changed some mechanic in your game where it's no longer required. Furthermore, when players start cheating you can address directly what needs to be fixed or secured down rather than once again stabbing at the dark.

While it seems like a logical investment to sort it out now, there's more other important things to work on. Always wait until you have a worthy game worth cheating on and cheating actually becomes a problem. It'll save you time and a lot of headaches.

4

TNet 3 Support / Best Approach

« on: April 29, 2014, 09:57:27 PM »

Hey again

Im just wondering, what would be the best approaching for having a sort of pre-match lobby for a server. So there would be a global list of servers, the player would choose one and connect, this would load up a match settings area (think RTS games) where teams can be setup, player colour, etc. Or where the admin can choose the map and map size, etc.

What would be the best way to approach a situation like this? Would it be best to say have a JoinChannel(1, "matchsettings") and then when the game begins do something like
JoinChannel(2, "game")? Or is there a better way to do this. Also, when everyone leaves a a channel does it clean itself up or do I have to close it manually, etc.

Or alternatively can I stay on the same Channel but change the map?

Cheers!

5

TNet 3 Support / Re: Networking Initialization

« on: April 18, 2014, 06:09:37 PM »

Thankyou!

6

TNet 3 Support / Networking Initialization

« on: April 18, 2014, 06:03:47 AM »

Hey there, is there a way to know when all game objects have been instantiated onto the client on first join?
I have a function that needs to be run on the client but it requires that all objects already exist in the scene. I currently have it being called at Start() but this seems to call it before the objects are created due to the delay caused by packets in transit.

Cheers.

7

TNet 3 Support / Best way to send object reference?

« on: April 15, 2014, 10:46:44 PM »

Hey there, I need to send an object to my CreateEx function, but Transforms and GameObjects don't serialize, so what's the best way to send an object reference so I can look it up locally?

8

TNet 3 Support / Re: What is the best way to sync positions, rotations ?

« on: December 07, 2013, 09:30:29 AM »

The Global and NetworkTime classes are just singletons. Just whack them on any gameobject and it should remain persistent through the scene.

Then put the SyncNetworkObject on the object you want to sync data for (e.g. a rigidbody or whatever)

9

TNet 3 Support / Re: What is the best way to sync positions, rotations ?

« on: December 07, 2013, 08:39:09 AM »

I implemented an interpolation method which you can use here if you like:

http://www.tasharen.com/forum/index.php?topic=5788.msg30798#msg30798

10

TNet 3 Support / Re: Time synchronisation and manual ping

« on: November 27, 2013, 06:06:48 PM »

Do you know how long the main thread is taking? (Check profiler if you can)
If you have a lot going on, or are processing a lot of data (like iteration through massive lists or something) then you increase the ping because the server/client takes longer to respond.

Ping=[Client Process Packet->Client Send Packet----TRANSIT----Server Receive Packet->Server Process Packet->Server Send Response->----TRANSIT----Client Receive Packet->Client Process Packet]

Also bare in mind with my implementation of time synchronization you will NEVER get perfectly accurate time. The accuracy is however ~10-80ms from my tests, which is perfectly acceptable for online gaming. You can improve this by increasing the amount of requests to send to build the average list, it should be commented in the file what you need to change to improve accuracy.

Even then though, it's unlikely you'll ever get below ~10ms of accuracy.

11

TNet 3 Support / Re: Networking Physics Discussion

« on: November 07, 2013, 11:12:06 PM »

Due to the increasingly high amount of issues brought about by Unity's lack of efficient networking for physics heavy games, I've unfortunately been forced to swap engines from Unity to UDK. The built-in networking in UDK is phenomenal, and the physics system provides an efficient and effective way of doing smooth interpolation and prediction of objects and players as well allowing for complex simulations that are interactable for the client. Luckily I was still in the prototyping stage for my game so it's not a great big deal doing this transition. It is unfortunate that it came to this, but I knew I would be spending at least well over a year to bring the networking up to a stage I was happy with, and that is time I just do not have.

Unity is a great engine, there is no doubt about that, and TNet is a fantastic solution for the sub-par inbuilt networking for Unity, I would certainly recommend it to anyone. I'd also like to thank Aren for all his help, as well as every other community member on this board. Feel free to use this thread as a hub of knowledge for complex networking

Because I will be no longer needing my scripts anymore, you can all have them. Feel free to upgrade them where you see fit, they're all heavily commented and work generally well.

NetworkTime.cs is my own networking time solution. It accurately syncs time across all connected clients, and automatically checks for clock drift at a set interval and updates where necessary. The logic of it is based on this article: http://www.mine-control.com/zack/timesync/timesync.html

SyncNetworkObject.cs is the script that you attach to any rigidbody you want to be networked. It will automatically update the position and rotation and physics data of your rigidbody or object over to all clients. It's primary function is to buffer changes over the ping time so it can smoothly interpolate effectively hiding lag.

Global.cs is just a global singleton class where I hold some variables that both scripts reference, not really important.

Good luck guys, if you have any questions feel free to ask!

12

TNet 3 Support / Re: Networking Physics Discussion

« on: October 08, 2013, 12:53:38 AM »

The server allows the client to handle collisions the player makes as part of its own prediction, if not then the client wouldn't predict properly in the first place, as the server would handle the collision but the client would keep moving. So in a way the client does *simulate* its own, yet very limited, version of physics. This simulated state of physics can be overwritten at any time of course by the server.

13

TNet 3 Support / UDP Lobby Server

« on: October 04, 2013, 09:08:56 PM »

I modified the standalone server example to just run an external UDP lobby server. However when clients start a server, their internal IP address is shown rather than their external.
I'm just using the example menu for hosting servers inside of Unity.

How can I get it to show the external IP?

14

TNet 3 Support / Re: Networking Physics Discussion

« on: October 01, 2013, 07:15:23 PM »

Good job on the Bullet Wrapper by the way. I was going to go down that route, but decided against it (for now).

I've seen that article too, great source of information. Especially in the comments section below the article itself, they begin to talk about alternative methods to Client-Side Prediction, since it's sort of an old system, and rewinding and replaying can be rather expensive to do for complex simulations.

15

TNet 3 Support / Re: TNet capability

« on: September 29, 2013, 02:06:48 AM »

TNet is a robust networking solution that serves a lot of functions. It can do lan and multiplayer networking.