Short notes on a future cricket game
Russell Degnan

All cricket on the computer is crap. Most are worse than crap.

The best, occasionally give some semblance to a real game, before screwing you with a riot inducing lbw or ridiculous close in catch. Those few have been known to have fun batting controls, but none of them have ever had anything remotely resembling the nature of batting. And most make you wonder if the programmer really put soem thought into the interface design before cobbling together the graphics and other incidental add-ons.

The bowling controls are always an order of magnitude worse than the batting ones.

But why today's rant?

Mostly, it is inspired by what might have been. Games are a good rest break from perpetual reading, and flash games are suitable short to suit that break. Pinch Hitter 2 is good for that, resolving the slightly bizarre scoring discrepancies and pointlessness of Pinch Hitter 1, and hitting that nice balance between gaining successful control of your destiny and its enemies: difficulty and luck.

It also has a nice, simple interface, you click the mouse when the ball goes past. Subtly changing the position and timing allows you to direct the ball into different zones, and over different distances. Not easy, but possible. A sure-fire recipe for a successful game.

So, if mousebreaker can make a pretty decent baseball game, then surely they can make a decent cricket game based on the same principles?

Not remotely. As with most cricket games, they make two fundamental mistakes.

The first is to assume that batsmen hit a cricket ball, instead of stroking it. Thus, the game involves precise timing, to anticipate the moment the ball passes the batsman, and to hit it. If cricket were actually played like that, then everyone would bat like Brendan McCullum or Vivender Sehwag: swinging at every ball and trying to belt it to or over the fence. And indeed, in every cricket game I've played, that tactic is invariably the best employed, because, in a game based purely on timing, timing it over the fence is at least as good a strategy as timing it along the ground.

The second is to assume that because batsmen play different strokes, they need different controls. Thus, we have the ubiquitous three-key control: one for pulls, one for straight drives, one for cuts. No mention of the subtler (and for me, most prolific strokes): the leg glance, the glide, the square drive, or the tuck into the leg side - not to mention the hoik! Some developers have worked around this by using the foot placement as a proxy for direction, which works to a degree, but in doing so they lose the ability to distinguish between say, a well timed square drive, and a missed straight drive.

Batting is not just about choosing a stroke and hitting the ball. Under these systems a player has no control of the shot, being no more than a baseballer with three swings. There need to be greater subtleties of foot movement, back, forward or across, of stroke-play, and of the wrist that allows both placement and creativity of stroke.

Foot movement is too often simplified into a strange hovering shuffle around the crease. It needs to be considered as either a back foot, or a front foot shot, rising, or getting over the delivery, and made sharper, to allow the batsman to get further across, or out to a ball, instead of the perennial no-mans land you often find yourself in, should you be trying to play somewhat sensibly.

Stroke play needs to be recognised as being predominantly about the line of the ball, to allow proper defensive and worked strokes to flourish. Most sensible cricket shots are low risk, because you can play them at any time, and then wait for the ball. It is only the bludgeon and the flourish that requires timing and skill, which is why, at many levels of cricket, you don't see the latter at all.

Hence, my aim here is to note a better control mechanism, in the hope that one day I might have time to implement it, or if not, then someone else might perchance upon it.

Firstly, the aim should be to reintroduce the bat as the mechanism of contact, by taking our lead from baseball. There, the bat is contrained by the pitchers box, but there are multiple possibilities. From outside off-stump a low shot would aim a square drive, a higher one a cut, or upper cut. From nearer the feet, a drive, or whip off the pads, and from higher, various pull, hook shots, or back foot drives. This is mouse contolled, aimed at a specific point past which the ball will travel, and from which (based on the timing and arc of the shot) will derive information on whether the ball was centered or edged.

Secondly, foot movement, based on the keyboard will allow the player to go forward, back or across in line with the ball. Ending at the point where the shot begins to be played.

Thirdly, the shot should be in two parts. On pressing and holding the mouse button, the arc of the shot and placement of the feet is set. This allows the player to get into position early, and play a defensive stroke down the line of the ball, without needing to time it, as such.

Fourthly, while holding the button, changes in mouse position will direct the shot. Pulling back giving glides or glances, forwards a drive, and left or right to pierce the field. More aggressive mouse movement makes a harder shot.

Finally, on release of the button, the shot should be played, giving a timing point. Holding the button down plays a block. Holding, then releasing on contact allows a glide or glance. Lofting the ball would involve hitting under the ball, using power, then timing to get it on the center (or if unsuccessful, straight up).

Controlling the player properly would take practice, which should always be the aim, but the controls are also simple, involving just the mouse and keys until the player adjusts to timing and direction. But, fully enabled, any shot could be attempted and controlled.

Frivolous Pastimes 19th May, 2008 17:38:02   [#]