And these games exploit all kinds of things, like hierarchical data structures, instancing, and whatnot.

With the right planning and the right game design one can render millions of objects without multithreading.

Edit: ninja'd :-) Yes, I think you need to rethink the game design, and write down on paper how exactly these things interact with the player, what their goal and objective is. With that we can certainly give more concrete help.

'nother edit: there's a lot of information on crowd rendering. I personally have not been there yet, but searching "how to render a crowd in a game" gives a lot of hits.

https://developer.nvidia.com/gpugems/gpugems3/part-i-geometry/chapter-2-animated-crowd-rendering

Of course, you will have to adapt that to Godot, and GDScript may be too slow. You will have to profile if you want to know which solution is better for your case. Can't say that often enough.

Just had a thought of a great example actually of the kind of thing I'm looking at.

relevant timestamp: 13:00

In Startopia you can have hundreds of characters on the screen yet it still runs smooth as silk especially for an old game and as you can see the character can be somewhat interacted with but also have their own animations.

Lethn The problem is that with the 300 odd villagers

I also want to make an agglomeration with at least a million characters… all with their own personalities… but I guess to start with a village with a dozen inhabitants maximum, gradually increasing the number.

The "anima" from AXYZ design works with a large number of people. Maybe they have something interesting to look at. There used to be even a free trial version.

    For large crowds it might also be worth looking into Niagara. It's Unreal, but they do provide you with a lot of information on the general approach:
    [
    It might be possible to implement something like that in Godot 4, but it would probably take some C++ to write such a system. Maybe one or two of their suggestions is already enough for your case. Only commit fully to this approach, if everything else isn't enough. At this point this is more R&D than straight up game design, so you'd have to spent a lot of time figuring out what creates bottlenecks when using Godot and how to avoid those.

      Now that was really interesting to watch, it's also the exact scenario that I've been dealing with and I've already identified some points for optimisation that I'll work on now.

      . Navmesh movement is happening constantly, I could reduce the strain on the engine by having a timer in which I planned to do anyway because having the villagers walk around continuously is unnatural

      . Code not within the camera view does not necessarily need to execute could potentially have very far away villagers be completely static until the player starts 'seeing' them in the camera

      . Haven't done a proper culling implementation yet, should look into that as it would likely make a major difference for performance, will need to look at the camera view specifically for that

      . Will also explore using sphere occlusion culling for the villages because I bet that would help things massively if I can get rid of that unnecessary stuff when it's at a distance

        MartinSenges For large crowds it might also be worth looking into Niagara. It's Unreal, but they do provide you with a lot of information on the general approach:

        I browsed hastily and may have missed something, but I didn't see individual character movement — everyone walks in a crowd, sometimes except for literally one dude. There's already such a thing in Godot.

        Lethn . Code not within the camera view does not necessarily need to execute could potentially have very far away villagers be completely static until the player starts 'seeing' them in the camera

        Those villagers who are not in the frame at all can not display, and load them only when the camera gets close to them.

              Just found an excellent video on these topics specifically for Godot he even does a bit on the occlusion node which is something I was a bit baffled by.

              The big thing for me is that I need to have the villagers be interactable, so you'll be able to pick them up and throw them among other things, time for some tinkering.

                Tomcat Didn't have that Godot tutorial on my radar, so thx 🙂 As for individual character movement: I'm not too knowledgeable about Niagara. But I think individual character movement is something you want to avoid with that system anyway. Either you split you crowd in a way that each group walks into a different direction or you make the code so generic that it keeps up the illusion of individual movement (the player avoidance example shown in the video + more stuff). Probably even both approaches.
                Maybe there's also a need to swap out a crowd villager entity with an individual villager entity during gameplay (and back of course). Don't know haven't made a game with that kind of complex system yet 🙂

                    Lethn The big thing for me is that I need to have the villagers be interactable

                    This was done in The Sims (2-4). By the way, in The Sims 3 there can be several hundred residents.

                    MartinSenges But I think individual character movement is something you want to avoid with that system anyway.

                    The implementation of crowd movement is done in anima, there you can see that the residents walking in the same direction have different speed. But I do not know what technology they used and whether it is possible to apply it in games.

                    The optimization section mentions multithreading.

                        Just had a very interesting eureka moment, without the animations, the FPS jumps pretty significantly, it almost double, so it looks like that's what I'm going to have to look at optimising the most is how the animations are being played through the code, will need to have a look at these methods when I'm in a better mood for it. The animations seem to be confirmed as hitting the performance the most.

                        I wonder if there's something I can do about the way the navmesh is dealing with the code? I'll have to have a look at that video again myself.

                        So really the conclusion is that instead of doing multi-threading it would be a better idea to see if there's a way I can instance the animations that my villager has to make everything run smoother instead of the GPU trying to render everything all at once? No wonder I'm regularly hitting 30fps.

                        Edit: I'm also seeing that I guess having however many agents all on screen at once will mean that it's simply not possible to play the game above 60fps except if someone happens to have a really powerful PC which is interesting, will have to look at how much I can tweak things.

                          MartinSenges Maybe there's also a need to swap out a crowd villager entity with an individual villager entity during gameplay (and back of course).

                          That would be my first go-to as a solution to try for this.

                          Lethn So really the conclusion is that instead of doing multi-threading it would be a better idea to see if there's a way I can instance the animations that my villager has to make everything run smoother instead of the GPU trying to render everything all at once? No wonder I'm regularly hitting 30fps.

                          So don't play bone animations for any characters that aren't visible to the player at all. Pause the animation playback. This might not even be limited to characters outside the view frustum but also characters simply too far to be clearly discernible on screen. Also characters sufficiently far away from the camera/player vision can probably utilize lower FPS animations. Less bones per skeleton should be less demanding but also less keyframes per animation track and lower fps. Try and take advantage of a combination of these.

                              Let me think more on how to actually implement all of this, would this be similar to object pooling? I have the villagers wondering about as 'background characters' almost until they're interacted with through whatever action the player takes? I think just because of the nature of this game it will probably be a performance hit no matter what I do. If for instance the player decides, yeah I'm going to set the whole village on fire the villagers will need to be interacted with as I have panicking animations and so on as well, lots to consider.

                              Maybe have the villagers object pool at a certain distance like with the occlusion culling to ease off the rendering? No sense wasting processing power on something very far away the player can't interact with anyway. Just thinking about what I could do to implement this relatively quickly.

                              Instant FPS jump with this method, I reckon I can squeeze more FPS out now, that's fantastic, thanks for the advice guys, the signals of the visibility notifier make it so that I don't even have to rely on any complex tagging to make sure I've got the right nodes. I will also potentially have to have a look at object pooling among other things to see if can get more going. I feel like it's worth pointing out, the villagers will die of old age naturally among other things, this scenario of mine with every village being filled with 100 villagers per village is a worse case for optimisation but I want to make sure it's all running fairly smoothly regardless and I'm aiming for a steady 60fps I think.

                              At the very least I think this will be a fun game you can really push the limits on with your hardware if you really want to have a ton of villagers at once just for the lulz which I find interesting. The most basic optimisation I'll go with is a global villager count slider so that player can tweak the numbers themselves according to their PCs.

                              cybereality It's a duplication of the same models with the same motion. But what's needed is individuality in a crowd.

                                Yes, but you can have like 10 or 20 real characters in the front, and then fake ones in the back, people might not notice.