No announcement yet.

How many AI characters can be supported on screen at once? RTS possibilities?

  • Filter
  • Time
  • Show
Clear All
new posts

    How many AI characters can be supported on screen at once? RTS possibilities?

    I've been pondering over starting a WWII RTS project on the side for a few weeks now and I'd like to hear your input before I start dedicating time to it.
    I was wondering if anyone has experience with masses of ai?
    It wouldn't be on the scale of Total war, more on the side of Men of War in terms of scale. ie perhaps about 150 men/tanks/gun emplacements on the map at once

    To do it, I'd make a squad system so that you'd have a commander within a unit that does all the sensing and decision making
    and soldiers that just follow the orders from that commander.

    I know it would depend on a lot, ie poly count, animation complexity, ai complexity etc. But any advice/experience would be greatly appreciated as there seems to be very little information on
    using UE4 for RTS style projects.

    Thus I have a few questions:

    How many AI characters can be supported on screen at once? before performance loss becomes a huge issue? Any guesses?
    /How many AI characters can be supported in game at one time?

    How would you personally design/optimize the AI for an RTS? Ie how would you implement the squad system , with pawns?

    How many soldiers would be viable in a squad?

    I also see that there's a lack of RTS style games created in UE4, is it not a viable engine choice for such a project?

    Last edited by TJa95; 12-05-2016, 07:55 PM.


    I'm working on 2 RTS projects.

    In the first one (you can find it under the funny title "Age of Total Heroes"), I use a couple of custom and optimized subsystems, like:
    - an own hierarchical pathfinder (separated long and short range, running on background threads),
    - a centralized unit and group actor update instead of ticking,
    - AI behaviour tree written purely in C++,
    - low poly (<1000 vertices) characters with a single simple material,
    - weapon attachment has also effect on performance: by skeleton (slow), by slot (med), or toggle by material group (fast),
    - fewer bones than UE4 skeleton has,
    - single node animation from C++,
    - simple low poly environment (vegetation and buildings), in realistic style, but high quantity instanced foliage should have simple material, for buildings I use PBR materials,
    - optimized landscape resolution and lod (it is very important),
    - optimized dynamic shadows (you should play with number of cascades and their resolution),
    and finally I can manage around 400 skeletal mesh based unit actors onscreen on my old laptop using a free camera (a top down camera can also save a lot of performance). Not pawns, simply actors. It support currently only single player mode. This is the hard way, but I really enjoy it.

    The other one is going to be a multiplayer project using UE4's built-in framework: Character, AIController, Behavior Tree etc. to ensure replication handling fine. It is mainly written in C++, and BT is planned to be converted to C++ as well, for better performance later. Currently I cannot say amount of units, imo it will be around 100, but the 150 you mentioned is achievable (especially if you use few skeletal meshes, I think vehicles are cheaper to render). Probably you should not use the Environment Querying System per Pawn, a simple group and boss system should manage decision making and enemy targeting. This is where my custom system is better, where AI influence maps or potential fields can be integrated into the pathfinder. If you use NavMesh pathfinding, you need a separated AI decision making system evaluating the map (enemy and danger zones, resource areas, AI building placement design etc.).

    Shortly: UE4 is okay for RTS, but not really designed for it. I think there is no general purpose game engine that is really designed for RTS, but small scale games can be done without problem. I know RTS games created with Unity (Meridian: Squad 22) or CryEngine (Reconquest), and there are a only a few UE4 ones (e.g. Empires Apart) under development. The Spring engine is made for RTS, but I'm not sure in that the achievable visual quality is good enough today...
    Edge of Chaos RTS
    "Age of Total Heroes" - RTS Pathfinding and Movement System for UE4
    RTS Camera C++ Tutorial


      I've ran some tests on this subject:
      Main performance killers are moving(seems like physics based(?)) and AI.I used an FX-8350 for this tests.Also there was no C++ involved.

      -Dummy characters without skeletal meshes (simple boxes) running around are okay(60 FPS) 'till 500-600 characters.Note that these boxes are constantly moving.Main performance consumer is "character movement component" and bottleneck was CPU.
      -Same scenario above with skeletal meshes (Epic provided robotic man) is good 'till 200-300.I didn't used any GPU instancing etc.Bottleneck was CPU.
      -First scenario with flying pawn component instead of character movement component test yielded about 600-700(can't really remember the numbers) characters.However this test was for to see how much unfunctioning characters that engine can handle.

      Results suggested that UE4 is not a good choice to make a -let's say- Total War game.At least not with the out-of-the-box pathfinding and movement.It's achievable at some degree but requires to rewrite some systems.
      AI sensing and EQS(for taking cover etc) is going to be costly on CPU and it's already struggling to handle large amounts of actors.

      Just my two cents.


        I would study how Age of Empires 3 was built; they've used a game engine called Granny:
        | Savior | USQLite | FSM | Object Pool | Sound Occlusion | Property Transfer | Magic Nodes | MORE |


          Thankyou for the replies everyone! You've provided me with a ton of useful information and tips to get me started and I really appreciate it. Sivan I've looked up age of total heroes and it's incredible what you're managing to pull off and I hope to see more from it in the future.


            I am using built in navmesh although I run pathfinding queries asyncronously, I have implemented a Grid based ASTAR as well, but I left using the Navmesh for now.

            I am using custom physics (more like NavEdge based physics).

            So being said I’ve reinvented my own MovementSystem with avoidance and NavEdge collisions. My own pathfollowing component that is really lightweight and fast (and has no stuck bug on slopes as the built in has).

            Now for me the main issue is a SkeletalMesh rendering I have around 2k verts meshes with simple animation and less bones than the Epic skeleton has.

            That being said I am still using an acharacter which for some reason takes huge performance hit on the GPU side.

            Rendering the same meshes animated alone without them being in a character - has no issues :-/ (Interesting why btw).

            I am posting a link to the video where 100 characetrs are moving and avoiding each other - in video CPU time is about 18ms - but it is a bit outdated now I reduced it to 12ms for 100 moving characters. There is a room for better optimizations I believe. It also is thread safe so it is possible parralelizing the whole movement stuff with a bit of collision checks additions.
            Which I believe will reduce the overal usage to around 8ms.

            Note the MS are overal for game - I didnt measure how much only the movement takes - but it is already lighting fast compared to the built-in options.


            If some1 can point out how could I optimize the SkelMesh rendering it would be great!

            My goal is 100-150 characters on screen - so I believe it is achievable?

            After some efforts playing with occlusions I was able to render 150 with acceptable FPS with shadows, and with high FPS without shadows.

            85fps for 100 characters in 1080ti with shadows and 160fps without shadows.

            Biggest benefit was from removing 3DWidgets with just planes(with the same material) and marking plane to no occlude the geometry.
            Last edited by ColdSteel48; 06-19-2019, 02:39 PM.