SpaceFree() could be IsSpaceFree(), for more clarity that it's checking rather than freeing.

Looking mostly good so far. (I don't like your formatting but that's a preference issue, lol.)

Will edit here after looking at the rest.

In the main fn, why do-while rather than just while? You set the condition prior to the loop. Also, it's not an issue in this case since the code is so short and clean, but in terms of design the 'play again' block could be segregated to its own function.

DrawExampleBoard() seems superfluous. All it does is write some lines and its only call is in the midst of a series of drawn lines. Do you intend to call it elsewhere in a later version?

You call DrawBoard() prior to calling TicTacToeGame(). Why not move it into the beginning of TicTacToeGame()? It seems more natural for it to be there.

I see main()'s board getting passed into a lot of member functions. Why not make it a member variable?

TakeInput() - huge switch statement in here. DRY. Convert the enum to your target value (It feels really gross doing this with a switch, but idk enough about C# console input to do it by character value.) and then run the code once on the derived value. If you want to change the action taken on the value later you won't need to change it nine times. Your code will also be smaller.

[source lang="csharp"]
int slot = -1;
switch(keyPressed.Key) {
//...
case ConsoleKey.NumPad9:
case ConsoleKey.D9:
slot = 8;
break;
default:
Console.WriteLine("\nPlease use your numpad or the keys 1-9 to choose a spot to mark.");
break;
}
if(slot != -1) {
validKeyPressed = MakeMove(board, marker, slot);
}[/source]

TakeInput() has another do-while that could be a while.


[source lang="csharp"] if(MakeMove(board, marker, 0)) {
validKeyPressed = true;
break; //this line is not necessary
}
break;[/source]

Still looking.

Going by function name, TakeInput() should not call MakeMove(). It should return the derived value and then the caller of TakeInput() should call MakeMove() with that value. This would technically be the better thing to do here, but in this case you could get away with just renaming TakeInput() to TakeTurn(), since that's what it's really doing here.

Did you not get a compiler warning for MakeMove()'s return paths? This is how to avoid it:
[source lang="csharp"] // Marks spot on the tic tac toe board with a marker if the space is free
static bool MakeMove(char[] board, char marker, int move) {
if(SpaceFree(board, move)) {
board[move] = marker;
return true;
}
Console.WriteLine("\nThat spot is taken.");
return false;
}[/source]

Try to find ways to make your data work for you, instead of you working for the data:
[source lang="csharp"] // The Tic Tac Toe Game's heart
static void TicTacToeGame(char[] board) {
char playerTurn = 'O';
string winner = "";

while(!gameOver) {
Console.WriteLine("It is " + playerTurn + "'s turn to move!");
TakeInput(board, playerTurn);
DrawBoard(board);
winner = CheckWinner(board, playerTurn);
playerTurn = (playerTurn == 'O') ? 'X' : 'O';
}
Console.WriteLine(winner);
}[/source]

This may save you some room:
[source lang="csharp"] static bool CheckWinSet(char board[], int a, int b, int c) {
return (board[a] == board) && (board == board[c]);
}

static string CheckWinner(char[] board, char marker) {
while(true) { //for breaking
// Horizontal Win
if(gameOver = CheckWinSet(board, 0, 1, 2)) {break;}
if(gameOver = CheckWinSet(board, 3, 4, 5)) {break;}
if(gameOver = CheckWinSet(board, 6, 7, 8)) {break;}
// Vertical Win
if(gameOver = CheckWinSet(board, 0, 3, 6)) {break;}
if(gameOver = CheckWinSet(board, 1, 4, 7)) {break;}
if(gameOver = CheckWinSet(board, 2, 5, 8)) {break;}
// Diagonal Win
if(gameOver = CheckWinSet(board, 0, 4, 8)) {break;}
if(gameOver = CheckWinSet(board, 2, 4, 6)) {break;}
break;
}

if(gameOver) {
return marker + " wins!\n";
}

// Tie Game
if(BoardFull(board)) {
gameOver = true;
return "No one wins, it's a tie!\n";
}

return null;
}[/source]

You may be able to find a stdlib function that searches for a specific character in a string. I dunno if C# has it, but if so you can tack a zero on to the end of your board array and then search it for ' ' rather than using BoardFull().


Overall, this is pretty good. It's clean and easy to read and I was able to track the flow of the program with no difficulty. I think you're quite ready to move on to the next level of complexity. You may want to look into some articles about general program structure and etc, but really you did quite well here. I have no significant complaints. I know I said a lot, but I don't want you to think that your own version was 'wrong'. It's just that there's always a 'better' way. (I'm resisting the temptation to change CheckWinner() to a loop that runs through static int[3] arrays) I'm sure that there are far better ways than what I showed you as well. You'll naturally pick up better flow habits as you practice and see more code and come across interesting ideas.

