RTS Max Landscape and Units

[TheJamsh]

Just because you can go virtually infinite in terms of world-size, doesn't mean you should. I imagine a lot of your level will be procedurally generated, because I know nobody with a budget or a team of people that can decorate an area that big with assets.

Planet EARTH is 12,742 km in diameter. I mean... do you REALLY need that kind of space? I'd build my own engine if I was serious about doing this. I'd probably also check myself in to get my head examined as well

[Thorax]

If you have the ability to modify the engine towards your needs yes you can create really large worlds.
Look at Star Citizen for example, they heavily modified cryengine for that.

This just isn't true. I haven't touched a single line of the engine code and I've made landscapes up to 400km x 400km.
There was nothing stopping me from having something much larger either. Using tiled worlds you can make a map as big as your pc can handle.

[Jimmy_Jazz]

you can have only a few hundred animated 3d human characters currently on screen, billboard lods could help a lot... but the built in navmesh pathfinder is not for RTS, it eats up too much performance, so you need to implement (in C++) your own pathfinding and AI system, featuring many optimizations (like the above mentioned lodded AI and unit behaviour). I mean RTS game making results in a lot of fun
there is a game out there with seamless overview map and battles (called as Hegemony?), but it uses its own custom engine, similarly to nearly all RTS games... so better not to dream of thousands of individually acting soldiers made with blueprints

Doesn't UE4 use A*? It's the most optimal way of path finding and used for RTSs all over the place. Kuju used A* to have 60-100+ characters moving around simultaneously in Battalion Wars on the Gamecube and those counts went higher for its sequel and off-shot Aragon's Quest on the Wii.

The problem is that it comes across as a straight up implementation of A* and lacking many optimizations, and even mufti-threading.

However, Rama has been working on something for a long time now, although it's not clear if it's going to be released in some form to the public. You can read up more about it here

https://forums.unrealengine.com/show...hysics-Support

[sivan]

@Jimmy_Jazz: A* is just the method of doing the search in the graph. the graph can be a navmesh or a tile grid, or a hex grid, arbitrary shaped areas, really whatever...

in case of RTS, it is usually a good decision to use a hierarchical pathfinder, i.e. use a low res. map data (where each node is a small area) for long search, and use the tile level path search only in small distances, because pathfinding is costy when you need a lot to do in each frame.

the UE4 navmesh pathfinder is not optimal for RTS at all. why? just start to make an RTS AI. evaluate areas and larger regions, those all requires further data what you can easily get from a hierarchical pathfinder, then AI and pathfinder can work together efficiently, e.g. by using influence maps... (sorry I have to leave now, but I can make a longer description if anybody interested)

[Jimmy_Jazz]

HA* is an example of the kind of optimization that I was referring to. There'a a great article on AA* too here:

https://aigamedev.com/open/tutorials...d-pathfinding/

I was reading about a great alternative to A* earlier this year but I cannot remember the name of it or find the link

However, I think we've got our terminology mixed up, which is common where many devs have their own bespoke terms for common techniques. Where I've worked the A* has been the path finder whilst a direct path follower handles short range movement. I've used graphs of grids of both a fixed size and ones that can dynamically change their resolution to match collision in relevant tiles, as well as Epic's navmesh.

You could use Blueprints to split your map into zones, if your levels have enough bottlenecks to create entrance and exit points into each zone.

UE4's problem isn't simple about the size of an area. Size on its own is meaningless, it's the resolution. If you're willing to have a low resolution per meter squared, you can have large area. You need to make that call based on your unit & obsticle sizes as well as your world size.

Next up are characters. If you're willing to get dirty with BP and BTs then you can spread your move orders out over time / multiple frames, rather than have them firing simultaneously and causing hitches.

Together they're not going to get you the next Total War, but maybe a great RTS on the same scope as C&C or CoH.

[sivan]

my system I'm porting to UE4 is very close to the system you linked, it was actually a great inspiration when I made it with another game engine. my map is different and I use no pre-processed path calculations, only dynamic ones, but requires similar preliminary map decomposition. (somewhere I have a collection of references I used for creating my own system.)

I personally found the movement system and formation handling much harder to implement than the pathfinder (how often to update path to keep it dynamic and help collision avoidance, how to handle collision if it happens, how exact collision resolution needed, how to manage units getting isolated from their group, how to optimize its performance by minimizing bone-animation and ticking cost of the engine etc.).

so finally this topic is rather a C++ topic than of content creation

[Errvald]

Basically, the dream goal is 10,000 x 10,000 km Map maximum...

Erm From LA to China is 10.000 km distance :P, did you mean 10 km instead?