Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I am working on a 2D game, where there's a game "board" on which other game objects are placed.

This this is 2D, my starting point was to design a class that will internally use a 2d array for the actual stored game objects.

This class could be simply accessed by 2 indices: (i, j) to get game objects on it.

My problem is that i have no idea how to make the game "board" "propagate" its data onto its children.

Design questions i ran into are:

  1. Should the children placed on the board have display properties such as size, screen position?
  2. Should the board itself dictate this information?
  3. How to update children in case the board changes some of its properties? (position, etc).
  4. Should the board be aware of the types of objects stored in it ?

I have no idea how similar things such as WPF or other UI frameworks go about organizing a "container like" object that can arrange or apply certain UI properties to its children.

share|improve this question
    
Work on your accept rate. –  Djentleman Jan 5 '13 at 0:03

2 Answers 2

Ideally, you'd structure it in whatever way would allow you to write self-describing code.

player["Black"].piece["Rook2"].move(2, 0);

Versus

chess_board.move("Black", "Rook2", [2, 0]);

Both of these are horrible pseudocode hacks and not exactly indicative of the final product, but hopefully provide consideration of how you might want to address the abstract concepts of playing the boardgame in terms of your code.

In terms of common issues, are you planning on animating pieces as they move?
If so, you might want pieces to control their own state.

Another consideration might be to "bind" and "unbind" pieces from squares.
Give the pieces a simple, loosely-coupled interface for querying the square they're in and/or the square they're moving to.

Your board could talk 100% in grid-coordinates (making rule-keeping easier, depending on the game), then the pieces could use those grid-coordinates to enforce rules, AND to request a connection to talk to their new grid square (dropping the connection to the previous square).

Most of the positioning logic for drawing, et cetera, could be held within a piece, which just needs to take the grid-coordinates and position itself inside the center of the grid square (when it's done animating).

At this point, pieces and squares could be put in separate arrays and updated separately, even.
Pieces would control their logic/presentation based on the grid coordinates they're given by the squares they're talking to.
Squares could maintain any bonuses that they might hold (snakes/triple-word-score/go directly to jail), and confer those to a piece, if the square believes that the rule is appropriate to that piece at that time (eg: go-to-jail/jail + just-visiting).

Note that this isn't THE way to do things.
In fact, it might be way over-engineered for your needs.
Or under-engineered.

Or it might just look like nonsense, because you'd really like to write the code from the perspective of the player who rolls dice/picks up a card/etc and manually moves a piece, versus a piece which moves itself or a board which pushes a piece around.

share|improve this answer

The answer to most of your questions is: It depends.

What you should keep in mind when designing this kind of system:

  • Does the grid have a constant size?
  • All cells have the same size?
  • GameObjects can be in-between cells?
  • Most of the cells will be full or empty?
  • How often does your GameObjects change it's position?
  • What is the source of logic? The board or the GameObjects?

If your board size is constant and cells are all of the same size, then it's good to make the board control the position. But if your GameObjects can be in-between the cells, then it's better to make them control the position separately from its index.

If most of your cells are going to be empty, putting your GO's in an array and just keeping it's indices available inside it is a good idea. If they most cells are going to be filled, an 2d array seems better.

To decide what updates(the board or the game objects) think of what is the source of the logic. For example: In a Chess game, it's a mix. The piece gives its rules, but the board knows where is everything.

And keep in mind: Do what feels right and seems good for you, but don't pre-optimize! If it's working and no flaws are detected, keep it this way.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.