Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Sunday March 03 2019, @11:23PM   Printer-friendly
from the Blinky,-Inky,-Pinky-and-???? dept.

Pac-Man: The Untold Story of How We Really Played The Game:

Released in America in October 1980 yet arriving in arcades closer to late November, Pac-Man rolled in like a guest at the wrong address. Since America was right in the middle of “the shooter craze”, when the competitive gaming scene was focused exclusively on mastering difficult multi-buttoned games, Pac-Man’s debut quite literally looked like a birthday party arriving on the front lines of World War III. Aesthetically, it didn’t fit in. Although some people migrated to it quickly, the press paid it little attention until full “Pac-Mania” finally hit in the Summer of 1981, its shift from a fad to a full-blown craze delayed by a historically brutal sub-arctic winter in many parts of America which kept millions of grade school gamers out of the arcades until things warmed up.

[...] If it’s been a while since you played Pac-Man on an original arcade game cabinet, let me refresh your memory:  Put in your quarter, hit the one-player button and grab the joystick. All you have to do is move Pac-Man through a series of tight cornered mazes, trying to eat all the dots and fruit on screen while also trying to out-maneuver a group of ghosts who will kill you as soon as they touch you. If you eat one of the energizer dots, though, you’ll have a short period of gameplay where the ghosts slow down and stop chasing you so you can eat the ghosts and pick up extra points. But something else happens, something I’ve never seen anyone ever mention in any article or video before.  It’s a physical response and it always occurs by the time the player reaches the second screen…

Pac-Man is more of a driving game than a maze game. As you’re playing, you’re jamming that joystick left  and right, up and down, movements that shifts your right shoulder forward and back, rocking your body side to side. When the going gets tough, and the ghosts start closing in, all of this rocking motion compels you to lean into the game and, whether you realize you’re doing it or not, you’re going to grab onto the game.  You actually need to get a grip…on something. You’re either going to lean hard against your left palm as it rests on the control panel which isn’t comfortable for very long or, like most people, you’re going to grab the side of the game and hold on tight.  You have to or you’ll lose your balance. You can’t take the sharp corners smoothly and quickly without doing this, ether. You need the extra stabilization to move Pac-Man around the corners accurately.

