player controls in love.update vs. love.keypressed/released

[T-Bone]

The point is that you never want to stop or change something after a specific amount of game ticks,THAT would lead to problems on computers with different frame rates. If you use dt properly, you have none of those issues.

Instead of doing something after three game ticks, add up dt in a variable and see when 0.2 seconds have passed instead. Seconds are (almost) equally long on all computers, game ticks aren't.

Also, you make it sound like it's harder to do things with dt than without, I'd say it's the exact opposite.

[oilyeye]

Kikito's method makes a ton of sense to me, but here is what I've been doing so far:

I populate a table called Commands with an action (or direction) and the associated key, then stick that somewhere in an easily modifiable area of game options. Then in my love.update(), I do a for loop through that table checking isDown(referencing the values) at the top and set a boolean for each one. Then the rest of my update functions just evaluate those to decide what to do.

[T-Bone]

Kikito's method makes a ton of sense to me, but here is what I've been doing so far:

I populate a table called Commands with an action (or direction) and the associated key, then stick that somewhere in an easily modifiable area of game options. Then in my love.update(), I do a for loop through that table checking isDown(referencing the values) at the top and set a boolean for each one. Then the rest of my update functions just evaluate those to decide what to do.

That sounds good. You can let "keypressed" put stuff in the table as well, instead of only using isDown.

[Username]

The character in your computer moves at 5 pixels per game tic, so if you need to stop movement at pixel number 3, you simply can't.

That is extremely fragile and I wouldn't recommend designing your game like that.

What does that mean exactly?

[T-Bone]

The character in your computer moves at 5 pixels per game tic, so if you need to stop movement at pixel number 3, you simply can't.

That is extremely fragile and I wouldn't recommend designing your game like that.

What does that mean exactly?

Game tics are unreliable. Their length in time will be slightly different every time the game is run, even on the same computer. And on different computers, the difference will be even larger.

If you code your game behaviour to depend on how long a game tic is, the game will play differently on different computers and/or occasions. That's bad. It can, in a worst case scenario, mean that the game won't work at all on my computer even though it works on yours. And there's no easy way for you to know that.

On the other hand, if you use dt, and measure real time instead of counting game tics, your game will run almost exactly the same every time, on every machine.

[Robin]

Plus relying on exactly the right position measured in pixels. It's incredibly easy to mess up and even if you don't, a bug somewhere else in your game could break your game because of it. (If you assume the player will never reach pixel 392, because at pixel 391, you turn them around, you still have a problem if due to some bug you suddenly move two pixels instead of one or something. If you had checked for >= 391 rather than == 391, it wouldn't have been a problem.)

[Username]

Plus relying on exactly the right position measured in pixels. It's incredibly easy to mess up and even if you don't, a bug somewhere else in your game could break your game because of it. (If you assume the player will never reach pixel 392, because at pixel 391, you turn them around, you still have a problem if due to some bug you suddenly move two pixels instead of one or something. If you had checked for >= 391 rather than == 391, it wouldn't have been a problem.)

No, no.. I think I didn't explained well.

What I mean is that if the game character amount of movement depends on the computer speed, then the character will move different amount of distances in different computers.

Lets say, we create a game like Quake, where we can jump over pits full of magma.

Now, we implemented a movement based on dt, like posX = posX + speed * dt.

When the player dt is high, his movement amount will be bigger, so for example, he may be moving 7 game meter per key press instead the supposed 5 or 3 or 1 or whatever the game is designed originally.

If he needs to jump over a pit of lava that starts at meter 10 and ends and meter 15, then he can't jump over it because he either steps in meter 7 and jumps to meter 14 falling to the lava, or he walks directly into the lava.

So basically, if the amount moved depends on dt, then pressing the key the same amount of seconds will result in DIFFERENT distances moved.
And this doesn't affect only the amount of movement. This affects the collisions because some objects that may be in the path blocking the movement, if the object is at meter 10, but the player moves 7 meters each step, then the player may never get closer than 3 meters away from that object (10 - 7) because if he moves beyond meter 7, he would be trespassing the wall, so basically, the collision is happening where it is not supposed to happen.


And this never happens when using love.keypressed. Even when low dt, if I press the key during 2 seconds I will move always the same distance if my dt is 1000 or 0.0001.

[Robin]

If you want to work with key presses instead of key holding, you shouldn't move the player for a single frame, you should use a timer with a fixed duration (for example .5 seconds), and move the player each frame while the timer hasn't run out.

So basically, if the amount moved depends on dt, then pressing the key the same amount of seconds will result in DIFFERENT distances moved.

If this is the case for you, you're using dt wrong. If you upload a .love, I could take a look at it for you, and give a suggestion for how to fix it.

[micha]

So basically, if the amount moved depends on dt, then pressing the key the same amount of seconds will result in DIFFERENT distances moved.

This is not correct. If you use dt properly, then the following happens: A small dt means that in each frame the player moves only by small steps, BUT at the same time, a small dt means that you have many frames per second. A large dt means each frame the player moves by large steps, but also you have fewer frames per second. Together these two effects cancel each other out.
As a result on both computers the player will move at the same speed in terms of "pixel per second" (NOT pixel per frame).

As a side note: There are cases, where you need a certain fixed frame rate (but this is not the general case). Namely if you need to reproduce a certain behavior. Depending on what sort of integration rule you use, the outcome of a simulation is slightly different. If you need to guarantee that you can reproduce a certain outcome, then you need to fix the frame rate. This is not done by using keyrepeat, but according to this article, see section "free the physics". I want to point out that no game I ever worked on, really needed this.