AFAIK most rts don't use physics for actual movement, they group units so they move together (i.e starcraft 2) only when they encounter an obstacle they break units off the group. You can see that when moving them in open spaces, they maintain their relative positions, they also use physics when static units are blocking the path on another, they simply push through them (I recall a couple of funny bugs in the first release of sc2), so they kind of become static physic objects when standing still. I remember a presentation (gdc maybe?) where someone talked about how trying to propagate the "push" when moving units was not a great solution and they went for a simpler solution, and used 2 distances, which lead to the behavior that they clump and then "relax" and try to expand pushing other units around, I don't remember if it was for SC2 or some random MOBA. Something I noticed long ago (too many years since I last played sc2) is that the units clump into a ball, so my guess is that the simplified shape they use for group movement is a projected circle, so a sphere or a cylinder would make sense for godot, when hitting an obstacle stray units tended to form a subgroup, unless they were few, then they seem to be more "autonomous" and try to fit into empty spaces of the virtual circle (sometimes triggering funny dances around the group). TLDR: you are not moving 20 units, but 1 with a big "footprint".
Will you eventually be covering how to code the game HUD? (Especially how to make it so when clicking on the HUD, the input doesn't register on the map)
Yep, eventually I want to finish this project with a minimal viable product for people to build their rts, sorry for the delay in making the videos, life's being getting in the way lately, I have a big change coming for the project that will present it's own set of challenges and rewards, for the better of course, should be fun, stay tuned for the next video, which should be out this week, If you want some solutions now here are a couple of ideas, eventually we will need to discard inputs depeding on the state of the interface, like building mode versus unit movement or selection, something like what I did in this video ruclips.net/video/sIrO5dVC9LU/видео.html , You can use unhandled inputs to filter inputs only to the interface by discarding a mouse click after the interface gui controls has used it, you can find some info for inputs here docs.godotengine.org/en/stable/tutorials/inputs/inputevent.html , You can also use controls to block the inputs from the mouse, with focus handling with controls, there are many ways to do what you want, this is a common issue.
Someone else also pointed this in another video, and I did researched about it, jolt it is really great, so this is a valid question, I would answer however with this, why Godot needs it's own collision engine then? I would probabilly guess it doesn't want to fully depend on a third party tool that can be discontinued or change in the future, forcing devlopers to use another physics engine or stick with an older version, almost what happened with the Bullet physics engine, previously it was a option inside godot, not anymore, though I don't know if everything that bullet did godot physics can do atm. I guess it is also a preference of mine, I would like to finish a project with just what Godot has to offer, though if someone is looking for a better solution I would recommend jolt, so I don't know, guess I want to try everything in-house first, then if needed we can use third party tools.
@@nanotechgamedev I have a feeling Jolt will be integrated as the default at some point. All it'll take is a funded directive like they've done for other parts of the engine like the particle system.
Depends on what you need physics for. For instance, let's say you wanted to have a interpolated rigid body with this technique, try to interpolate from the physics object using it's transform, almost will work the same with the units position, rotations will be a little different to handle, because they will probabily not look great with just linear interpolation, so maybe slerp or other transform or basis rotation functions, really depends on how you are using physics with your project. You can also research how multiplayer games synchronizes their information with various players to get some ideas, most of them also use similar techniques to interpolate the position of the characters and animations, otherwise players would be teleporting all over the place in the game, something very familiar if you ever played escape from tarkov or warface.
@@nanotechgamedev I'm more interested in what you'd do if you needed the tick rate higher for something else that requires it. This is a system/game wide change and I'm not a big fan of that. It might be good for a quick fix, but I'd rather use something more exotic but scaleable than this unless I'm missing something.
I don't think you should be using physics at all in an RTS game. Sure it's easier with units colliding, but i doubt RTS games in the past used physics.
@@aharon672 Why would they? Physics is not beneficial in RTS games, it's only going to cause the problems like this. Having to calculate physics for every unit is wasteful when everything can be done with much simpler algorithms.
@@DVSoftware There are all sorts of reasons to use physics in a game, RTS or not... if you're thinking outside the box, that is... if you want to wallow in the dark ages go ahead, but I don't mind pushing my rig a little for some convenience if it doesn't kill the framerate.
AFAIK most rts don't use physics for actual movement, they group units so they move together (i.e starcraft 2) only when they encounter an obstacle they break units off the group. You can see that when moving them in open spaces, they maintain their relative positions, they also use physics when static units are blocking the path on another, they simply push through them (I recall a couple of funny bugs in the first release of sc2), so they kind of become static physic objects when standing still.
I remember a presentation (gdc maybe?) where someone talked about how trying to propagate the "push" when moving units was not a great solution and they went for a simpler solution, and used 2 distances, which lead to the behavior that they clump and then "relax" and try to expand pushing other units around, I don't remember if it was for SC2 or some random MOBA.
Something I noticed long ago (too many years since I last played sc2) is that the units clump into a ball, so my guess is that the simplified shape they use for group movement is a projected circle, so a sphere or a cylinder would make sense for godot, when hitting an obstacle stray units tended to form a subgroup, unless they were few, then they seem to be more "autonomous" and try to fit into empty spaces of the virtual circle (sometimes triggering funny dances around the group).
TLDR: you are not moving 20 units, but 1 with a big "footprint".
Really cool video. I'm sure I'll run into it again when I'm a more advanced game designer haha. Right now I just made the godot basic example game.
Will you eventually be covering how to code the game HUD?
(Especially how to make it so when clicking on the HUD, the input doesn't register on the map)
Yep, eventually I want to finish this project with a minimal viable product for people to build their rts, sorry for the delay in making the videos, life's being getting in the way lately, I have a big change coming for the project that will present it's own set of challenges and rewards, for the better of course, should be fun, stay tuned for the next video, which should be out this week,
If you want some solutions now here are a couple of ideas, eventually we will need to discard inputs depeding on the state of the interface, like building mode versus unit movement or selection, something like what I did in this video ruclips.net/video/sIrO5dVC9LU/видео.html , You can use unhandled inputs to filter inputs only to the interface by discarding a mouse click after the interface gui controls has used it, you can find some info for inputs here docs.godotengine.org/en/stable/tutorials/inputs/inputevent.html , You can also use controls to block the inputs from the mouse, with focus handling with controls, there are many ways to do what you want, this is a common issue.
Why won’t you try another physics engine like jolt to fix the framerate ?
Someone else also pointed this in another video, and I did researched about it, jolt it is really great, so this is a valid question, I would answer however with this, why Godot needs it's own collision engine then? I would probabilly guess it doesn't want to fully depend on a third party tool that can be discontinued or change in the future, forcing devlopers to use another physics engine or stick with an older version, almost what happened with the Bullet physics engine, previously it was a option inside godot, not anymore, though I don't know if everything that bullet did godot physics can do atm.
I guess it is also a preference of mine, I would like to finish a project with just what Godot has to offer, though if someone is looking for a better solution I would recommend jolt, so I don't know, guess I want to try everything in-house first, then if needed we can use third party tools.
@@nanotechgamedev I have a feeling Jolt will be integrated as the default at some point. All it'll take is a funded directive like they've done for other parts of the engine like the particle system.
The issue is Jolyt doesn't support mobile. It's not widely known. Unless this changes you can't expect it to be default.
thank you
What do you do if you need physics for something else?
Depends on what you need physics for. For instance, let's say you wanted to have a interpolated rigid body with this technique, try to interpolate from the physics object using it's transform, almost will work the same with the units position, rotations will be a little different to handle, because they will probabily not look great with just linear interpolation, so maybe slerp or other transform or basis rotation functions, really depends on how you are using physics with your project.
You can also research how multiplayer games synchronizes their information with various players to get some ideas, most of them also use similar techniques to interpolate the position of the characters and animations, otherwise players would be teleporting all over the place in the game, something very familiar if you ever played escape from tarkov or warface.
@@nanotechgamedev I'm more interested in what you'd do if you needed the tick rate higher for something else that requires it. This is a system/game wide change and I'm not a big fan of that. It might be good for a quick fix, but I'd rather use something more exotic but scaleable than this unless I'm missing something.
I don't think you should be using physics at all in an RTS game. Sure it's easier with units colliding, but i doubt RTS games in the past used physics.
Any modern RTS will use physics for collisions and the navigation server.
@@aharon672 Why would they? Physics is not beneficial in RTS games, it's only going to cause the problems like this. Having to calculate physics for every unit is wasteful when everything can be done with much simpler algorithms.
@@DVSoftware There are all sorts of reasons to use physics in a game, RTS or not... if you're thinking outside the box, that is... if you want to wallow in the dark ages go ahead, but I don't mind pushing my rig a little for some convenience if it doesn't kill the framerate.