1
\$\begingroup\$

I have been developing a game and until now I have been handling input like so:

  1. Player presses a key
  2. HandleInput() acknowledges a key is pressed calls a function within the Player class which increments the Players position by a pre-determined amount.
  3. Update() sets the players sprite to be at the players position.
  4. Draw() renders the players sprite.
  5. Return to Step 1.

Now my question is this, should I continue to run my loop in this way or should I implement the following:

  • HandleInput() sets a state within the Player class which when Update() is called the Player object checks if it is in a state of motion and updates its location appropriately, before updating the sprite to its new location.

This question arose within me while I was altering my loop so that only the Update() function had a maximum refresh rate (60 cycles per second) and I realized I was unsure how I should appropriately communicate events to the objects on how they should act.

I did not include any code as we're discussing in pseudo-code if you feel some is required let me know.

\$\endgroup\$

1 Answer 1

0
\$\begingroup\$

The second possibility seems better, for two reasons:

Each part does have its own job.

The Update function should have every sprite movement handling, while HandleInput should only listen input and tell Update what to do.

Give more possibility

Imagine that you would want to give some inertia to your player. The code to make it move would become more complex, maybe something like that:

const sf::Vector2f& movement = player.currentMovement();
if (player.isMoving())
{
    player.speed += 1.0;
}
player.speed *= 0.95;
player.move(movement * player.speed);

Instead of a simple player.move(movement).
So here the code become longer. And it would become even more if you do a more complex movement system.

This piece of code in HandleInput function would seems to not be at its place, as it is clearly a data update. But it would look better to see it in Update function, while movement variable and player moving boolean would be initialized in HandleInput, depending of which keys are currently pressed.

\$\endgroup\$
8
  • \$\begingroup\$ That was my thought, so how would you suggest then I handle collisions? Should the player class, or each entity handle collisions themselves? Currently I have been handling such things within the state, which overlooks handling players etc \$\endgroup\$
    – CS Dude
    Commented Sep 11, 2015 at 4:53
  • \$\begingroup\$ @OliverGiess The SFML already has its own collision system: you can compare bounding boxes with methods getGlobalBounds of any drawable thing. \$\endgroup\$
    – Aracthor
    Commented Sep 11, 2015 at 11:33
  • \$\begingroup\$ Oh yeah I know that, but I need to have access to each collidable objects bounding box(s). How would you do that? \$\endgroup\$
    – CS Dude
    Commented Sep 13, 2015 at 4:30
  • \$\begingroup\$ @OliverGiess getGlobalBounds IS a collidable obejct bounding box... As long as your entities classes are containing the sprite/shape object, they can directly access to it. \$\endgroup\$
    – Aracthor
    Commented Sep 13, 2015 at 7:45
  • \$\begingroup\$ Oh I get that, but I meant for lets say two characters to collide wont they need access to each others Global Bounds? \$\endgroup\$
    – CS Dude
    Commented Sep 14, 2015 at 8:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .