Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 09 Jan 2010
Offline Last Active Jun 02 2013 03:06 PM

#5063014 Separation of concerns in game architecture

Posted by on 19 May 2013 - 10:02 AM

I'm looking at writing a simple iOS game. I'm a .NET developer by trade but have only ever dabbled in writing games before. The game I'm writing is a relatively straightforward tile-based puzzle game. Since I have little experience of videogame architectures, I've done some Googling around for similar open source games and tutorials, to find out what the common design patterns are. I am looking, in particular, for the way the relationship between the physical, visual entities and their abstract, logical counterparts is managed. What I tend to see is something like this (pseudocode):


class Tile
    public int PosX;
    public int PosY;
    public string Value;
    public SpriteClass Sprite;


Now, when I see this, my architectural brain tells me that something smells bad. Tile is, in this instance, a logical representation of the individual Tile on a board. Its X and Y coordinates are graph coordinates, rather than physical screen coordinates. Its "physical" counterpart is its Sprite property.


I can't help but feel that Sprite should not - in fact - be managed by Tile at all, but that Tile should be exposed to some kind of independent manager that interprets the Tile object's position and creates the appropriate Sprite object, removing this tight coupling and making the Tile and the Sprite completely ignorant of each other.


Are my concerns unfounded? Is the above common practice in well-architected games? If not, can anyone provide any insight, tutorials or examples of a better way of managing the relationship between the physical and the logical?