Player assignment in Tic-Tac-Toe I am building my first OOP program, Tic Tac Toe.  I want to conquer it in chunks, but the first part for me is the intialization of the program and the creation of the two players.  I want to get some feedback about how I structured this before I move on to build the board and the actual gameplay logic.  

For instance, should I have made the player_names assignment method part of the Player class?  Or is the parent TicTacToe class good?

class TicTacToe

    def initialize
        @player1 = Player.new
        @player2 = Player.new
        game_sequence
    end

    def game_sequence
        puts "Let us play a nice game of Tic Tac Toe!"
        player_names

    end

    def player_names
        puts "Player 1, what is your name?"
        @player1.name = gets.chomp
        puts "Thanks, #{@player1.name}!  Would you like to be X or O?"

        answer = ""

        until ["X","O"].include?(answer)
            answer = gets.chomp
            if ["X","O"].include?(answer)
                @player1.mark = answer
                break
            end
            puts "You must enter in either X or O"
        end

        case @player1.mark
        when "X"
            @player2.mark = "O"
        when "O"
            @player2.mark = "X"
        end

        puts "#{@player1.name}\'s mark is #{@player1.mark} and Player 2\'s mark is #{@player2.mark}"
        puts "Player 2, what is your name?"
        @player2.name = gets.chomp

    end

    class Player

        attr_accessor :name, :mark

        def initialize(name = nil, mark = nil)
            @name = name
            @mark = mark
        end

    end

end

TicTacToe.new
When coming up with an OO design, always ask yourself "What is the responsibility of this class?" There should be only one. If you have to describe it with a bunch of ANDs, e.g. "it runs the game and prompts for player names and sets up the board and..." then it is a sign you may want to break it down further. This is called the Single Responsibility Principle. Resist the temptation to put all functionality into one class that does everything, as it is very easy to grow the class into the antipattern known as the God Object. Sometimes naming helps. If instead of TicTacToe, you called the object GameRunner (for example), you may be less tempted to put any and all Tic Tac Toe related things into it.

In your case, I'd try to keep TicTacToe as lean as possible. Prompting for a player's name should be something a Player object knows how to do, so I'd move that to the Player class. Also prompting for a mark can certainly be moved into the Player class. Possible interface:

marks = ["X", "O"] #this would be in the initialization
player1.mark = player1.select_mark(marks)
player2.mark = marks - player1.mark


Also, you'll want to create an object to represent the game board.