Long story short: I’m trying to get a movement/collision function working for the first time with my 2d game. No colliders, no rigid bodies. Specifics: I shoot out a line from each corner of the enemy in the direction he’s going. The lines all go to the right spots, I’ve checked this over and over and have even given it a buffer area to extend the lines further. If any of the linecast checks find an object with the “Wall” tag don’t move and do another linecast check in a different direction. If there’s another wall repeat, else move there. It might sound odd but this is basically what I want.
As far as I can tell the code works like a charm. I’ve tested it with one enemy and he can run around forever and never run into a wall. It works fine with two enemies, three…However after adding many enemies, which is going to be a common occurrence in my game, enemies run into and through walls constantly.
I have a draw function so I can see where the lines are going, after a lot of testing I’ve noticed with so many enemies on the screen, some don’t have any lines being drawn from them. I’m wondering if unity has a limit to how many linecast/raycast checks can be made at a time.
If this is true should I completely scrap this ‘move’ concept with linecasting? Is there a way around this or is there just a better way of doing this? Or should I go back to my code and do some more testing? I’ve been at this for 4 days so I would love any help I can get
No functions ever have any limits about the number of times you can run them; computers don’t work like that. Calling a function a million times works the same every time, it just takes a million times longer than calling it once. So the only way code using linecasts would fail is if you have something time-based in your logic, and calling many linecasts is exceeding some interval you’re using.
Thank you for the reply, I was worried it might’ve been some memory issue or something, which it appears it isn’t. After further inspection some of the linecasts stop short of where the enemy actually stops and sometimes it extends further. I’m using the usual [distance = speed * time] fomrula for the endpoints of the linecast and I’ve tested the numbers over and over and they all seem to work, which lead me to think it might have been this ‘limit’ problem.
I think I’ve found a potential problem. When I use the distance formula to find the endpoint in a distanceCheck function I use [velocity * Time.deltaTime] for the speed, however when the enemy is moving in the update function I have [transform.position -= velocity * Time.deltaTime]. If there’s a drop or increase in the frame rate between when the endpoint was calculated and while the enemy is moving would this make up for the difference in the endpoint of the linecast and where the enemy eventually moves to? This would at least explain enemies moving through walls more often while there are more enemies on the screen due to a large change in frame rate…
Could this be my problem and how would I go about fixing this without having to check the distance every frame?
For anyone interested, I did solve this problem. The problem was with Time.deltaTime changing from when I calulated the endpoint to while the enemy was moving thus manipulating his actual endpoint. To fix this I made a distance check:
This was added where I made the endpoint calulation-