Chasing May
Language in games design regularly requires a specificity and accuracy alien to casual speech, made all the more onerous by the necessity of brevity to aid memorable retention. Also not aided by the tendency of some people to use words like onerous. Probably the worst ever word for games designers to use is 'may', may essentially means nothing, of course I may do that, but do I have to or can I choose to not? Knowing that, I've still chosen to make 'may' a central game term.
I need statements on cards in SSO to be approached in four ways. 1) As things you just have to do and there are no other options; 2) as totally free options you can select to do partially or to any degree; 3) as something you need to do or something else will not happen; or 4) as something you need to do as much as is currently physically possible but there is no penalty if it is impossible to do to the stated degree. Clearly writing that out on every card is out of the question, some form of carefully defined rules short hand is a necessity.
Rather oddly, my instinct was to colour code various rules, black as necessary, blue as a requirement for later conditions, green as optional, yellow for that which must be done as much as possible, red as a conditional for either term. It seemed logical, by colouring the exact rules and words could be indicated and I thought people would find colours nice and clear. It was ugly and made cards confused and split lines unclear, so words were brought in. 'May' meant a choice of yes or no, 'may try' a choice of degrees, 'must' needed to be done or nothing happened, and 'must try' to be done as much as possible. On a re-write 'may' and 'may try' condensed into 'may' and 'must try' became 'try'. So hangs the tail by which I chose to play with fire and try to tame 'must' and 'may' in my rules.
Playtesting is vital. Its hard to know how much is enough, just like re-writing, but certainly some is vital. As a designer its very easy to fall in love with your design, and its even easier to forget its complexity, its fiddly parts and its awkwardness. The first version of SSO marked crew locations with numbers, which seemed fine on paper but absolutely was not, and lasted all of the first playtest when it became colours instead. The most valuable point of playtests is to find out those sorts of human things, which elements are just annoying, which rules people consistently forget, which things aren't obvious and which things get too many questions asked about them.
SSO has a minimum player count of one so the one player version got a hell of a lot of testing, which was one of the reasons I chose it to be our first full project. I have an excellent, smart and accommodating regular gaming group so I get to do a lot of testing with experienced table top gamers. At a playtesting event at Handy Con I had a family herded over to me by the organiser. Now to be honest, I'd been hoping for the sort of group that I could hand the game over to and watch play, running a "blind playtest". What I got were a group entirely unlike any I'd introduced the game to before, who seemed pretty uncertain they even wanted to play it and a good lesson in how stupid I was to want a certain sort of playtester. We had a great game and I got to see people who didn't play co-op games, didn't like sci-fi and I suspect in at least one instance out and out didn't want to play SSO, get taken in and genuinely enjoy themselves, which was a very real confidence boost both for me and the game. That is something you really can't get without having people playtest.
Oh, and I noticed I had to clarify the nature of activating eliminated missions.