You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 as setup in the startup phase, the main
game loop has three phases and is implemented in a function/method named mainGameLoop() in the game
engine:
Reinforcement Phase—Players are given a number of armies 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 armies corresponding to the continent’s control bonus
value. In any case, the minimal number of reinforcement armies per turn for any player is 3. These armies
are placed in the player’s reinforcement pool. This must be implemented in a function/method named
reinforcementPhase() in the game engine.
Issuing Orders Phase—Players issue orders and place them in their order list (i.e. the “order issuing
phase”—see below) through a call to the issueOrder() method. This method is called in round-robin
fashion by the game engine. This must be implemented in a function/method named
issueOrdersPhase() in the game engine.
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 armies still to deploy (see startup phase and reinforcement phase), it will issue a deploy
order and no other order. Once it has deployed all its available armies, it can proceed with other kinds of
orders.
• The player issues advance orders to either (1) move armies from one of its own territory to the other in
order to defend them (using toDefend() to make the decision), or (2) move armies from one of its
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.
This must be implemented in a function/method named issueOrdersPhase() in the game engine. The decisionmaking 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 their highest-priority order
in their list of orders (priorities: 1:deploy 2: airlift 3:blockade 4:all the others). Once the game engine receives the
order, it calls execute() on the order, which should 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 that demonstrates that (1) a player receives the correct number of armies 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 armies in their reinforcement pool; (3) the game engine will only execute non-deploy
orders when all the deploy orders of all players have been executed; (4) a player can issue advance orders to
either defend or attack, based on the toAttack() and toDefend() lists; (5) a player can play cards to issue
orders; (6) a player that does not control any territory is removed from the game; (7) the game ends when a single
player controls all the territories. All of this except the issueOrder() method must be implemented in a single
.cpp/.h file duo named GameEngine.cpp/GameEngine.h.
The text was updated successfully, but these errors were encountered:
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 as setup in the startup phase, the main
game loop has three phases and is implemented in a function/method named mainGameLoop() in the game
engine:
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 armies corresponding to the continent’s control bonus
value. In any case, the minimal number of reinforcement armies per turn for any player is 3. These armies
are placed in the player’s reinforcement pool. This must be implemented in a function/method named
reinforcementPhase() in the game engine.
phase”—see below) through a call to the issueOrder() method. This method is called in round-robin
fashion by the game engine. This must be implemented in a function/method named
issueOrdersPhase() in the game engine.
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 armies still to deploy (see startup phase and reinforcement phase), it will issue a deploy
order and no other order. Once it has deployed all its available armies, it can proceed with other kinds of
orders.
• The player issues advance orders to either (1) move armies from one of its own territory to the other in
order to defend them (using toDefend() to make the decision), or (2) move armies from one of its
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.
This must be implemented in a function/method named issueOrdersPhase() in the game engine. The decisionmaking 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 their highest-priority order
in their list of orders (priorities: 1:deploy 2: airlift 3:blockade 4:all the others). Once the game engine receives the
order, it calls execute() on the order, which should 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 that demonstrates that (1) a player receives the correct number of armies 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 armies in their reinforcement pool; (3) the game engine will only execute non-deploy
orders when all the deploy orders of all players have been executed; (4) a player can issue advance orders to
either defend or attack, based on the toAttack() and toDefend() lists; (5) a player can play cards to issue
orders; (6) a player that does not control any territory is removed from the game; (7) the game ends when a single
player controls all the territories. All of this except the issueOrder() method must be implemented in a single
.cpp/.h file duo named GameEngine.cpp/GameEngine.h.
The text was updated successfully, but these errors were encountered: