Game Mechanic Explorer – examples for game mechanics, algorithms, and effects | Hacker News Reader

Game Mechanic Explorer – examples for game mechanics, algorithms, and effects

gamemechanicexplorer.com

404 pointsdavidbarker42 comments

I tried my hand at a side scrolling platformer in phaser myself some time back.

When I came up to variable jump height I tried a solution very similar to the one presented here, but I just could not get my jumps to feel at all "right". Jump height that's modulated by initial or continued velocity feels weird and floaty and a bit hard to precisely control.

I finally broke down and found a detailed analysis of the physics maths used on the original Super Mario Bros. I discovered to my surprise that variable height was achieved SMB1 by temporarily reducing gravity during the time the button was held down, capped by a time limit. Using this rule, jumps feel very solid precise and look more realistic than the image of a character with a continuously firing rocket under its feet.

So altering the acceleration rather than the velocoty gives more natural results? I wonder if our brains are good at first derivatives, but nothing beyond, so a discontinuity or warp in acceleration is less noticeable. SMB1 does have fantastic variable jump height.

I think it's that, regardless of the "strength" of your jump, the curve is always fast at first, then slowing against gravity following a natural quadratic-ish curve.

So strong jumps, and weak jumps both always look like the first "push" happened at the very start.

As I said before, the velocity approach looks a bit more like the character has a jetpack, and is rocketing into the air. That is, the accelleration is slow. then fast, then slow again (as gravity takes over). Instead of just fast then slow.

re:perception, derivatives, and discontinuities. I think you are right. In bezier curves, discontinuities are numbered according to which derivative the discontinuity occurs in. So if you draw a straight line with a corner in it, in adobe illustrator, that's a c0 discontinuity. A curved line, where the control points for the curve after the vector are the same angle, but different lengths are a c1 discontinuity (but c0 continuous), and so on.

It's useful to number these, but c0 continuous "looks" smooth, always.

edit: sorry, I've misnumbered these. I should say that g1 continuous always looks smooth.

http://www.clemson.edu/ces/credo/AID/ACIS_HELP/HTM/DATA/ACIS...

The jump algorithm I've used for a long time(and cribbed from an old co-worker) uses three variables, going to a second derivative: velocity, acceleration, and "power." The first two are pretty explanatory, the third is applied to acceleration and decremented each frame to a minimum of 0, and is instantly zeroed when jump is released early, allowing gravity to start pulling down acceleration. (Acceleration is also usually zeroed at release for a tighter top.)

Tuning these has let me reproduce pretty much any controllable jump arc - for example, the jump in Metroid has a lot of "float" to it at release time. This is doable by making acceleration at release equal to inverse of gravity.

In physics, the name for what you call “power” – the derivative of acceleration, and the third derivative of position – is “jerk”. https://en.wikipedia.org/wiki/Jerk_%28physics%29

I came up with the same thing a while back. I was hacking on a side-scroller and spent a lot of time trying to get the feel right. The detailed explanation:

To start a jump, the user presses the jump button while the character is standing. There is a "grace period" where you can still jump if the character isn't on the ground now, but was a few frames ago. This is important to be able to jump right as the character reaches the edge of a platform. Without this, you have to jump earlier than you feel you should.

Once a jump has started, we track how long the jump button has been held down. Every frame, the character's Y velocity is modified by the "jump acceleration". This acceleration starts at some high value, and ramps down linearly the longer the jump button is held down.

For example, the first frame of jumping may add -10 to velocity, then -8, -6, -4, -2, until finally zero. I found this acceleration ramp was the key to getting the jump to feel snappy yet responsive. The first frame gives the biggest velocity boost, so the character immediately leaps into the air. Then later frames give a diminishing effect so that you can more precisely dial in how much oomph you want the jump to have.

Gravity is then applied on top of this. In code, it looks like:

    // Start jump.
    if ((Actor.LastOnGround <= JumpAllowedFrames) && UserInput.JumpHeld) {
      jumpFrames = 1;
    }

    // Accelerate upwards while holding jump button.
    if (jumpFrames > 0) {
      velocity.Y -= JumpSpeed * (MaxJumpFrames - jumpFrames) / MaxJumpFrames;

      if (!UserInput.JumpHeld) {
        // Stop accelerating if player releases button.
        jumpFrames = 0;
      } else if (jumpFrames >= MaxJumpFrames) {
        // Can only accelerate for so long.
        jumpFrames = 0;
      } else {
        // Keep jumping.
        jumpFrames++;
      }
    }

    // Apply gravity.
    velocity.Y += Physics.Gravity;

I was really happy with how this turned out. Actually, now that I dig into this several-year-old code, it kind of makes me want to resurrect the project. :)

