what happened to chess++?

[10X9216C]

NoX wrote:

I can't even participate because I have no clue wtf that is.

Yah std::enable_if can get messy really quickly, i tend to avoid it when possible, in that instance a static_assert would have been better, less code and provide a more readable error message.

From there all there is is variadic templates which aren't all that difficult to understand once you understand the syntax. They can be really useful.

Is there even a point to having this in a resource file:
https://github.com/cpluspluscom/ChessPlusPlus/blob/master/config/chesspp/board.json#L32

This is getting so specific it might as well be hardcoded.

[LB]

Nothing should be hardcoded. That's not a resource file, it's a config file.

[N36fSL3A]

Why are you getting hostile? There's no need to be an ass, seriously. I'm not blindly defending someone, you clearly are just looking to start an argument. Please take your hostile behavior elsewhere.

[LB]

Do I have to become a lawyer to make perfectly correct statements all the time with no chance of alternative interpretation? What is your problem?

[Lowest0ne]

I just wanted to mention that the chess pieces I made are totally free to do whatever you want with them.

Let's call it the CC Attribution License.

[NoXzema]

Well, I started becoming of the opinion that each type of chess would have to literally be a completely separate game. It shouldn't share pawn or bishop movement. The best we could do is make it as simple as possible to define how pieces moves, defining game rules, etc.

However, I started thinking of a way to express piece movement through algorithms that can be expressed in configuration so it would be easy to define such things... and lost interest greatly.

I don't like the current json...

- "suits" should be expressed as "teams" so as to remove a two-team limitation. Teams can then have their own attributes. Using the simple number such as 1 and 2 to express teams is much less verbose and just as clear.

- "cell width" and "cell height" should be determined by game implementation and rendering.. not by the config. I can't imagine any situation where this would be useful.

- "pawn facing" should be removed. All pieces are the same... except for the pawns which are two essentially different pieces (you can define there movement as decending or ascending the location system, which is direction agnostic). Also, this makes it painful to have the black pieces sit on top.

-"first turn" should be changed to a team number.

- What if a board isn't a perfect rectangle?

-We can express *all* of this in C++ almost just as clearly. To what advantage does putting it in json format do?

[LB]

NoXzema wrote:

- "suits" should be expressed as "teams" so as to remove a two-team limitation. Teams can then have their own attributes. Using the simple number such as 1 and 2 to express teams is much less verbose and just as clear.

What two-team limitation? No such limitation exists.

NoXzema wrote:

- "cell width" and "cell height" should be determined by game implementation and rendering.. not by the config. I can't imagine any situation where this would be useful.

I just moved this out of the original source from before my time and into the JSON, so I don't really care what happens to it.

NoXzema wrote:

- "pawn facing" should be removed. All pieces are the same... except for the pawns which are two essentially different pieces (you can define there movement as decending or ascending the location system, which is direction agnostic). Also, this makes it painful to have the black pieces sit on top.

I disagree, currently you can have diagonally-moving pawns or pawns facing any direction regardless of their postion on the board.

NoXzema wrote:

-"first turn" should be changed to a team number.

I really don't see any point in replacing a text ID with a number ID - it seems kind of pointless.

NoXzema wrote:

- What if a board isn't a perfect rectangle?

I hadn't gotten around to refactoring the board class(es) to support that kind of stuff but intended to.

NoXzema wrote:

-We can express *all* of this in C++ almost just as clearly. To what advantage does putting it in json format do?

The point is to be able to change a lot of game aspects without recompiling code.

Keep in mind, there's nothing stopping us from forking and creating our own derivative works. I have no idea what direction the "community" repo should go in, though.

[helios]

Can I configure the game to play go on a 5-sphere with four other people yet?

http://en.wikipedia.org/wiki/Inner-platform_effect
http://en.wikipedia.org/wiki/YAGNI

I don't think fundamental aspects of the game is really something that needs to be in a configuration file.

[LB]

The game mechanics are coded in C++. The board layout and some aspects of the behavior of pieces can be configured without recompiling. You guys are acting like you've never worked with level editors before.

[Catfish666]

ChessPlusPlus Description wrote:

ChessPlusPlus is a modular game of chess programmed with the latest gadgets and gizmos in C++, namely whatever happens to be the most recently released standard (currently C++11, soon to be C++14).

From the get-go the goal is ambiguous; is it to create a chess game, or some game that supports a "chess mode", or is it about experimenting with new and obscure C++ features?

ChessPlusPlus Description wrote:

The project aims to show the simplicity and elegance of C++ and to constantly use the latest features of the language and the most modern design practices.

Hah! There is simplicity and elegance in #pragma once -- which is never used.

[3hM2Nwbp]

Catfish666 wrote:

There is simplicity and elegance in #pragma once -- which is never used.

Which completely goes out the window when you protect your translation units from non-standard extensions properly (as the boost library authors thankfully have).

