Starfire – It’s Perfect, Now Change Everything (Part 2)

In the last article I discussed my experience with republishing the original Starfire rules. The experience was not without its challenges. Yet the payoff was amazing. As good or better than any modern board game.

Still, it became rapidly apparent that finding opponents other than my overexcited teenage son was going to be difficult. The game is a product of its time and thus presents numerous flaws to the modern gamer:

• 2 player game – Today’s players have gravitated toward the extremes. Either they’re playing alone or with a large group of 4 or more. The original Starfire is designed for only 2 players, albeit with some exceptions.
• Pen and paper – The original record keeping system was the strength of Starfire. Unfortunately modern players expect mats, tokens, meeples, custom dice, iconography and playing cards. They are not going to tolerate a pen and a blank sheet of paper. At least not en masse.
• Complex rules – Starfire has fairly simple gameplay mechanics. The rule book hasn’t held up well enough for most players to learn that.
• Component quality – There are literally no components with the republished rules. Even if the original components were included they would be unacceptable to the modern player.
• Story – The lore behind Starfire is a product of a generation that had relatively poor access to information on the science and technology of space travel. While the rule book itself is slim enough to squeak by, much of the extended universe (especially the materials published in Nexus magazine) are outdated enough to invoke cringe reactions.

None of these points make Starfire a bad game. All they make it is old. Old is not a problem. The ideas behind the game are still sound. If the game is sound then it’s ripe for modernization.

Such was my thinking when I started working on my own record keeping system. While I can’t tackle all of the issues at once, I hope to start on a few key items and experiment with what can be done to modernize this amazing game.

The Power of Paper

Every designer would love to jump straight to using fully designed components for their tests. The problem is in the cost of those components. Be it the time with computer drawings, printouts and scissors or the monetary investment of contracting a printer, it’s not worth it if you don’t yet know if your designs are going to work. Thus most designers start with simple pieces of paper and work their way up. I’m no exception.

To start my experiments I headed to Office Depot and loaded up on 3×5 cards, 5×8 cards, a pair of scissors, a good ruler, and a rotating gizmo to hold it all.

Rotating gizmo of awesome

I also dug up some pens, binder clips (for the rules printout), and some two inch baggies from Amazon to hold my parts.

Since my initial focus was on record keeping, I decided to try making player mats. My thought was that tokens could be used to track attributes of each ship including the ship systems, current/max impulse, and the number of turns until the ship can perform a 60 degree turn maneuver. I did some calculations and came to the conclusion that if 1 cm was equal to a hull point, I could fit smaller ships on a 3×5 card and larger ships (all the way up to a superdreadnaught) on a 5×8 card.

I then created small paper squares at the same 1 cm size to represent ship’s systems. You can see the result below in the battle between the Discovery and the Alkzar. 

For the first prototype I didn’t get fancy with the tokens. Ship systems were represented by their letters. An arrow was used as the tracker token for impulse and turning. For convenience a special “Stop” token was used to limit the impulse to the number of undestroyed engines.

Destroyed systems would ideally be removed. Unfortunately the paper squares were hard to manipulate so I settled on pushing them aside.

In an epic battle of first contact, the Alkzar was destroyed!

I ran a couple of playthroughs using these prototypes. Both by myself and with an opponent. We agreed that the idea seemed sound, but the component quality wasn’t high enough to prove it yet. Armed with this knowledge I committed to self-manufacturing the necessary components.

Manufacturing Tokens

Fair warning: If you want to replicate what I’ve done here, this is not a process for the faint of heart. It’s perfectly possible to create high quality components using craft shop materials, but it is very time consuming and involves the purchase of some relatively expensive materials.

Simply gluing paper to corrugated cardboard isn’t good enough. The pieces will be very lightweight, prone to accidental damage, and the edges will tend to catch on other pieces. We’re going to have to use tougher stuff – chipboard.

If that doesn’t phase you, here’s a video from Pub Meeple that explains the process:

The craft store near me did not have any standard chipboard, but I did luck out in the quilting section. There they had project boards which were basically chipboard with the adhesive sheet already applied. The chipboard itself was white, which was a nice touch.

I then set to work on creating some graphics in GIMP that I could print out on 5×8 heavy card. During the playtesting with paper squares I realized that tokens got easily caught on each other. I decided to give my tokens rounded corners to ease in manipulation and prevent snagging.

