Understanding Deterministic in UCC

C

chrisk

Active member
Hi, Justin,

I recently stumbled upon performance issues and I found out that DeterministicObjectManager takes the most of the CPU cycles, hence I'm trying to understand why and what it's doing?

I have several questions and I hope you help answer them.

1. Deterministic means that it's predictable. Is that what you are trying to do? perhaps for the network synchronization? Or are you just trying to make the character animate smoothly?

2. If the answer is to make it predictable, I know it's a good thing if we can achieve deterministic behaviors, however, Unity itself is not deterministic, mainly due to the Physic simulation. Even if you make UCC deterministic, the game will not be deterministic because of the randomness in Unity. Unity talked about making the physics deterministic but it's far down the road. If Unity cannot be deterministic, what's the point making UCC deterministic?

3. From what I understand, UCC uses fixed timesteps to recalculate everything. Is it really necessary to recalculate everything in the FixedUpdate(), including, collisions, animation, and etc? Even if the purpose of having DeterministicObjectManager is to make it predictable, you can still do the expensive calculation in Update() and just interpolate results from the last Update() to the current Update() in FixedUpdate(). This is what UnrealEngine does.

4. When a user is making a game with 100s players and if we can have 100s of players in a single scene and get a good framerate, my questions won't matter but it seems almost impossible expecting good framerate(disregarding rendering time) in the current setup. Have you run a simple test with 100s of players? Well, assuming the user favors faster FPS, instead of the accurate prediction, is it possible we can turn it off? Just interpolating positions, animations without the expensive operation may be much better desired. Yeah, changing the fixed timestep would not be a good idea since it will affect everything else and fundamentally, it doesn't really fix anything.

It can be quite difficult questions and I hope I better understand you and UCC.

Thanks a lot!
 
Last edited:
1 & 2: Yes, it is to make the character deterministic for network playback. Unity's physics isn't deterministic but we aren't really using Unity's physics - since the controller does all of the collision detection it doesn't need Unity to be deterministic.

3: To have a fully deterministic character it is. Even animation needs to be run in fixed update because of root motion. The DeterministicObjectManager does smooth the results within the Update loop. I can look at not having the animator update within fixed update though if you are not using root motion.

4. I have not run a test with that many players because you generally will be having things disabled for remote players. If the character is a remote player then really all that it needs to update are the position, rotation, and animator once every frame and not go through the UltimateCharacterController.Move method. For AI you'll also want to disable unnecessarily calculations - something like IK takes a considerable amount of time and if the character isn't in view then IK should be culled to prevent it from running.
 
1&2, Even if the character is deterministic, it will still be very difficult to make a deterministic game. If you truely want to make a deterministic game, synchronizing user input is a far better way as the network usage is very small.

However, I'm not sure if such User input synchronization method is desirable. If there are delays, everyone else has to wait. Photon Quantum is trying to do that but it will only work when the network is very steady. I think it will be only good for a turn-based game in my opinion.

I'm not certain if deterministic FPS game is really possible or desired, most of them are just doing dead-reckoning and that's pretty much the standard. Perhaps we are talking about two different determinism here??

3. Oh, that would be a good option. But won't root motion work with Update if you know the time delta?

4. I'm not sure if UCC already doing it or you are planning on doing it? Yeah, it makes sense to make non-player character use as little as calculation, however making non-player as good looking as possible is also a goal. I have to assume that they can be in all in one place(imaging a waiting area in PUGB) and they have to use at least Weapon Aim IK, otherwise, it won't look correct.


In a summary, right now I'm not so sure what would be the benefit of paying a high price for a deterministic character. I can't tell if there is improvement visually nor deterministic FPS game is even possible.

Thanks.
 
Last edited:
For server reconciliation and client side prediction the character controller needs to be deterministic in order for the server to accurately playback the user inputs. The rest of the game will also need to be deterministic for accurate playback but the main moving pieces are covered by the character controller so I don't think that this will be too much of an issue.

