cpluspluscom / chessplusplus Goto Github PK

I recently noticed that @usandfriends has an incredibly different fork of ChessPlusPlus, and that in his readme he refers to the organization as "C++.com". Unfortunately, when I chose the name for the organization, I meant for the "com" in "cpluspluscom" to be short for "community", as in "C++ Community". I just wanted to clear this up. He didn't have issues enabled in his fork (which is GitHub's default setting for forks), and I figured other people might be confused as well, so I put this here instead.

I just pushed a commit to the master instead of my fork, how can I revert or delete it?

Nevermind, I got it.

Any ideas on a logging API? I've had very good luck with Pantheios. (http://www.pantheios.org/)

I've been having a futile attempt at getting Travis to build this project (see #83). It seems there are two issues which stem from Travis servers running Ubuntu 12.04 still:

• By default, we have gcc-4.6 which does not support C++11. At least not what we need.
• By default, we're stuck with CMake 4.8.7. Apparently we need 4.8.8, though I'm not sure what about our CMakeLists is enforcing that requirement.

Our travis.yml has a good bit of stuff in here and I'm not sure if we actually need everything. We have a bunch of lines commented out. If we could clean this up to just the essentials, it would make getting our project to build a lot simpler.

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.

GraphicsConfig::spritePath() currently appends "chesspp" to the beginning of the specified path.
This kind of hidden behavior can be confusing and counterintuitive.
Although everything in the graphics.json file should be under the "chesspp" node, I don't think we should jump to the conclusion that it's impossible for there to be another top-level node, and have users specify the full path when requesting a resource.

I bring this up because @ResidentBiscuit and I were thrown for a loop for a while when his added resources were producing the "missing" image, when the json path he provided to GraphicsConfig looked correct. Even though I wrote a huge amount of the graphics functionality, I was still at a loss for a while. So that says something.

To make this easier to contribute to, I think we should decide on a list of general tasks/features (user stories if you will) that need implemented. Otherwise it's going to remain pretty unorganized, with people just working on random parts of the code.

What sort of documentation should be used? We could use in-code documentation via Doxygen, or we could use the wiki on this repository.

Personally I would prefer a combination of both, as Doxygen is quite powerful for generating graphs, displaying relationships, etc. and the wiki on this repository would be a great place to help get people familiar with the code base by explaining the basic workings of the design.

Alright, on the topic of resource management.
I've been putting together an abstract base class for managing anything that needs to be loaded off of the disk into memory.
https://gist.github.com/Thumperrr/4b963734b398dd93559e
You can take a look at it there. I'm pretty sure it's not leaking anything, but another set of eyes would be helpful.
The base class is pretty much just a glorified std::map<std::string, T>. Resources are stored with a std::string key, and are loaded based off of that key, so usually it has something to do with the resource (i.e. file location.)

Now, any number of derived classes can be made from this. This should be able to handle anything that needs to be stored in memory. I've made one called TextureManager that adds the functionality to load sf::Texture objects.

Bring on the criticism!

Evidence suggests it's something in our code that isn't working right with SFML.
I grabbed a commit from April 11th in Naraku's repo that compiles and links with SFML perfectly fine (before we started messing with it.)

Hmm.

Application::changeState() should return a reference to the new AppState instance so that calling code can interact with it beyond passing constructor arguments.

Additionally, something should be done about the destruction of the old AppState object inside the call - generally an AppState will be making the call to changeState() and will thus be destructing itself. This is dangerous even if documented.

I'm thinking of returning both the old and the new in a std::pair<std::unique_ptr<AppState>, std::reference_wrapper<NewState>> or making a simple custom struct to label them previous and current.

When Piece::moveUpdate() is called, the piece is already at the position indicated by to. This redundancy allows for subtle bugs if a coding mistake causes to to not be the actual position of the piece.

I think I'm about ready to migrate this project to cpluspluscom.

Any objections?

Right now chesspp::Exception is used when standard C++ exceptions would be more appropriate - I plan to fix that eventually.

I'm also not sure if there's much point to having such a generic exception class anyway - what do you think? If we choose to keep it, it should probably be made abstract, but I'm not sure we even need it at all.

Application implements a function called changeState, who's function speaks for itself.
When creating AppStateGame, Application passes a pointer to itself, presumably so that AppStateGame should be able to call changeState when necessary.
However, the Application pointer in AppStateGame isn't a complete type, so you can't access any members of it.
I can't think of an elegant way to resolve this. Ideas?

