Ok I feel like I'm a pretty good programmer but all my learning is self taught, so I'm trying to brush up on the "proper" ways to implement specific design patterns and other programming techniques. This situation kinda has me at a stand still scratching my head. I know how I would normally do it and for something this small it'd probably be the easiest without causing headache down the road. But I'm trying to learn so...

First to paint a picture, for the sake of this question the game is similar to 'Checkers'. Theres a game board that only two players play on. All the game pieces are the same except that they belong to different people.

What I'm wandering about is who should own the game pieces and how would interaction with the pieces be handled in all respects to OOP?

The way I would do it is the player would own the pieces and handle the interaction with the pieces. The first thing that pops out to me though is interaction between different players pieces would require each player to have some knowledge of the other players pieces. This makes me think I should have another class/function outside the player that handles player input and interaction with game pieces and just pass the whole lot of info to this controller. Am I on the right track with that?

This makes me think I should have another class/function outside the player that handles player input and interaction with game pieces and just pass the whole lot of info to this controller. Am I on the right track with that?

Yes, I would say so.
What occurs to me is to have a Board class which models the state of the board (i.e. the position and type of all the checkers) and has public member functions for updating that state according to the rules of the game - such as moving a piece diagonally, hopping over another player's piece, kinging a piece - Not to mention some functions to query the board state in order to find out who's winning and whether the game has finished. Also, if there's an AI involved then it will probably need index into and/or iterate over the board to see precisely where pieces are located.

Agreed. Just a 2D array of enum values something like {EMPTY, PLAYER_A_PIECE, PLAYER_B_PIECE} could represent the board state internally and then member functions using the MVC architecture would probably work great.

This would most likely use the least resources and be the most convenient way to trigger interactions between the pieces, since all the information belongs to a single class.

I'll agree. OOP doesn't make a whole lot of sense here.

Representing each piece as an object doesn't make sense, but OOP is fine in terms of implementing the board itself. A class would be a good way to isolate the data and provide a standard means of observation and safe manipulation. The benefit, like frob pointed out, is that implementing in this way allows a 'player' to be more or less anything (local player, network player, AI, chicken with a USB port wired to its brain, etc).

I'll agree. OOP doesn't make a whole lot of sense here.

Who are you agreeing with?
"Not everything has to be it's own class in OO" != "OO is nonsensical here".
If everything in OOP had to be a class, we'd be writing code like below, which we don't --
[font=courier new,courier,monospace]Assertion( Comparison( Adder( Integer(1), Integer(1) ).Result(), Integer(2) ).Result() ).Check();[/font]

Yeah, that'll start a holy war. I should probably bow out at this point...

Yes, in a thread asking how to use OO design in a specific situation, you're just trying to OO-bash, poorly.

Please no one take the bait.

[font=courier new,courier,monospace]Assertion( Comparison( Adder( Integer(1), Integer(1) ).Result(), Integer(2) ).Result() ).Check();[/font]

Smalltalk says Hi (I wonder why it never got much traction )