5

In relation to this answer about the "English" control of the Magnavox Odyssey, I am wondering if the concept found its way into other games for later computers and consoles that supported paddle controllers, and, perhaps, even took some inspiration from this Odyssey feature. Most of the early systems from Atari, Commodore, Apple, and others supported both joystick and paddle controllers, with the paddles being most appropriate for paddle-style games like Pong, Breakout, and the various derivatives.

It is a rather natural UI concept to support "English" (e.g. imparting spin) in these sorts of games by simply rotating the paddle left or right, swiftly, just as the virtual paddle collided with the virtual ball on screen. This would be used to modify the ball's trajectory "in-flight" or following a "bounce", as can be done with spin in billiards, tennis, pickleball, and other "real-life" games where implement is used to strike ball.

Were there any early computer games known to support this style of input from a paddle controller?

enter image description here

8
  • 1
    How early is early? Various PC Breakout-style games from the early 90s supported this, using mice rather than paddles. Incidentally, in real-life sports spin can be imparted using only hands or feet, no implement needed ;-). Sep 16 at 18:39
  • 1
    @StephenKitt I'd encourage earlier examples from the late 70s to mid-80s when paddle controllers were still prevalent and a mouse would have been a real novelty.
    – Brian H
    Sep 16 at 18:41
  • 2
    Brick Out for the Apple II, which was designed for paddles, said in its instructions YOU MAY "PUT ENGLISH" ON THE BALL (DEFLECT THE BALL) BY HITTING IT WITH THE PADDLE HELD OFF-CENTER, but that's position, not speed, and it doesn't appear to curve the ball's path in flight.
    – benrg
    Sep 16 at 19:23
  • @benrg While I was thinking of something more advanced than just modifying the angle of deflection off the virtual paddle, your description of Brickout is at least relevant, especially since the author even refers to it as "English".
    – Brian H
    Sep 16 at 19:41
  • 2
    @JimNelson the one on the right is one of those TV "Plug and Play" things from the last decade or so; it isn't a vintage Atari paddle so your memory is not at fault here :-)
    – bjb
    Sep 16 at 20:28
2

I'd say none, as there was no standard controller element to do so. Paddles allow only one value to be inputted (plus some button) but adding a spin would requite another value with multiple digits plus sign (direction).

Of course and as usual, it's next to impossible that something didn't exist.

The situation is of course different using other methods of input - like keyboard.

10
  • 5
    You don’t need anything additional in the paddle: on top of the classic deflection calculation, you check whether the paddle moved while the ball was colliding with it, and add an appropriate effect if so. With mice-based Breakout-style games, the common result was to adjust the angle further, allowing the player to flick the ball by flicking the mouse at the exact moment the ball hit the paddle; that would also be possible with a physical paddle. Sep 17 at 14:02
  • 1
    Yes, it wouldn’t be all that easy to use ;-). At least on 8-bit Ataris it would have been implementable — the paddle position is updated 60 times a second. Sep 17 at 14:29
  • 1
    @StephenKitt: The act of reading paddle inputs is a fairly long process, which involves timing how long it takes for capacitors to charge up through the paddle resistance. On the Atari 2600, this process is triggered manually by user code, which must then poll periodically to determine when the capacitors have charged. Are the POKEY's polling cycles triggered under the control of the VBL, or do they run autonomously?
    – supercat
    Sep 17 at 16:43
  • 2
    @supercat I know how it works on the 2600, I’m not 100% sure of all the details with POKEY. The start of the POT counts is triggered in the VBI routine as far as I’m aware, and the OS watches for the process to complete and then updates the shadow registers. As you say it takes a while to run, so the position can’t be checked more than once per frame. Sep 17 at 17:07
  • 3
    You don’t really need a good instantaneous measure of velocity though; you could probably use something like the difference between player position when they hit the ball and player position three frames later and get away with it — players aren’t that precise either. Though that’d be more like Sensible Soccer-esque aftertouch; I’d be very surprised if such a thing were implemented so early, regardless of feasibility.
    – Tommy
    Sep 17 at 17:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.