Russia 122 for 2 at Lunch

[Biggs]

I like your idea of that feedback being dynamic too. Play and miss a few and you lose an element of 'reading' the ball. Perhaps, as you suggested a shorter glow of the ball or something. Could be really cool.

...one thing, that I think might be a happy-medium solution would be 'ball marks' being left on the pitch. Especially in Test matches and ODI's if you've ever walked onto the field at the break, the pitch is littered with cherries from the white or red balls. Perhaps, there could be some way for the ball to leave a subtle mark each time, even just for an over or two to aide batsman in the "corridor" the bowler is working in?

 

[Dutch]

Yeah the ball marks would work really well I think: i think a great area of feedback is possible from the commentators standpoint: they are bowling too short to this guy; they need to bowl fuller on this pitch, he needs to get more forward....,endless possibilities

 

[grkrama]

ya i would actually like some physics to bowling too especially the run up part instead of having a button press and the bowler running in animation at constant speed. I would like to see the analog trigger put to good use here as that run up can be tied to stamina system to have a great experience on bowling fast.

Also using LS for determining type of delivery seems a bit of a waste of a whole stick especially for pace. As mostly you would determine the type of ball before hand just have it as one of the button press and use LS for a way to aim on the pitch while RS for the jump and execution.

This will make pace bowling a bit more challenging while also rewarding to nail the perfect deliveries you had in mind.

 

[T.J.Hooker]

No, I'm claiming that you're telling me to watch the pitch for a "blink" that's going to tell me exactly where the ball is going to land, with a pitch marker, so I don't need to watch anything at the other end because I know exactly whats about to happen because, "T.J.Hooker Technology" ...except for when the ball swings, so I'm getting guided premeditation thanks to the pitch.