chrisk said:
I'm not sure if UCC already doing it or you are planning on doing it?
Click to expand...
It's not disabling unnecessary scripts right now - that will be part of the networking addon.

Edit: going back to single player/ai, I could see adding an option to the controller so that it can automatically cull itself, such as only updating once every update loop. You wouldn't want to do this with your main player but it could make sense for ai.
 
(I edited my previous post with an idea for single player culling just in case you missed it).

chrisk said:
I can think of Vehicle. Determinism will fail when it comes to objects are driven by physics.
Click to expand...
That's true - the vehicle controller would need to be written to support a deterministic timestep. This does mean that it means that the existing vehicle controllers on the Asset Store probably will not work without a lot of modification. But in order for them to get the best results on the network they would need to be deterministic anyway.
 
Ok, if you think you can make the character deterministic at least, meaning when you shoot a guy, both your and your enemy player are really synchronized, I'm all for it.
I don't think I haven't seen any game that let you do that. There was a game called SeriousSam in mid '90s that used User Input Based synchronization that had perfect sync but, the game was basically unplayable over the internet. haha..
 
Having both you and your enemy player synchronized is that I mean by determinism. If the enemy character is not synchronized, there is no point of making a deterministic game.

Your character will always be synchronized on your computer so... no need to make deterministic just for the player character ^^

I assume that you are making the deterministic character for others to see you exactly where you are. Just to make sure we are talking about the same thing. And I think it will be a very difficult task unless it's impossible with a high latency network. I'll wait until we see the network add-ons.

Sorry about being a bit negative but I'm bit concerned that it will end up CPU hungry and does not behave as deterministic as expected.
 
I understand your concerns but don't worry - a year ago I had a prototype version of the controller working with unet with server playback and it was working well. I ended up having to stop because of a bug in the animator but the deterministic part was working well :) I will also be looking at performance with many players when implementing this but I don't think that it will be too much of an issue because the remote players won't be running the full update loop.
 
I think I have a better understanding now what's going on.

The player character will move deterministically but the enemy player will move using prediction. It's not like every player is in perfect sync. As I mentioned it previously, it's very difficult or impossible without a bad side-effect.

So my take is that it is no different from traditional sense. Your character has to move independent of the framerate, otherwise unplayable.
I think it's a misnomer that it's named deterministic. I thought it was designed for the exact network synchronization for the both end. ^^

Anyway, thanks for the clarification.

ps. FYI, In every FPS game, users are the most sensitive about lags and hit detection. Users rage when they get killed in a seemingly impossible situation they always say that the opponent is a hacker. We spend countless hours trying to verify if the players is really a hacker. So reducing such complain can save us a huge amount of time during the service.

It happens because the hit detection happens on the client(hit detection on the server is not acceptable because of the delay and user will complain much more of bad hitbox detection) and the player positions are predicted on the other side. Only way to fight it is to send the packet as often as possible. When users cheat there is nothing you can do it in p2p network. That's why you need a dedicated server to verify the hit before accepting it is a valid hit, for an example. I hope it makes sense and the reason why I'm very interested in determinism.
 
Last edited:
Hi,

Having a clearer understanding of what Deterministic means in UCC, I have few comments to make, hopefully, it will make UCC more optimized.

Problems.
1. Deterministic update happens in FixedUpdate and it currently uses most of the CPU cycles.

2. Since the update happens in FixedUpdate, it's causing conflicts with other assets that depend on Update.
2.1 Currently, you cannot simply parent UCC character to other moving objects. It will cause stutter.

2.2. FinalIK solver is incompatible since it happens on LateUpdate.

3. UCC Deterministic doesn't really make your character to synchronized over the network and I thought it's what it was for, mainly.

4. Unity itself is not deterministic, therefore, making UCC character deterministic will not make the game deterministic. It will run into many issues when UCC character is interacting with non-UCC objects(nonstatic) because the update happens in a different loop. I don't think it's possible to solve the problem unless the position and collision detection happen in the same loop.

