RTS Without Physics Collisions or Navigation Agents - How to do it in Godot 4 : Stop using them!
HTML-код
- Опубликовано: 2 окт 2024
- When you are making an RTS you need perfomance, our project at the beginning used a physics approach to making the units move easier, that with the addition of collision avoidance of navigation agents looked really interesting as a first setup to start building an RTS.
As the project started to finish the most critical areas, some issues started to accumulate, precisely the fps drops with 200 units, meaning not that great, upon close inspection turns out our physics based approach is really nice, but the cost of running units with physic collisions ins't worth it if you are trying to make an RTS, where a single unit needs to interact with many different things at once,
However if you removed all physics nodes, how are you going to detect collisions? On this video I am going over the main changes and updates to the project, if you are following the series this is a must to watch,
Our current system is awesome for a third person or fps game, not that great for an RTS, this is about to change now, as always if you have any questions, please let me know by posting down below in the comments, like the video and subscribe,
Hey nice video, I'm working on rts too. I think your issue was not having to many collision shape in the collision engine. In fact the engine hardly care about a 1000 unit if they are stale. The issue was they were constantly colliding and calculating the response to that collision is expensive. To avoid collisions during pathing I also use the get_points of an astar (would me the same with nav mesh) and apply a formation offset. Since the units are moving in formation they generally dont collide.
Oh me too! Good times.
this is how they did it in AOE, this is why formations existed. offsets! also include size of the group, and then the turning for each point in the path. Seems like a lot, but it's only done to an array of selected troops. I mean you can limit the troops to 12 like C&C or just have the group look like a bunch of units even tho it's 1 unit like 40k does. It's more about path direction so if they do a horse shoe the guys in front don't end up the guys in back. Doesn't seem to difficult, but at some point you're kind of making boids having the units space out each second, when they are in a group it should be a standard offest (per each unit based on size) keep it to a radius and you have a calculation simpler then a rect2.
EITHER WAY, THIS IS MORE OF THE VIDEOS THAT I WANT TO SEE. PEOPLE MAKING BETTER CHOICES!
Getting rid of physics like that is a really interesting approach. 👍
I start thinking now if I should rework the units of my own RTS project yet again. 😅
It's a lot of work (again!), but I can't tell I don't like the idea at all. 😆
However. Thanks for sharing your findings and experiences. Always exciting to see how others are handling similar challenges that I am confronted myself. Keep up! 😘👍
Killin' it with these videos! I'm working on an RTS and might be lifting this idea at some point if performance becomes a problem. BTW I think you can use spheres instead of rectangles because spheres are surprisingly easy to calculate. Might be a big enough benefit to warrant the performance hit.
definitely! this channel's the best!
Not sure, if it's possible or not... But you can use now compute shaders in Godot 4. Perhaps you can calculate the next position for every unit on the graphics card and then the unit only have to move to that calculated point.
Also you could combine this with a formation. Like you have 16 units. then you get this formation for exemple:
UUUU
UUUU
UUUU
UUUU
You can then sent all the position for that formation to the shader-code and the shader calculates all the 16 new positions at once.
then every single unit only moves to their new formation and due to the fact, that the shader calculated the new position all at one, the units keep their formation more or less, because they all get their new moving-directs at the same time.
But it's just an idea. I have no real clue at this moment, what compute shaders are capable of.
Thank you for the video. Now I know how to optimize my game 😃
When attempting to calculate whether there is a collision or not on a 2-dimensional plane, you might be tempted to first calculate the distance between two objects and then decide whether they collide, but strictly speaking, you only need to know is whether they collide or not.
The calculation of distance requires Pythagoras' theorem which requires that you calculate a square root. And this is computationally expensive. But that is unnecessary.
If difx = difference between the x coordinates of 2 objects and dify = difference between the y coordinates of 2 objects, then the distance = square-root(difx^2 + dify^2) per Pythagoras.
However, all you need to know is whether distance < minimum collision distance.
If you square both sides you get the equation: difx^2 + dify^2 < (minimum collision distance)^2 which resolves to True or False, and doesn't include a square-root calculation.
I don't understand why I have to implement non-physic system for collisions and detections in my RTS on my own and nobody did it as library. I feel like I have to reinvent the bicycle
You're not wrong, it is just that Godot tries to be a all purpose Game Engine, so it doesn't have any game system out of box, everything has to be built, that of course talking about Godot Gdscript ecosystem, from the point of C#, C++ or other bigger programming languages pov, one can extend from many already built libraries, but then again doing your own game makes you fine tune everything to match your game design, so built in libraries can also become their own challenges to maintain or customize. I wanted the solution that Lawnjelly did in his video to be implemented in the core, this would help a lot with perfomance, but I think it didn't get enough attention: ruclips.net/video/WUj9pcB4Tqc/видео.html
Mom, I'm famous! Haha, thanks for the video, I'm also advancing in my own rts game, and I've done many things that I've implemented following your videos, on the subject of performance, if it's a problem as one progresses and I think that the idea of not depending on physics would be the best option, about Jolt I have heard that they want to add it as the default physics engine in future godot updates which would help a lot, but even so an rts game should use very few physics, I wanted to ask you a question, what hardware do you have?, to know what is the performance limit that your PC supports.
If Jolt get`s integrated that seems like a good idea to me, the engine looks great, my setup has a very old processor, it is a i5 3.2GHz 4th generation, 16gb ram, and my gpu is a Nvidia GTX 1050 Ti, isn`t the beefiest setup, but the great thing is if it runs smoothly on my end, anyone with better gear than me would be able to play one of my games better, so it works great as a baseline atm, I will probabily disclose my setup on a video because I keep blabling about bad perfomance but never showed my specs,
Hey, I just discovered your channel with this video, and it is really great! I love the level of explanation you have, not too detailled, yet still giving quite some insights 🙂 Happy to continue watching your content, thanks a lot!
Thank You for this video. I like a lot how You share Your though processes, assumptions and conclusions. And find them reasonable and competent.
You should be using flowfields for things like this, it'd work better - you know the thing that allowed Supreme Commander to have thousands of units. NavMesh is likely overkill for what you need here, unfortunately there is no built in flowfield so you'd have to implement it yourself but its not too difficult, you're just doing a cost of every tile in an array and then telling the AI to steer through that array.
Many people recommend jolt like it's some silver bullet. The project is on version 0.10, you can check their roadmap and see why its not ready for production.
I litteraly did all this in the GameJam game I released today ha ha
From the Video it appears your using QuadTree / maybe Sparse QuadTree and then using using Box detection between the objects within each leaf though circular detection would actually cheaper because it just takes the radius of each object and does a distance check. You mentioned Boids which would be a better alternative along with stored the data in an accelerated data structure like a 2D hash grid OR you could use what Supreme Commander did and use Flowfield / Hierarchical Flowfield navigation... I believe I have seen some GITHUB projects with some examples of these methods but I cannot comment on how good the particular implementations are.
unit collision 3d with spheres is way more performant ... i tried it yesterday i also thought boxes are easiers on the physics engine but it seems the "less" colliding points of a sphere are better
@@thefufuu3157 I think performance wise its Sphere then Capsule then Box because it's to do with the math required and not to do with the amount of faces / triangles.
Muchas gracias, esta genial
Circle collision (squared distance) is faster than rect collision generally. Idk about godot's implementation.
your latest video out-shines your previous ones!!!
Unit-unit collisions are very important for RTS, and play a huge role in keeping micro both skillful and intuitive. If unit-unit collisions are too slow you can try a spatial hash (RUclips channel 10-minute Physics has a great video) or you can use a grid (like a chess board) and have units occupy tiles on the grid.
Physics would be good -- There are a number of RTS that use physically-calculated units and projectiles. Beyond all Reason, the Wargame series, and WARNO are some examples. You're right though, most RTS don't need physics engines at all
Pretty much yea, but if we used Godot with C# and the Jolt Physics Engine, it would probabilly work a ton faster, and it would have been possible to make an RTS with physics without any issues,
@@nanotechgamedev jolt has 0 impact on character body collision ... also all demos show its crazy performance on rigid bodys ;/
Great video!! i just discovered your channel and i think that changing things you did in previous videos is part of a wonderfull journey and seeing it through your videos is fantastic!
Welcome aboard!
this is very helpful. great series
I was thinking how this navigation method is not real time therefore if an obstacle shows up in the path of the units, the path si not updated. So as a solution, I think a very good one is to generate raycasts or collision boxes that go from each point of the path to the next one. If an obstacle appears and any of those collision boxes (raycasts, etc) detects it, then trigger a refresh of the navigation path. This involves the origin of the action to move with the unit group and once it reaches a point in the path, the collision boxes before it need to be deleted. Just thought about this, no idea if it is the best way. But if no obstacle appears, then no calculation is necessary. If one appears, the path will be regenerated once and that will be that.
You could also just use raycasting for this, to get more precise collision detection, rather than having Rect2's or other static shapes.
As a Protoss player stopping/clipping units is mandatory
Incredible job! Really ingenious solution!
Great video,
Do we get to see the codes to see how it actually works?
It's merely a quad-tree, for which you can find plenty resourcs on the internet. Followed by a distance-check. Same principle as what a physics engine does, but simplified to the specific needs of your game, so you end up with a more performant solution.
What if I want create turn based tactical strategy? (I can't search tutorial in 3 d. I am sad, because I want create game so)
A turn based game most likely is going to use a grid system to navigate units, and because it doesn't need to happen in real time, it's much more simple to make, you need a way to navigate units, a navigation system, and a way to detect where units are already placed, you could use a simple check against a grid cell using arrays, however everything I am saying here is if you are experienced with working with Godot,
If you yet don't know how to work with the engine, then I would advise to search for tutorials on how to work with Godot and it's basics first, doing simpler projects before you jump to your turn based strategy game, no tutorials will 100% guide you through the projects you want to make, you need to grab different pieces from the mechanics you want to build from different places, tutorials, examples, reverse engineering games, etc. If you are not finding tutorials for what you want, try to find them for other engines or at least in 2D, that should you give you some ideas how to implement what you want,
Now this video talks about an RTS, which is in real time, so perfomance is key because a lot of things will be happenning at once, hence why we needed to cut these nodes from our project, you can build your game whoever you like, there are no rules, only when you start to see problems you should try to optmize them.
yo is there some documentation on how you implemented the rect2 with your 3d units since the documentation states that AABB is the 3d counterpart ? the video doesnt do it for me to wrap my head around it
It's simple really, Rect2.has_point() only accepts 2D coordinates, on this video the idea is to use the units 3D position X and Z to make a 2D coordinate system like X and Y as if you were looking at the game from topdown,
really cool idea! would a 2d RTS game also benefit a lot from replacing physics in a similar way? or are 2d physic much more performance friendly that it wouldn't be worth it that much ?
I believe it would be more perfomant, however that depends on your project, the amount of units or interactions you have between the physics nodes and other objects, generally speaking I believe 2D physics to be faster than 3D, but using Rect2 would be even faster, because it`s a simpler calculation.
6:14 wait, that doesnt sound right
In military operations units are made up of units so generals don't have to micromanage them. The whole collision and pathfinding is much easier if you issue orders to SQUAD LEADERS instead of individual soldiers. It's really a SPAN OF CONTROL business issue, but in an RTS it reduces the amount of clicking you need to get what you want.
Squads also have states they can be in. As a squad travels they should assume a MARCHING FORMATION that's generally a line with multiple columns, so they have less collisions. When they are in combat they should form a FRONT. In classic warfare that's a wide line in modern warfare that is dispersing, then hiding behind cover or digging a foxhole.
The ANARCHY that RTS'es have done for a very long time is quite DUMB. As the old RTS formula doesn't seem to work anymore, maybe it's time to try something new?
There is no end of squad-based/cover-based/realistic RTSs. In fact, that's probably one of the reason RTSs fell off. I don't know why you think this is "new".
@@ahall9839 It's a about the level of detail. I think most squad-based/cover-based/realistic RTSs have a focus too close to an FPS and lose sight of the overall theatre. On the other side there is grand strategy where an army is just an icon is too abstract. I mean a Command and Conquer like RTS where troops can be individually ordered around, but they can also function in a designated team. In the video you can see multiple units selected, then ordered to move and they try to maintain some relative position to each other as individuals. I think that should be select multiple units, designate them as a team, then order the team to move and they should have a tighter formation. Maybe even collisions checking between team members removed.
It has little to do with realism although units in reality try to solve much of the same things.
very interesting content, keep up the great work
Awesome stuff
Glad that you considered ditching physics. I would also divide the terrain into the smaller grid and let single unit occupy single or multiple grid cells, then you could use something like A* pathfinding to let units find their place on the grid.
navmesh also uses A star. it's faster because it's prebaked into triangles that are bigger than the grid cells. rebaking the mesh is slower than updating a grid though. So it's a compromise but in most cases, calculating the path quickly is more important than updating the mesh quickly. especially since updating the mesh is done on a different thread.
You are right, and if people are worried about the speed of baking the navmesh, I already implemented multiple smaller nav meshs per region of the map just like I outlined in the video, this way baking should be instantly or at the very least just like you said, with Godot now multi-threaded baking the navigation, fast enough for the player to not even notice it, we will be needing to re-bake the navmesh everytime a new building is placed, because we can't rely now on collision avoidance with the navigation agents, so that was my solution, to split the navmesh into multiple smaller navmeshs so re-baking takes less time, we will see how that works out in the end,
Rect2's are 2D tho. How are they gonna work in a 3D game?
By using their 3D X and Z positions to be a 2D X and Y, their position from top down.
2:19 what game is this? looks fun
Ayii, sorry for the late response, found your comment just now, that game it's called TABS, Totally Accurate Battle Simulator, it is a very fun game indeed,
old school techniques might be handy
think of the map as 2d pixels, 1 pixel equals smallest unit, bigger units occupy more pixels ofcourse
this way u solve collisions in integer math (very fast)
1 pixel units have 0 rotation since they are single pixel large units rotation is simple raster or even predefined 45 degrees rotations.
the visual unit might be rotated, but in the logic-map no rotation is needed, thus greater performance gains
heights are in layers to solve overlapping and units y-axis visibility, say underwater for submarines is 0 layer, first ground plane is 1, mid ground plane is 2, and so on to air units in layer 4 for example
u might be able to solve all collisions path finding and units visibilty and fog in "shaders" by thinking of your map as 2d image, and units as unique pixels on the map.. maybe this can handle thousands of units
What if a 1 pixel unit is in between 4 different 'pixel' positions? Count all 4 pixels as occupied?
That, or you snap their pixel position in a grid so it is forced to only occupy 1 pixel, I have seem some games though were units when they move occupies more than one pixel, it looks weird though if you use that as your minimap texture as well, specially when the pixel density is low,
@@GlobusTheGreat well on the visual part units can be anywhere between map's cells (1 cell = 1 pixel), this is to keep animation smooth, but on the logical part where all processing is done it still occupies one cell.
keep in mind visual grid is larger for better graphics only
when a unit moves, logically it occupies the next cell only when it is less than half way to that cell from current occupied neighbour
while bullets and explosions can render using the positiin of the visual unit for visual accuracy, the collision detection if needed still uses the mini map for fast integer calculations
@@nanotechgamedev it is prefferred to keep units occupying only same pixels count matching their sizes
a 3x1 unit for example; should occupy 3x1 pixels even when rotating, this only changes the pattern of pixels.
this keeps game logic clean
🚀🚀🚀
cool vid
You could try using a navigation mesh