Lovely Supertux

[snake]

I wondered if there is a real reason for using love.physics for Supertux or Mariostyle games and so i made a small demo that is NOT using love.physics.
I think it might help people who want to make such a game to get an Idea on how to do it.
There might be some nicer solutions (i did not really spent much time working on it) so feel free to edit it and post your version.

Features:
- no Box2d
- simple
- under 100 lines

(What is wrong with Box2d?
Nothing, i just don´t think it is a good choice for this type of game)
Tested with Love 0.6.1!
I might make a more complete demo but on the other hand then it might grow over 100 lines so not sure.

(images used are all from the original Supertux game)

[Robin]

I wondered if there is a real reason for using love.physics for Supertux or Mariostyle games

There is rarely a reason to use love.physics.

The physics in your little demo are a bit flaky though.

[snake]

The physics in your little demo are a bit flaky though.

Flaky?

[Robin]

Well, not flaky, but I can't find a better word.

In more words then: they feel unnatural, uneasy, somewhere between sluggish and jittery, instead of smooth and responsive.

[Jasoco]

A real Mario-style sidescrolling engine that feels exactly like the 2D sidescrollers of the NES and SNES days is like the holy grail for Löve. I've tried my own hand at it and failed but one day someone will succeed.

Also, you are right. Box2D is not proper to use for these things. Physics in a sidescroller should be game-y, not realistic and physics in any Box2D program just feels too floaty and fake when you compare it to the real thing. People try to use Box2D because it's convenient, but it is just not the right device to use in these cases.

The original Mario's engine was buggy, (The Minus-world was created due to a bunch of bugs all working together) but it still worked. Every Nintendo sidescroller since then has gotten more and more refined. It all takes practice and years of perfecting the art.

Maybe we should ask Pixel, who created Cave Story, or the guy who did Knytt Stories, or even the I Wanna Be The Guy! programmer. Or you could pay $2500 and buy the code for Power Game Factory and see how it does it.

[sauer2]

In my opinion, Mario physics works similar to following:

Y-acceleration isn't calculated, you have something like 3 fixed velocity rates for running, walking and stopping running.
Let's say 1 Pixel for two game loop cycles, 1 for one game loop cycles and 2 in a gameloop cycle.

Same with jumping, if you press A on the Gameboy Color (or the NES, or the simulator button), you'll notice Mario flies up with constant speed from the beginning for a long time (along with the 'keeping the button pressed' check). After this time there is a short part that simulates the loss of the most speed.(about 1 block size) A very short stopping part. And then Mario falls with nearly constant speed, althought I'm not sure if there is a short beginning part to simulate downwards acceleration.

Don't ask me how to handle this in combination with different cpu speed, this is another road.

[Robin]

Don't ask me how to handle this in combination with different cpu speed, this is another road.

dt?

[sauer2]

dt is delta time?
Well, from what i found on big G, multiplying the delta time with the movement should work.

[Robin]

That is the standard way to make a game CPU/fluctuation independent, so yeah.

[sauer2]

I knew, but I never figured out before how this should work. So I didn't use these before.