I'm working on a simple block-based puzzle game.

The game play consists pretty much of moving blocks around in the game area, so it's a trivial physics simulation. My implementation, however, is in my opinion far from ideal and I'm wondering if you can give me any pointers on how to do it better.

I've split the code up into two areas: Game logic and UI, as I did with a lot of puzzle games:

  • The game logic is responsible for the general rules of the game (e.g. the formal rule system in chess)
  • The UI displays the game area and pieces (e.g. chess board and pieces) and is responsible for animations (e.g. animated movement of chess pieces)

The game logic represents the game state as a logical grid, where each unit is one cell's width/height on the grid. So for a grid of width 6, you can move a block of width 2 four times until it collides with the boundary.

The UI takes this grid, and draws it by converting logical sizes into pixel sizes (that is, multiplies it by a constant). However, since the game has hardly any game logic, my game logic layer [1] doesn't have much to do except collision detection. Here's how it works:

  1. Player starts to drag a piece
  2. UI asks game logic for the legal movement area of that piece and lets the player drag it within that area
  3. Player lets go of a piece
  4. UI snaps the piece to the grid (so that it is at a valid logical position)
  5. UI tells game logic the new logical position (via mutator methods, which I'd rather avoid)

I'm not quite happy with that:

  • I'm writing unit tests for my game logic layer, but not the UI, and it turned out all the tricky code is in the UI: Stopping the piece from colliding with others or the boundary and snapping it to the grid.
  • I don't like the fact that the UI tells the game logic about the new state, I would rather have it call a movePieceLeft() method or something like that, as in my other games, but I didn't get far with that approach, because the game logic knows nothing about the dragging and snapping that's possible in the UI.

I think the best thing to do would be to get rid of my game logic layer and implement a physics layer instead. I've got a few questions regarding that:

  1. Is such a physics layer common, or is it more typical to have the game logic layer do this?
  2. Would the snapping to grid and piece dragging code belong to the UI or the physics layer?
  3. Would such a physics layer typically work with pixel sizes or with some kind of logical unit, like my game logic layer?
  4. I've seen event-based collision detection in a game's code base once, that is, the player would just drag the piece, the UI would render that obediently and notify the physics system, and the physics system would call a onCollision() method on the piece once a collision is detected. What is more common? This approach or asking for the legal movement area first?

[1] layer is probably not the right word for what I mean, but subsystem sounds overblown and class is misguiding, because each layer can consist of several classes.

  • \$\begingroup\$ Did my answer help, need any further information? \$\endgroup\$ Commented Feb 7, 2011 at 4:00
  • \$\begingroup\$ Please, either upvote and accept the answer if this has helped or tell about your problems implementing such an architecture or something, but keep us informed of your situation so that we may be of better assistance. =) \$\endgroup\$ Commented Feb 8, 2011 at 15:56

1 Answer 1


I'll try an attempt to answer this question as I can understand what you're asking, though I don't have much game development experience since I'm still only learning.

As I see it, you to to separate the GUI code from your game logic and domain objects, that is, the puzzle pieces. These are indeed three separate layers - and yes, layer is an appropriate term in my opinion. It is often used to explain the concepts of separating each objects level of a system into subsystems that are independent from each other.

In regards of object-oriented programming, each object shall be a class. So, each piece of your puzzle shall consist of a class per itself, and so the game board. The game board should contains X pieces of puzzle depending on its size and movement capacity that you want to give to the player.

So, here are my thoughts on the topic - I hope that it will help:

  1. The GUI layer: This layer shall contain methods only to display the pieces on the game board to allow the interaction between the the game itself and the player;
  2. The Game Controller layer: Is responsible for the player's inputs. That is the layer that should tell a piece to move in the different directions, and ask the game board whether there will be collisions upon movement and so on;
  3. The Business layer: This layer shall contains all of your business classes, that is, the pieces of your game and the game board object that contains the puzzle pieces.

In this architecture, you would have the GUI layer show the player of the game state, the location of each pieces of puzzle. The GUI layer would then be responsible for getting the player inputs and pass it to an underlying Game Controller layer, which would then be responsible for collision detection. If there's none, then the piece can be ordered to move into that input direction. To do so, you would simply have to call this piece's MoveLeft, MoveRight, etc. methods to make the piece move. You might as well let the game board know what piece you want to move, and then it orders by itself the piece's movement, and piece then moves into the demanded direction. This architecture makes it easy for testing each piece of code into the different layers, and then allows you for unit testing, integration testing and functional testing.

I know this might seem a little confusing at for sight, and thank god if it isn't! Should you require further details and help, please feel free to ask, I'll be glad to help the best I can though I'm a beginner into game development.

Thanks for reading! =)

  • 3
    \$\begingroup\$ Which sounds very similar to Model View Controller. \$\endgroup\$
    – tenpn
    Commented Feb 7, 2011 at 10:32
  • \$\begingroup\$ To be honest, any description of abstracting interface from underlying implementation is going to sound like Model View Controller. But that's because the terminology and techniques used are the same (abstracting away from implementation details, and separating user interface from implementation). But it assumes a very simple environment. There are multiple layers here, and there are controllers in each layer. Separating the view from the model isn't enough here, you need to also separate the user interaction control from the game control. \$\endgroup\$
    – MrCranky
    Commented Feb 7, 2011 at 13:30
  • \$\begingroup\$ I wonder what's so complex here, since we're moving pieces of a puzzle onto a delimited game board. The controls are gotten from the GUI, which is fact is a good way, and pass out to an abstraction layer, that is, the game controller. The game controller checks for collisions upon movement, then tells the piece to move if there no collision detected. The piece of puzzle then moves properly toward the requested direction and reveals its new position through its Position property getter function, so that the game controller now require the GUI to display this moved piece to that new position. \$\endgroup\$ Commented Feb 7, 2011 at 14:23
  • \$\begingroup\$ heh, I blogged about "MVC" in game development a few months ago. Yes, it's a good gateway concept for those uninitiated with game development: codecube.net/2010/08/xna-for-the-everyday-developer \$\endgroup\$ Commented Feb 9, 2011 at 17:53
  • 1
    \$\begingroup\$ Sorry for the late accept, I was unfortunately distracted from the project for a while. I really like the controller approach, I'll adopt it! \$\endgroup\$
    – user5207
    Commented Feb 20, 2011 at 15:23

You must log in to answer this question.