I'm currently making a conversion of a board game I have - I don't intend to release it, it's merely to sharpen up skills. I'm currently refactoring it to completely separate game logic from everything such as rendering, getting user input, etc. The game logic is now in a library independent of the project that is actually run.

However, I've come across the problem that, if I don't store piece positions in the game state (as the game logic does not need to know about these), I'm struggling to think of how to store this information in the project that deals with rendering/user input stuff, so that it may render pieces.

Game State

The game state looks like this within the game logic - each district used to have a Vector2 indicating where the trouble marker would be displayed, and each piece would also have a Vector2 indicating their position on the board. They do not at the moment, as I wish to only have such things in the game project, as opposed to the logic project


I have thought of creating a clone of this structure but adding position information, or of trying to use inheritance. But both of these methods seem extremely painful to do in the situation, and I'd really prefer to keep the game logic completely unknowing of things like this.

How would I go about doing this cleanly? Is it possible, or do I need to do a complete rethink of things?

  • \$\begingroup\$ Could you do something like in the game project, the position Vector2's get sent into the logic project and are updated there? For example a base Piece class that has Vector2 in the logic project, in your game project you have a RedPiece that extends Piece. You call UpdatePiece(RedPiece as Piece) or however your language works. Hope that sounds ok and not confusing. \$\endgroup\$
    – lozzajp
    Oct 18, 2016 at 12:21
  • \$\begingroup\$ @lozzajp I'm not sure that'd work - pieces are placed and removed in the logic project without regard for their position other than the district they're in. So the logic project shouldn't have anything to do with the positions at all. Thanks for the suggestion though, I hope I haven't sounded like I've shrugged it off! \$\endgroup\$ Oct 18, 2016 at 13:08

1 Answer 1


It depends on if the game logic needs to know what the physical position of a gamepiece is. If that is not the case you can separate the render logic entirely from the gamelogic.

Suppose the game is Monopoly. You need to consider how to represent the board based on the information. For it to render it only needs to know the type (station, street, chance), if there are gamepieces on the square, any houses or hotels. This is all gamedata.

There is no need to include the exact positions of all pieces as they are relative to their parent container. So calculate the number of houses on that tile and draw them relative to that tile. Alternatively a tile with houses in them could also be represented as a circle with dots on the edges where each dot represents a house. For this you also do not need to know any Vector2 information in the game logic, as the circles are based on the number of houses and relative to the position of the tile (which in turn is relative to the previous tile and so on). This way, the board could be represented as a circle or a long winding strip or exactly as the 'real' board. As the presentation is just a matter of how you plan to represent pieces on the gameboard.

It becomes a different story if your game is like a tabletop wargame, where real positions become key (for example, distances within a district influence the odds a gamepiece can 'hit' an other gamepiece. In that event, you will need an exact representation of the gameboard in your logic as well.

  • \$\begingroup\$ It's actually partway between the two. The game logic does not care about positions at all - only the districts the pieces reside in. \$\endgroup\$ Oct 18, 2016 at 15:03
  • \$\begingroup\$ However, an arbitrary enough amount of pieces can be added to a district, and the player actively selects this, so the piece is placed where the player puts it - within the district selected, but also on the board, if that makes sense. So it ends up that while the game logic doesn't care, I can't just calculate the positions from the pieces in the district \$\endgroup\$ Oct 18, 2016 at 15:06
  • \$\begingroup\$ In that case you need to include the position- my advise is to store the position relative to the district. Use 0 to 1 as top/left to bottom/right. This way you can position the pieces but also hilight/zoom a specific district in a different view and still render the pieces in the correct positions inside the district. This effectively decouples the render logic from the gamelogic as the positions can be converted to whatever format you like for the render portion. \$\endgroup\$
    – Felsir
    Oct 18, 2016 at 15:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .