I definitely got the game running a lot smoother. In fact it was so smooth and intuitive the players tended to fall asleep. This is not good. The choices were obvious and a bit repetitive, which led to a boring game. I also balanced the building of the webs too much, resulting in a simple strategy which was obvious and completely bypassed the Push-Your-Luck aspect of building frail webs and hoping a storm doesn’t come too soon. Fortunately this is all fixable.
I believe the players should have more things they would like to do than the resources to do it. This results in tough choices and compromises, as well as strategies and tactics that shift during the game. To accomplish this, I re-worked the web building action cards and spider powers. The player will have to choose a smaller working hand of cards, with the option of changing things up later, at a cost of course. The players will also have a good idea what the opponents cards are, but not enough information to guess their possible moves.
I introduced a foreshadowing stage and a very simple programming stage to the turns to encourage bluffing and trying out-guess your opponent. The programming of two action cards will hopefully add just a little chaos to spice things up. The baby spiders which are added to your web will encourage more asymmetry. The different spider powers and bonuses will hopefully provide multiple paths to victory.
I am ready for a playtest of version #5 tonight. Hopefully the game stays on the rails, the latest overhaul was done fairly quickly. Fingers crossed.
The last playtest was very constructive. The game flowed like an old engine wanting to start but sputtering to much to really get going. The problem turned out to be a wonkey turn rhythm. The heart of each turn is simultaneous play which seems to flow well, but each turn begins with a purchasing phase based on turn order. This disrupts the flow and takes the players right out of the immersive theme of the game. I yanked this part out and tossed it aside. In version #4, the purchasing is triggered individually with an action card, just like all the other actions. Turns should be simpler and more consistent now.
Another problem was the turn order token which is periodically passed from player to player. It was awkward, disruptive, and didn’t work well. I tossed that into the scrap bin as well. I’m working on a player order randomizer which can be implemented whenever required to resolve the order of playing actions. It will be pretty slick once I figure out exactly how to do it. Meanwhile, players can just draw colored tokens from a bag to determine play order.
The worst of the problems was the excessive randomness in the game. You could be doing everything right and still get beaten down by random events. There were actually four randomizing elements in the previous version. That’s enough to ruin anybody’s day.
Players drew random tiles from a bag to build their web, some of these provided much needed food, and others did nothing but expand the web. Draw too many of the latter and you’ll end up starving. This was not acceptable. The tile placement should be a decision point, not a punishment. I eliminated the bag, modified the way potential food points are implemented, and stacked the tiles in front of the players so they can choose which tiles to use. This even allowed me to implement a new headwind mechanism which I will describe later.
The second randomizer was the rotating action card market. This did nothing but handcuff the players. The economic constraints and the new card which allows you to buy or sell only one card is more than enough to mediate the market. Having a limited choice is not necessary. Having all the card types available (but in limited supplies) also helps promote asymmetric play and should make the game more fun.
The random draw bag containing the food and special events is definitely staying in the game. It adds loads of tension and a fun push-your-luck element to the game. This, along with the “Wiggle Die” which is occasionally used to determine if the bugs escape from your web, should provide just enough randomness in the game to make it fun and a little unpredictable.
The last playtesters wanted more player interaction. I had already planned on doing this, once I get the game flow right, so I have done this in the latest version. I’ve added a starting card which will enable every player to mess with an opponent’s web as well as a couple advanced cards which players can buy if they want to be more aggressive.
Finally, one last flaw reared its ugly head during the last playtest. There tends to be a slight snowball effect, when one player gains an advantage. A player could possibly gain a runaway lead and be un-stoppable. Rather than a blatant catch-up mechanism, which might seem contrived, I decided to implement a headwind mechanism to deal with this. In version #3, as each new spider was added to the web, an additional maintenance cost was un-covered, increasing the overhead costs of the web. I took this one step further and added an additional maintenance cost under the seven stacks of tiles in front of the player, This will hopefully slow down the run-away leader just enough to keep them in check.
The costing of items is currently seat-of-the-pants guessing. I plan on focusing on this once I get the game flow right. You can’t tune an engine until you get it running reasonably smooth, so the accurate costing of actions and other components might have to take a back seat for now.
I hope all these changes have the effect I desire, but that’s what testing is all about. Fingers crossed on version #4. You can check out the TTS prototype here:
The game is coming along quite nicely. The first playtest didn’t go, down in flames as usual. The worst that happened was that one player got a bit bored, and the mechanics and components were much too fiddley. This is all fixable, especially with the great feedback I received.
I started by reducing the board size to encourage more engagement (less boredom) amongst the players. The action selection system evolved into a mechanism much like the one used in Concordia. I added the ability to play two cards if they interact with each other so it wouldn’t be a total rip off of the Concordia card mechanism.
Drawing the food tiles out of a bag turned into a neat push-your-luck mechanism. I originally planned on using a die, but threw the tiles into a bag because I didn’t know how many faces I would need. It turns out to be a pretty nifty push-your-luck mechanism if you draw them all out one at a time, then refill the bag when it’s empty. I added the “Wiggle” tile to simulate the potential bug escapes as well as the Swarm and Storm tiles which have drastic effects on game play. If the storm comes out early, it’s a free-for-all as players built their webs as fast as they can before the bag is replenished and the storm risk increases again with each tile pulled. This bag has also simplified all the awkwardness of the earlier implementation of all four of these mechanisms, random food selection, escaping bugs, periodic swarms of bugs, and the occasional storms that come along and damage your frail webs.
I’ve switched to simultaneous play with a turn marker which is just used to resolve conflicts. This will speed up the game quite a bit and provide a simple programming aspect to the game. (One of my favorite mechanisms.) I’ve also modified the game set-up and beefed up the child spider capabilities to encourage more asymmetrical play. The first couple of turns are similar but the play diverges quite quickly.
I’ve streamlined the play as much as I can and tried to incorporate all the complexity into the cards. This, I hope, will make make the game flow better, and be simpler to follow.
The next test will determine whether I have succeeded in working out the initial bugs. Even though I’ve run through it quite a few times myself, It’s hard to see all the potential problems that might arise with other players. Fingers crossed.
My next step will be to fine tune the player interaction once the webs start running up against each other. The basic gameplay needs to be fine tuned first, before we get into the nitty gritty.
If you want a peek, you can check out the Tabletop Simulator Mod Here:
Arachnid You are a spider in a small area where other spiders (players) also reside. You build your web to capture food and expand your web as you build your small spider family, while defending your web from other spiders and competing for space and control. You are subject to the elements and interactions with competing spiders as well as periods of feast and famine, so you must always plan for the unexpected. Keep your colony on an even keel or you might slip into a rapid decline, or even a rapid expansion which could be just as bad if you’re not ready for it. You win the game by having the biggest and most efficient spider family.
At least, this is the way it plays out in my head. I have jotted down enough mechanisms, systems and components to choke a horse and have begun to sift through them to build a base prototype for testing. I’ve come up with some intriguing new mechanisms which are meant to constantly push the players toward chaos as they fight to maintain some kind of control over their spider family. It’s basically an area control / resource management game with a little “Push your Luck” thrown in. Oh yeah…I almost forgot…since it is my brainchild, there is definitely a little “Take That” in the game for fun. I hope it works because it sounds like it could be really fun. I’ll let you know when it’s ready to try on TTS.
I just read an article which explored the idea that a spider’s web was possibly an extension of its consciousness. At the very least, it was a part of its sensory system. It’s tendrils extend into the world and providing information in the form of vibrations about what is happening around the spider. It was an intriguing idea, and started me thinking about how to represent this in a game.
A typical tableau or engine builder probably wouldn’t be able to emulate this, but maybe an abstract game with a grid on which markers are placed in an ever expanding pattern. Events on the periphery could perhaps trigger a chain reaction which would somehow affect players pawn which could travel along this “web” like construct.
It’s an interesting approach and needs a little more thought, but I’m sure there is a game in there somewhere.
Lets create an artificial construct which might simulate spider behavior. It doesn’t have to be accurate but it should appear plausible. The game could have the following functioning parts:
Spiders respond to external stimuli like a fly landing on their web.
This behavior is an automatic reaction of the spider
They build elaborate webs
They cannot build and monitor their webs at the same time.
there is a central hub or home base in their web structure from which they monitor their webs
Spiders gain energy by eating flies
They expend energy by building webs.
Flies appear at random
The larger the web, the more food they can consume.
Spiders can choose to eat food or store it for later.
Capturing food damages the web and it must be repaired
Spiders compete for territory with other spiders
If an opponent’s spider enters a spider’s web, this will result in a battle.
Battles will result in a loss of energy which will have to be replenished.
The victor in a battle can steal an opponents food
A spider can lure an opponent into its web by moving adjacent to it and plucking the neighboring web.
If a spider runs out of energy it dies.
The webs can be constructed by laying marker pieces out on a grid. These webs can be free-form with each player being a different color. The home base would be a special marker and the beginning point of the web construction.
The spiders can be represented by a special pawn which can be placed over any web marker. It will be moved around the webs and will travel around the edge as the web is built. It must move to the home base to monitor the web and look for flies. The player has to decide whether or not to build or repair the web, monitor the web, eat some stored food.
The flies could be represented by a deck of cards. Some of the cards will have coordinates for bug-hits. These cards are revealed turn by turn and will randomize the bug hits in the webs. When a bug hits the web and a spider is monitoring it, it is captured. If the spider is not monitoring the web, a dice is rolled to determine if it will escape the web. This might happen repeatedly until the spider retrieves the food.
This is starting to sound like a viable concept for a game. I’ll have to give it some more thought and perhaps make a game out of it one day. It you have any thoughts about this game concept, let me know, I would be glad to hear them.
Recent Comments