I think when you're talking about a stocky plumber jumping several times his height without even bending his knees, you can discount the idea of the brain finding this movement natural.

You just need to make sure your rocket is providing less than 1G of accel and then it is the same as lowered gravity.

I've seen some great talks by the amazing game designer, Shigeru Miyamoto.

https://en.wikipedia.org/wiki/Shigeru_Miyamoto

In an earlier talk, he explained that he designed his games starting with how you physically interact with the controls you're holding in your hand, and then inwards into the computer, instead of the other way around like so many other people tend to do.

In a later talk, about the Wii, he explained that now he designs his games starting with the facial expressions of the people playing them, then to the physical experience that could evoke such an expression, then on into the computer that could conduct such an experience.

As an example, he showed a picture of a grandfather with his granddaughter sitting in his lap, playing a game, looking totally entranced and delighted at the game, and her grandfather looking at her, with just as entranced and delighted an expression as on his granddaughter's face, even if he didn't necessarily understand what the game itself was about. He got so much enjoyment out of just watching his granddaughter enjoying the game, that it was fun for him, too.

The Wii was so successful as a social party game, because the players themselves were more fun to watch than the game on the screen, because they make spectacles of themselves, which is much more entertaining to watch than the computer graphics. And you don't get bored waiting for your turn to play, because it's fun watching other people play.

Those are great insights.

I'll add that many games don't understand "the reveal." They simply rely on "the experience." iow, Sure, it's great to be an astronaut zapping meteors, but it's not great to instantly and always be that astronaut. It's best to earn the ability in several large strides.

oh hi Don Hopkins. I KNOW WHO YOU ARE! welcome to whatever is left of Hacker News.

Do you have link? As someone who's written 8bit platformers and effectively "copied" Mario's feel I didn't have to lower gravity to achieve a similar feel. I just set velocity while the button is held. There's no reason to lower gravity.

Mario is an 8bit game. There's no "real physics" in it. They aren't "applying a force to a mass". They're just adding an acceleration (gravity) to a velocity and that to a position.

here is a link. http://s276.photobucket.com/user/jdaster64/media/smb_playerp...

>> As someone who's written 8bit platformers and effectively "copied" Mario's feel

I'm not sure that's the feel I would shoot for. SMB 1 feels very odd, I'd try to mimic Super Mario 3 or Super Mario World.

These are not game mechanics.

http://en.wikipedia.org/wiki/Game_mechanics#Game_mechanics_v...

(Cross posted from another reply I made:)

Asteroids-like spaceship movement is not a game mechanic. Shooting bullets is not a game mechanic.

A game mechanic would be the system that is the feedback loop of moving to chase/avoid asteroids while shooting them and creating more and faster obstacles and targets.

Will you are probably technically correct, it would be helpful if you could explain what they are instead. Because they're a bit more than just applied physics - the choice in jumping mechanics has a fundamental influence on gameplay, so there is at least some kind of relation to game mechanics.

You can look at it like this: mechanics are abstract, while gameplay is concrete.

The gameplay is what the player can actually do at any given point in the course of the game: move a piece, make Mario jump, shoot a gun.

Rules define both the valid inputs and the reaction of the game to player input: you can't walk through walls, monsters drop loot, XP lets you level up.

Mechanics are the higher-level constructs resulting from the feedback loops created by the game's rules, in reaction to choices that the player makes.

The example of Asteroids:

The gameplay is moving a spaceship and shooting asteroids.

The game rules state that you progress to the next level by clearing all of the asteroids from the screen. When you shoot a larger asteroid, it breaks into several smaller pieces. When you shoot the smallest asteroids, they disappear. Colliding with an asteroid means you lose a ship, and losing all of your ships means you lose the game.

The mechanics that result from this are evading the asteroids on the screen, judging the risk of shooting each particular asteroid, choosing the right place to be and the right time to shoot, allowing you to stay alive to eliminate them all.

Yes, it is more like these are examples of the building blocks that you build game mechanics around.

It is interesting that the author of the page calls them "examples for game mechanics" not examples of game mechanics, so he may be in agreement with you.

Nice stuff. I noticed something slightly weird in the "Spaceship motion / With drag" example. Looking at the code it seems that drag is applied individually on the X and Y axis. If you rotate the ship just a little bit, gather some speed and then let go, the ship will have its horizontal speed zero out rather quickly and the ship will glide sideways until it comes to a halt in the vertical direction.

Can't write more now, need to go play with the other examples!

"drag" seems like a bit of a misnomer for what that parameter is doing - the effect on x and y velocity is calculated separately, so you're always going to get the little "twist" at the end when velocity on one axis drops below the drag value.