Blocktober 2019 Breakdown

I wanted to adapt a map that was based on the games Chivalry and Mordhau. These games pit players in PvP battles using Medieval weapons and tools to attack and defend. Maps where there is a constant attack and defend with objectives for the attackers is a Team Objective (TO) map. Since it is a TO map it is effectively a few maps put together. The objectives are informed by the style of the map because the environment would inform how someone would attack. 


  • Obj 1: Red (almost always attacker) must take the choke and raise the front gate for easier access to the keep

  • Obj 2: Red must hold the front gate and push the ram to the door. 

  • Obj 3: Red must hold both gate towers to raise the inner gates.

  • Obj 4: Red must eliminate the enemy King (blue)

ObjectivesView.jpg

With this in mind, I have several colors throughout my map which represent different things.

Purple = mechanical related objects that require scripting

Blue/Green = static environment

Grey = Terrain

Yellow = Important pieces, landmarks, and anything meant to stand out

GateExample.jpg

For me, this method makes it very easy to point out specifics such as "this tower" is important and I want the player to see it from "these angles". As well as, the gates are important, specifically the animal heads carved into the stone to signify which gate the player is at. However, let’s talk about what I did from beginning to end. I will layout a few key points:

  1. Study of the location and architecture, even fantasy concepts will be based on the real world. I want grounded majesty so references are important.

  2. I will sketch out the map from the top-down which is not always needed but in this case, it helped me layout the space within the walls.

  3. I create a reference and then I generate a cube that is about the size in width and height. I will also measure this against the player character to establish the scale. So, in this case, I started with the base of the outer wall.

  4. After doing step 3 several times I am able to create an anchor to work from. These help to inform spacing for the entire inside of the map.

From here I spent a lot of time running simulations in my head and running around as a player on the map. I did this a lot to determine if there would be enough room for fighting and if the various types of weapons would be useful. Some areas make bows, spears, and shields very useful, especially for the defenders.

I wanted objective areas to be clear to the player. These buildings or areas have the highest geometry on the map. I also wanted players to see most of these from both spawn points. For me, it is important for a player, especially in multiplayer, to be able to establish a mental map. The stronger the mental map the more the players can make meaningful decisions based on their position on the map.

BlueSpawnPerspective.jpg
RedSpawnPerspective.jpg

I also enjoy small juke spaces where a player can engage and disengage in an attempt to juke their opponent. Being able to slide into a doorway and run up some stairs or through the building. These little areas create fun experiences where players have to think ahead of their opponent. 

Things I would have wanted to explore but for lack of time could not. A better right pathway because the current one is very straight and angular. An underground section to create some alternate routes. A better castle section, it currently feels cramped.

RightSide.jpg

In conclusion, the #Blocktober2019 was fun and while I had limited time for this one I think it is a great block out to start with. I hope the information I have provided can help readers in some way or maybe help inspire creativity.

Avoiding Design Traps in Game Mechanics

This particular post is my thoughts & opinions on design traps in game Mechanic. 

Mechanic Trap: A mechanic purposefully or accidentally designed to look beneficial to the player but doesn’t provide appropriate benefit.

(this may not be the best description, but it is a starting point).

I have run into this many times in both digital and tabletop games. This commonly appears in RPG games, but is not limited to just that genre. A very brief example would be Dungeons & Dragons 3rd Edition where many feats available to the player actually provide little to no benefit. It can be argued that it is up to the player to make the choice of which feats they are going to take. However the deceptive nature of some of the feats leads us to question if the feat should be in the game at all.

While working on my tabletop RPG, Project Aymir D12, I ran into such an issue. I was designing the abilities for the rogue class and I gave them two reactive abilities. Reactive abilities are literally used as reactions to something and the player can only use so many “reactions” a turn. So, when I created these abilities I looked over both to make sure that the player would want to use them but have to make a skillful decision on which one to use due to their limitation.

Let’s look at the abilities: (these are just quick overviews of the skill and not the final description).

  • (R1)Quick Acting - if the rogue fails to evade an attack he can spend a reaction to attempt a second evasion roll.
  • (R1)Lucky Coin - When the rogue receives damage he may luckily escape the full force of the attack. Flip a coin, if the coin is heads reduce the damage based on your luck score. If tails take the full damage.

The issue here lays within the second ability Lucky Coin. The player gets a 50% chance to reduce damage or take the full damage. You may ask: What is wrong with this?

The skill provides a 50% chance to gain a bonus and costs an important resource. It doesn’t reduce damage to 0 unless the players luck score is really high. On the other hand the player could use Quick Acting and have a chance to negate the damage all together.

This causes “gamist” players or players with some common sense to only chooseQuick Acting as a skill because Lucky Coin is too risky and a trap/waste of experience. If players only choose Quick Acting and based on the games rules it is the most viable option then Lucky Coin doesn’t even need to be in the game.

In that case all we need to do is add some kind of “reason” for people to want to take Lucky Coin. With that in mind I added a second bonus to the player for getting tails on the coin flip.

  • (R1)Lucky Coin - When the rogue receives damage he may luckily escape the full force of the attack or cause the attacker to get hurt as well. Flip a coin, if the coin is heads reduce the damage by your luck score. If tails take the full damage but deal your luck score back as damage.

Now when the player flips the coin he receives a benefit from either side but he takes damage no matter what. This makes it so that players with high evasion may want to retaliate or reduce their damage when actually being hit, so they may take Lucky Coin. Players who do not have a high chance to avoid may choose Quick Acting to give them a second boost in dodging the attacks.

Conclusion:

When designing mechanics for anything make sure that there is a reason to choose all mechanics. It is important that the players decisions are skillful choices of their gameplay style. Adding a skill for filler isn’t a valid excuse to put it into the game. It is your job as a designer to piece together the interesting choices players can make.