How does UEBS get a million troops on the field simultaneously?

At first I thought Ultimate Epic Battle Simulator was just a joke (an army of chickens defeats Roman legions in the trailer), but gameplay videos seem to show unusually large numbers of troops (with relatively good framerates), such as this one:

So how did they get so many animated figures in play at the same time?

Obviously, there are some physics quirks. A battle between 10,000 Chuck Norris clones against 10,000 armored knights results in the Chuck Norris clones only slowly making headway, whereas in real life we all know even one Chuck Norris could easily win against 10,000 armored knights using nothing but his left pinky; so the realism is a bit wonky.

 

Lots of instancing, lots of physics faking, and lots and lots of optimization to every system to work smoothly. Seems they did a pretty good job!

 

Ten year old console game. Not 1 million, but an enormous number all the same.

They're all following the same command. Only the ones near the player (in KH) are acting uniquely.

 

Focus on the soldiers that are close up and then focus on the soldiers that are far away. Up close the units are receiving a good deal of animation but the farther away they are the less animated they become.

 

The only thing that counts is that they did it under Unity and many here and elsewhere thought it was IMPOSSIBLE.

Well done.

 

Well, rather than process the animations based on bones, they are just cycling through what appears to be a handful of pre-animated models. Only the few in the front line are actually animated. Thus, much less processing power, all it's really doing is writing stuff to the vertex buffer and then the graphics card takes care of the rest. Still interesting.

 

I saw an asset that this brings to mind, where the distant units were billboarded as animated sprites, and it was pretty convincing, made up close units have detailed LOD and the far ones were simple quads with an animated sprite angled to represent the units... it even did the sprite generation automatically and everything. I think the demos of that asset showed something like 10k units? If I remember correctly? But... that is a lot, and tricks could be used to simulate a larger crowd which are little more than pixels at the distances they are at...

 

Right, they're essentially baking the animations into the meshes. Which makes sense because as far as I'm aware Unity's GPU instancing doesn't support skinned meshes. Someone who wanted skinned meshes would have to add support for it themselves. Speaking of handling large numbers of meshes I found this thread from four months ago with more details.

https://forum.unity3d.com/threads/e...der-massive-numbers-of-skinned-meshes.447749/

 

Instancing. The soldiers are pretty much particles. The tech has been used since Total War times.

 

They write to one big vertex array that have all the character and use offset to access single character, ie no transform, no animation, one mesh, everything is made by "hand" using their own process.

 

By the way :

 

If you want to have a huge number of units, assume you will not use a game object for each unit. Create a custom struct that will hold information about one unit, and then make an array of that struct. Then use GPU instancing API methods to draw units with very few draw calls. Check out Graphics.DrawMeshInstanced at
https://docs.unity3d.com/550/Documentation/ScriptReference/Graphics.DrawMeshInstanced.html

And instead of using normal animations, you need to bake the animations into static meshes. Then you can select which mesh to draw using the GPU instancing. Part of the custom struct will be an index of which animation is currently playing for each unit. Your code will combine units at the same animation index into the same GPU instancing groups.

You code will need to manually decide what the units will be doing in the scene, including moving and attacking other units, and update unit details within your array of your custom struct.

 

Nice idea.

 

There's an asset on the asset store called "Mesh Animator" or something like that, it helps you do this as well. In the video you can see that the fps is pretty bad, he's getting about 10-15 fps. But that number of characters on screen is impressive I bet you could have a 60+ fps game with about 3k troops on each side. Which is still really good. I love games with large numbers of units in them lol.

 

I wish I had known about DrawMeshInstanced before. Thank you.

 

Sure, but in the Total War series the AI is done entirely at the regiment / cohort (etc) level, whereas in UEBS individual soldiers are clearly doing their own thing, as you can see by watching how they gradually curl around the enemy flanks one by one. In a Total War game, an entire group might maneuver around the flank, but individual soldiers are just offset from that group.

 

I believe In total war individual soldiers were particles and not part of the regiment. I think I recall them breaking formation during fights, etc. You won't get this kind of behavior by making them a "part of regiment".

Similar system was used in black and white 2, by the way. Meaning that while individual units weren't running an AI, they would stil avoid obstacles, etc. Basically, you need to reduce a "soldier" from a full blown object to a set of a few floats. (for example... position, movement vector, maybe animation frame). Doing that will turn it into a "particle" which can be then fed into a shader.

 

The developer of that, or something very similar, has talked a fair bit about it on the forums.

People saying it's impossible to do this kind of thing in Unity are almost always referring to using the built-in, general purpose tools. Those tools simply aren't built for this kind of use case.

I've done something similar myself, albeit less graphically focused. In my project rendering wasn't really a concern, but we still had to handle all of the "physics" side of things. We did it by making a custom system built specifically around the types of interactions we needed.

In our tests, for our needs Unity's built-in systems topped out at around 6,000 units on our target hardware. A simple test with a mockup of our custom system had several tens of thousands on the same hardware. Rendering wasn't the bottleneck in either case. We did have a bunch of ideas to push the limit up further, but since we'd already exceeded our spec'd requirements we didn't get to try any of those out.

Basically, Unity's built in stuff is great, but it's built to meet broad and generic requirements. There's plenty of savings to be had if you figure out specifically what your unique case needs and build something custom that only does that, in the most efficient way possible.

 

That makes sad, because the more I document myself on that, the more I see I need custom physics, and nobody will do it for me lol, I'm not a programmer damn it!

 

Unfortunately for nonprogrammers, that is just the way it is when you need to push the limits in a game. Pushing the limits nearly always involves writing custom code.

 

