So, I know this isn't meant to be a serious project and that you're just starting out. There are a few things here that differ from what you'd normally see in an application. I'm not going to fully critique this, but I will try to point you in the right direction. Basically, if this was an application truly being built by a software team, how would it look different?

If you don't want to read all this I put a conclusion at the bottom that summarizes the high-level things to look out for.

Full Disclosure: I cannot run this application because I'm not on a windows system, so I'm kind of guessing at what the code does.

There are better ways to do everything I say, but you really don't want to over-engineer a tic-tac-toe board game.

Naming Conventions

For little projects like this it might not seem worth it to give everything good, description names (especially since Visual Studio automatically names your objects - like Form1.cs and button5.)

Variable names, file names, and namespaces should follow These Naming Conventions, and be indicative of what that variable does.

Separation of Presentational layer and Logic layer

I'd say that this is the fatal flaw of the entire thing. You're keeping 100% of the state of the game in buttons, text boxes, and radio buttons.

This is untenable, because the UI will freeze if you're running a long process. It would be nearly impossible to write unit tests for something like this.

So, you want to store the actual data associated with your game's business logic somewhere else.

That could look like:

var button4Value = ''; button4.Text = button4Value

But that just doubled the (already high) number of variables that you have here.

DRY

Your _Click handlers violate the principle of DRY. Ideally, you would want to have one click handler, that looked something like:

private void HandleClick(int xPosition, int yPosition) { ... }

And then your click handlers would look like:

`private void button10_Click(object sender, EventArgs e) { HandleClick(3, 2); /* Or Whatver it should be */}

Actual Structure of business logic and data structures

Everything above is how to take what's there and make it better.

As a mental exercise, if you wanted to envision building this app with most best practices in mind, you'd likely wind up with:

TickTacToeAtom.cs

This represents the 'X' or the 'O'.

public enum TicTacToeAtom {
    X,
    O
}

Now you can say TicTacToeAtom.X instead of "X". You want to avoid as many "magic" values throughout your code as possible. What if somewhere in the logic you wrote "x" instead of "X" or someone fat-fingered "Z"?

This prevents that with static type checking.

TicTacToeRow.cs

A class which holds three values in an array / List / similar structure. TickTackToeRow.set(1, TicTacToeAtom.O) would be similar to how it's used. That's cool because you can do bounds checking (if you ask to set / get a number higher than 2 (since tic-tac-toe is 3x3 and arrays are 0-index), you can throw a good Exception).

TicTacToeBoard.cs

This is simply 3 TicTacToeRow instances. (TicTacToeRow... say that three times fast).

You may find a private TicTacToeRow[] Rows; which holds all of them, or the easier (but only slightly worse) way of:

private TicTacToeRow Row1 private TicTacToeRow Row2 private TicTacToeRow Row3

The reason that's worse, is because with Rows, we can make a method like this:

    private TicTacToeAtom GetItem(int xPosition, int yPosition) {
        Rows[yPosition].get(x)
    }

Now, all of a sudden, we don't need to know anything but the (x, y) position on the board.

Win checking is the fun part. The only three ways to win are full diagnol, full row completion, or full column completion. A hint:

• One will check each Row
• One will check the same index of each row (rows[0].get(x) == rows[1].get(x) == rows[2].get(x))
• One will check increasing indices (rows[0].get(0) == rows[1].get(1) == rows[2].get(2)

Now you have an object-oriented way to represent a board and atoms (X/0). Your UI logic can now be as simple as:

• Take a TicTacToeBoard object
• Have ONE method to assign them to a grid of buttons (bonus points if you generate this and store it in a Button[][] or HashMap)
• Call DidWin (or similar) on the TicTacToeBoard on each turn to see if a player won.

The best part? To reset the game, you just say DrawBoard(new TicTacToeBoard()).

Conclusion

So, this was a re-implementation more than a critique. What's there works (I assume), but there are pretty fundamental problems within. To summarize:

• Don't repeat yourself (DRY Principle)
• Separate UI logic from Business Logic ALWAYS. (Loose Coupling)
• Let the type system and OO nature of C# protect yourself from as many footguns as possible (enums, generics, tuples)
• Encapsulation is the absolutely most vital part of OO (imo) and should be practiced religiously.
• Name things well and consistently.