Project Outline: During this assignment I will be creating a 4-player board game. I am focusing specifically on a combat system that has both non-determinist and intransitive mechanics. A board game that is both balanced in its primary form while also adding a layer of randomness that prevents optimal play. I will I start by analysing 2 board games: Risk and Chess and identify key features that will influence the development of the game. The Concept: May I present to you "CyberBlitz", a 4-player strategic board game set in the realms of cyberspace. Each player takes the role of a hacker as you utilize virus units to attack opposing players bases. Successfully destroying a player's base reveals them to the mainframe and kicks them out. The last player to remain in the system wins.
Chess:
Chess is a strategic game in which two players take turns moving pieces according to precise rules - only 1 piece can be moved per turn. The objective is to place the opposing players' king under direct attack with no means of escape. The board is chequered, consisting of 64 squares arranged into an 8x8 grid. The chequered pattern is broken down into black and white to help distinguish spaces; the players are also called, respectively, black, or white. (Though referred to commonly, it is important to note that both the board & its pieces are not always black and white in its literal sense, but instead lighter or darker in contrast). Taking a closer look at the precise ruleset assigned to the pieces, chess pieces can be broken down into 6 different types:
-The Pawn
- The Bishop
- The Knight
- The Rook
- The Queen
- The King
Each piece has its own move set and constraints when attacking/capturing a piece. Pieces can also be assigned a value of points depending on the strength of the piece to help identify what piece should be exchanged with another. To summarize, Chess is a battlefield between two feuding kings who dispense an array of units to seize victory by trapping the opponents' king in a state of capture. What particularly inspires me is the class system put in place by chess. Movement and combat are linked by the constraints of the piece. For instance, pawns can only move one space (unless it is a pawns first move) in a forward direction. To capture an opposing piece, a pawn must move diagonally into the opposing pieces square. If two pawns meet face to face, they can no longer move until one of them has been removed and the space is free. Pawns are considered a minor piece. We then observe the rook, a major piece. The rook can move as many squares as it wants both horizontally & vertically, but it is unable to move diagonally. These constraints are also the same when capturing a piece. Chess is a deterministic game. When a player moves a piece, both the player and opponent know where the piece will go and what is it able to achieve within its move. Pieces can also be taken out of play by any other piece regardless of attributes. Victory is often assumed by the player with the most skill as there is no random outcome, only optimal play. This is great for competitive gameplay, but it can easily lead to frustration if there is an imbalance of skill, which is something I want to avoid with a family board game.
Risk:
Risk (1957) is a strategic game set on a political map divided up into 42 countries, grouped into 6 continents. Players are in control of pieces which represent a numerical value of troops. players use their pieces to capture adjacent provinces by battling against defending pieces; results are determined with dice rolls. The number of players can vary between 2-6. Each player starts with 40 troops; if there are more than 2 players - 5 troops are to be deducted for each additional player. During a turn, players can either choose to pass, move, or attack. The player who controls all territories wins. The combat is based around dice rolls. Depending on how many troops an attacker places on occupied territory, an attacker can have up to 3 dice. Defenders can have a maximum of 2 dice. Attacking players roll their dice and discard the lowest roll, Defenders roll their respective dice, the two sides are compared. If an attacker's dice are higher, they may remove up to 2 troops from the defenders. If a draw occurs or the defending player has the highest dice roll, they may remove a troop from the attacking side for each dice the defender won. Unlike Chess, Risk is non-determinist.
Even if you have a much larger army than your opponent this does not mean you will win. Dice rolls add 1/6 probability which allows us to remove the skill required to win. This is not to say you are left completely to the whims of lady luck. Players can increase their chances by bolstering the territory to gain more dice.
We can identify the scales have been tipped to the advantage of those attacking if both sides meet at full force, however, probability still determines the outcome. It is also important to note that it is key to have the balance tipped in favour of the attacker as the game is based around conflict. If the defending side were to meet the attackers with the same number of dice, players would be less likely to engage in combat, specifically in smaller skirmishes, as the risk/reward ratio (no pun intended) would be at an almost level playing field.
Risk also uses a card system which allows players to reinforce their armies. To do so the player must match 3 specific cards. There are 3 different matches, each resulting in low, medium or high yield of troops. To acquire these cards players must capture territories.
Analysis:
When compared side by side both board games deal with conflict differently. The only thing that truly joins them is the strategic choices players can make.
In Chess your actions are finalized, an opposing player can only react once the move/attack has been completed. With Risk, players have the chance to challenge their aggressors during the exchange with a probability of coming out on top. I like the concept of specific pieces having set moves, attacks and the tactical decisions that need to be considered. I also like the randomness in outcomes from capturing strategic zones. Having extracted these ideas from both board games I will now incorporate them into my idea.
Initial Setup: Combat
I begin with the combat system. As a lover of history, particularly medieval and imperialism, I have been inspired to create units with attributes similar to military units of the time. I will then be masking their purpose to fit a virus theme. I currently have 3 units:
- Ranged
- Melee
- Cavalry
Intransitive gameplay can be most associated with "Rock, Paper, Scissors". The idea being there is no single dominant strategy, everything beats something else. For my current model, I have planned a simple ratio of 1:1:1. To determine each unit's value, I have created a table:
R M C
R 0 -1 +1
M +1 0 -1
C -1 +1 0
0 = draws| +1 = wins| -1 = LosesR = Ranged | M = Melee | C = Cavalry
From the table we can identify that Ranged beats Cavalry, Melee beats Ranged and Cavalry beats Melee. I then give each unit a pair of values. The first being a number of moves the unit can make, the second, a range in which it can attack another unit. Both of these values will be measured in square spaces on the board.
-Ranged: 4 Range, 1 move.
-Melee: 1 range, 2 moves.
-Cavalry: 2 range, 3 moves.
Initial Setup: interactive zones
Currently, the game is deterministic. Like a game of Chess, we identify how many moves each piece can make and build a rough idea to our opponent's outputs. We also understand the outcomes of combat which will be key in helping us make decisions. This is a good start for a strategic game; however, it is balanced which means optimal play will either dominate or lead to the game being solved. I need to apply some randomness, something that can change the probability without disturbing the intransitive mechanics. I have come up with two solutions.
1). Card system: Each corner of the game board will contain a pickup zone. When a unit enters the zone, the player may pick up a card. The cards will contain random numbers of viruses the player can spawn as reinforcements. (To help prevent card spamming, a rule has been put in place to prevent players going back and forth between the same square). By applying a random spawn system, I hope to achieve non-deterministic outcomes which could lead to players of less skill seeing more frequent victories. I have also created areas of importance which will allow players to make more tactical decisions.
2). Capture point: In the Centre of the board is a neutral zone that can be occupied by any player. When a unit enters the zone, they renounce their unit status and become a ranged unit able to attack anywhere on the board. They also lose the ability to move. I have envisioned this zone as a cannon which players can occupy. To keep in context with my theme I have labelled it "The Task Manager". By creating a neutral zone, I hope to instil urgency in a player's decisions, create subliminal objectives and add another strategic avenue for victory.
Both zones will change the flow of gameplay. Players are no longer out to attack one another; we identify that bolstering our armies can lead to an advantage. We also identify that having map control can help prevent others from receiving the same benefits.
Initial Setup: Board Design
We have 3 troop types - 2 zones of importance and a home base for each player to defend. Now I need to design the board. Early playtesting for combat was conducted on a 13x13 square board.
During the playtesting trials, it was recorded that Melee and Ranged would pair up and head to the centre of the board to occupy the Task Manager. Melee was often the vanguard and Range its support. Cavalry would usually be sent immediately to secure card pick up zones on each corner of the map. From my findings I have created two maps:
Map 1:
Map 1 has been designed with the data found from playtesting results. The amalgamation of a square and cross creates a symmetrical board with an equal distance between each player and the centre.
The board has an outer lane funnel which can be used to reach card pick up zones in each corner and eventually another player's base. Large portions of the map have been blacked out around the central cross to prevent players from avoiding conflict.
Each player has a coloured base protruding from the square frame. In front of each base is a spawn zone connected to three lanes. Left and right lead to card pick up zones and eventually another player base. The central lane leads to the task manager, an occupational space capable of attacking anywhere on the map.
Map 2:
Map 2 expands on map 1 and feedback from playtesting. By implementing an additional lane to the game board, I can include more card pickup zones. This iteration was due to the positive feedback of picking up cards.
The outer lane is twice the width of map 1 to allow for bigger flanks and tactical diversity. A 2nd lane now encompassing the central zone, distancing players further from one another. By distancing players, I aim to extend the average time in which conflict occurs, which in turn will result in more opportunities to pick up cards.
Both the inner and outer lanes contain card pick-up zones, allowing for more units to spawn. Player bases are now a row of three and can be entered from 2 points instead of 1.
Further playtesting:
I was able to secure one play tester. The ongoing Covid-19 pandemic, along with isolation has made it very difficult to playtest in person. I was recommended by my tutor Terry Greer to simulate my board game in Roll20 due to the recent success of remote play within the designer's guild. However, Roll20 suited towards tabletop RPG's and I found It wasn't flexible enough for my needs. To adapt to this situation, myself and the playtester took on the role of 2 players to compensate for the lack of playtesters. I felt that diverting from a 4-player game and developing the board game for 2 players instead would take away from my initial idea of creating a family experience.
Map 1:
Games lasted up to 1 hour. Playtesting revealed that combat was lacklustre, both I and the playtester felt there wasn't enough engagement and that intransitive mechanics felt too simplistic. The movement and range mechanics worked well though, as they allowed us to plan strategies within the constraints of each piece while considering what our opponents could do.
Task Manager: The Task Manager was too powerful. Because of the intransitive design, players who were able to successfully occupy the zone destroyed everyone's cavalry and range units. The only unit able to defeat the Task Manager was a melee. It also came to attention that the only units worth entering the Task Manager were range and cavalry. If a melee unit assumed the role of Task Manager, you were left with the Task Manager to deal with the oppositions range unless you were lucky with card reinforcements.
No troops: If a player lost all their troops, they would effectively be left with nothing to do except wait for someone to attack their computer.
Losing 1 attack could cost a player the game: A cavalry unit would win its battle around the edge of the map and hook around to the opposition's base. If there were no units to protect the base and the oppositions remaining troops were scattered, the opposition would be left to watch as the next turn removes them.
Map 2:
Only 1 game was conducted because of the time it took to finish. There were lots of ways for players to avoid combat and the additional card zones meant players could build up huge armies before anything would happen. Players could also create a frontline of troops to prevent opposing players from getting to their base. The card zones were easy to lock down, allowing players to quickly replenish any forces lost. It appeared the game wasn't going to end which soon led to frustration and boredom. From the results gathered from playtesting, I decided to scrap map 2 and focus on reiterating map 1 and redesigning the combat.
Iteration: Combat
A new combat system was needed. Intransitive mechanics work well for balance but felt empty when in practice. I took a step back and thought about what I want from the mechanics. I like the concept of blending deterministic and non-deterministic outcomes. The idea that one can predict a move or strategy, but its outcomes are determined by the randomness of probability can lead to interesting gameplay. More importantly, skilled play can only increase the odds of winning.
Each unit currently has a Move value and a Range value. I will now apply an Attack and Defence value to each unit. To fit my virus theme, I have labelled the attack value as Infection and defence as Detection.
For my new model of the combat system, players can now pit any unit against another and are no longer restricted by the intransitive system.
If the attack is equal to or more than the defence of the unit, the unit is destroyed. If the defence is higher, neither troops are destroyed.
Iteration: Player health system
Players were able to die in one hit once an invading unit entered a player's base. Players could also lose all their units and be left with nothing to do (effectively taking them out). To prevent either scenario, I have created a life system:
-Each player has 3 life cards.
-Attacking a player's base removes 1 life card from that player.
-To remove a player from the game, destroy 3 life cards and attack the base one final time.
-If a player has no units on the board, they may sacrifice a life card, allowing that player to spawn 2 random units distributed underneath the card. If a player has no units and no lives left they are out.
-If a player has been attacked for 1 life and has no units within their zone, they may immediately sacrifice an additional life to spawn 2 units, ready to retaliate on the next turn.
-There are twelve life cards in total. At the beginning of each game, players shuffle the cards and take 3 at random. Underneath the card face is a total number of units the card can spawn. Spawning consists of a mixture of units. 3/12 cards are strong reinforcements. 1/12 cards is a weak reinforcement. The remaining cards consist of a mixture of varying averages escalating in strength.
By creating the life system, players have a limited resource to manage, and a preventative against successful attackers. Reinforcements have been randomised, forcing players to adapt to events as they unfold.
Iteration: Card system
After our colossal game on map 2, it was decided that there needed to be an additional card type. One that could upgrade troops, change the map and affect players. This again would further extend the variety of play and avenues for tactical choice.
As I began to transition to my theme of cyberspace battles, I came up with two card types:
Invasion Card – Able to spawn a random number of viruses, much like the original card used throughout playtesting. There is now also a small chance to pull a card that prevents a player from supporting their virus units with dice rolls.
Utility Card – Contains an assortment of cards that can spawn tokens or affect the board. These include:
- Upgrade tokens that allow individual viruses to increase their attack or defence value by 1 point permanently
- Firewall tokens that can be placed anywhere on the map to block lanes and defend bases
- A purging effect that removes all firewalls, upgrades and player effects currently active on the board.
Alpha concept:
After much playtesting and iteration, I was able to determine a balance of attack and defence stats between each virus class.It was during another game that we decided to make the Polymorph virus (Melee unit) more powerful than the Malware virus (Ranged unit) or the Trojan virus (Cavalry unit). Though it was still beatable, the chances of either Malware or Trojan defeating the Polymorph were slim. The power given to this one troop changed the dynamic of the game.
The very nature of the piece was changed. What was once a simple melee unit, could now be perceived as a hulking menace slowly moving in for the kill.
The buff also had a positive impact on the other pieces, their roles becoming ever more vital. Trojans were our source of spawning more Polymorphs, while the Malware was busy supporting card zones and frontline Polymorph battles. Each unit finally felt like it had a purpose and from this breakthrough, I went into beta concept mode.
My only concern was that the game was getting too confusing. There was lots of data to keep track of. This, in turn, could put players off or just over-complicate the game if left unchecked. To prevent this, I will be creating an Operation Card. Each player will have one, and it will act as a hub for life tracking and a point of reference for the virus's stats.
Beta concept:
Each player now has 1 Operation card, and 3 Proxy server cards (Player lives). There is now a design for each unit that communicates its purpose, and a clear set of rules designed to be accessible. Viruses have been numbered 1-4 to help keep track of units in the field.
I was able to secure 4 playtesters during the beta testing stage. Before the playtest, all players were shown the rule book. Once they all felt comfortable and understood the game they began to play. During this phase, it was noted that players came to a consensus on the rules and were almost correct in their understanding of game play.
Playtesting was a success with the game running for just over an hour. There was a decisive winner, and some key flaws were identified:
- An Invasion Card effect that prevents players from supporting their troops needed to be limited to several turns rather than being a permanent effect as it was difficult to find the utility card needed to remove the effect.
- The Card buffering rule needed to be clearer. 1 player was very confused with the system when picking up cards, as they did not understand the concept. After reviewing the rules again with the playtester, they were able to identify how the system worked.
Playtesting Feedback:
Final Concept:
Having gone through multiple iterations, I can finally say failure is a good thing. What started as an intransitive game soon became a hybrid of deterministic and non-determinist mechanics, leading to more depth and interesting gameplay.
The board is emphasised around each corner outline. The same goes for the central grid which also has a printed radius for the Task Manager. Player bases no longer protrude and instead have been replaced with a zone, referred to as the Network Connection.
Future Revisions:
In the future, I would have 3-Dimensional game pieces for virus units and a token system to help players follow the buffering state rule. The buffering state is a rule which was created to prevent players from picking up cards from the same zone i.e., moving in and out of 1 space continuously. Here is an explanation:
-Each player manages their own buffering state.
-When a player enters a corner, they can occupy 1 of 2 card pick-up zones.
-Once a player has picked up a card, the card pick-up zones belonging to that corner enter a buffering state.
- The buffering state prevents that player from picking up cards from that corner.
-To remove the buffering state, move to a new corner and pick up a card The buffering state will be removed from the previous corner’s zones and placed on the activated corners zones.
-If a unit still occupies a buffering corner while another unit enters an active corner, the player does not pick up a card and the buffering state is not removed or transferred.
Currently, the buffering state must be remembered and tracked by players. For the future, I would incorporate a buffering token that each player can place when activating corners. This will help keep everyone informed and remind the affected player where they are unable to use zones. Currently, my game board is a paper prototype, and so by default, the pieces all look like tokens. I think the addition of physically managing the buffering state in the games current form may feel slightly overwhelming. But if all the troops were all 3d pieces, it would seem more organised and less cluttered allowing for players to visually digest each mechanic.
As for the board’s aesthetic, I would likely have a board designed in the form of a hardware system and the void space filled with virtual algorithms, binary and processes.
Graphics:
Trojan
The Trojan virus was simple in conveying its purpose. When playtesters read the bio from the rule book it further instilled the Trojan’s identity.
Malware
Malware proved difficult when finding a way to convey its purpose, attacking from range. After multiple iterations, I settled on a simple spikey ball outer casing much like a real virus. In the centre, a giant eye in the form of a scope.
Polymorph The Polymorph was another difficult virus to design; when the Polymorph’s mechanics were updated, a giant bug surrounded by more bugs seemed appropriate. Out of the three designs, I would probably change this model to something more menacing, but still insectoid in shape.
Below are PDF files for the Board Game, Rule Book, Troops, tokens and Card sheets. Please feel free to download, print out and play with your friends and family.
Comments