Simple Chess Variant

[nmb]

Hi,

I'm writing an interface to play a game that I call Slip (a chess variant) using SFML and TGUI. Using the program, one can play against one of the three engines that comes with it or make two engines play against each other. I have added a readme file with all the rules to play the game.

Thanks,

NMB

https://github.com/nmblais/Slip

[texus]

It looks nice but it is still buggy (sometimes you can't move a piece, the program hung once, etc).

I think the next thing you should do is fix the movement. When you select a piece and place it in an invalid position it should be moved back where it came from. Optionally you can even highlight the places where you can put it down. And don't allow to pick up a piece of the opponent. By just making these changes the game will already be a lot better.

The most important parts of the game are probably already implemented so you just have to finalize it and make it a bit more user-friendly. Keep up the good work.

Btw, the zip files contains the dlls which are needed to run the exe, but in the github files these dlls are still missing so you still have to unzip the zip file to play the game. Once all files are there on github it won't be necessary to have the zip file there anymore.

[Normand Blais]

Thanks for the feedback. I appreciate.

NMB

[Normand Blais]

I have uploaded a new version of Slip.exe improving the mouse behavior and the game management.

Thanks for trying the game,

NMB

[texus]

Playing is a lot better now. But you will still have to test it a lot and find the bugs in it because it does go wrong from time to time.
In a few minutes I saw the following things happening:
- The pawn of the opponent was immediately placed back to where it came from after moving. The square where it moved to is occupied according to the game (you can't move a pawn there if you have one right in front of it), but the pawn is still drawn on the wrong location. See the attachment if my explaination is unclear, the pawn should be at c4 but it is at b5 (Black was configured as NWC-North).
- At one point the opponent started using my pawns. So during black's turn a white pawn was e.g. moved from b2 to b1.

[Normand Blais]

Texus,

The program is obviously not bullet proof yet and I thank you for the help you provide. But I may need some suggestions about design without having to share the source code (which changes all the time.) I'm trying to learn SFML and TGUI (and maybe C++ 11) by writing stuff (and not finding what I need in the documentation or the example provided). I almost came to the conclusion that keyboard handling is a lot easier than mouse handling. I bought two books on SFML programming and I found that they mostly focus on the keyboard. Back to my program. I need to think of design. OOPs or not to OOPs.

Thanks again,

NMB

[texus]

Design wise I would store the board as a grid. Based on the kind of errors that I found you are not doing that and are instead drawing the pawn "manually" based on where you set their position. I would instead generate the sprites at runtime every frame.

You would just have a grid of integers (e.g. vector<vector<int>> or even better use std::array instead of std::vector if the grid is a fixed size). Every cell in the grid has a value depending on what it contains, e.g. 0 when empty, 1 when there is a pawn, 2 if there is a queen. To draw on the screen you just loop over every cell in the grid and determine if you need to draw something there or not and you create a sprite and draw it (the texture that the sprite uses should of course be loaded upfront).
You may already have something like a grid to determine where there are pawns, but I'm suggesting to also use it for drawing. This ensures that what you see visually always represents the internal state. The only tricky part would be to not draw the one that you are dragging.

There isn't much room for OOP for the game itself, you just need a simple grid. Maybe other part of the code can use OOP, but you should only use it when you feel it becomes more structured and easier to maintain, not just because you arbitrary choose to. You should see for yourself, I don't know what else you are storing outside the grid that you need to have for the player and computer.

Whether to use the keyboard or the mouse depends a lot about the game, in case of chess the mouse is a lot more intuitive so you don't get much choice. The mouse isn't any harder to handle than the keyboard, it's just that implementing dragging and dropping an object takes a bit of effort.

[Normand Blais]

Texus,

This is not the first time that I write a UI but it is the first time using SFML (and TGUI.) A few months ago, I found an SFML program (source code included) on YouTube that was showing how to simulate dragging a piece on a Chess board using the mouse.  It was a demo program and I got interested. I would like to keep that feature but we will see.

Without seeing the code, it not easy for you to come up with ways to improve it. I think I'm already doing what you suggest but I'll try to verify. I can tell that I have struggled a bit with TGUI. It took me a while to understand, for instance, how the radio-buttons and the menu selection work. It is not obvious. Anyway. Again, I really appreciate your input.

Thanks,

NMB

[Normand Blais]

New version 0.2

Fix draw detection in the GUI.

NMB