tend to design more in terms of state and transformations. Think about what structure can represent each valid configuration of your game unambiguously. Then think about which are valid transformations on that data and which actor has the authority to do these. This should lead to a nice code structure will well defined operations where classes control the integrity of the game state. EDIT: I realized this sounds pretty vague. Maybe it is because that's the way one should design regardless of language. I guess the TL;DR version would be: Don't think of OOP as a philosophy that forces you to program a certain way. Rather, think of it as a tool set that enables you to more efficiently implement a sensible design. If everything in OOP had to be a class, we'd be writing code like below, which we don't -- Assertion( Comparison( Adder( Integer(1), Integer(1) ).Result(), Integer(2) ).Result() ).Check(); smile if Ruby.isBeautiful? is_readable? depend_on_dev() : ruby_char_saver(); "Programmer" (n) - A person so utterly maladjusted that they can take a language as beautiful and expressive as Ruby and write something that looks like a declaration of war composed by a drunken, illiterate Klingon. If everything in OOP had to be a class, we'd be writing code like below, which we don't -- Assertion( Comparison( Adder( Integer(1), Integer(1) ).Result(), Integer(2) ).Result() ).Check(); smile if Ruby.isBeautiful? is_readable? depend_on_dev() : ruby_char_saver(); "Programmer" (n) - A person so utterly maladjusted that they can take a language as beautiful and expressive as Ruby and