Journal Articles
| Browse in : |
All
> Journals
> CVu
> 124
(22)
All > Topics > Programming (877) Any of these categories - All of these categories |
Note: when you create a new publication type, the articles module will automatically use the templates user-display-[publicationtype].xt and user-summary-[publicationtype].xt. If those templates do not exist when you try to preview or display a new article, you'll get this warning :-) Please place your own templates in themes/yourtheme/modules/articles . The templates will get the extension .xt there.
Title: Building the Board
Author: Administrator
Date: 03 July 2000 13:15:37 +01:00 or Mon, 03 July 2000 13:15:37 +01:00
Summary:
Body:
The board is composed of hexes which, in turn, are composed of colored areas. The design of the hex was considered last issue. The construction of hexes into a board will be addressed in this column. In the previous column, the hex requirements were numbered. To prevent confusion when referring to requirements in this and subsequent columns, requirements will have both a number and a subsystem. In this way, the first hex requirement would be Hex-1, the first board requirement would be Board-1, and a requirement which effected both might be Hex/Board-1. So as long as things are simpler now…
The board is composed of hexes displayed in a specific pattern. The initial board we will build will be composed of 19 hexes. The hexes are laid out to form a board in the pattern shown in Figure 5. In this figure each number represents a hex.
01 10 06 17 02 14 11 07 18 03 15 12 08 19 04 16 13 09 05 |
| Figure 5 |
The board is composed of 19 hexes laid out in the pattern shown in Figure 5.
The number of hexes in the board with 3, 4, and 5 color sections is also predetermined. There is only 1 hex with 5 color sections, 6 hexes with 4 color sections, and 12 hexes with 3 color sections.
The board will be composed of the following mix of hexes: 1 hex with 5 color sections, 6 hexes with 4 color sections, and 12 hexes with 3 color sections.
The hexes that compose the board are selected randomly from within this subset and placed into the board in the order shown in Figure 5. In addition, the hexes are randomly rotated before being placed into the board.
The hexes are placed onto the board in the order shown in Figure 5. The hexes are generated randomly.
As hexes are placed onto the board, they are rotated randomly.
Because pieces move across the board from hex to hex, it is important for the board to know which hex is a neighbor to another hex and which faces of the two hexes are touching. Thus, the board should respond to a query for the neighbor associated with a specified face of a given hex.
The board should be able to respond to a query for a neighbor from a given face of a given hex.
When the game begins, players select three adjacent perimeter hexes as their starting points. Once the first player selects three hexes, the remaining possible positions are determined. Thus, the board should be able to validate a given starting set of hexes and be able to specify what groups of hexes are available for starting.
The board must be able to identify available starting positions.
Looking at the strategy that may be involved in playing the game, it is quite possible that it would be important to identify the location of certain sequences of colored areas, the diversity of colored areas from a given starting area, the number of colored areas between an edge position and a starting position, etc. These strategy based requirements all involve manipulating information which is currently available from the board given the existing requirements set. As a result these types of requirements are not really of the board itself, but represent the types of manipulations of board objects which may occur. As such, these will be addressed as requirements of functions that are currently not defined.
There are other requirements of the board that will be addressed when other game structures are being developed. For the purposes of getting started, these requirements will be ignored.
Since we are looking to design objects, it is important to consider interaction between objects. This section examines the interactions that can be anticipated at the current time between the board and a hex.
A hex needs to know its relative position on the board. In a sense this is similar to a chess piece needing to know on which square it is currently positioned. In a standard board (such as those used for chess and checkers), the board grid is generally represented as a two dimensional matrix. Thus, board positions can be identified by a tuple which indicates the location of a piece as an offset from the axis. In chess, one axis is usually labeled with letters ("a" to "h") and the second axis with numbers ("1" to "8"). In this nomenclature a piece can move from square "a4" to square "a5." The Swamp game board needs to have a similar system for identifying the position of a hex within the board.
A grid based nomenclature needs to allow unique identification of a hex position on the board.
The starting positions for players are defined as being three adjacent hexes on the edge of the board. Thus, it is important for a hex to know when it is on the edge of the board and which portions of the hex constitute the edge of the board. For two player games, the starting points must be opposite each other on the board, and for three player games, there must be an appropriate spacing between player starting positions so that all are evenly spaced around the board. This knowledge of opposite ends of the board and space between hexes needs to be captured in the hex and board objects.
It must be possible for the board to determine which hexes are diametrically opposed on the board.
Edge hexes must be able to determine how many intervening edge hexes separate them on the board.
Editorial Notes
I have published the above even though it is but a fragment of what Brett had planned for this issue. There is a serious reason for this so please do read these notes to the end.
In case any of you are wondering, it has nothing to do with the deadly silence on the mailing list we set up for this project so the guilty among you can relax. However, get yourselves on that list and start doing some work. I remind you that if we manage to bring this project to completion Brett was planning some way in which the end result could raise money for a charity nominated by our Disabilities Officer (Silas Brown, another member who gives unstintingly of his time and expertise)
One of the things that I always tried to promote when I was ACCU Chair was a sense of family among members. I care about people as individuals. I know that this feeling is shared by many members.
Enough pre-amble. Brett recently became the proud father of a son to add to his family of three adopted teenagers. Any of us who are parents know just how much extra stress such a welcome event adds to our lives; lost sleep being the least of our worries. In Brett's case this has been compounded by his infant son needing to return to hospital several times.
I feel confident that readers of C Vu will wish Brett's son and his loving parents a speedy return to peaceful and healthy existence. In the meantime, you can burn some oil with some coding practice. It would be nice to see some sample code being discussed and refined on the mailing list. Now what was the address of that list?
Notes:
More fields may be available via dynamicdata ..