Refer to the repo as of this commit: 5f27e5a

EDIT:
Would it be intuitive to make Application a singleton class?

Currently we have several makefiles. @Lowest0ne recently tried changing the one @ne555 made, and everyone seems to be personalizing things.

I think there should be one makefile for all platforms and possibly a batch script like the one I've made for Windows. Obviously if the makefile supports Windows there will not be a need for the batch file.

I did a little work on the resources today. Basically, I took the pieces from naraku9333's images, and moved them around so that they each lie in the center of an 80x80 square (making a 480x160 pixel image). I made another chess board to match the size of the pieces (it is 640x640, no border). I also made an image that could possibly help someone center the pieces in their respective "slot".

Thing is, I'm brand new to GitHub, and have no idea how to share this with you all. I have forked the project, but beyond that I am lost. If someone could help me out, that would be great.

I imagine I will have more questions. I did a little looking for help, but I'm lost in the terminology mostly. I might guess that more people will come from C++ Reference, and be a little lost here.

Anyway, thanks.

getResourcePath does not find the correct path on all systems. I would also like to know what it is intended for - is the working directory not suitable for finding resources?

So, I'm not sure how best to add resources into the grapics.json file. And then once they're there, what's the best to load said resources? I see there's TextureManager and ResourceManager classes, are we supposed to use those? Is using direct SFML to load resources not the right way?

This is in reference to #65

Can we move all function definitions into cpp files so that it is easier to understand the roles of the various classes?

irc.freenode.net #ChessPlusPlus

Posting this in the issues so it doesn't get buried in the forums.

I'm not quite happy with my design for how the board and piece movements work - it's a lot of iterator hell that's easy to get lost/confused in. I want to improve it at some point.

The project needs documentation, which I will work on when I can. I've already got basic doxygen support and everything in src/util/ is already documented.

Any pull request adding or fixing documentation should have the Documentation milestone. The final pull request after which all code is documented should contain the text Fixes #55.

LB, is your branch able to be compiled and run at the moment?
I want to do a little bit of work, but I want to base it off of your repo because you have some changes in Application (that I will be playing with) that I like and don't want to conflict with in the future.

Right now, piece class registration is inside the board class. Logically, it would make more sense if it were in the abstract piece base class.

I think the current logging system needs some work. I'd like to see something where we replace std::clog's streambuf, but that wouldn't be very flexible. Still though, something needs to be done about the current logging system.

@Interlocked has created a logging file in his ancient fork:
Interlocked@2249dc0
Compare it to the current one:
https://github.com/naraku9333/ChessPlusPlus/blob/master/src/log/Logger.hpp
https://github.com/naraku9333/ChessPlusPlus/blob/master/src/log/Logger.cpp

I hacked together a CMakeLists.txt file that works for me in windows using g++. It needs testing on other OS and compilers. Configuration options are
CMAKE_BUILD_TYPE [Release|Debug]
SFMLROOT Path to SFML root directory
STATIC_BUILD Link statically if checked.

#ChessPlusPlus
cmake_minimum_required (VERSION 2.8)

project (CHESSPP)

if(WIN32)
set(SFMLROOT "" CACHE STRING "Path to SFML root directory")
option(STATIC_BUILD "Link statically")
endif()

include_directories (${CHESSPP_SOURCE_DIR}/lib/json-parser ) 
include_directories (${CHESSPP_SOURCE_DIR}/lib/boost)
include_directories (${SFMLROOT}/include)

file(GLOB_RECURSE CHESSPP_SOURCES "src/*.cpp")
file(GLOB_RECURSE CHESSPP_HEADERS "src/*.hpp")
list(APPEND CHESSPP_SOURCES "lib/json-parser/*.c")

set (CHESSPP_INCLUDE_DIRS "")
foreach (_headerFile ${CHESSPP_HEADERS})
    get_filename_component(_dir ${_headerFile} PATH)
    list (APPEND CHESSPP_INCLUDE_DIRS ${_dir})
endforeach()
list(REMOVE_DUPLICATES CHESSPP_INCLUDE_DIRS)

include_directories(${CHESSPP_INCLUDE_DIRS})
link_directories(${SFMLROOT}/lib)
add_executable (chessplusplus ${CHESSPP_SOURCES})

