The initialisation phase is the phase in the Stratego game where the player has to place all of his
pieces on the board. Once this has been done, he presses the START button for the game to begin.
At the start all of the pieces are displayed at the bottom rows of the screen.

The screen with the coordinates looks like this (picture courtesy of Andrew Bates):

The pieces to be placed on the screen lie in the bottom part of the screen. These are picked up by the player
and placed on the board.

Data Structures


The basic data structure containing all information needed during this phase is:

start_piece start[START_X_DIMENSIONS][START_Y_DIMENSIONS]; where START_X_DIMENSIONS = 6 and START_Y_DIMENSIONS = 3

A 6x3 dimensional array is used throughout the initialisation phase. The dimensions of this array are closely related
to the board squares of the screen. Therefore, its dimensions represent the first three rows of the screen,
which consist of two rows of pieces and one row of buttons. Thus, start[2][1] will correspond to a specific piece while start[1][0] to a button.

The elements of the array fully analysed are:
  • int player : Player identification
  • String name : Piece name i.e. Marshal, General, Bomb ...
  • int remaining : Piece revaling the number of pieces of type name yet to be placed
    This array is used throughout the initialisation phase of the game, during which the players place their pieces on the board.
    Each element of the array is associated with a piece and contains the information needed to define it and check how
    many pieces of this kind have yet to be placed (field "remaining") by the player defined by the player field..

    For reasons of clarity, the numbering of the array corresponds to the numbering on the screen.
    For example, start[2][1] corresponds to the square x=2, y=1 on the screen.

    INITIALISATION

    When initialising the array all pieces are placed to a specific position. These positions are described by the code below:

    /* first row */
    start[0][1] = marshal;
    start[1][1] = general;
    start[2][1] = colonel;
    start[3][1] = major;
    start[4][1] = captain;
    start[5][1] = lieutenant;

    /* ...second row */
    start[0][2] = sergeant;
    start[1][2] = miner;
    start[2][2] = scout;
    start[3][2] = spy;
    start[4][2] = bomb;
    start[5][2] = flag;

    Initialisation is not necessary for the buttons since we know their coordinates from the start. Therefore whenever referencing
    start[0][2] we know it is a sergeant and so on.

    COMMUNICATION

    When exchanging information with the input and network modules the negative values of the y-coordinate are used so that we distinguish
    the top part of the screen from the bottom. These values can be seen in the picture of the screen below.
    For example, when a sergeant is placed on the field, a move command is generated i.e.move(1,0,-2,4,5). When the core receives this
    it gets the absolute value of the y value and accesses the data structure. Now it knows that a sergeant (found in start[0][2]) wants
    to be placed on the field.

    In addition whenever a placement has been completed the battlefield array(which is the basic data structure used throughout the batle phase)
    should be updated accordingly.


    Data Flow and Rules Checking


    During the initialisation phase, there are specific rules that have to be preserved. Whenever an input is received from the input module,
    the action is verified against the game rules and the two basic data structures of the game. The actions performed and the verification
    process when a move command is inputted, is described in detail in the Data Flow Diagram below:

    Circles represent terminal conditions. When we have text inside inverted commas (") then it represents a string being outputted on the user's
    console. When there is no commas then commands are represented. When there is a diamond then we have a conditional.

    NOTES ON DIAGRAM

    1: "update battlefield" is the link between the initialisation and the battle phase. This action updates the battlefiled array which stores
    all the information need later on in the game.

    2: "remaining--" is the action taken when a piece has been successfully placed on the field. This indicates that a piece of type start[x1][y1].name
    has been placed and that there are start[x1][y1].remaining-- pieces of this type yet to be placed.

    3: There are 4 actions that are performed when a piece has been successfully placed on the board. These are:
  • decrement number of this piece remaining to be placed
  • update the battlefield array with the new placement information
  • draw graphics. This would display the piece on the battlefield part
  • send a move command to the network. This command would later be received by opponent and observers and they would perform the actions
    outlined by number 4 below.

    4: When receiving a move command from an opponent,(i.e. player did not send the command) a player has to:
  • update the battlefield array with the new placement information
  • draw graphics. This would display the opponents piece on the battlefield part

    5: As we see if the console is an observer all it has to do is draw the graphics. The observer does not validate or check the legality
    of a move since this has already been done by the sender of the command. Finally, the battlefield array is updated so that the observer
    keeps its data up to date. This is necessary, as it has to know what piece to draw at any time during the battle phase of the game.

    Apart from a move, we can also have a button input. A button is pressed to indicate a quit and a start. Additionally, a button signal, is used
    upon initialisation of the game. This is sent from the lobby to indicate what role of the core will be and if it is a player it assigns
    to it a unique integer identifier. To avoid confusion when setting this variable, the x parameter is set to 2 and the player parameter is the
    unique identifier. If this identifier is 2, then the console is used as an observer.
    The actions performed and the verification process when a button command is inputted, is described in detail in the Data Flow Diagram below:


    NOTES ON DIAGRAM

    1: x only takes the value of 0,1,2. 2 assigns the console to an observer, and 0/1 are the player identification numbers.

    2: if the console is an observer then ignore the button press since an observer has no right to interfere with the game

    3: the turn variable is used as a semaphore and controls the turns at which the players play

    4: battle_started is a variable checked every time a movement is made to check if we are at the initialisation or the battle phase of the game.
    Upon initialisation of the game, this variable is set to FALSE. When all pieces placed and start button is pressed this variable is set to TRUE, to
    indicate that the game has started.


    Please email me if you have any questions.

    Proceed to battle phase
    Back to core module home page
    Back to core design page


    Copyright © 2002 Spyros Lambrinidis
    Last Updated 16/03/02