It's one of those things that I never thought of before, but seeing it pointed out, it seems obvious in retrospect. (The linked story has a plethora of pics showing the left-hand death grip. Get a load of the fashions back then, too.) I wonder how many other "obvious" things happen each day that I also fail to notice. Also, I rarely got past the second screen; how well could YOU play?


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 5, Interesting) by el_oscuro on Monday March 04 2019, @01:51AM (5 children)

    by el_oscuro (1711) on Monday March 04 2019, @01:51AM (#809647)

    ... Except I never played Pac-Man. Instead I played Tempest and Asteroids.

    At least in the arcade. At home my Dad got a Heathkit computer for his work. I asked him I could play video games on it. He said: "If you program them yourself". So I did. A VT100 terminal with primitive ASCII graphics with a 9600 baud modem and 8080 assembly language. Asteroids or tempest was completely out of the question. But Pac-Man with the only objects moving were the monsters and the player, it was possible.

    First challenge was having to keep a separate copy of the level in memory to detect walls and collisions, as the state of the dumb terminal couldn't be accessed by the program. Second challenge was the 9600 speed - it was only fast enough for 2 monsters instead of the usual 4. So I had to make my monsters bad assed. I initially set them to always try to follow you but they became trapped in certain parts of the maze. So I needed a random generator, which my dad helped with, but I coded. Now my monsters could chose a random direction at any intersection, or chose one of the available ones instead of getting trapped. I also slowed the player when eating dots and sped him up when not, just like the arcade game.

    The final challenge was control and scoring. Originally, I had it so you would try to turn the direction when the key was pressed. But that would stop you if you weren't quite lined up with the intersections. This was really clunky and affected play - I needed it to work like the arcade one. So I set it to "save" your last keystroke and turn a the first possible chance. That really brought the game play up to arcade standards. But I still needed to work out scoring. Doing decimal arithmetic in 8080 assembly was *hard*. So I did ASCII arithmetic, basically using a process identical to the mechanical counters that 1970's pinball machines used.

    And that game worked - those 2 monsters were totally on the players ass.

    Oh, and I learned assembly language and other skills which I use today.

    --
    SoylentNews is Bacon! [nueskes.com]
    Starting Score:    1  point
    Moderation   +4  
       Interesting=4, Total=4
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5  
  • (Score: 4, Interesting) by Pino P on Monday March 04 2019, @01:26PM (4 children)

    by Pino P (4721) on Monday March 04 2019, @01:26PM (#809763) Journal

    You were programming a game with multiple enemies on an 8080, whose ISA is largely a refactor of that in Datapoint programmable terminals. The challenges you may have faced resemble challenges faced by modern-day Game Boy homebrew game developers once they realize how weak the 8080's [HL] addressing paradigm is at reading and writing fields of structs [gg8.se]. Did you have any special trick for efficiently accessing numerous properties of a particular enemy? Zilog did add [IX+offset] addressing to its Z80, but Sharp didn't add [IX+offset] to the Game Boy CPU, making it handle more like an 8080 in this respect.

    • (Score: 2) by el_oscuro on Monday March 04 2019, @11:51PM (2 children)

      by el_oscuro (1711) on Monday March 04 2019, @11:51PM (#810054)

      Interesting link. I didn't actually use any structs at all and had no special tricks. The screen was 80x25, so x/y and direction for both monsters and player, and last key pressed, all single byte variables.
      Plus the score (as actual ASCII digits), and a 2k character array for the playfield.

      That is pretty much it.

      --
      SoylentNews is Bacon! [nueskes.com]
      • (Score: 2) by Pino P on Tuesday March 05 2019, @06:45PM (1 child)

        by Pino P (4721) on Tuesday March 05 2019, @06:45PM (#810356) Journal

        so x/y and direction for both monsters and player

        There are two ways to organize that.

        Array of structs is common on machines whose indexed addressing mode is a small constant offset from a big (16-bit or more) variable pointer, such as Z80, 68000, and MIPS. It puts each entity's properties one after another:

        X for enemy 1, Y for enemy 1, direction for enemy 1
        X for enemy 2, Y for enemy 2, direction for enemy 2
        X for enemy 3, Y for enemy 3, direction for enemy 3
        ...

        Structure of arrays is common on machines whose indexed addressing mode is a small (8-bit) variable offset from a large constant address, such as 6502, and in BASIC dialects without structs. It puts each property in a separate array, where the properties of one entity are found at the same index into each array:

        X for enemy 1, X for enemy 2, X for enemy 3, ...
        Y for enemy 1, Y for enemy 2, Y for enemy 3, ...
        direction for enemy 1, direction for enemy 2, direction for enemy 3, ...

        Which did you end up using?

        • (Score: 2) by el_oscuro on Thursday March 07 2019, @12:56AM

          by el_oscuro (1711) on Thursday March 07 2019, @12:56AM (#810952)
          No special organization.  Just single byte variables.  It has been almost 40 years, but it was something like this:

          pl_x:   db    0    ;Players x position
          pl_x:   db    0    ;Players y position
          pl_dir: db    0    ;Players direction 0-up,1-down,2-left,3-right
          m1_x:   db    0    ;Monster 1 x position
          m1_x:   db    0    ;Monster 1 y position
          m1_dir: db    0    ;Monster 1 direction 0-up,1-down,2-left,3-right
          m2_x:   db    0    ;Monster 2 x position
          m2_x:   db    0    ;Monster 2 y position
          m2_dir: db    0    ;Monster 2 direction 0-up,1-down,2-left,3-right

          lstkey: db    0    ;Last key pressed
          score: db    '00000'    
          --
          SoylentNews is Bacon! [nueskes.com]
    • (Score: 2) by el_oscuro on Tuesday March 05 2019, @12:03AM

      by el_oscuro (1711) on Tuesday March 05 2019, @12:03AM (#810057)

      If you are into old school game development, you might want try fixing the Atari 2600 ET [neocomputer.org] game using the Stella Debugger [github.io].

      --
      SoylentNews is Bacon! [nueskes.com]