Thumperrr
commented
11 years ago I like what you've started. Throwing out some of my opinions
The board, in my opinion, should be responsible for movement of pieces. The rationale behind that being it is more intuitive for the board, a central object, to keep track of where all of the pieces are placed. If the pieces were allowed to move themselves, it would create complications for things such as detecting whether or not another piece is already in the same coordinate and such. That said, a global enumeration of piece types is required, and each piece must have a type member.
//naming can be changed in the future.
enum piece_type {
TYPE_PAWN = 0,
TYPE_KNIGHT,
TYPE_BISHOP,
TYPE_ROOK,
TYPE_QUEEN,
TYPE_KING
}
class Piece {
virtual bool move(short location) = 0; //Returns true on success, fail on failure..
virtual bool attack(short location) = 0;
std::string name;
Location location;
piece_type type;
sf::Sprite sprite; //I'll elaborate on this
};I added an sf::Sprite instance to the parent class Piece because, as far as I can see, it will be necessary to have in all base classes as well. The constructor of the base class will be responsible for filling out the sprite with the required image, which leads to the proposal of a resource manager (which I've already mostly designed).
Firstly, I'll get out of the way some more global definitions for image locations.
//in some header yet to be named
const std::string img_pawn_black("res/img/pawn_black.png");
const std::string img_pawn_white("res/img/pawn_white.png");
//... and so on.The resource manager (as a whole) will
- Be responsible for all physical loading of images
- Be responsible for distribution of images
- Ensuring that the image is not loaded into memory more than once.
I've split this into two different concepts. The first being an abstract base class, ResourceManager, which handles the storage/retrieval of a resource, and provides a virtual method for the loading of resources. The base class, in this case, sfTextureManager (working title), will
- Be a singleton
- Inherit ResourceManager
- Implement ResourceManager's virtual load method.
The following is a short example to help push the point.
template<class T, class deleter_type = std::default_delete<T>>
class ResourceManager
{
protected:
virtual T *onLoadResource(const std::string &location) {} //pure virtual method; base class is responsible for implementing.
public:
std::shared_ptr<T> Load(const std::string &key) {
//pseudo code
if exists in memory
return shared_ptr to the resource
else
call OnLoadResource to load it
store the loaded resource in memory
return the resource
}
void Free(const std::string &key) {
//pseudo code
free the resource from ResourceManager memory (namely, delete the shared_ptr)
//resource will not actually deallocate unless the reference count is 0, which it should be before calling Free.
}
};
class TextureManager : public ResourceManager<sf::Texture>
{
public:
static TextureManager &getInstance() { //singleton class
static TextureManager instance;
return instance;
}
protected:
sf::Texture *onLoadResource(const std::string &location) {
sf::Texture *ret = new sf::Texture();
ret->loadFromFile(location);
return ret;
}
};
//usage:
TextureManager::getInstance().Load(img_pawn_black); //img_pawn_black defined earlier.So then every instance of a piece can call Load, and multiple allocations of the image will not occur. So that's what I have to say about that.
I'm working on the full code, which I'll push to the master either tonight or tomorrow afternoon.
computerquip
cire3791
jaredready
naraku9333
ghost
LukeLeber
So, I've been thinking of something to come up with in design. To begin, let's get some terminology out of the way:
Board: A grid consisting of valid locations for a piece to move.
Piece: An entity that contains logic on how to move and other entities like itself.
Game: Generally consisting of a board and a set amount of pieces (although not always the case), it handles global logic such as when the game ends, when a piece changes (such as when a pawn reaches the end of the board in a default game), and so on.
Please note that these definitions may need to be extended later since it's difficult coming up with defined terminology to fit the humongous amount of chess variations.
Moving on, there are some things that we know for sure:
So using, this... we get pretty much nothing. :8ball: So, my idea so far consists of implementing the logic of the game using generic virtual types. In example:
Obvious flaws are whether the piece should move or the board should move the piece or the game should move the piece. I like the idea of virtual interfaces but I'm not so sure about the interface I'm introducing... this is where I fall short most of the time anyways. Any ideas would be lovely.
Also, I'm starting to think there's no reason to seperate "Game" and "Board" since game needs to know the dimensions of the board anyways.