#ifndef HEADER_GUARD_STILL_HERE
#define HEADER_GUARD_STILL_HERE
// Shaves off microseconds of compilation time when using Microsoft's compiler
// ...or perhaps use clang which is much faster to begin with
#if defined(_MSC_VER) && (_MSC_VER >= 1200) || defined(GCC_VERSION) && (GCC_VERSION >= 30400)
# pragma once
#endif
#endif 

*Also, check motti's answer in this link: http://stackoverflow.com/questions/787533/is-pragma-once-a-safe-include-guard

**The inability for a community to agree on even the most simple things makes me turn away from most open source projects. I'm more of a "You can read my source, fork your own slice, but you sure as hell can't change the master without my permission." lone wolf.

[devonrevenge]

So that is what happened, can we all now just take a minute to reflect on my awesomness.

[Little Bobby Tables]

i took two minutes

[Catfish666]

Luc Lieber wrote:

Which completely goes out the window when you protect your translation units from non-standard extensions properly (as the boost library authors thankfully have).

Is that the case for ChessPlusPlus as well? If yes, the project's even more FUBAR than it appears.

And by the way...

LB wrote:

The game mechanics are coded in C++. The board layout and some aspects of the behavior of pieces can be configured without recompiling. You guys are acting like you've never worked with level editors before.

This sounds more like modding than it does level editing. Also you should clarify what you mean by "game mechanics".

helios wrote:

Can I configure the game to play go on a 5-sphere with four other people yet?

Delicious. Also delicious is how this game reflects the nature of C++: to take something which is good and popular, like chess, and keep adding features to it.

[NoXzema]

Luc Lieber wrote:

Which completely goes out the window when you protect your translation units from non-standard extensions properly (as the boost library authors thankfully have).

#ifndef HEADER_GUARD_STILL_HERE
#define HEADER_GUARD_STILL_HERE
// Shaves off microseconds of compilation time when using Microsoft's compiler
// ...or perhaps use clang which is much faster to begin with
#if defined(_MSC_VER) && (_MSC_VER >= 1200) || defined(GCC_VERSION) && (GCC_VERSION >= 30400)
# pragma once
#endif
#endif 

*Also, check motti's answer in this link: http://stackoverflow.com/questions/787533/is-pragma-once-a-safe-include-guard

**The inability for a community to agree on even the most simple things makes me turn away from most open source projects. I'm more of a "You can read my source, fork your own slice, but you sure as hell can't change the master without my permission." lone wolf.

That #if doesn't even begin to cover the compilers #pragma once is supported by... It's viable because the likelihood of finding a compiler that doesn't support it is ridiculously low. Even compilers you've never even heard of support it...

[htirwin]

I think that the configuration file is a good idea, but I think that cell height and width shouldn't be part of it.

I would make cell height and width dynamically resize to match the screen size.

And I think that width and height ( in squares ) aren't needed, you can deduce that from pieces/layout.

Even in traditional chess programs you have various different starting configuration. On top of that, configuration files make it convenient for resuming games.

I would add time limit, and configuration identifier. I would also make a separate configuration file for themes / looks.

Those who think this stuff should all be hard coded, if I was your boss, you would all be fired.

[NoXzema]

Except it already is hardcodedconstant... just in a json format. I don't see your point. There's no advantage to doing that. When would someone ever go, "Oh, good thing I have this configurable json file to change while I'm in the middle of a game"? Never.

EDIT: Also, glad to know you'd fire me over having a different opinion. I would probably spit in your coffee.

[htirwin]

There's no advantage to doing that. When would someone ever go, "Oh, good thing I have this configurable json file to change while I'm in the middle of a game"? Never.

The advantage is that the files are in long term storage. If a user always plays upside down chess, with a 30 second timer, playing as black, then it can easily be set so that the program opens with this configuration. If you would like the game to be loaded with the same configuration the game left off in last time it was closed, then you just load that configuration from a file. If you want to add support for a new chess variant without modifying and recompiling code you can, and you can distribute these types of extensions as text files.

Maybe the user wants to have various saved game configurations, maybe from famous games, they can. Maybe they want to add more of these without modifying and recompiling the program.

The ability to do all of this stuff seams like it should be standard to any serious chess application.

[NoXzema]

While I understand game recording, I don't understand why you would want to define a game in a configuration file which you seem to not be understanding. You would not change game rules in the middle of a game. Ever. You can barely define the logic it takes to change a piece on the table via json without being disgusting. At best you can move pieces around and change board size... not even in an irregular fashion currently.

[htirwin]

I just think that game state should be captured by the configuration file. In the configuration file I would include the placement of game pieces ( or something indicating the placement should be randomized in some fashion ), who's turn it is, some way of indicating pawn facing, timer settings, a sequence of moves going back to the start of a game, optionally identifiers for the players, and an identifier for the game configuration.

To allow for rule changes, you would probably want to use a scripting language. But rule changes are less fundamental than configuration changes. Because it is rare enough that anyone plays chess with altered piece powers, I think it would be reasonable to have this hardcoded. But I would still prefer that at least piece powers be encapsulated so that if you want to add new variants you have to do minimal restructuring.