patterncsharpMinor
Chess game in Windows Forms Part #1
Viewed 0 times
partchessgamewindowsforms
Problem
I've recently created my own 2-player chess game, no AI... at least for now.
I do plan to do that in the future, so one of my concerns is if the code is flexible enough to just use the same classes in all the different modes so I can avoid rewriting the same code over and over again. I've tried to explain most of the logic with comments in the main
User Interface
The game itself starts in the
As I've mentioned earlier currently the only working mode is the 2-Players mode so the other buttons are disabled and have nothing inside they're
From here you can go to the
It mostly works with the
The form itself is implemented like this :
```
public partial class OptionsForm : Form
{
private bool settingsSaved = false;
private bool closeOptions = false;
private bool enableTurnHelper = Properties.Settings.Default.EnabledTurnHelper;
private bool enableTurnTracking = Properties.Settings.Default.EnabledTurnTracking;
private bool enableTurnTimers = Properties.Settings.Default.EnabledTurnTimers;
private uint timerTime = Properties.Settings.Default.TurnTimer;
public
I do plan to do that in the future, so one of my concerns is if the code is flexible enough to just use the same classes in all the different modes so I can avoid rewriting the same code over and over again. I've tried to explain most of the logic with comments in the main
Form but I've skipped most of the explanation of what's going in the other classes, so if anything is unclear I will be happy to answer in the comments.User Interface
The game itself starts in the
MainMenuForm:public partial class MainMenuForm : Form
{
public MainMenuForm()
{
InitializeComponent();
}
private void bExit_Click(object sender, EventArgs e)
{
Application.Exit();
}
private void bOptions_Click(object sender, EventArgs e)
{
OptionsForm optf = new OptionsForm();
optf.ShowDialog();
}
private void bOnline_Click(object sender, EventArgs e)
{
}
private void b2Players_Click(object sender, EventArgs e)
{
CooperativeForm cpf = new CooperativeForm();
cpf.ShowDialog();
}
private void b1Player_Click(object sender, EventArgs e)
{
}
}As I've mentioned earlier currently the only working mode is the 2-Players mode so the other buttons are disabled and have nothing inside they're
Click event handler.From here you can go to the
OptionsForm:It mostly works with the
Properties.SettingsThe form itself is implemented like this :
```
public partial class OptionsForm : Form
{
private bool settingsSaved = false;
private bool closeOptions = false;
private bool enableTurnHelper = Properties.Settings.Default.EnabledTurnHelper;
private bool enableTurnTracking = Properties.Settings.Default.EnabledTurnTracking;
private bool enableTurnTimers = Properties.Settings.Default.EnabledTurnTimers;
private uint timerTime = Properties.Settings.Default.TurnTimer;
public
Solution
Some brief thoughts:
-
Too many tuples. Whatever notion pair-of-ints represents, it is plainly important. Important enough to have a class or struct of its own. Make the program read like its semantics; no one thinks of chess as being a game of tuples of ints.
-
There is a LOT of duplicated code in the valid move checker. Can this be simplified? Can it be broken up into smaller methods?
-
Valid moves end with the player not in check. I don't see that computed anywhere.
-
You will need to know whether the king and rooks have moved; you don't need to know that for any other pieces. However, it doesn't hurt to track this for all pieces.
-
A king may not castle through check. You don't check for that in your valid moves.
-
When a pawn is promoted, does it maintain referential identity? Or is it replaced by a newly allocated piece? Either is fine but think about how you're going to represent that.
-
You do not need to know if a pawn has moved; you need to know when a pawn has moved in order to get the en passant rule right.
-
The whole notion that code in the piece class should determine the legal rules is deeply suspect. When playing chess we do not ask the queen what the legal moves are for the queen; we consult the rules. You think you are doing good OO design by putting stuff in classes, but that is not necessarily good OO design. I would be inclined to have an object called Rulebook, which has a method which takes a piece, a board state, and returns a list of legal moves for that piece. Don't ask the piece, ask the rule book!
-
A word of advice: make everything immutable now. When you write your AI, you're going to want to be able to represent many different variations on the same board. When you make a move, that doesn't change the board. It makes a whole new board. That way to go back to the old board you don't have to undo anything.
-
Too many tuples. Whatever notion pair-of-ints represents, it is plainly important. Important enough to have a class or struct of its own. Make the program read like its semantics; no one thinks of chess as being a game of tuples of ints.
-
There is a LOT of duplicated code in the valid move checker. Can this be simplified? Can it be broken up into smaller methods?
-
Valid moves end with the player not in check. I don't see that computed anywhere.
-
You will need to know whether the king and rooks have moved; you don't need to know that for any other pieces. However, it doesn't hurt to track this for all pieces.
-
A king may not castle through check. You don't check for that in your valid moves.
-
When a pawn is promoted, does it maintain referential identity? Or is it replaced by a newly allocated piece? Either is fine but think about how you're going to represent that.
-
You do not need to know if a pawn has moved; you need to know when a pawn has moved in order to get the en passant rule right.
-
The whole notion that code in the piece class should determine the legal rules is deeply suspect. When playing chess we do not ask the queen what the legal moves are for the queen; we consult the rules. You think you are doing good OO design by putting stuff in classes, but that is not necessarily good OO design. I would be inclined to have an object called Rulebook, which has a method which takes a piece, a board state, and returns a list of legal moves for that piece. Don't ask the piece, ask the rule book!
-
A word of advice: make everything immutable now. When you write your AI, you're going to want to be able to represent many different variations on the same board. When you make a move, that doesn't change the board. It makes a whole new board. That way to go back to the old board you don't have to undo anything.
Context
StackExchange Code Review Q#128039, answer score: 5
Revisions (0)
No revisions yet.