4 ms·

Aren't inputs usually on a queue? So you shouldn't miss them. And why shouldn't AI move at the same time as the physics? You don't want your AI to behave differ

Aren't inputs usually on a queue? So you shouldn't miss them. And why shouldn't AI move at the same time as the physics? You don't want your AI to behave differently on a slow or a fast computer.

BoorishBears 6y ago
"Aren't inputs usually on a queue" isn't really an easy question to answer because there's so many levels of it (and I'm not saying that to be difficult) But generally if we're talking about Unity and stuff like GetButton, no. You're polling for input at a specific point in time. Like I said, FixedUpdate can be called multiple times a frame, or not at all, so there'll be entire frames where Update is called (and you'd have gotten input), but FixedUpdate isn't (and you miss that input) - And AI moving and actually running AI are two different things. You want the AI's physics-based effects to be in FixedUpdate like any other physics, but you don't want your AI to be in FixedUpdate. A lot of people don't seem to get, FixedUpdate isn't magical, it's trying to run at a target rate, but if your game can't do it's work at that rate, there's no way to "cheat" time So it will try and run 2 times in a row for one frame if your frames are slow enough. And if your FixedUpdate is slow enough, it won't be able to run 2 times quickly enough, and then the next frame it needs 3 runs to "average out" to the correct number of calls per frame. That creates a cascading effect that leaves it trying to run as many FixedUpdates as it can. It also leads to a weird sort of "jitter" where FixedUpdate is called several times and your AI in turn updates several times before Update is called once. So it "sees" the same exact world view multiple times in a row and acts on it (unless all your game's logic is in FixedUpdate, which you definitely shouldn't do) then the next frame because the engine "caught up" on FixedUpdate calls, FixedUpdate isn't called at all, while Update is called, and your AI doesn't act on the new world view from Update's logic until the next frame. Instead, if you want a repeatable task updating independent of frame-rate like AI, in Unity use a coroutine or "InvokeRepeating"
- cosarara 6y ago
  I'm thinking though that if the AI runs less often, it might take different decisions depending on how fast the PC is. So just like if you did physics without fixedupdate, you could have players jumping lower or higher depending on how fast their PC is, maybe you'll be making the AI dumber or smarter (due to thinking more often).
  - BoorishBears 6y ago
    The big problem here is "AI" is some an incredibly unconstrained problem space for games, "AI" could just be lerping towards the player, or it could be a state machine that doesn't have a concept of manually being stepped forward In fact, I don't think I've ever worked with a game AI that had a concept of manually being stepped forward. But more importantly, I can't think of any common game AI that benefits from "more thinking time" on a continous basis. For example, there's games like chess where more time can result in a better solution, but you wouldn't be using FixedUpdate anyways, you'd manually start "thinking" and use a timer to end "thinking". "Continuous" AI I've worked with are usually a state machine (or some loose definition of one) that will respond to events and change state, and while in a given state they're usually running a certain set of code on each update. There are parts of that update code you should put in FixedUpdate, like a raycast. You're (ideally) moving the colliders that are being cast against during FixedUpdate, so you do the raycast in update, you can miss raycasts that should have hit. - But that actual decision making shouldn't be in FixedUpdate. FixedUpdate should set some flag or fire some event that is then handled in Update. The AI won't be dumber or smarter based on FPS in any appreciable way (and if that's a concern you could still use coroutines). The parts of it that react to physics will already be happening as fast as possible since they're in FixedUpdate, the actual transition of states will happen on the very next frame rendered after this detection. If anything, putting everything in FixedUpdates means there are times when the user gets to provide input (frame renders and Update is called), but the AI doesn't because FixedUpdate never got called
neutronicus 6y ago
Honestly I kind of like the idea of (optionally) allowing the AI to use every bit of the player's silicon against them.

Aren't inputs usually on a queue? So you shouldn't miss them. And why shouldn't AI move at the same time as the physics? You don't want your AI to behave differently on a slow or a fast computer.

BoorishBears 6y ago

"Aren't inputs usually on a queue" isn't really an easy question to answer because there's so many levels of it (and I'm not saying that to be difficult) But generally if we're talking about Unity and stuff like GetButton, no. You're polling for input at a specific point in time. Like I said, FixedUpdate can be called multiple times a frame, or not at all, so there'll be entire frames where Update is called (and you'd have gotten input), but FixedUpdate isn't (and you miss that input) - And AI moving and actually running AI are two different things. You want the AI's physics-based effects to be in FixedUpdate like any other physics, but you don't want your AI to be in FixedUpdate. A lot of people don't seem to get, FixedUpdate isn't magical, it's trying to run at a target rate, but if your game can't do it's work at that rate, there's no way to "cheat" time So it will try and run 2 times in a row for one frame if your frames are slow enough. And if your FixedUpdate is slow enough, it won't be able to run 2 times quickly enough, and then the next frame it needs 3 runs to "average out" to the correct number of calls per frame. That creates a cascading effect that leaves it trying to run as many FixedUpdates as it can. It also leads to a weird sort of "jitter" where FixedUpdate is called several times and your AI in turn updates several times before Update is called once. So it "sees" the same exact world view multiple times in a row and acts on it (unless all your game's logic is in FixedUpdate, which you definitely shouldn't do) then the next frame because the engine "caught up" on FixedUpdate calls, FixedUpdate isn't called at all, while Update is called, and your AI doesn't act on the new world view from Update's logic until the next frame. Instead, if you want a repeatable task updating independent of frame-rate like AI, in Unity use a coroutine or "InvokeRepeating"

cosarara 6y ago
I'm thinking though that if the AI runs less often, it might take different decisions depending on how fast the PC is. So just like if you did physics without fixedupdate, you could have players jumping lower or higher depending on how fast their PC is, maybe you'll be making the AI dumber or smarter (due to thinking more often).
- BoorishBears 6y ago
  The big problem here is "AI" is some an incredibly unconstrained problem space for games, "AI" could just be lerping towards the player, or it could be a state machine that doesn't have a concept of manually being stepped forward In fact, I don't think I've ever worked with a game AI that had a concept of manually being stepped forward. But more importantly, I can't think of any common game AI that benefits from "more thinking time" on a continous basis. For example, there's games like chess where more time can result in a better solution, but you wouldn't be using FixedUpdate anyways, you'd manually start "thinking" and use a timer to end "thinking". "Continuous" AI I've worked with are usually a state machine (or some loose definition of one) that will respond to events and change state, and while in a given state they're usually running a certain set of code on each update. There are parts of that update code you should put in FixedUpdate, like a raycast. You're (ideally) moving the colliders that are being cast against during FixedUpdate, so you do the raycast in update, you can miss raycasts that should have hit. - But that actual decision making shouldn't be in FixedUpdate. FixedUpdate should set some flag or fire some event that is then handled in Update. The AI won't be dumber or smarter based on FPS in any appreciable way (and if that's a concern you could still use coroutines). The parts of it that react to physics will already be happening as fast as possible since they're in FixedUpdate, the actual transition of states will happen on the very next frame rendered after this detection. If anything, putting everything in FixedUpdates means there are times when the user gets to provide input (frame renders and Update is called), but the AI doesn't because FixedUpdate never got called

neutronicus 6y ago

Honestly I kind of like the idea of (optionally) allowing the AI to use every bit of the player's silicon against them.