Finally, I was able to incorporate some interesting decisions into the Arachnid game with version #10. Before this, the game was predictable, repetitive and things weren’t happening fast enough. The game and the theme promised loads of fun, but it just didn’t deliver. The players needed to make more interesting decisions and the players always wanted to do more. The new shifting action tableau solves both those problems.
Players get a hand of action cards and place them onto a constantly shifting action tableau which works like a conveyor. Each time a card is added to the left, the tableau shifts to the right and the last card is taken back into the hand. The cards themselves have three different, or modified, actions which trigger based on the card position in the tableau. As the cards progress down the tableau, the costs of the actions tend to increase, and, in some cases, the actions change.
The player can perform any or all of the actions available on the tableau as long as they can pay the associated costs. Instead of a card action, a player could place a movement token on the card to move a spider, or a consume token on a card to eat the bugs on their web. On the next turn, the skipped actions will shift to become more expensive.
The player is faced with some interesting decisions. The timing of when to introduce actions into the tableau and the necessity of sacrificing actions to consume bugs and move their spiders, makes for some interesting tactical planning. Performing multiple actions effectively is fun and changing your tactics because of another player’s interactions is maddening. (But still fun.)
The game flows much faster and is full of some tense moments. I’m just tweaking things now to get the bug economy working right and make the game flow smoother. Version #10 is ready for some real testing. Fingers crossed!
In the previous version, I decided to eliminate as many constraints as I could and let go of the reins. As the playtest started, I eagerly anticipated the game moving along like a run-away stage-coach at break-neck speeds……but I think the horse may have fallen asleep. The most insightful comment was “The best part of the game was the teach”. In other words, the game was full of promise, but just didn’t deliver on any of them. I had to call it quits early again because the game just wasn’t progressing. The economy was also dysfunctional, one player just couldn’t get things rolling because of an early expenditure of energy to buy an action card, and another player experienced an over-abundance near the end. Much of the excess gains were just wasted, but in spite of this, the players, still, couldn’t do what they really wanted. The energy track and maintenance costs were simply not working.
I know there are some fun bits in this game, but the players just haven’t been able to get to them. It’s time to take a serious look at the economy of the game.
The second problem, of excess resources, is easy to fix. A slight rule change regarding the incorporation of the bug hexes into a player’s web and a different distribution should correct this problem. These tiles will also be double sided so that their function will be more clear. The broken economy, however, is another story. I’ve often heard the expression “Sometimes you have to kill your darlings” as it pertains to game design. I decided to take out what I originally thought was the most crucial part of this game. The Energy track, along with the maintenance costs are being eliminated.
There will still be some type of economy, but it won’t be an explicit energy track because the maintenance costs are unnecessary and punitive. Players can incur costs many other ways, like opportunity costs when they have to decide between one action or another, or spending resources or actions to gain new abilities. I will be reworking the action card mechanics in order to embed these costs in a less direct way. This might be a bit tricky but I’m sure it can be done.
Another thing that came up in this playtest, as well as the prior one, was the ability of spiders to move onto the opponent’s webs. I originally didn’t allow it, but I really can’t see why this shouldn’t be allowed. This can open up many strategic possibilities, and the opportunity cost of being on an opponent’s web, rather than expanding your own web, will help counter-balance this tactic. I don’t know why I didn’t allow this sooner.
It’s time to move on to version #9. Hopefully the next game will make it all the way to the end. We’ll see what happens with the next major play-test.
I fixed it “real good”, the last play-test was a disaster. I felt sorry for the play-testers who suffered through this last version of this game. I made a few last minute changes which streamlined the rules, but the precariously balanced energy economy took a turn for the worst. One player, just couldn’t get his engine (his Web) going well enough to accomplish anything. The other player slipped into a state of economic decline which was impossible to climb out of. I had to call it quits early to relieve them of their suffering. That was just one of the problems.
Aside from the broken economy, one of the underlying premises of the game was simply wrong. The game was intended to induce great economic swings, pushing a player between feast and famine which triggered certain automatic events, resulting in even more changes to the economic state . This boomerang effect rarely happened, and when the players actually wanted feast or famine, it was very hard to accomplish intentionally. This resulted in a boring game where players were often financially struggling, and would occasionally get beat up by the game. The few rewards the game gave out seemed random and the players didn’t have enough decisions which drove the game forward. Looking back, this was just a bad idea. What was I thinking?
If you were very familiar with the subtle economics of the game and played it a certain way, it could be fun. In real life, however, the game would likely end up in the trash can or be pitched off a roof long before anybody mastered the games many quirks. It’s time to dump the see-saw, semi-automatic, and often abusive economic system. Players just want to build webs and do what spiders do.
One thematic disconnect which the play-testers didn’t really complain about, but I had issues with was the baiting of the webs. Spiders aren’t fishing, they don’t put bait out to attract bugs. They go where the bugs are and try to snare them in their webs. The new version resolves this, and eliminates the awkward and fiddly mechanism of placing out bait tiles as well. The bug-hit areas are now distributed around the board, and the spiders have to expand their webs to to surround them. These special areas constantly accumulate bugs, enticing the spiders to compete over them.
One play-tester was not happy with the energy economy in any form. He was expecting more of a tile-laying puzzle, which is implied by the use of spider webs in the game. I think he might have been dissuaded more by the perceived scarcity of energy than the economy itself. Perceived scarcity, consumes much of a player’s cognitive bandwidth and can cause players to subconsciously fixate on the scarce item. This can result in overlooked opportunities, poor decisions and feeling that you don’t have enough player agency. Giving everyone more opportunities to overcome periodic scarcity and providing more potential abundance should overcome the extreme scarcity issues. This is addressed in the latest version.
As far as the game having an economic element goes, I believe that this accurately portrays a spiders life. Spinning a web, patiently waiting for bugs, and trying to capture enough food to make it another day is basically an exercise in energy economics. In times of abundance spiders will procreate. In times of famine, they conserve energy and try to make it to the next meal. It’s tough being a spider.
One feature that I’ve been wanting to implement is the greater use of different spider personas. Players can now decide which spider they will be at the beginning of the game and add additional spiders to their web with unique abilities. Asymmetry is always a nice feature to have in a game.
In this latest version (8d) I have eliminated the tight economic constraints, eliminated some of the awkward mechanics, and given the players more choices which drive the game forward. In other words, I’ve let go of the reins. Hopefully the game will stay on track and not end up in a heap on the side of the road. Fingers crossed.
Feel free to check out the latest virtual prototype in Tabletop Simulator. If it works out, I will start working on a proper set of rules. Drop me a line if you want me to guide you through it or play a game with you.
Comments are always welcome, whether it’s a shout-out, a compliment on my ingenious insights, or a even a crack about me being completely bonkers. I would love to hear any feedback.
It looks like most of the core mechanics worked. However, the Loss Aversion monster reared its ugly head. The players were punished severely when the storm hit and further hammered when an unusual number of bugs escaped from the web. This caused some bad feelings for the players because they felt that they lost everything they gained in a quick one-two punch. There are a few reasons for this.
Removing the limits on the actions resulted in the two new players quickly slipping into a decline position which was hard to climb out of. This might have been caused by my game teach being sub par. I may not have made the magnitude of the consequences clear enough as well as the importance of not over-extending yourself. The economy is very tight in this game and un-forgiving.
The lack of readiness for the upcoming storm resulted in an overly severe result when it did happen. The bugs escaping was the straw that broke the camel’s back. It was an overly harsh penalty when both players were financially strapped. I definitely need to “Nerf” the “Wiggle” mechanism which allows bugs to escape from the web, this is just cruel and unusual punishment. The storm, however, needs to stay in the game because it is a critical timing mechanism, as well as providing a great deal tension.
Once the players have survived their first game, they will get a good feel for these events and learn how to deal with them. The “Wiggle” tiles discourage players from storing too much food and add a moderate level of risk, but they can be toned down a bit to lessen the punch without affecting the timing of the game. The “Storm” tile enhances the energy swings from feast to famine and cannot be removed. It can, however, be tamed a little for the first time play of the game, until players get a good feel for the rhythm of the game.
This is where the training wheels come in. The idea of no limits in the game simplifies the play, but it can be very un-forgiving if players make one or two errors in judgement. The first experience should be fun so I am introducing a beginning mode to the game. In this mode, all multiple actions will be capped at two and the storm will be capped at a maximum of two destroyed web spaces. This should help prevent the rapid slip into a “Decline” state for beginning players.
During the last test, I changed the direction of the “Robo-Spider” token, not realizing that this would reduce the rate of energy introduced to the game. This created an energy crisis and we had to give everyone bonus energy, just to get through the play-test. I will try it again on the next test with the right energy balance in mind.
I will also modify the Home action so it triggers the feeding/maintenance cycle as soon as it is played. Delaying it only causes confusion and disrupts the rhythm of the game. I can’t remember why I chose to delay this action, but whatever the reason, it was a bad one. The actions should be simple, you play a card and perform the action.
One more problem with the last playtest was that the players felt the movement was too restrictive or costly. This hampered the expansion of the webs and slowed down the game. I will address this problem after I get a good test with the previous revisions I have planned. It’s too early to address this one at the moment.
Once players get a game or two under their belt, they can remove the training wheels (action and storm limits) and take on the full risks of their actions. The players can also flip the game board over to the advanced side where they create their own map boundaries and choose where to place the “Bait” markers. If that’s not enough, they can head to the local game store and buy “The Hunters” expansion which adds non-web spinners like the Wolf Spider, Jumping Spider and the deadly Wandering Spider. This, of course, will be long in the future. I need to get this game going first.
Feel free to comment and let me know you want to try the game out on TTS.
I thought I was at the tweaking stage of this game, but when one of the playtesters’ most positive comments is “Well….I didn’t hate it…..” it’s time to take a good look under the hood and start yanking out the bad parts of the game. I know there are really fun bits in this game, but they are currently buried somewhere under the convoluted, redundant and totally unnecessary mechanisms which should be chucked to the curb like a useless old tire.
I added a programming mechanism to the game, simply because I love programmed actions and I thought that the occasional time that you out-guessed your opponent would be really cool. This hampered the players actions and the structured turns required for the programming, revealing and execution of the actions slowed the game to a snail’s pace. It did much more harm than good…..Into the trash bin it goes!
I have this awful habit of trying to control the players behavior with more rules and constraints. These often go against the natural flow of the game and tend to handcuff the players so they can’t do what they really want to do. I have to remember that, if the game is designed right, it will keep itself on track and often control the players indirectly.
One example of this was the limited abilities of the action cards in this game. One let you “spin” or create a web space, and the other reinforced the frail web spaces to protect them from occasional weather events. I limited these actions to one or two spaces. This handcuffed the players and made them feel that they couldn’t build their webs fast enough. The tight energy economy and the physical limitations of expanding adjacent to the player’s spiders already limited the actions, so the explicit limits were unnecessary. I removed these limits on the cards so the players are free to expand as fast as they want. The limited resources and physical limitations are enough to keep the game in check.
The convoluted turn procedure of placing, programming, and revealing the cards is gone. The players simply play a card and perform an action. This will greatly speed up the game and let the players concentrate on the area control and engine building mechanisms of the game. One of my worst ideas to date was a randomized turn order for each turn. It was supposed to balance out the first player advantage, but all it did was confuse and irritate the players. This was abandoned at the beginning of the play test and replaced with a first player pawn which was passed forward with each turn.
The individual spiders each had a unique ability, but it was unclear exactly when to use it in relation to the action turn order. I eliminated these and moved these abilities to the action cards. This way, each spider has their own small unique set of action cards. This simplifies the rules and enhances the asymmetry of the various spiders.
The expansion of the webs was very slow. Players played cautiously and slowly without taking too many chances. This ended up causing a slow moving and boring experience. One of my playtesters “Bert” suggested providing “bait” spaces on the board, rather than letting the players place the bug baits wherever they wanted. This would incentivise players to expand faster and compete for critical areas. Thanks “Bert”, I have implemented something like this in the latest version.
Last of all, I’ve made a few graphic design improvements to clarify game play and create a more intuitive and cohesive look. All told, I think I’ve increased the play speed of this game at least twofold. This was necessary, in order to make the push-your-luck elements of the game really stand out. They were almost nonexistent in the last version because it was such a slog.
It’s now updated and ready for the next playtest. I hope it goes much smoother and is not just broken in a new and different way. LOL . Fingers crossed, I’ll see you on Tabletop Simulator.
Recent Comments