• Thanks for watching! • Discord: / discord • Metallophobia: store.steampowered.com/app/18... Music Used in this Video: • KOLA - Better Alone • KOLA - Break #unity #unity3d
I hope you found this video useful. If you would like to watch some of my more creative projects, check out the bacterial simulation I made in Unity: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-ws19Wrv37-A.html
It's strange that your channel has so few subscribers. The depth and quality of the content are outstanding. Subscribed! Looking forward to more videos like this.
What is this place? I don't know. Do I understand the things appearing on my screen? No. Why am I here? The almighty algorithm has sent me. And what a wonderful place I have been sent. And now I shall attempt to appease the almighty algorithm, so that others too may experience this joy.
Very nice tutorial, however, did you figure out how to move the enemies smoothly? Currently they jitter a lot, as they only move every Xth of a second.
OMG, I want to make a Survivor game and performance is a huge limitation without using DOTS, watching your video I'm impressed if you can share the source code, I really appreciate your work. your current job!
this a good tutorial, I usually just slam a box trigger collider to make in the list of the enemy. if enemy got in, add to the list, if enemy out, delete from the list. lol
first of all ty for this amazing video and can i get this project that you made here to see how all this combine into one? i got kinda lost while trying to make it work for me
I assume that the code choose the enemy randomly from spatialgroup right? So if we for example have 2 enemies in spatial group that will meet distance requirement it just choose first one in the list right?
Would it be better in your sorted set to rather than sort every single batch, keep track of which scores change and move them in the set accordingly? That way you don't have to sort the entire list and can just move around the ones that need moving
Smart approach. Thanks for the video, but may I ask this: Aren't you just "exchanging" low FPS for high FPS but with enemies moving at even lower FPS? Or didn't I get it right?
I wonder if the physic layer in Unity will help in this case. By saying no collision between enemy, using collision trigger tom reduce the work. Does this help? never try with a lot of object like this game. But thanks for the tutorial, somehow I think this is better solution.
Initially I had "No DOTS" in the title but I thought people that didn't know what that is would be confused. But yeah, this solution has no DOTS, just plain Unity :)
So after you get a the list of the enemies in the Partition (or neighbor Partitions) you check the projectile distance from the enemies? What about the enemy who is big enough to get inside in the other Partitions? Does an enemy exists in multiple partitions because of the size?
That is a good point that I didn't talk about. Basically every bullet and enemy has a radius so if a bullet is 0.2 wide, enemy is 0.5 wide, that means if their distance (center to center) is 0.7 or less, they are touching. In terms of even "considering" the enemies, that is indeed a limitation in my current setup. If there is a really large enemy where its arm is on a partition that might not be considered by the bullet. But here are two solutions: 1. Keep track of largest enemy on the map currently in the GameController so every bullet considers that added range when checking partitions. 2. I think an even better solution is: If you have a lot of big enemies, or large variety in size, you should increase your partition size. If most of your enemies say span a 3x3 box, you should increase your partition size to be a 3x3 box, instead of using 9x 1x1 boxes in a square arrangement. I hope that makes sense.
Yeah the GameController is a singleton that manages which enemies get updated (I show that part in the video). It picks based on the batches. So basically there are 50 frames a second, and every frame 1/50th of the enemies update. For your 3rd option, yes, definitely different solutions could also work. Very flexible depending on the game & your needs.
@@ZiberianDev The one thing that throws me off about spatial partitioning is that even if your partition sizes are big enough to fit your largest enemy, that one large enemy is still going to move *gradually* between partitions. You'll always have a situation where an enemy can be between and in two partitions
@@kplays_6000 Ziberian covered that in the video. That you can account for this by checking nearby partitions, like a 3x3 grid around the monster, or if it is an incredibly large enemy, you can hard code it. In a more dynamic or variable equation (2+s) * (2+s). Where s is the size of the enemy. So, if a normal enemy is 1x1, it will check a 3x3 area. 3x3 enemy? 5x5. etc and so on.
I think Jobs and Burst are reasonable to use for such a game. ECS would be better, but then the code-maintenance and expansion, as well as integration of Managed Assets/etc, will be more difficult.
