A devlog by Neeraj Kotwani, who builds every game on Elipar.
Buried in the middle of a longer message about several unrelated things, somebody mentioned that the ball never went in the net in Pro Football 3D. I filed it as "aiming is too hard", because that's an ordinary complaint about a shooting game and it has an ordinary fix.
I was wrong. You couldn't score. Not "it was difficult". Nobody had ever scored, in any direction, at any angle, since the game launched.
Two checks, one number
The pitch has an invisible wall that keeps the ball in play. It bounced anything past x > 44, regardless of where the ball was along the other axis.
The goal test also began at x > 44.
Both numbers were correct on their own. The problem was the order. The wall ran first every frame, so it clamped the ball back to exactly 44 before the scoring check ever looked at it. There was no gap between them to slip through, because they started at the same coordinate.
I didn't believe this until I'd built something deterministic. I added a hook to move the goalkeeper out of the way, put the ball straight in front of an empty net, and fired. The ball's velocity flipped negative at around x=43 every single attempt, and the score stayed at zero across fifteen ticks. Repeat, repeat, repeat. That was oddly satisfying to watch, in the way that watching a confirmed impossibility is satisfying.
Carving the hole
A goal mouth is a gap in a wall. So the wall now skips its bounce inside the goal's own Z range, and inside that corridor the ball is only stopped by a deeper limit behind the net.
My first attempt used -3.4 and 3.4 for the gap. The goal mouth is -3.5 to 3.5. Close enough, I thought. It isn't: that leaves a thin strip at each edge where a shot is inside the goal but outside the hole, and it bounces off nothing visible. I'd reintroduced a smaller version of the same bug while fixing it. Use the actual constants. Don't retype them approximately.
There's an ordering trap on the other side of this too. The goalkeepers have to update before the ball does. If they run after, a shot can cross the line and get saved in the same frame, which is a very confusing thing to watch and an even more confusing thing to debug.
Then it happened again in the same game
Months later I went looking for this bug's relatives on purpose, and found that football still had one.
The goal test asked for the ball to be inside a band and moving faster than 0.1. So a ball that drifted over the line slowly stopped dead in the net, uncounted. And if it rolled past the far side of that band, nothing could ever reach it: the player is clamped to 43, the keepers are pinned at 42.8, and the ball would be sitting at 47. I measured one at rest there for eight seconds with the nearest player four units away, doing nothing, while the match played on without a ball.
The thing that makes this worse is a second threshold I'd picked somewhere else entirely. The keeper only attempts a save above 0.15, so slow balls get deliberately waved through. Which drops them precisely into the 0.05 to 0.11 window the goal rule was throwing away. Two numbers, chosen independently, months apart, and the gap between them was a hole the ball fell into.
Now a goal is just the ball crossing the line. No speed condition at all. It's more permissive than the old rule and it can't be skipped, because once the ball is past the line it stays past until the reset.
Measured against the old build: of sixteen slow arrivals at the line, six lost the ball permanently before and none do now. Everything that used to score still scores.
How common is it, honestly
I want to be straight about this. A 75-second hands-off match measured identically on both builds, because an ordinary rally rarely gets the ball near the line at all. This isn't the kind of bug that ruins most sessions.
But when it fires, your ball is gone for the rest of the match, and there's nothing you can do about it. I'd rather fix a rare total failure than a common mild annoyance.
And the shape turns out to be everywhere once you know to look for it. The pockets in Pool Master had their own version, bad enough that it got its own post. The goals in Paddle Clash were written with this already in mind, which is why they've never had the problem, and there's a test there that fires a puck at the wall just outside the mouth to confirm it bounces instead of scoring. That test exists because of football.
So: if a boundary in your game has a deliberate opening in it, the opening is its own feature with its own bugs. Test the thing going through it, test the thing hitting the wall a pixel to the side of it, and check which of your two checks runs first. All three of mine were wrong at some point.
Pro Football 3D and Paddle Clash both play in a browser tab, no download.