set(SFMLLIBS sfml-graphics sfml-window sfml-audio sfml-network sfml-system)

if(STATIC_BUILD)
    add_definitions(-DSFML_STATIC)
    foreach(_lib ${SFMLLIBS})
        set(_lib "${_lib}-s")
        list(APPEND TEMPLIBS ${_lib})
    endforeach()
    set(SFMLLIBS ${TEMPLIBS})
endif()

if(CMAKE_BUILD_TYPE STREQUAL "Debug")
    add_definitions(-DDEBUG)
    foreach(_lib ${SFMLLIBS})
        set(_lib "${_lib}-d")
        list(APPEND TEMPLIBS2 ${_lib})
    endforeach()
    set(SFMLLIBS ${TEMPLIBS2})
endif()

target_link_libraries(chessplusplus ${SFMLLIBS} boost_system boost_filesystem)

This is a new PR for a branching discussion com in from #65.

Basically we're unhappy with our current resource management system, and desire that it be reworked. Currently we must create a new class for each type of resource that we want to handle.
Both @LB-- and I have ideas for how we can fix this and will assumably submit competing pull requests.

Discussion about resource management refactoring should continue here.

AppStates are bound to an sf::RenderWindow upon construction, however it would make more sense if the sf::RenderWindow were passed to onRender() instead so that, for example, the same AppState could be rendered to multiple different rendering targets. After all, the only time an AppState ever needs to know about its render target is in onRender().

We need to decide on a license for this code. GitHub requires that a license be in a file titled LICENSE, and by convention we would also have to place the license in all our source files. We also have to account for the licenses of the graphics we're using.

A commit or pull request resolving this should include the text Fixes #40

Currently the game has no checks for determining that the game is over. This should be dealt with so we can have a functional game finally.

Might be too early for this, but I was bored and so I wrote this.

/******************************/
/*NETWORK PROTOCAL DESCRIPTION*/
/*           (NPD)            */
/******************************/

/*
    INTRODUCTION:
        I believe that the game should use a simple, but 
        concise way of communicating data. For this reason
        I have decided to suggest a simple command type system,
        that could be easily written, but is then "compiled" to
        a more concise form.

    TERMINOLOGY:
        Throughout the rest of this description the following term will be used:
        Client: The program sending the message.
        Server: The program recieving the message. (Could be a main server or a peer)
        (NOTE: Both playing applications will take the role of both the client and server
               in every session)

        Message Options are given as follows:
                msg_code[(option_name:data;)+]
            If there is no data the ':' and ';' characters will then be side by side.
            All whitespace is ignored.

    MESSAGES:

    Communication Messages:
        H377O   Message sent by client to server to initiate converation. 
                (Note the 'O' is a capital 'o' and not a zero)
                [Compiled to 0x405D  (CPP base 36 in base 16, I think)]

        H3Y     Message sent by reciever of H377O message.
                Sent only if reciever is willing and able to play.
                [Compiled to 0x4ooo]

        busy    Sent by reciever in response to a H377O message.
                Sent only if reciever is unwilling or unable to play.
                [Compiled to 0x4ooo]

        bye     Sent by client to server indicating that the client has closed the
                connection, and that the server must stop sending messages.
                [Compiles to 0x4ooo]

        error   Message sent by client to server indicating that there has been an error.
                -Options
                    n       no message
                    m:s     a string is attached with information of the error
                [Compiled to 0x404D]

        readyornot  Sent by client to server indicating that they are ready for the game to commence.
                    [Compiled to 0x4ooo]

        ready   Sent in response to readyornotmessage, indicating that client is ready.
                [Compiled to 0x4ooo]

        wait    Sent by client to server indicating that they are busy, and will send next message
                when the client is free. (Recievers of this message are expected to wait until they
                another message, however, recievers should end session if wait time exceads 5.0s)
                [Compiles to 0x4ooo]

    Out-Game Messages:
        Handles info like score, game type, colour.

    In-Game Messages:
        Handles info solely related to the movement of pieces.


    COMPILED CODE FORMAT:
        All Communication messages are prefixed with 0x4, Out-Game messages 0xA and In-Game messages 0xE
        All message codes are compiled to two bytes, followed two bytes indicating how many optional bytes
        there are following. The optional bytes format is as follows:
            (option_name ':' option_data '\0')*

*/

I have included the whole file here, because I do not know how to add a file to the repository.