C#/XNA Newbie with a Design question

Question

I'm trying to design a small game using C# and XNA, before I start I wanted to make sure that this approach makes sense:

Basically, I want to create a GameObject Class that contains all elements that are common with everything I am going to draw on screen, be it a Weapon, Monster, Human, Pickup, etc.

So I was thinking I should create an Abstract Class called GameObject with Properties to set the Texture2D, Vector2 Location, A Draw() Method and a Move() Method.

Also, as I have Humans and Monsters, I could create a base class called Biped or similar and give it an "AttackBehavior" property (Which is a class in itself) so then I can create different attack methods (Humans attack Monsters, Monsters attack Humans). I would use an abstract implementation of the Move() method in my GameObject class so I can override it for items that don't move (Weapons, etc) and give different Move Speeds, patterns, etc to my Humans and Monsters.

So my questions are:

• Does this design pattern make sense? I've been reading Head First Design Patterns and reading about Composing objects (Hence my AttackBehavior object)
• What type of code should I put in my Game1.cs? Should this be the 'View' in the MVC pattern?

Answer 1

At the surface, yes the design makes sense ... but in my experience (YMMV of course) I've found that trying to start by designing a deep object hierarchy from the get-go results in decisions that will limit you later. Since every game is unique, I have better results when I just start coding, adding elements to the game, and refactoring as I go. If there are two classes with similar functionality, then I either make them inherit from a common base, or refactor out into a common class which can be re-used. That gives you the best of both worlds.

to your second question, the way that I wholehearted suggest you organize your game is by using the game state management sample:
http://create.msdn.com/en-us/samples/gamestatemanagement

download the sample, and learn it well ... it's a tried and true pattern

Answer 2

On a side note, I don't think that a weapon should ever be in the same class as something that is able to move.

Also try to separate your "model" from your sprites (think MVC for games). It might not always be the best idea to have a base object that both lets behaviour as visual extend. But for a simple game this is the quickest (and maybe) best approach. Really matters what size you're thinking. (Always start small in the beginning).