Provide a group of C++ classes that implements the main game loop following the official rules of the Warzone
game. During the main game loop, proceeding in a round-robin fashion in the order setup in startup phase 4b.
The main game loop has three phases and is implemented in a function/method named mainGameLoop() in the
GameEngine class:
[ ] 1. Reinforcement Phase—Players are given a number of army units that depends on the number of
territories they own, (# of territories owned divided by 3, rounded down). If the player owns all the
territories of an entire continent, the player is given a number of army units corresponding to the
continent’s control bonus value. In any case, the minimal number of reinforcement army units per turn for
any player is 3. These army units are placed in the player’s reinforcement pool. This must be
implemented in a function/method named reinforcementPhase() in the game engine.
[ ] 2. Issuing Orders Phase—Players issue orders and place them in their order list through a call to the
Player::issueOrder() method. This method is called in round-robin fashion across all players by the
game engine. This phase ends when all players have signified that they don’t have any more orders to
issue for this turn. This must be implemented in a function/method named issueOrdersPhase() in the
game engine.
[ ] 3. Orders Execution Phase—Once all the players have signified in the same turn that they are not issuing
one more order, the game engine proceeds to execute the top order on the list of orders of each player in
a round-robin fashion (i.e. the “Order Execution Phase”—see below). Once all the players’ orders have
been executed, the main game loop goes back to the reinforcement phase. This must be implemented in
a function/method named executeOrdersPhase() in the game engine.
[ ] This loop shall continue until only one of the players owns all the territories in the map, at which point a winner is
announced and the game ends. The main game loop also checks for any player that does not control at least one
territory; if so, the player is removed from the game.
Orders Issuing phase
The issuing orders phase decision-making is implemented in the player’s issueOrder() method, which
implements the following:
[ ] The player decides which neighboring territories are to be attacked in priority (as a list return by the
toAttack() method), and which of their own territories are to be defended in priority (as a list returned by
the toDefend() method).
[ ] The player issues deploy orders on its own territories that are in the list returned by toDefend(). As long
as the player has army units in their reinforcement pool (see startup phase and reinforcement phase), it
will issue a deploy order and no other order. Once it has deployed all its available army units, it can
proceed with other kinds of orders.
[ ] The player issues advance orders to either (1) move army units from one of its own territory to another of
its own territories in order to defend it (using toDefend() to make the decision), and/or (2) move army
units from one of its own territories to a neighboring enemy territory to attack them (using toAttack() to
make the decision).
[ ] The player uses one of the cards in their hand to issue an order that corresponds to the card in question.
Note that the orders should not be validated as they are issued. Orders are to be validated only when they are
executed in the orders execution phase. This must be implemented in a function/method named
issueOrdersPhase() in the game engine. The decision-making code must be implemented within the
issueOrder() method of the player class in the Player.cpp/Player.h files.
Orders execution phase
[ ] When the game engine asks the player to give them their next order, the player returns the next order in their
order list. Once the game engine receives the order, it calls execute() on the order, which should first validate
the order, then enact the order (see Part 4: orders execution implementation) and record a narrative of its effect
stored in the order object. The game engine should execute all the deploy orders before it executes any other
kind of order. This goes on in round-robin fashion across the players until all the players’ orders have been
executed.
[ ] You must deliver a driver as a free function named testMainGameLoop() that demonstrates that (1) a player
receives the correct number of army units in the reinforcement phase (showing different cases); (2) a player will
only issue deploy orders and no other kind of orders if they still have army units in their reinforcement pool; (3) a
player can issue advance orders to either defend or attack, based on the toAttack() and toDefend() lists; (4) a
player can play cards to issue orders; (5) a player that does not control any territory is removed from the game;
(6) the game ends when a single player controls all the territories. All of this must be implemented in a single
.cpp/.h file duo named GameEngine.cpp/GameEngine.h, except the issueOrder() method, which is a member
of the Player class, implemented in the Player.h/Player.h file duo. This driver function must be in the
GameEngineDriver.cpp file.
Provide a group of C++ classes that implements the main game loop following the official rules of the Warzone game. During the main game loop, proceeding in a round-robin fashion in the order setup in startup phase 4b. The main game loop has three phases and is implemented in a function/method named mainGameLoop() in the GameEngine class:
[ ] 1. Reinforcement Phase—Players are given a number of army units that depends on the number of territories they own, (# of territories owned divided by 3, rounded down). If the player owns all the territories of an entire continent, the player is given a number of army units corresponding to the continent’s control bonus value. In any case, the minimal number of reinforcement army units per turn for any player is 3. These army units are placed in the player’s reinforcement pool. This must be implemented in a function/method named reinforcementPhase() in the game engine.
[ ] 2. Issuing Orders Phase—Players issue orders and place them in their order list through a call to the Player::issueOrder() method. This method is called in round-robin fashion across all players by the game engine. This phase ends when all players have signified that they don’t have any more orders to issue for this turn. This must be implemented in a function/method named issueOrdersPhase() in the game engine.
[ ] 3. Orders Execution Phase—Once all the players have signified in the same turn that they are not issuing one more order, the game engine proceeds to execute the top order on the list of orders of each player in a round-robin fashion (i.e. the “Order Execution Phase”—see below). Once all the players’ orders have been executed, the main game loop goes back to the reinforcement phase. This must be implemented in a function/method named executeOrdersPhase() in the game engine.
[ ] This loop shall continue until only one of the players owns all the territories in the map, at which point a winner is announced and the game ends. The main game loop also checks for any player that does not control at least one territory; if so, the player is removed from the game.
Orders Issuing phase The issuing orders phase decision-making is implemented in the player’s issueOrder() method, which implements the following:
[ ] The player decides which neighboring territories are to be attacked in priority (as a list return by the toAttack() method), and which of their own territories are to be defended in priority (as a list returned by the toDefend() method).
[ ] The player issues deploy orders on its own territories that are in the list returned by toDefend(). As long as the player has army units in their reinforcement pool (see startup phase and reinforcement phase), it will issue a deploy order and no other order. Once it has deployed all its available army units, it can proceed with other kinds of orders.
[ ] The player issues advance orders to either (1) move army units from one of its own territory to another of its own territories in order to defend it (using toDefend() to make the decision), and/or (2) move army units from one of its own territories to a neighboring enemy territory to attack them (using toAttack() to make the decision).
[ ] The player uses one of the cards in their hand to issue an order that corresponds to the card in question. Note that the orders should not be validated as they are issued. Orders are to be validated only when they are executed in the orders execution phase. This must be implemented in a function/method named issueOrdersPhase() in the game engine. The decision-making code must be implemented within the issueOrder() method of the player class in the Player.cpp/Player.h files.
Orders execution phase
[ ] When the game engine asks the player to give them their next order, the player returns the next order in their order list. Once the game engine receives the order, it calls execute() on the order, which should first validate the order, then enact the order (see Part 4: orders execution implementation) and record a narrative of its effect stored in the order object. The game engine should execute all the deploy orders before it executes any other kind of order. This goes on in round-robin fashion across the players until all the players’ orders have been executed.
[ ] You must deliver a driver as a free function named testMainGameLoop() that demonstrates that (1) a player receives the correct number of army units in the reinforcement phase (showing different cases); (2) a player will only issue deploy orders and no other kind of orders if they still have army units in their reinforcement pool; (3) a player can issue advance orders to either defend or attack, based on the toAttack() and toDefend() lists; (4) a player can play cards to issue orders; (5) a player that does not control any territory is removed from the game; (6) the game ends when a single player controls all the territories. All of this must be implemented in a single .cpp/.h file duo named GameEngine.cpp/GameEngine.h, except the issueOrder() method, which is a member of the Player class, implemented in the Player.h/Player.h file duo. This driver function must be in the GameEngineDriver.cpp file.