I want to step back for a moment, and get away from such things as "fatigue isn't working properly" or "interception rates are too high (low)" or "my 68 STR OL should be pushing a 58 STR DL all over the place". I think the problem with this engine lies more in a fundamental design flaw, and so I want to focus on the higher level picture of "how do you simulate a football game?"
I'm sure there are a dozen different ways you could calculate which team wins and loses a game, based on any number of factors. This game has always taken the approach that a football contest is comprised of a series of (mostly) unrelated plays (meaning the results of one play are not factored in any way into the results of the next play - with the exception of player fatigue and possible injury Down and distance factor into which play is called, but the fact that a run up the middle has been stuffed 8 times in a row is not taken into consideration). At its most fundamental layer then, the engine, then is a simulation of a football play (with a meta-engine that ties all the plays together). In simulating a single football play, there are two basic ways to do it:
1) Generate the results of a play based on a play chart (Inside Run Results) using a random number generation that is modified by whatever factors you input as relative to the results (+ for OL STR/BLK, - for DL STR/TKL, for example). This is, in essence, how board games like APBA work. A game like Strat-O-Matic takes this same approach, in essence, although the mechanics of how the modifiers are applied are built in to the "charts" (player cards) themselves.
2) Generate the results of each play by modeling the behavior of the participants during the execution of the play. Long-winded way of saying keep track of where every player is, and what they are doing, at successive "check points" during the play. This is obviously much more complicated, and should require many more decisions to be made for each player's actions at each checkpoint. At a certain level, one would think this was the most "realistic" way of generating the results, because it models what occurs on a "real" play.
GD takes this approach - sort of. (It's what I believe to be the approach anyway, based on information presented back when the developer actually took any time to communicate with the testing base.) The GD approach, as I understand it, is to model the behavior, not of all players, but of relevant portions of players. As in, a WR blocking a DB isn't really factored into a running play -- although at some point in that play, a DB may be called upon to make a tackle, and so they then mysteriously appear.
The design flaw, I believe, is the "half-way" approach to modeling a play. Every player is not modeled, so you don't KNOW where every player is at any point of the play. You don't model "does this player recognize that it's a play-action fake?" for every defensive player on the field and have them react accordingly. And so you get an incomplete model of the play - which still relies on a large number of decision points, thereby complicating the process of getting your results.
As much as I would love to see an improved version of this game published soon, I have come to the belief that it's time to scrap what has been done so far, and re-evaluate your design. There's nothing wrong with the first approach - it's been done successfully by APBA and SOM for years. And there's nothing wrong with the second approach, providing you want to put in the effort (and have the computing power) to effectively model the physical and mental activities of all 22 players on the field.
Figure out how you want to simulate a play. Get that working right. Then build on that as to how you simulate a drive (plays called, substitutions due to injury, fatigue, etc.). And THEN you have a working game.
It wouldn't hurt to talk to us once in a while, either.