To me it's a simple exercise in data gathering, analysis and cricketing logic. If I've to go about addressing the logic this is what I would do at a simplistic high level...
1. Look at various shots and determine their success/failure rates. Say cover drive is successfully played 70% of the times. That means there's 30% chances it's miscued. Then figure out how many times the miscue results in an edge. Say 15% of the miscues result in an edge.
2. Then factor in the conditions. in flattish and non-overcast conditions this failure rate drops down to 5% and in green, overcast condition it bumps up to 20-25%
3. Then look at the length of the delivery. Fuller the length, the failure rate goes down further and it increases the shorter the length you are trying to cover drive.
4. Factor in the line of the delivery. If line is closer to the batsman, failure rate drops else it increases.
5. Factor in seam/swing.
6. Factor in batsman's strengths & weaknesses.
The thing is there can't be a simplistic answer/solution to edges. It can't be "cover drive on a green pitch is an automatic edge". Oh and this has to be done for all shot types andAnd that's why I suggest giving more control to the end users by adding a 'Edge Frequency' modifier. Either one generic modifier for all edges or two - one for drives and one for horizontal (cuts & pulls). Or maybe give a 'Edge frequency' modifier for each common shot type - cover drive, straight drive, on drive, glance/flick, cut, pull/hook. I'm more in favor of going the modifier route to solve the problem as Big Ant can crowd source the gameplay balancing and also folks can adjust their own gameplay experience.
This has been the key issue in dbcs, the edge system doesn't show of this kind of depth.
. So most changes affect the whole batting in general. And you would start edging full deliveries that are there sitting upto be driven with no lateral movement..
The length line pace lateral movement distinction really needs to get with the edge system