Ive currently got time implemented in my cooldownBar class, which is a simple cooldown bar that when it needs to be drawn adds the current delta time to a timer that i have inside the object and when the timer gets to be greater than the set time it stops drawing the object.
That's more or less how I would do it. Are you happy with how the cooldown bars have been performing, other issues aside?
However when i implemented that i ended up removing the 60fps restriction i had placed in the game, and that then fucked up my player movement(because now if saw W is pressed every time the game loops he moves, which makes him rocket off into the sunset). so now im just looking for suggestions on what i should do, or rather how to implement time into my game so that i can fix this, and also try to prevent further problems related to time in the future.
This sounds more like an input problem to me-- it worked at 60fps, but arbitrarily, and there isn't sufficient input state or game object state checking to handle anything else. You could use an enumerated state member in your Player class to prevent "doubling up" on actions:
// Somewhere else in your project...
public enum PlayerState { Nothing, Jumping, Ducking, Blocking, Attacking }
//
public partial class Player
{
#region Fields
PlayerState currentState;
...
#region Methods
public void HandleInput(InputKey theKey)
{
if (theKey.Code == Keys.Spacebar)
{
// If the player is ready to jump (i.e., not jumping right now) then initiate a jump. Otherwise do nothing.
if (currentState != PlayerState.Jumping)
Jump();
}
}
private void Jump()
{
currentState = PlayerStates.Jumping;
// Whatever physics/movement code you have defining a jump goes here
// When the player lands, set currentState back to Nothing
}
}
You can also adjust how frequently the SFML window will interpret a held-down key to be pressed (sort of like simulating a KeyPressed event if isKeyPressed == true after a certain amount of time has passed), or use object states to deal with the input however much time has passed (like with jumping above-- if the player is jumping, no additional jump-inducing input is considered).
I think I've interpreted your issue correctly, but if not then it might help to post the code that isn't behaving as you intended.
