Arena Robot League First Design
Previously, I wrote about the history toward my first real game design. Today, I’m going to talk a little about the game as it stood before the first playtests, and the changes I’ve made since then.
As a reminder, here were the main goals of my design:
- Build a team, not just a robot
- Friendly competition - in other words, nothing malicious like breaking other players’ robots
- Strategic game
- Room for growth
And the mechanics that I found interesting:
- Student cards as a “mana system” - you can only take as many actions as you have Students, and each round you could only play one, at the expense of using another Student to recruit.
- Assemble robots from several cards to add capabilities.
- Students build Robots, Robots score Goals. Goals are worth points at the end of the game.
The design that I put into action was based off those mechanics. Players would draw a Team card, representing a Student or a Skill. Then they would take turns taking actions until they ran out of Students. Actions included drawing a Team card, recruiting a Student, or using a Student’s ability. In addition, multiple Students could be used at once to pay a cost to purchase Robot cards. Using the stacking card mechanism, robots would be built with a combination of abilities and effects. Finally, a Student could pilot an assembled robot to score goals.
Excited, I made cards. Many cards. I even started playing with Tabletop Simulator, making a layout that was somewhat functional. I did some play testing on my own, and found that there was at least a little strategic thought involved, so I shared it with a couple of people to look over the rules and play test the concept.
Feedback could have gone better. From what I was told, the concept itself was “fine”, but all the complexity was in the wrong place and there was too much randomness involved. In addition, it was strange that any student could pilot a robot, and the first round started off very slowly.
Randomness was an interesting issue. During the play test, I noticed that half of the players had hands of cards that were not at all helpful. This was due in large part to the fact that half of the Team deck was made of skill cards, which could be discarded to enhance specific actions. Despite the odds, those players ended up with cards that each gave benefits to only one skill, which severely limited the usefulness in situations that required multiple - like assembling a robot. To remedy this for the next play test, I’ve made a few changes. First, instead of drawing a mystery card, players are able to freely choose one of three face-up cards from that deck. Second, I reduced the number of Skill cards, and increased the number of Student cards (which provide more varied bonuses) to match.
Complexity is tougher to tackle. There was a lot of complexity on the front half of the game - specifically the actions of getting Student cards onto your team, and using them to pay for robots. Meanwhile, the actual act of scoring goals was very minimal - match a few symbols and you got the goal card to keep. I decided to reduce the number of robot cards that limit each other - there was some issue with how specific cards could only be played on a certain base, but also other bases limited what parts could be attached to them. I saw a lot of players having trouble with checking to make sure that the parts could match up. If this mechanic does come back up, I’d need to devise an icon system or similar, but for now I’m restricting this issue to just specific robot cards that are limited when used as a base. For the goals, I decided to change them. Instead of having duplicate cards, and working through the entire deck, I’ll reduce the number of possible goals and select just a few. The current concept for them (which is still in development) is that each one has a track on it, and the act of piloting the robot moves a cube along the track. This way, you earn points based on how well you scored on particular goals, but there are diminishing rewards to doing so, so you’ll still need to diversify.
The Student piloting issue actually solved a few other complaints I had with the design. Instead of using a messy “charge” system which involved putting tokens on the robots and taking them off, skills can be activated based on the piloting student’s Pilot skill. This allows for more creativity, and makes players have to think about which student pilots.
The first round problem was also easy to solve. Instead of starting with one student and no robots, each player can start with the same student, plus a Freshman student (no skill boosts but versatile), and a simple robot. This allows more freedom for the opening few moves.
I’m still in the process of writing up these rule changes and the actual card effects based on them, but it’s helpful for me to put my game design ideas down in a more prosaic form first. This way I have a record of what decisions I’ve made, and why, and hopefully some people can learn from my mistakes!