#First of all - I just want to voice that

1 messages · Page 1 of 1 (latest)

meager vale
#

Now for the learning case - Here's some case for starters:

If you really want to control the simulation 100% in a game what you want to do is to make your own timeStep instead of deltaTime but use some number you choose - and for every frame, use the same number to update any motion or logic. This way, every single machine, every game, every device, would have the same "DPF - Damage per frame" instead of the traditional "DPS". A code example could be to use a "Tick" instead of Unity's update. So for example:

public class ShootingTower
{
    public void Tick(long timestep)
    {
        // Update, cooldown and shooting code here
    }
}

The advantage here is that you can force any unit in the game to always move the same distance for each frame, so even if framerate lowers, the units won't "skip a bullet" so to speak.
This means you're developing the game's time around it's frame number instead of by seconds of gameplay.

Older games would run this way in the 90's. But one side-effect was that they didn't anticipate the crazy increase in computational power after the 2000's and if you tried running old DOS games on Windows machines you might experience that the game was running too fast. There are ways to work around that.

So you may have different scripts around code that use "time" to calculate how far something moves or how often to fire a bullet. This way you could design your numbers in one way and expect the same result every time.

De-sync-sensitive games have to operate in this way. This is an accurate simulation approach used in competitive games, online games, replayable modes and more.

That being said, you would still want to make it seem like it follows a reasonable "human timescale". Now this goes back to the old separation of "Ticks vs Updates" in the past.

Sometimes your update loop might be running slow. So maybe if you repeat the Tick from before the _currentCooldown might still be below 0, but since Shoot was already done, it won't fire another bullet yet.

The trick there is a "catch-up" mechanic where if the time was so much delayed that "two bullets should have been fired by now" the simulation part can run the "Tick" part twice to catch up.

Essentially this is the concept that Unity's "FixedUpdate" does. FixedUpdate is similar to a "Tick" system. And the idea is that the code to shoot bullets might be running quick and steady, but if you have really heavy graphics, the normal Update (or "Rendering" loop) might run too slow. However, the FixedUpdate is a sort of "Best-effort" system that still uses the actual time it took to run. It tries to start after roughly 20 milliseconds, but a PC is running many things at once and sometimes there are small delays between the various programs, services and threads a CPU has to work on. This results in FixedUpdate sometimes happen after 19 ms and sometimes 21 ms.

The use of a custom "timestep" ignores this time and allows the game to be deterministic instead of time-based. You can still run your "Tick" code on FixedUpdate and it will try to run every 20 ms, but if you opt to use your own long timeStep = 20 for any calculations you make in code you will always get the same results without getting the inaccuracies of FixedUpdate.

#

There is a great read on how "Game Loops" were built for games in one of the most popular books about game programming patterns. Here's a link to the chapter on Game Loops, but I recommend the entire book:
https://gameprogrammingpatterns.com/game-loop.html

outer laurel
meager vale
#

You mean ISystem in DOTS?

outer laurel
#

Yep

#

I did try normal gameobject but it drop fps if i made like 500 objects

#

Ans only logic for them was "go to the player pos"

meager vale
#

So realistically, if the first example that carries over the cooldown to the next tick worked for you then the short answer is just like the others said, you don't need a custom tick step.

You can use your own tick step anywhere you like. But the primary use is if you want determinism.

meager vale
outer laurel
#

Dots is faster or normal "game object" its ok but i did wrong ? (I want make like 400 enamy on screen or more plus for example 20 towers shooting them

outer laurel
#

OMG its do hard to write at my phone xd (Polish dictuonary try fix my english xd )

meager vale
#

Oh you used normal GO's. Right, well the number depends. If you have 500 models then that could be heavy for the GPU to run. If it's just primitive capsule shapes then maybe it's something else. And also if you're using the Navigation system to find a path then maybe there's something in that system that is causing too many path requests.

And also if you're on an older PC or a laptop, you might be seeing performance problems because of that. If you try to build the game it should run faster, but it would be slower while trying to do that many units inside Unity.

outer laurel
#

No path finding at all

#

2d sprites (even not sprites just colour)

#

I just made test for collision and enamy detection

#

Everytinh was a 2d sphere

meager vale
#

Aha, well that's your problem then. Physics systems quickly gets worse then there are 100s of objects, and specially if they're close together

#

The other thing is that in cases like that, the 2D physics system is actually worse than the 3D physics system in collision performance, ironically.

#

So perhaps there are simpler ways of doing what you want to do with physics.

First of all is to identify "who should collide with who?"

#

If all objects should collide with all other objects you have a performance problem that is difficult to solve. If "all enemies should collide with the player" then that's a much simpler problem as you can solve that by setting different layers, and making sure all enemies can ignore each other but only care about the player by unchecking a box in the Layer Matrix:
https://docs.unity3d.com/Manual/LayerBasedCollision.html

outer laurel
#

I did that collision filter but didn't help a lot

#

And i think that problem was colliser on stay update

#

I made "remeber cur target"

meager vale
#

Try add 3D Sphere colliders instead of the 2D ones and see if that magically improves

outer laurel
#

But the funcion on stay will call even if its empty

#

I did thst for dots xd

#

Becouse i put linear speed

#

For objects (only calculate direction)

#

Ans i need 3d for that xd

#

So now i have sphere 3d and everythiing at z =0

#

Ok thx i go to the dance class xd i will back on 2-3 h

meager vale
#

Good luck

And yeah OnCollisionStay might be expensive too PepoThink

outer laurel
#

Hi

#

If you will have time ping me please XD

#

i wanna know why i have actualy nothing at scene (like 40 object)

#

and i have 120 fps instead of 500 ETC

outer laurel
#

My systems actually take no time but i have only like ~70fps WTF

image.png
meager vale
#

You should take a look at the normal profiler as well. Chances are that the limitations are outside the DOTS systems if it doesn't show in the entity profiler. You can also look at timings on the "Stats" menu in the corner of the Game window.

image.png
outer laurel
#

Yes i know i take FPS from that place and its low ):

#

I will go sleep now (:
But if you will have some time could youu help me XD ? maybe some screen share and like 20 min of help (: ?

#

I had to make something very bad XD