I’m working on an ability that needs to be lobbed into the air along an arced trajectory. This has been a simple thing to do for spells that are cast by a real player - the player simply aims, casts the spell, and the projectile follows its arced path until it hits an object or a player.
But for the AI to cast a similar ability, I need to do an arced ray-cast / hit-check in order to check a few different angles and ensure that the player is within the AI’s “Arced Line-of-Sight” so that the projectiles land at the target location, rather than having a chance of exploding in the air if a tree or mountain are in the way.
Any ideas as to what would be the best way to do this? I did some googling and couldn’t find any JME threads or tutorials related to the subject, and the best idea I’ve had so far is to use multiple rays or bounding boxes and check for collision every 4-5 units along the arced path, but I don’t know if that would be the most efficient way.
Unless I’m mistaken, I think I already have these values in the form of the start location (the NPC casting the spell) and the end location (the target player) , and I’m trying to find an arced path between the two without any collisions.
So I already have multiple arcs with the same zero-intercepts and varying angles, and I want to pick the arc with the smallest slope that does not have any obstacles in the way.
I’m not great with math theory, so hopefully this image I made in paint will do a better job explaining what I want to do than my original post
The NPC on the right is trying to cast a lobbed spell at the Player, and I am looking for the best way to find the collisions along each arced path. This way the enemy will not cast the spell unless the projectile has a clear path with no collisions along the arc, and if none are found then he will not cast.
So the NPC can vary both the angle and the velocity.
…yeah, that’s a tougher problem. (Also a little unrealistic since even human players can’t do this without trial and error.)
You may want to scale back your approach a bit somehow. Can the player also control angle and velocity or just angle? (Angle and velocity is a bit unusual, really.)
Well what I do for my game’s projectiles is do a tiny raycast each frame for the distance a bullet moves in space. So you’d have an object flying the trajectory with physics and just doing a raycast from previousPos to currentPos after moving. At the end of the day, your object will never move in a perfectly mathematical way across the screen anyway, you’ll always have some steps in the curve that it follows - no point doing it in pure math imho.
You can also skip one or two frames for less of a performance impact and sacrificing path resolution and just doing a raycast between those.
I’ve found every second frame works well in terms of accuracy and speed. Just make sure the actual collideWith methods for your terrain and game objects are as lightweight as possible.
If you generally have such problems which are hard to solve, you can construct a set of random trajectories, and test each to see if it is viable. Eg. checking 10, 20 or 100 random trajectories might not be expensive depending on how often you do it.
Very true, I will most likely reserve this level of perfect accuracy for bosses and certain difficult enemies. Right now I have a boss that player’s can exploit and kill from a safe zone behind a hill, so I want to add some level of precise accuracy for lobbed spells to counter this (the other less desirable option is to make the boss “Evade” spells much like World of Warcraft does if the player is exploiting an enemy )
Right now the player can only control the angle when they cast arced spells, but you are right that controlling both would be unusual, and would make the controls harder to grasp for new players. I will most likely keep it consistent that players can only alter the angle.
I like this idea and just implemented into my “Arced Spell Type” class for collisions. I actually do something similar for spells that lock on to players, so it was quick to copy/past and adjust some of my code to make Arced spells like work in this way.
That sounds like a good solution and should work well with the collision approach @MoffKalast suggested. I should only be checking a few trajectories every few seconds and it doesn’t seem like I’ve ran into any performance issues trying to implement the collision check so far (it also helps that all of my spells have cooldowns, so enemies will only look for a clear trajectory when the spell is off cooldown and the AI is not doing anything else).
