Which Option is more taxing?

Unity Engine
1

So I am Building an RTS, Assume I Have average of 200 units Running this processes.

I have 2 involved scripts;

  1. Targeting Script
  2. Attacking Script, Name of Script “InfantryClickToMove” I know Stupid name

Currently my attacking script does something that “I thought” was suppose to be very taxing, and that is to getComponenet of target Unit-Stats Script and apply damage to it with every damage tick, assume my attack rate per unit is sub 1 second.

Script That I used:

if (myTargetScriptRefrence.target != null)
{
targetUnitStats = myTargetScriptRefrence.target.gameObject.GetComponent<UnitStats>();
targetUnitStats.damageHealth(currentDamageOutPutValue);
}

Thus I changed it to this:

  public UnitStats injectedUnitStats (UnitStats InjectedtargetUnitStats)
    {
        targetUnitStats = InjectedtargetUnitStats;
        return targetUnitStats;
    }


if (myTargetScriptRefrence.target != null) //Consider this on Update
{
targetUnitStats = myTargetScriptRefrence.target.gameObject.GetComponent<UnitStats>();
targetUnitStats.damageHealth(currentDamageOutPutValue);
}

And I made it so that my targeting Script, does this every time it changes target:

targetunitStatsReference = target.GetComponent<UnitStats>();
InfantryClickToMoveReference.injectedUnitStats(targetunitStatsReference);

Now heres the Problem, I tried both scripts with 200 units attacking at the same time, and yet, my FPS was the same. but why?? I dont understand

Please help, I am a noob

2

Why is this a problem? It seems like the obvious conclusion is that “neither of these things takes any notable amount of time” and you shouldn’t worry about it either way.

2 Likes
3

thank you for reply as always

I am trying to improve my FPS, and trying to understand whats more costly so I can become more efficient (In general). I was told before that getComponenet is taxing, so I have been trying to avoid doing that as much as possible. And I thought In this example where 200 units calling getComponenet of the target every second might be very costly. I am currently at 70-100 fps with only 200 units, so I am trying to optimise this script because most of the time according to the profiler, this is my most taxing script.

I ask this here to find out weather it is indeed very taxing, but maybe its being dwarfed but something even more taxing and thus I was unable to notice the difference.

But Out of the 2 methods, had you not tried it first, which method would you have though would be more taxing?

4

Could it possibly be because of this Line of Code:

if (myTargetScriptRefrence.target != null)

Meaning that, I am still calling the script very frequently?

5

I wouldn’t expect there to be much of a difference between them. But more importantly, I wouldn’t bother trying to guess that without profiling.

Premature optimization will keep you from getting your game done. If you have performance problems, use the Profiler and find out where the processor time is actually going.

6

theres so much going on in my profiler, I am finding it very hard to read. All I know, is that if a disable these 2 scripts, my FPS can improve by 200-300%

7

This is For the Method that I Originally thought was more taxing

This is for the new Method

8

And the thing is, depending on where I click on the profiler, it will show me something completely different, I find it very hard to compare

9

Put Profiler.BeginSample(“SomeTextHere”) and Profiler.EndSample() around these code blocks when you try them so you can see how much time is actually spent on these specific blocks of code. Do that with every potential time sink in the scripts and you’ll narrow down what is actually taking time.

10

Thank you, Sounds very useful, I dont think I am using it right though lol:

11

We don’t understand the measurement of FPS here if we’re serious about optimisation so I won’t discuss it. Instead how many millisecs is the most expensive?

Looking at the profiler screenshots I can see:

  1. your use of co-routines are ruining your performance due to allocations. Stop using them.

  2. Most of your slow downs aren’t even in your RTS code but how you’re using Unity. Canvas, rendering etc, all are ruining perf. Turn off the visuals while your optimise or hide them.

  3. Switch to DOTS for an RTS, you might even find it easier after the initial confusion. It’s just, DOTS is basically tailor made for an RTS. It will do a million units in realitme on any decent modern PC.

If DOTS isn’t an option then you are best of with a manager pattern, not co-routines, which aren’t really designed for game development. Even the manual states that, and it’s pretty much approaching legacy now with DOTS here.

Let’s assume though you won’t use DOTS. If that’s the case then an RTS really has to be done with a manager. You just don’t do scripts on each object and you don’t use co-routines. Both will ruin your performance really badly for anything that has a lot of units.

A manager works like this:

  • a class called UnitManager will be responsible for holding a list of all your units.
  • this list is a simple class that holds all the data. It really should just be separate arrays for performance but this is good enough and a lot better than individual monobehaviours.
  • Loop through the list of units in the manager and do maybe 10 units per frame. Every frame just shift the index start and end for looping through them. So you’re just looping through some of them every frame for logic.
  • For movement, loop through all of them every frame to update them in one go. Should be fine really.

Though honestly I think it’s probably rendering, co-routine allocations and canvas stuff eating your perf.

12

@hippocoder , Thank you very much for detailed answer.

In All honestly I didint know I was using them in the first place, I can only assume this is as a result of “Invoke function”, reason why I use Invoke, is to reduce how often a function gets called as apposed to keeping it on void update. I was never told that using Invoke function is taxing., I usually Stop other Invokes before I implement a new one.

Most of your slow downs aren't even in your RTS code but how you're using Unity. Canvas, rendering etc, all are ruining perf. Turn off the visuals while your optimise or hide them.

I have added Health bars to my Units, this is an asset I got from the asset store, however, I recently Came across a Video that shows how to use this while using only One Canvas, so I was planning to tackle this next. (not sure if this is relevant)

Furthermore, My health bars are Only Visible if the Unit is selected.
My HealthBars rotate to face the camera, that function also only applies if the unit is selected.

I really did want to learn this, I was advised as a noob that I should not use this yet, and that its still being developed. and that its not currently very user friendly, so I though I may do this later.

Furthermore, My units currently use trigger colliers as having all my units iterating a list including all enemies without multi threading will be very costly. Though I still want to implement this for units with very Large targeting range, because it sounds less taxing than having a very large trigger collier. And Hopefully by the time I will Implement those Siege units, I will be familiar enough to use multi-threading for that.

I also find that there isnt enough guides on youtube for DOTS, the only good one is by CodeMonkey, but tbh, I find his guides very advanced for me and his teaching methods “intimidating” (Probably because I am not ready for them yet).

I have received this advice before, and I have Implemented it for some things, I just dont Know how to implement this if the Script uses Functions like if(Input.GetMouseButtonDown(1) && ETC).

Thank you so much for your advice… and further guidance would be greatly appreciated.

13

DOTS is locked down enough now to start dev with, and so long as you’re learning programming with the mindset that inheritance and all that isn’t the one true way then you might have no problem migrating to DOTS later. I disagree it’s not for beginners though. It’s easier to code in DOTS but unfortunately harder to find learning resources.

So I would suggest so long as you keep your mind open about what programming should be I think you’ll nail it regardless.