The blink (let's stick with that) doesn't have to show exactly where the ball will pitch. You just need a good enough idea to be able to make an informed shot choice. And I specified that the final patch of the ball will not be an exact match for the marker, anyway.

Your objection seems at least partially founded on suspicion of the suddenness of a marker, as if being suddenly aware of (roughly) where the ball will bounce at the beginning of the delivery is part of the problem, but that's actually just how batting works. The ability to arrive at a sudden realisation of the bounce point on release is a batsman's primary skill.

I'm somehow supposed to look at the bowler and watch for a blink of yellow at my toes at the same time? Talk me through that. It's not possible

Um, well bullshit, really. If monitoring one moving and one fixed point 5 or so inches apart on a 2d screen was some kind of American Ninja level challenge, we'd all be pretty crap at computer games.

And anyway, throwing EA cricket back into the mix, the fact that you already knew where the marker was before the delivery meant there was no need to watch it at all through the delivery. This is another reason why I'm not taking an argument based on the impossibility of not watching the marker very seriously.

Under my scenario, you'd watch the ball, the bowler and the run-up the entire motion of the player right on to the bat. ...and that's not taking into account any other subtleties of perhaps, having the bowlers arm-movement change speeds to indicate faster/slower deliveries, so over time you can pick the "slower ball" or "quicker ball" with the animation of the action speeding up, slowing down ...just as one idea.

Well I agree that if you could present the data so it's visible purely from the bowling action and first instants of the flight, it would definitely be the better option. I've said before that being able to read line from arm position would be my first thought.

If I had to come up with the best objection to a pitch marker, it's that in real life you *just know* where the bounce point is and then adjust your focus there, rather than learning the location of the bounce point by seeing it. That is a fundamental difference in the process.

But obviously, you can't *just know* in a game. Either you have a graphical representation or a bell goes off for half volleys or your testes receive a shock for bouncers or whatever, so some loss of naturalism seems inevitable.

 

[grkrama]

Well I agree that if you could present the data so it's visible purely from the bowling action and first instants of the flight, it would definitely be the better option. I've said before that being able to read line from arm position would be my first thought.

was checking these out today

The batsman focus on the pitch almost instantaneously as the bowler releases the ball, other than blink mechanism, something other that can be looked at is the camera itself.

As of now the PRO cam and close cam have blind spots against full deliveries.

Upon ball release if the camera can focus on the area/length of the pitch were the ball is likely to pitch, that it gives a subliminal indication of where the ball is coming it will aid picking length as well the blind spots will vanish.

That couple with authentic bowler actions to pick the different type of deliveries and a slightly more visible seam would make it really good i guess.

This is just rough idea i thought on seeing those vids not entirely sure if its a good idea .. i will mess around withe replay cams later and see if a workable camera thats not too intrusive but at the same time can indicate pitch is available so can get a better idea if it will work.

 

[T.J.Hooker]

I never thought of moving the pro cam focus point. Not sure people would like more involuntary camera movement, but I really like the elegance of the solution.

More artificial, but I was thinking you could do a hud with just a short vertical line instead of a ring. So for instance, this hud would be telling you short, wide outside off stump :



The line would appear directly on the hand for straight, and the other side of the hand for legside, with further distance from the hand indicating wider deliveries.

 

[Biggs]

I'm not sure a line is the solution but that's a vastly better concept...

 

[dhump]

Matt, I can't speak for others but my expectation of skill level is follows :-

Minimum (0 bars) - The batsman should bat like Chris "Phantom" Martin, i.e. no clue which end of the bat he's holding and averages between 0 to 5
Maximum (Full bar) - The batsman is a reincarnation of Don Bradman and would be literally impossible to get out cheaply unless he gets a corker and averages in 80s or 90s
Bar half full (50% skill level) - The batsman averages around 30
Bar 75% full - The batsman averages in high 40s
Bar 80% full - Batsman averages close to 60
Bar 90% full - Batsman averages in 70s


Similarly for bowling my scale would be as follows...

Minimum (0 bars) - Bowler who doesn't bowl and would average in excess of 100
Maximum (Full bar) - Bowler who averages in teens a la Sydney Barnes
Bar 50% full - Bowler who averages in high 40s
Bar 75% full - Bowler who averages in early 30s
Bar 80% full - Bowler who averages in late 20s
Bar 90% full - Bowler who averages in early 20s

Again Big Ant's or other people's scale may vary but it should allow for every kind of batsman or bowler to be represented in the game. Currently there's no scale to get you batsmen who consistently average below 15, forget replicating Chris Martin or Danny "The Duck" Morrison. This is what people want to see, i.e. the skill levels and attributes should mean something. We have such a great player editor (DBC Academy) but it looks like it doesn't matter how you skill players, especially batsmen, as even a 0 skilled batsman is capable of flaying McGrath on a green pitch in the game.

This is very good and I always had this in mind but with implementation of batting and bowling from- + condition. I think I can post it in next edition thread with proper definition.

 

[blockerdave]

This is very good and I always had this in mind but with implementation of batting and bowling from- + condition. I think I can post it in next edition thread with proper definition.

it's not as good as you think, because it's far too simplistic. skills must be relative to the conditions and opponent.

associate cricket for example, isn't all scores of 75 all out, which the low batting skilling would imply. the fact is a player can score highly against players of similar skill, but struggle against higher skilled players. similarly a bowler might be prolific in county cricket, but lack the yard of pace or extra movement/variety to succeed in international cricket. the game should be able to model that.

 

[blockerdave]

which leads me to a follow up, to the conversations between @Biggs @T.J.Hooker @grkrama and others regarding HUD

I think some sort of possible slightly earlier indication of length and/or movement via a HUD, providing it keeps you watching the bowler, would be a good idea.

BUT, and it's a big BUT, the actual timing would be dependent on bowler and batsman's ability.

so, different batsmen perceive the length earlier or later than others (replicates real life); good swing bowlers can hide the indication and generate late swing, less skillful bowlers can't; spin bowlers can disguise deliveries better or worse than others as batsmen can read the delivery better and worse.

so, let's say the default length indicator is 0.5ms before delivery... the batsman's ability in picking up length would add a modifier that would make that earlier or later.

similarly, say the default movement indicator for swing is at delivery (when the human bower makes his delivery selection) so the bowler's skill/disguise modifier would potentially move that later, but the batsman's playing swing attribute would modify it to take it back towards delivery (appreciate it can't be earlier) or even later to reflect their skill/lack of it.

exactly the same with spin, i think the indicator can be earlier, since the human bowler makes their choice before delivery. this is equivalent to the batsman reading the grip. the bowler's disguise attibute can be plotted against the batsman's spin reading attribute to get a final timing for spin indicator.

 

[Biggs]

I think whatever it is too, it needs to be able to be toggled on or off as well... Given, I'm sure, but worth putting in writing all the same.

 

[blockerdave]

I think whatever it is too, it needs to be able to be toggled on or off as well... Given, I'm sure, but worth putting in writing all the same.

yes, but done properly, it would be such that actually you'd be losing something if you switched it off.

 

[Langeveldt]

This may be a far out suggestion, and I don't mean graphically (as that would look stupid), but is there scope for making the zone of contact smaller for tailenders when it comes to the bat hitting the ball? On instant replays I've seen some weird stuff with the ball morphing through the bat and edges with half the ball inside the bat. Does this suggest the actual invisible wall that hits the ball doesn't exactly replicate the shape of the bat? Could it be altered for different batsmen?

 

[T.J.Hooker]

This may be a far out suggestion, and I don't mean graphically (as that would look stupid), but is there scope for making the zone of contact smaller for tailenders when it comes to the bat hitting the ball? On instant replays I've seen some weird stuff with the ball morphing through the bat and edges with half the ball inside the bat. Does this suggest the actual invisible wall that hits the ball doesn't exactly replicate the shape of the bat? Could it be altered for different batsmen?

There is no collision detection or anything like that happening on screen, as far as I know. They don't swing a virtual bat of certain dimensions at a virtual ball and then work out the outcome. They work out the outcome by processing user input (timing / shot choice / footwork) versus delivery characteristics, and then they produce a graphical representation of that outcome.

If I was designing my ideal batting sim then I'd want the act of aiming the bat at the ball to be under the user's control if at all possible (my best guess is using mouse and a crosshair to aim the swing at a contact point), because that's the really important bit of batting, and in that case yes, increasing or decreasing the size of the bat's collision area would be a good way of simulating different batting abilities.

 

[Dutch]

There is no collision detection or anything like that happening on screen, as far as I know. They don't swing a virtual bat of certain dimensions at a virtual ball and then work out the outcome. They work out the outcome by processing user input (timing / shot choice / footwork) versus delivery characteristics, and then they produce a graphical representation of that outcome.

If I was designing my ideal batting sim then I'd want the act of aiming the bat at the ball to be under the user's control if at all possible (my best guess is using mouse and a crosshair to aim the swing at a contact point), because that's the really important bit of batting, and in that case yes, increasing or decreasing the size of the bat's collision area would be a good way of simulating different batting abilities.

On this note i would love to see a twist mechanism that determines the angle of the bat blade...not sure how it could work but would add a new dimension to intuitive play...