Here’s a picture of the images adhered to a piece of uncut chipboard along with a number of cut pieces. As you can see, the results are pretty good. (Yes, I know the missiles have the wrong letter on them. Fubar on my part.)

This was a lot of work. Good thing cutting is peaceful and meditative.

You may have noticed that tokens for some systems are larger than others. My goal was to make the length of the token match the number of hull points required to add the component to your ship. Thus shields are 1 cm wide, guns are 3 cm wide and lasers are 4 cm wide. The idea is that you end up with an intuitive sense of how to build a new ship. The player mat represents the “hull” which you can then physically fill up with the systems you want. A side effect was players more acutely “feel” hits on important systems.

This plan did result in a couple of problems. The first was that the layout of the system grid could run into space problems. i.e. If you have only 2 slots left on a line there is no way to install a gun without moving it to the next line. This forces pieces to be ordered according to the physical constraints of the player mat. This is an unintended and unwanted side effect of the physical layout.

Another problem was that some systems have a different cost depending on the hull itself. Engines are the main offender here. Smaller ships have a hull point cost of 1/2 a point for each engine. I worked around it by stacking engines, but the solution wasn’t ideal.

The final problem was the Datalink which is not supposed to have any hull cost. It may not be an issue in many circumstances – the rules also specify a monetary cost for systems – but there is the possibility that a player could overflow the number of available spaces.

Laser Printed Player Mats

Now that we had tokens it was time to get a serious conflict going. To do that I need more hulls than I had prototyped to date. Thank goodness for laser printers!

I kept miscounting the hull spaces though and finally just printed a bunch with too many spaces. Since I was playing pre-defined scenarios it didn’t matter as much.

Notice the paper hex board on the left? It’s a prototype I’m working on for a tri-fold hex map. I used the same rounded token design to create new ship counters too. While smaller than the Galactic Starfire board, it worked fairly well. Alas, further discussion on the board will have to wait for another time. Like when I actually manufacture said board. (It will be so cool!)

Here are some more photos of the final game in action:

If it looks like fun, that’s because it was! Starfire is fun to begin with, but the alternate components really helped bring it to life as a more fleshed out board game.

Experimental Results

So when all was said and done I learned a lot about the game and how it might be improved upon. Here are a few items I can share with you:

• There is still work to be done on impulse and turn tracking. All the necessary information is there. We just kept forgetting to reset the counters or lose track of ships and forget a pulse. With a bit of practice I’m sure we could catch on. I’d like to make it more intuitive, though.
• The weapons lookup table desperately needs to be reduced to a quick reference card. Ideally one for each player. Passing that thing back and forth was a pain.
• As cool as the player mats are, table space quickly became a problem. Larger battles will get even worse. Further size reduction is warranted.
• As much as I love the token approach, it won’t scale in the current incarnation. The original Starfire rules are all about taking the game to the utterly ridiculous. I can’t even imagine playing battles with superdreadnaughts and their hundred plus systems. That’s got to take a lot of time and far too many tokens.

  The string-based design better allowed for and even encouraged this kind of scaling. Yet I’m not sure it’s conductive to keeping the game balanced and fun. There has got to be a breaking point somewhere. I imagine the modern player would find that point a lot faster than a player in the 1980’s.

• The vast majority of tokens are expended on redundant piles of systems like shields, armor and engines. Very few tokens are expended on weapons systems. This suggests there are significant opportunities to simplify system tracking. The greatest challenge is maintaining the semi-arbitrary order of systems.
• The idea of using the hull points to size tokens is a very cool one. As much as I like it though, hull building maybe better left to worksheets. The other option is to attempt rule changes that homogenize ship building and thus better support the hull-unit concept.

My goal at the start of this process was to see how far I could go while sticking to the original Starfire rules. That’s quite a challenge since the only significant component-driven constraint on the rules was the hex map. So far I had a lot of fun and learned tons without (yet) making any changes. I’m quite proud of what I’ve accomplished to date and can’t wait to run further experiments.

As these experiments continue it will be interesting to see how many rule changes I decide to make. The question this raises is: will these changes remain superficial or will I end up with a game that merely has the flavor of the original Starfire?

I can’t wait to find out!

Enjoy this article? Have thoughts of your own? Share them with us in the comments below!