https://blogs.unity3d.com/2017/01/03/a-look-inside-scenario-testing-at-unity/
Unity’s blog highlighting the Scenario testing Unity uses but does it go far enough?
Personally the RTS testing scenario was very underwhelming…
I managed to throw together a basic 3 x AI Robot vs Player RTS game with a simple AI that provided a playable RTS experience. (Simple RTS by Arowx)
Then to really push the boat out Unity could go for an Ashes of the Singularity big unit count battle scenario that would really help Unity improve the performance of it’s game engine.
1 Like
They should at least have a few hundred units to test how it preforms
Stress testing again? You really like this one don’t you.
Read the whole post. The point of these tests was not to see how the engine performed with real games. Its not a test to see how many copies of the same script can be used at one time. Its not a stress test in any shape or form. The automated testing suite can far more accurately determine if performance has regressed or improved in any area.
Rather the point of these tests is to check out the human machine interface. It was to check out how developers interacted with the editor. And what the pain points were for developers using the engine on a daily basis.
And that’s a very good thing.
2 Likes
It’s not just me saying this check out the blogs comments section e.g.
or
or
All comments that say, larger more complex projects or scenarios are needed to help find the bugs in Unity.
1 Like
I believe I tested pathfinding routines last year. IIRC they usually could handle something up to 50 or 80 simultaneous agends at once, after that things were slowing down, BUT it is possible they were slowing down due to my collision avoidance algorithm, which was computationally exoensive.
They need to make pathfinding multi-threaded or something, 80 units is kind of bad. We need a 1000 units
Given it was 80 units with full blown ai and combat mechanics trying to get to the same spot, I think it was alright.
These days in most you usually get something around 12 enemies per frame anyway.
You’ll almost always need a custom pathfinding solution for an RTS. It doesn’t make much sense to do it at the engine level.
1 Like
Why?
Because
- No two RTS games I’ve played have used the same movement rules.
- Pathfinding is a simple algorithm to implement
Given those two facts, it makes sense to keep it as something custom built.
Not saying there couldn’t be improvements to the built in system. Unity could help out a lot by exposing more bits and pieces from it.
1 Like
I made my comments on the blog. I think that this is nowhere near enough to push unity to break points, but it’s a good start. Usually you’ll hit break points at the same time as performance points. Basically pushing something to the edge either has a crash barrier to protect you or it doesn’t.
It usually won’t affect the sunday driver keeping well within the speed limit in his family car. However, for general testing and seeing if system A still works when system B is being used, it’s good, I guess.
I am very happy they’re doing it.
Even arrowxs demo would have been better for pushing unity to the limit (the zombie one). This shouldnt be lagging.
Hmm… I could probably check if the engine can handle a thousand of angry ai-controlled wizards.
Then again, I’ll probably hit different kind bottleneck long before I get to pathfinding-related slowdown.
Who knows with the Multi-threaded job/transform system due in 2017, that can handle 20k fish maybe 10k characters in battle will be possible on the right hardware.
You’re looking for miracles again.
I believe 10k characters were already possible in total war so it is nothing special.
https://www.youtube.com/watch?v=g1kKKU6gyW4
And fish is just boids algorithm, which was invented in 1987.
Make it ten million units, and I’ll be much more interested.
AI wars threw 2 million at me. That’s a Unity game.
After a point the numbers start to become meaningless. Human RTS players (or at least me) can’t appretiate much more then a couple hundred units at a time. After that we start to abstract the individuals away.
In the end fighting a million units isn’t significantly more fun then fighting a thousand.
At one point in the Civ series Sid Meier came to the conclusion ‘I can have just as much fun in half as much space’. I think it applies here.
Well, we can keep adding zeroes. The realistic top number I’d be very interested in would be 7.5 billion simultaneous ai agents active and being displayed per frame.
That depends on presentation. Very large numbers of enemies are necessary to provide feeling of an “epic battle”. Most games don’t even attempt to do that.
I think historical wargamers would disagree as Unit strength is a fundamental feature in major battles.
Waterloo 73k vs 118k
Gettysburg 104k vs 75k
It’s the difference between being Wellington at Waterloo or Chard and Bromhead at Rorke’s Drift.
Anyway Unity would need to use toy soldiers as Waterloo was fought over a battlefield of about 50 miles.
Or you go from directing armies to directing squads.
I just get the impression that we should be able to get more out of these GHz multi-core supercomputers in our devices and on our desktops, not to mention the raw power of our CPU’s, than a HD version of games we used to play on much slower computers and consoles.
Take a modern FPS like Battlefield, what if it could actually simulate an actual battle with thousands of troops fighting over days. When you join you take over an NPC, until you die then you get another NPC, until you quit or the battle ends.
A lot of it would be smoke and mirrors and probably need to run on some solid supercomputer style servers, but how would that experience compare to a 64 player session?
As far as I know, wargames tend to prefer their battles to be turn-based.
You don’t need a supercomputer for this, and it should be possible to fit entire battle in a memory of a modern machine.
The difficulty here is not computation, but networking. You’ll run out of bandwidth.
Let’s say you have 200k troops on the battle field, all of them player controlled. Let’s say that one soldier’s state is represented by, say, 4 floats and an int (position, heading, animation state). So. that’s 20 bytes. Now, you need to send an update about the state of battlefield to everybody. Let’s say every player needs to personally receive a packet. That’ll be 200000 * 200000 * 20 = 80000000000 bytes of data. Per frame. Let’s say it is running at 30 fps, and you suddenly need 19 terbit link to handle it and 960 megabit link to receive it. And then you’ll need to deal with predictive movement and lag.
Of course, this is a signfiicantly dumbed down example and numbers will be lower due to compression, optimization, but the main issue is making this multiplayer, and not “making this happen”.
It will be probably less fun. Also, good luck making 200k players sign in into the session at the same time.