Good job!

I think you will get the most in terms of learning experience and better design by not assuming a fixed board size and hard coding every possible win condition. After all, the real core of programming isn't knowing language X or memorizing whole libraries, but about problem solving.

How would you write it, if the board size can be configured to 4 or 5? Ironically, you should find that your code will get a lot shorter, cleaner and contain way fewer messy if-else and switch-case constructs.

Once that is working, how would you handle the win condition not being n in a row (where n equals the board size), but a value that can be configured independently? You should find this to be a very small adjustment to your existing code (okay, I'm lying, unless you didn't realize that only two diagonals need to be checked for n = board size).

What if the board doesn't have to be square? Again, this should end up being only a minor change.

[quote name='Khatharr' timestamp='1353036021' post='5001432']
I see main()'s board getting passed into a lot of member functions. Why not make it a member variable?

Which brings me to the issue that this whole program has only static methods. So the suggestion of adding a member variable wont work.
[/quote]

It seems to work okay for 'gameOver'.

Moving toward a more object-oriented approach would definitely be the next step, though. I agree with that.

Once you're comfortable with OOP you should see some ways to do things like that.

The text formatting may give you a little bit of a challenge, but his suggestion will lead you into the realm of object-based encapsulation, which will let you have re-usable, adjustable parts like he's suggesting.

I wouldn't actually focus on OOP for the things I described. Those are simply applications of loops.

For a weird comparison, think of the difference between "calculating" and actual "math". Math isn't about calculating the result of 2+2, but is more often dealing in abstractions and finding generic solutions to problems. For example n+n = n*n. You can now go and "hard code" it for all numbers from 0 to 1000000 and see which one works (basically the equivalent to hard coding all possible win conditions for tic tac toe), or you can apply math (in programming: come up with an algorithm and apply it):

(n+n)/n = n
n/n + n/n = n
1 + 1 = 0
n = 2

In the same way, when you write code and find yourself doing something really tedious (like writing down all winning combinations) and especially when you start copy/pasting things all over the place, it is time to stop, take a step back and try to understand the pattern or system behind the problem you're solving. That's completely independent of any programming language. The actual "coding" is usually the easy part, where you just need to translate the solution you came up with into your language of choice.

Back to topic:

You already know how to use loops, so in pseudo code, you can start by not saying "if it is this, this, this, this, .... or this state, the player wins, but instead "if in any row or column or diagonal, the same symbol appears 3 times in a row...". Most people end up hard coding it for Tic Tac Toe, because it's quick and easy and unfortunately the board is so small that it's a feasible solution and a generic approach might look like overkill.

So think ahead. There are lots of games where gems, symbols or whatever must be placed in a row to score points. Those grids are usually large enough that hard coding every possible occurrence of 3 in a row/column/diagonal would be pretty insane (and lead to murder, if someone decides to change the number of row or columns on short notice). Point is: if you solve it generically for Tic Tac Toe, you will have a reusable piece of code that will work just as well for all kinds of games or situations where you need to find chains of length n in a grid of size x*y.

Also, whenever you look at a problem and think "the solution is going to be really complicated", find ways to break it down into manageable steps. For example, don't try to handle chains in rows, columns and diagonals all at once. Solve it step by step.

One first step might actually be to write a helper function that will turn x/y coordinates into an array index (and maybe the other way round), so you won't get additional headache from your board being represented by a 1 dimensional array.

Small tip:


keyPressed = Console.ReadKey(true);

switch (keyPressed.Key)
{
case ConsoleKey.NumPad1:
case ConsoleKey.D1:
// etc...
}


Can be shortened if you test ConsoleKeyInfo.KeyChar instead:


keyPressed = Console.ReadKey(true);

switch (keyPressed.KeyChar)
{
case '1':
// etc...
}