This week's coding challenge: obstructions to range attacks. We're using traditional random-roll RPG mechanics driven by 3D simulation factors. It's one of the trickiest parts of the game design, but it'll make for some very cool tactical gameplay - if it works according to plan!

In a normal 3D shooter game we'd simply raycast along the player's facing vector until we hit an object, and that's where the bullet strikes. Not in a turn-based rpg! You could spend all your AP to line up a perfect headshot with your last rifle round, only to clip a wall corner by 2 millimeters. We can't have that! Instead we assume you'll lean sideways and aim around obstacles if possible. There's still a chance you'll hit an obstacle, but we compute the odds before you roll the dice.

We're attempting to model this common-sense aiming behavior by doing 5 raycasts, one on the centerline and 4 parallel lines offset about 6-12 inches (15-30 cm) in 4 directions. In this screenshot, the X's/crosses show where each line intersects the wall:

If all 5 raycasts hit a wall, you can't make the shot - try something else.

If there's a wall on one side, you can lean the other way. Your to-hit chance is reduced slightly. The greater the distance to the obstacle, the greater the odds of hitting it instead of the enemy.

If the wall is blocking the whole centerline too, you can lean further, albeit with lower odds.

If the centerline is clear but you're aiming through a narrow gap, you can't compensate, so the odds are much worse - but with the right weapon and skills it's worth a shot. 

Here's a screenshot of the last case; notice the orange X's on the support column and wall corner:

For speed and simplicity we only scan for small obstacles (like furniture and NPCs) in the centerline raycast. While not strictly accurate for offset shots, if it plays right and looks right, it's perfect. (Knock on wood!)

Small obstacles reduce the visible target area and therefore your to-hit chance, and they can stop bullets or at least absorb some of the destructive energy; this mechanic makes high-powered rifles and jacketed rounds rather interesting in pop-a-mole scenarios. 

This includes friendly (N)PCs:

The 20% friendly fire risk in the console output is a placeholder; it should be about 80%. We'll be using the NPC targeting formulas to compute the chance of hitting an (N)PC with crossfire.

For an inanimate object we use the bounding box to compute the approximate chance of hitting it, and we can adjust it with a "cover=NN%" tag. Soak and deflection tags determine its armor value. To simulate bullet interference, we may also increase the cover% according to the distance from obstacle to target. For example, hiding behind a hedge row offers little protection against enemies shooting at you from across the lawn, but it'll deflect your shots so badly that it's impossible to hit them.

We save all the obstacle data in a 'hit list' sorted by distance to target. Then if you pull the trigger and roll a miss, we compare your to-hit roll against the cumulative exposure/cover of each obstacle to determine which one you hit. There's also a chance you missed the enemy and the obstacles; in that case we raycast behind the enemy to see where the bullet lands. Then we show it on screen.

It's a work in progress. After all these details are coded, we have to refactor and hook it up to the AI. 

Then we're on the home stretch:

• Combat tuning & playtesting
• Finish worldbuilding and encounter design
• Finish quests & scripting
• Shadows, wall/floor textures, sound effects, and other nice touches (we must resist the temptation to make it better than it needs to be!)
• Beta testing

BTW - this is high-difficulty gamedev! If you're an indie dev contemplating a game design like this, be sure your math & coding skills are up to the task. If in doubt, consider FP or 2D graphics, pure dice-roll mechanics, medieval fantasy combat, magic spells, etc.