Benefits.
1. If you are using root motion animation, it can make the movement more accurate.

My thoughts.
1. There could be more benefits that I didn't think of but I think there is too much problems and high CPU price to pay for it.

Proposal.

1. Please add a mode that doesn't use Determinism. If your character is moving mostly by mouse click or WASD, the more accurate root-motion will not be noticeable. Yeah, if you are making a fighting game where characters move very randomly, accurate root motion is important.

2. If adding an option to turn off Determinism hard, I would rather remove it.

Thanks.
 
1 & 2 can be solved by writing a cleaver integration script. Version 1 of TPC was updated in FixedUpdate and had a FinalIK integration that worked well even though FinalIK updates in a different loop. UFPS v1 was also updated in FixedUpdate and had many integrations to go along with it.

3. It doesn't automatically make your character synchronized over the network, but it does help with network playback. Without a deterministic character server reconciliation and client side prediction wouldn't be possible.

4. Unity's physics being nondeterministic does not have any effect on the deterministic nature of the controller. The physics raycast calls will return the same result given the same input which is what really matters to the controller.

The controller was designed from the beginning to be a deterministic character controller and it is so ingrained into the controller that it would be a significant undertaking to change this. I also do not see any advantage of having a nondeterministic character. If you are running into performance issues different systems can be culled so they are disabled or not updated as often, or you can also adjust the physics timestep to reduce the amount of time in between fixed update loops. Due to the DeterministicObjectManager the controller will still run smoothly even with a slow fixed update time.
 
How did you solve TPC v.1 FinalIK integration? Did you make FinalIK update to happen in FixedUpdate too? or else?

This is my understanding.

Update() happens at every frame anyway, no matter how many FixedUpdate happens, users will see the result at every frame.
In other words, you can press WASD very fast at sub-framerate but you will see the result as if you pressed once, roughly.

I think FixedUpdate is for the fast moving objects to make the physics more accurate, and not about user input and slower moving objects such as character.

Yeah, more accuracy would be better if affordable, but making non-deterministic character would be as good as a deterministic character in most of the case in my opinion.

Thanks.
 
chrisk said:
How did you solve TPC v.1 FinalIK integration? Did you make FinalIK update to happen in FixedUpdate too? or else?
Click to expand...
No, the integration updated all of the FinalIK components within LateUpdate. The LateUpdate code only ran after a FixedUpdate though.

chrisk said:
I think FixedUpdate is for the fast moving objects to make the physics more accurate, and not about user input and slower moving objects such as character.
Click to expand...
It's also useful for network playback :) There simply isn't a way to predict the client's location without having a deterministic controller.
 
Ah, I see..that's an idea to try. I guess I need to know when the last FixedUpdate is finished.
If there is a quick answer, please let me know. ^^

I'll have to think about what it means by network playback. I assume you are not talking about capturing network packets and playing it back through the packet reply. Or you are really talking about packet replay? Is this something you will support in the future?
Yeah, you will need determinism for playing back the captured gameplay but then it will not be possible unless the whole engine is deterministic.
 
Hey @Justin do you have any code examples of the original FinalIK integration where the the FinalIK components were updated within LateUpdate but only ran after a FixedUpdate? I believe the currently downloadable integrations are for the v2 controller.

The reason I ask is that I have heavily modified the FinalIKBridge for my own application, but would like to use FixedUpdate instead of Update to move the character. However in the current FinalIK integration the code says: Debug.LogWarning("Warning: The Ultimate Character Locomotion Update Location must be set to Update." Therefore, I also wanted to get a better understanding of why it needs to be set to Update and how to workaround that.
 
I don't have a code example anymore but the idea was to set a flag (m_FixedUpdate) to true within the Fixed update loop, and then only execute the LateUpdate code if m_FixedUpdate is true.
 
You must log in or register to reply here.
Top