Spider Pit Prototypes

Spider Pit, a dummy name for the project, is a game where two players set their gladiators against one another. Each person controls two gladiators, set on a board shaped like a spider web. The players move their pieces around, trying to attack the other's pieces. But placement has to be strategic. Each player's gladiators can have defense buffs if two of the same team's gladiators are next to each other, and likewise two gladiators of the same side can add an attack buff when attacking.

But there's more to placement, there's the actual clash initiated by an attacker on their turn if they choose to. When attacking, both players roll die. If the attacker rolls higher, they can attack one of the other player's gladiator. There are three types of weapons that can be drawn as cards: swords, axes, and shields. Swords leave bleeding damage, axes blunt damage, and shields both nullify the attack and do a small counter.

The core mechanic here is player elimination, supported by die rolling and a somewhat rock/paper/scissors styled clash with cards.


Play logs:

Play log 1



Me and the other player started out with one gladiator each, with 15 hp each. However, we immediately realized that we had no reason to move around the board, as we only had to move up to each other an attack each other until one of us died. After the game ended we decided to use two pieces (or gladiators) each.

Play log 2



Me and my sister started with two gladiators each, and reduced the hp pool to 10 hp each. We got through  few rounds before we started to lose track of who got what damage and had to start over the round. We used pen to mark our different pieces. I also modified the bleed mechanic, as the total sword damage plus bleed for two turns equaled the same total damage for the axe. The sword then became 1 damage on the initial turn, and then 1 bleed damage for the next three turns. It was still somewhat hard to keep track of with how fast the game can go, so after the game I decided to go with 2 damage on the initial hit, and then 1 damage for two turns after. I also decided to let sword attacks stack, which would be tested in the 3rd play log should someone play two swords in quick succession in rounds. I also decided to give a potential penalty for a player's gladiators being next to each other, to prevent players from just lining their two players up to get an infinite defense/attack buff. For each turn two of the same color gladiator are next to each other, the player rolls two die. If the number is lower than 5, the gladiators attack each other for 1 damage. The context here would be the spiders being untrustworthy of each other's team member, or worse, trying to cannibalize each other or some other arachnid madness. I may raise the threshold number in the 3rd play log.

The one main issue we ran into however is that we each came down to one gladiator, resulting in the same scenario in the first play through. I will test adding a third instant-kill "computer" player , aka the lion to the gladiator, that will be released when each player has one piece left, and will target the player with the most hp, though I would like to find a way to randomize it's movement, perhaps spinner based, and will go to the adjacent spot the spinner is pointing. The other thing that worries me is that if one player is down to one piece and the other has two, that it'll be easy to gang up on that last piece. I will test the mechanic of a player being able to attack and then flee, and that if that the remaining gladiator will be able to move a total of three steps per turn rather than two like the other pieces.

I also removed the middle spot in the board, as removing it forced players to be much more strategic. This could be a place for the spinner for the giant goliath spider later in game.

Play log 3



Playing with Areeb allowed me to really polish up the mechanics of the game. Only a few turns in did we realize that I kept forgetting to roll for when ally spiders were next to each other to see if they would inflict damage on each other. To better keep track, spiders had to be deliberately stacked to get a defense or an attack bonus on the given turn. This worked really well, as I had recreated the spider tokens to be four legged tokens (and I am now sticking to the term tokens for the spiders). So when they stacked they became one whole spider, adding the nuance and charm the game needed. It happened by pure accident too, which was really cool. These spider towers run the risk of toppling over each turn, and the minimum roll was increased from 5 to 8, and can only be used for two turns in a row before the spiders have to unstack, and require a cooldown period of two turns. They would both take one damage each as previously if they failed the roll, and be forced to unstack, as they had "lost balance".

When spider towers are attacked or attack, only the top spider takes damage, so a player can think about what spider has more hp to spare, or if a near-dead spider should go out in a blaze of glory.

The starting point for the spiders was also changed. Rather than both sides starting on opposite ends, the spiders were laid in an x formation, so that spiders from the same team start out separated at the beginning of the turn. It was also established that a spider cannot attack on the first turn of the game, only move pieces around.

During clashes, we found there were too many shields in the deck, and I cut the percentage of shields to 10% rather than an even 33% for the three types of cards.

The goliath spider was an interesting experiment, and the spinner used for it went through a few drafts. The first iteration was that the spinner's direction when it stopped moving would determine where the big spider would go. It ended up getting stuck in a corner and didn't really pose a threat, so instead the spinner would land on one of several labels that would determine the number of steps it would move towards player 1 or 2's remaining spider, along with an instant-kill spin for both players. The first spin resulted in Areeb's spider being instantly killed and ending the game. In future iterations of the spinner the instant-death space will be a lot smaller. I would also like to put the spinner in the middle of the board, to take up the space that was originally there.

Comments

Popular posts from this blog

Blog 5: First Playable

Blog Post 8: Final Project

Blog Post 4: Videogame Lab