'Pushing the limits' is a very relative thing. In this guy's case he's wanting 1000k units fighting realtime and since there is no built-in solution to do that feasibly without assuming that some sacrifices will be made he just wrote his own solution. Someone elses scenario might be wanting 18 cameras and monitors rendered at 1080p which is an entirely different issue.

I guess what I'm saying is Unity can't really support everything stock without making sacrifices on those features and doing that would handicap its overall flexibility. As you branch off from 'standard' it becomes clearer which features require custom solutions and what sacrifices are acceptable relative to your product, and that is where pushing the limits turns into pushing the limits of hardware.

 

You can learn to do it yourself, I believe in you.

 

I do, it's just putting many features together that collapse, also there is a size there I can't track code, and hen I abuse encapsulating code into function, it make tracking bug a nightmare, after a few inception scroll and I forget what I was doing. But generally individual features I do.

Also the kind of gameplay I want to do always involve obscure stuff nobody can help, My last encounter with unity's physics let me running in literal circle during 3 years, because it was a 6dof platformer, where you crawl freely on a surface with a camera similar to zelda games (direction of cam and character aren't the same). In a world with no up direction that's a nightmare. And I stopped when I realized I had to implement moving/rotating platform too, and differentiate between force applied by environment () or the input for the animation. Because animating + moving ground + wind + moving platform is a hell lot of reference to translate and sync. And gravity wasn't constant either ... then I notice mario galaxy forgo the free cam I had, now I know why lol And that's leaving the problem of listening multiple contact points which was a great source of pain but was needed (and slowed unity to a crawl).

For some reason, no project I do have simple idea like that, I'm trying to implement a planetary terrain, a "sphere" again, no up, I put it to rest for a moment to catch with life, I had a recursion bug to track lol I will finish them (I need the crawl system for having a controller working on a planet), but it will be a grind.

 

Exactly. It is not practical for Unity to include every imaginable edge case situation in the engine. If game developer wants to do something non-standard and push the limits, then the game developer accepts responsibility for custom coding it. It is not practical for Unity to include full blown solutions that do not require any programming at all by the game developer in those cases.

At most, the game developer can ask Unity to add certain features to the engine that open up the options for the game developer to custom code a solution. The DrawMeshInstanced API method is one case of that. Without a really low overhead method for us to pump huge arrays of GPU instancing data through, certain things would not be possible. I was thrilled when Unity added that API method in v5.5, because it open the door to build games with huge amounts of units.

 

This...

 

Do you maybe prioritize working on interesting and stimulating problems to work on, over picking achievable gamedesign goals? You could try to chose a clear goal, and if that's "finish a game", then you might want to drop some of the bleeding edge fancy stuff in favor of simpler problems to solve. Of course if it is more a kind of "the jurney is the destination" kind of thing and you just enjoy working on very complex problems, then I'd perfectly understand as well. I struggle with the balance as well, though my stuff is already far less complicated then what you want to do.

 

Be the way, official documentation is very poor in information about GPU instancing (and that kind of thing).
Like many developers Unity Developer's, i learned a lot of things from this man: Keijiro Takahashi.

So, since he is an employee of Unity Technologies, give him a medal and a salary increase. Really....

https://github.com/keijiro/KvantSprayMV
https://github.com/keijiro/KvantSpray
https://github.com/keijiro/KvantStream
https://github.com/keijiro/KvantWall









etc etc etc ..

 

@Martin-H

Well all my problem come down to I don't want to make a game I could play by picking an existing game. While it doesn't necessary mean that it will lead to complex problem, it mean I won't work on solve issues because those are other game.

Sometimes I want to make a zelda game, but I have nothing to add (especially since BOTW) so why not just pick up zelda? I also want to make 40h rpg, but it won't have any polish, any value, because I just want to make a 40h rpg as a challenge ... What's the point in doing that.

For example:

Spoiler: Project I'm working on and the challenge I have met

1- I tried a side project: classic sonic but in 3d with mario galaxy physics, it mean creating an arbitrary controller for crawling any volume surface reduced to its core ... I had no idea how hard it would be, wasn't design that way. I did solved teh core issue, but I still have no idea to make a moving platform with reference frame (which is basic issue every game implement). And since it was side project, well I put it to rest after 3 wholes years trying to solve the core issue.

2- I'm making a caraibean game, but it mean representing certain people correctly, it turns out that was a harder problem than anticipated which lead to a lot of research, I cut the project to his core, but that meant gameplay too! until I find a fitting story and universe to "tell". I was stuck on a long time in finding the basic structure of the story, Long enough to prompt working on something else to not be completely stale. Turns out working on that something else help me answering the last question I needed, that made me grumpy because now I have the urge to work on the two. But this taking the front seat I'm back to it.

3- I always wanted to make a game like no man's sky with some new pcg idea. Then no man 's sky happen. So I started to grok the basic (with the former sonic project being a basis for the controller), the entire game design right now is to have a planetary terrain system working, as long it's not validated, nothing else matter, but I know what I want next a local city generation (I have no idea how to do it yet, I need to make a grid "flows" then use that grid to spawn road pattern) and local stateless NPC generation with the illusion of history (that looks impossible but I have an idea how to do it partially validated), then build on typical skyrim like game with a progression across galaxy with a hierarchical quest generation (at the regional level then planet, then solar system, then galactic, then intergalactic, then inter dimensional, then inter temporal, then inter spiritual plan until the main character become the god of everything). But that's the kind of game you work on it indefinitely just to work on it, it is never finished, it's pure exploration. It's too crazy too, so it's never on the front.

 

Also, don't forget quad trees (AKA, spatial partitioning) are a thing.