Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Regarding structure.  (Read 1261 times)

0 Members and 1 Guest are viewing this topic.

GunnDawg

  • Newbie
  • *
  • Posts: 22
    • View Profile
    • Email
Regarding structure.
« on: December 20, 2014, 06:49:26 am »
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

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10936
    • View Profile
    • development blog
    • Email
Re: Regarding structure.
« Reply #1 on: December 20, 2014, 11:43:24 am »
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.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Ixrec

  • Hero Member
  • *****
  • Posts: 1241
    • View Profile
    • Email
Re: Regarding structure.
« Reply #2 on: December 20, 2014, 11:49:04 am »
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

  • Newbie
  • *
  • Posts: 22
    • View Profile
    • Email
Re: Regarding structure.
« Reply #3 on: December 20, 2014, 12:32:25 pm »
Very well. I shall keep my mouse commands within the main.cpp and carry on. Thanks folks.

 

anything