Re: Cracking Open Combat
Posted: Fri Aug 16, 2019 6:36 pm
So, I think i found out why they where apply the range they were. It doesn't have to do with raycasting at all. It instead, has to do with how the weapons manager tracks what weapons are equiped and which ones are selected for actual combat. In order to make it easy for the system to update range no matter what is equipped in what hand, they just have it run every frame. It's a simple solution, but not super efficient coding and cpu cycle wise. I'm going to see if I can streamline this a little, while I work through this project. The more cpu cycles/ frames I can free up, the more I can use those freed cycles for other combat related computations. I honestly think they were planning on doing something more complicated with range and stamina and other combat mechanics, but ended early because of developer creep and bugs. Original release of the game was pushed out and bug ridden, despite its scale and greatness.
I can update this, but it will probably required me adding some type of pass through method just for setting range when weapons are switched and equipped,
Some more good news. I was able to ram in a simple raycasting debug line. Now, when in the unity engine, I can see where attacks are casting and how far they are going out. It draws a bright green line in the scene window for 600 seconds where the spherecast is. However, since it is a debug feature, it will not show up, on the fly, in the game. To do that, the raycast code itself would need modified, and I don't even want to dump the time into that yet, if ever.
Also, the game is using spherecasts, which are large spheres that are project outward instead of a small line to blow up the hit trace box and make it more likely melee weapons will hit on the side of the screen. However, this explains why weapons feel odd and janky a lot of times. The on screen animation has nothing to do with what is being detected for hits. There is a single sphere being projected outward from the center of the screen/mouse position. If an enemy is on the side of your screen, and the weapon animation seems like it should hit, it never will.
This was an issue faced in Age of Chivalry, when it was a HL2 MOD, and I was working on it heavily with the modding team. HL2 was built for gun based play, so all attacks where raycast lines to simulate bullets. To mimic melee weapons, we built a raycast projector routine/method that read a simple text file, and then cast a series of rays, instead of a single one, to try and mimic the animation of the weapon as close as possible. It was not perfect, but it may be a good solution here for the age of the engine and the more simplified mechanics and visuals.
I can update this, but it will probably required me adding some type of pass through method just for setting range when weapons are switched and equipped,
Some more good news. I was able to ram in a simple raycasting debug line. Now, when in the unity engine, I can see where attacks are casting and how far they are going out. It draws a bright green line in the scene window for 600 seconds where the spherecast is. However, since it is a debug feature, it will not show up, on the fly, in the game. To do that, the raycast code itself would need modified, and I don't even want to dump the time into that yet, if ever.
Also, the game is using spherecasts, which are large spheres that are project outward instead of a small line to blow up the hit trace box and make it more likely melee weapons will hit on the side of the screen. However, this explains why weapons feel odd and janky a lot of times. The on screen animation has nothing to do with what is being detected for hits. There is a single sphere being projected outward from the center of the screen/mouse position. If an enemy is on the side of your screen, and the weapon animation seems like it should hit, it never will.
This was an issue faced in Age of Chivalry, when it was a HL2 MOD, and I was working on it heavily with the modding team. HL2 was built for gun based play, so all attacks where raycast lines to simulate bullets. To mimic melee weapons, we built a raycast projector routine/method that read a simple text file, and then cast a series of rays, instead of a single one, to try and mimic the animation of the weapon as close as possible. It was not perfect, but it may be a good solution here for the age of the engine and the more simplified mechanics and visuals.