Design and Flexibility

[computerquip]

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:

• There is always a board.
• There are always pieces.
• The game has to end somehow.

So using, this... we get pretty much nothing. 🎱
So, my idea so far consists of implementing the logic of the game using generic virtual types.
In example:

class Location {
    int8_t x;
    int8_t y;
    //int8_t z; //Perhaps a 3D variation?
}

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;
};

class Board{
    virtual void place(Piece* piece, Location location) = 0; //This should throw exception on fail.
    virtual int move(Location curLoc, Location newLoc) = 0; //No exception, returns error or 0 on success.
};

namespace default {

//We have no reason to make this class virtual that I can see 
class Game {
    Game(Board* board) { /* Place pieces on the board. */ }

    /* 
    Returns number of moves made. No exception.
    This also checks for "rules" such as a check or checkmate and whether the game has a next turn.
    */
    int next();
}
}

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.

[Thumperrr]

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]

That's one thing I don't want though is hard coded pieces! There are thousands of variations of chess, some containing pieces that aren't what you're used to: http://en.wikipedia.org/wiki/Chess_variant

Since this isn't a very heavy application of algorithms, I thought using "name" to identify piece types would suffice.

[cire3791]

It would be beneficial to keep the design of boards, pieces, moves and game logic free of things like sf::Texture and sf::Sprite. There's no reason those things should be coupled to the graphics library.

[Thumperrr]

computerquip, it would be impossible to code one game that fits every variant of chess. Which is why they're called variants. We could have XML setting files containing names of piece files, so they could be changed externally?

cire, That makes way too much sense. Thanks, definitely keeping that in mind.
Drop what I said about including an sf::Sprite in piece.

[computerquip]

I'm not so sure. It's like having different gametypes in one game. For instance, having Deathmatch, Capture the Flag, and Domination in Modern Warfare 2. Or having different gametypes of tetris. Just like any other console game really...

I'm not saying make one that fits every variant but just enough to be able to implement most with minimal problems.

[Thumperrr]

Then, as mentioned earlier, we could have external configuration files that we can change in the future. Either way we need to have the paths to all of the pieces coded somewhere in the game, whether we use those pieces or not.

[jaredready]

I think this should be kept as the classic chess that everyone is used to. And yes we should also definitely keep the graphics components outside of the internal classes (piece, board, space, etc). That should be handled separately.

What about having the Piece class have its own internal representation of the grid, with valid places that given piece can move to?

[Thumperrr]

Agree on that.

Disagree on the second point. There are <= 32 pieces on the board at a given time. So up to 32 pieces have to have a representation of the grid, and every time the grid is altered up to 32 representations of it have to be altered as well.
I think a better idea would be to give board a member function or something called bool isFree(int xpos, int ypos), which returns true if the position is free to move to, and returns false if it isn't.
Then piece can call that function and find out whether the move is valid or not.

[jaredready]

But each piece moves differently. Should the board be responsible for handling each piece's movement behavior, or should the piece be responsible for that? It makes more sense for the piece to, but like you said that leads to lots of recalculations. Granted, it would only need to recalculate when a piece moves. As far as the piece is concerned it just knows where it can move. The board can keep track of if that place is free or not (be it line of sight issue, or preoccupied by allied piece).

[jaredready]

Sorry, each piece would only have to recalculate when it moves. The other pieces don't care. I'm just saying each piece keeps basically the movement behavior of itself. The board can handle whether or not that movement leads to an attack, is impossible due to line of sight, or the space is occupied.

[naraku9333]

Maybe a piece can hold a std::vector<std::list<Point>> where each list is a possible move path and Point is a point relative to the pieces position.

[Thumperrr]

Okay, yeah I take back what I said about the board handling movement patterns. Unique pieces should know where it's allowed to move. Up two positions, over three up 2, diagonally, etc. The board should have member function 'isOpen" which the piece can use to see whether or not a specific movement spot is open. Yeah?

[jaredready]

Are we against having an abstract base class Piece, with derived classes for each type of piece? We could then store a std::vector<Piece> in class Board and populate it with all the pieces. Then we can just iterate through the vector each turn checking for validity and what not.

I realize this won't be as flexible as adding a new type of piece will require recompilation, but it's a thought.

[computerquip]

I have an example I'll post up here in a few moments... I just need to finish basic game logic.

[Thumperrr]

That was the original idea (i think). Piece would be the base class, derived classes for pawn, rook, bishop, knight, etc would be specific to that piece type.

I'll wait on your example, computerquip. In the mean time, I'm going to start a new issue on the topic of resource management.