Regarding structure.

[GunnDawg]

Hello folks, I am pretty new to SFML and had a few questions in regards to the most common techniques for setting up games. I kind of made the mistake of not starting with a player class and am at the point where I want to roll a lot of my code into classes. Player and Input being two of them. So my question is do most people have a class just for input, and another class for player functions? Here is how I have my player class looking at the moment and am starting to second guess my self into making an input class for just mouse and keyboard input.

Player.cpp

Code: [Select]

#pragma once

#include "Player.h"
#include <SFML/Graphics.hpp>


Player::Player(const sf::Texture& imagePath) :
mSprite(imagePath),
mSource(1, Player::Down)

{
mSprite.setScale(1.5f, 1.5f);
}

Player::~Player()
{
// TODO Auto-generated destructor stub
}

void Player::draw(sf::RenderTarget& target, sf::RenderStates states) const
{
target.draw(mSprite, states);
}

void Player::moveUp()
{
//mainChar.move(sf::Vector2f(0, -10));
}

void Player::moveDown()
{

}

void Player::moveLeft()
{

}

void Player::moveRight()
{

};

It's obviously ready to start going with player input but if making a separate class just for input is the more appropriate way to go, then I'll adjust accordingly.

Thanks for any and all input folks.

[eXpl0it3r]

The most simple way is to check for the input directly in the game loop and pass the actions to other objects, thus there wouldn't be a need for an "input" class.
More advanced techniques would be writing your own callback system or a message bus, but I think for now the simple way is what you want.

Please utilize the [code=cpp][/code] tag for code.

#pragma once is an include guard and should only be using in header files.

[Ixrec]

As far as I know, having a single Input class doesn't serve much of a purpose, because how the input should be interpreted is up to whatever game object you're controlling, and the actual inputs are already provided by SFML in a very convenient format.  Most of the time what exploiter said is correct.

Now, for more complex projects, the things I know of that *are* useful for encapsulating/modularizing your input-handling logic are:

- A system that keeps track of "raw" input events and translate them into meaningful "commands", which you then pass to your game objects.  Thor has some stuff for this: http://www.bromeon.ch/libraries/thor/v2.0/tutorial-actions.html.

- Having a set of input components for various purposes, as part of a general implementation of the Component pattern.  One good explanation of that pattern is: http://gameprogrammingpatterns.com/component.html

[GunnDawg]

Very well. I shall keep my mouse commands within the main.cpp and carry on. Thanks folks.