Looking for advice on organizing classes in a 2d game.

I’m looking for some advice on the layout of classes and organization of a 2d, static screen monogame I’m building. The game itself is basically a Tetris clone, but instead of just dropping pieces into a well you’re controlling robots that are throwing Tetris pieces into a well.

A very generalized mockup can be seen here:http://i.imgur.com/PcdqO45.jpg

I’ve got a pretty good grasp on how I want to program it but not how to fit all the pieces together. I’ve already got a working Tetris class (Blockwell.cs) and now I need to wrap that in a 2d engine and put in player sprites. When I started trying to figure out what the classes would be and what would be abstracted out I find I keep second guessing myself what logic should exist where. I would appreciate some advice on how you might split out the classes or how you might arrange the data. I’ve made a diagram of how the classes would be built and instantiated (The arrows indicate, more or less, which way the objects would be created and which data would flow.)

The actual details of the classes and objects as I see them working out are:


  • Default class of Monogame

  • Runs the loop that draws the screen at 60fps.

  • Tasks are takes care of translating from the X/Y coordinates in GameLogic to the screen X/Y coordinates.

  • All screen drawing effects will take place here.

  • Runs the content manager and will load the Texture2d objects for GameLogic.cs


  • Where all the game logic and player objects exist.

  • Takes care of collision detection, movement and game event logic.

  • Has a sub class of GameObject.cs and maintains a list of GameObjects that it will iterate through to update.

  • In Game1.cs there’d be a call of “foreach (GameObject obj in gameLogic.gameObjects) { spriteBatch.Draw(obj.spriteTexture…);}


  • Has the core logic of Tetris.

  • Player Actions are fed in and BlockWell calculates the block events (Does the block fall, do the lines clear, can I rotate this piece, etc)

  • Has a public playfield that is read to generate the fallen blocks and current block sprites


  • Takes a playfield object from BlockWell and creates background Texture2d.

  • Only called when an update is needed, not every frame.


  • Holds layout of walls

  • Holds logic of gameplay items


  • I want the layout of different stages to be defined in XML files so it’s easy to spin up new levels without recompiling. This class will import XML files for LevelLayout.


  • Holds the button mappings lookup table. E.g. “Gamepad 1 - Button 1 = Rotate Player 1 block Left”

  • This class will receive the current keypresses from Game1.cs then call player events inside of GameLogic.

I’ve never worked on a puzzle game before, but I can say that with a simpler project like a tetris-inspired game, the layout of your classes isn’t too important as long as it works. I’ve never had a GameLogic-type class, I usually just call Level.Update() from Game1, which calls Update on all the GameObjects and updates other things for the level, but it doesn’t really matter too much, I think.

I’m by no means a reliable or conclusive source for this sort of advice, though. A more experienced programmer could tell you better.


You could take a look at game components. I like to use it to separate out modules of code (e.g. User Inputs, Networking, etc) so the Game class isn’t one giant file.

The game appears to be fairly straightforward though. I wouldn’t worry too much about design; if it works it’s probably good enough.