Tag: 2015

[Cross-posted from Omiya Games]

So, I’m programmer, been consistently making digital games every month, and yet, made a card game for Global Game Jam this year. Oddly enough, I found the experience to be more challenging than the common perception would imply. While the development process of the prototypes and iterations were quick and easy, properly identifying problems with the game, as well as understanding why the inspirations for the game were so engaging proved to be more tough than expected. This is the post-mortem of Impossible Poker, a game where you don’t know the rules.

What is Impossible Poker?

Impossible Poker is a card game that’s easily playable with 4 or more people, a deck of playing cards, 2 cards with one saying ‘yes’ while the other says ‘no’, and some tokens. The game starts with one person designated as the RuleMaster, and creates a rule that governs the values of each card. Each player is given 5 cards, and they play one card from their hand at once. The RuleMaster, then, determines which played card wins, then creates a stack of that card to provide a visual history of the results (note that by default, the highest valued card wins). Finally, the players can either ask a yes or no question to the RuleMaster or make a guess to the rule using either one of their 3 tokens, or the free opportunity they’re given every 3 turns. A yes or no question will be answered privately using the yes or no cards, while guesses will be answered with a correct or incorrect publicly. The first person to guess the rules correctly wins.

Our team consisted of four people: Kelli Dunlap, Eric Vignola, James Kim, and myself, Taro Omiya. I largely worked more as a supporting role, proposing many different solutions to problems we’ve identified (most, which I admit, weren’t all that useful).

What went right?

Learning something new

I swore to myself that I would get around making a board/card game at one point, not only to experience what it’s like to work with them, but also because I strongly believed it would help me become a better game designer. Not only am I happy that I finally satisfied that bucket list, but I’ve also come to a surprising conclusion: designing analogue games aren’t all that different from video games. Much like designing digital games, creating an engaging card game revolves around creating tight feedback loops, giving steady reinforcements, and dealing with holes and exploits in the rules. The only differences I found were quick feature implementation and feedback, simpler aesthetic, and the lack of juice (which is actually a relief). This experience should be useful when I experiment with different methods to prototype before creating the final product.

A worthy challenge, with a satisfying twist

I’m also proud about taking on the challenge of creating a game where the rules aren’t obvious. It has the classic hook of, “how can you play such a crazy game” that I like to implement in most of my digital games. Plus, the game proved to be a pleasant challenge to design, with unique problems and solutions I haven’t encountered with other games. A lot of people at the end of the jam were interested in trying the game, so we were definitely onto something with that selling point.

Finally taking comfort in supporting role

As of last year, I’ve been working solo as a full-time indie developer, and it’s been a pretty big concern to me on whether I’ve started losing touch with other people. Additionally, the Global Game Jam 2013 proved to be a wake-up call when I realized I was somewhat uncomfortable at taking roles outside of designing and programming. So I was pleasantly surprised this year that not only did I feel comfortable taking on a more supportive role with the team — with my efforts focused largely on forming the team, planning a simple schedule, providing some feedback, and programming the random rules generator — but I also felt like a valuable contributor as well. I also had the feeling that throughout the development, the rest of the team members were comfortable with their roles as well. Nobody was talking over each other, we were quick to identify and solve problems, and only times when we were really tired did any of us wander off and disperse. Plus, at least for me, there was a huge sense of relief that the programming aspect of the game was completely optional rather than a major component.

What needs improvement?

That one play-tester

At 3:00 on the second day, the doors were opened to allow any curious convention goers at MAGFest to visit and play test our games at the current state. We’ve hand some wonderful feedback from several people who visited our location, but one in particular stood out: the one who lectured us for a few hours. This play-tester actually had a lot of great insight about our game, such as the lack of hints to figure out the secret rules, and the exploitable win condition. While useful, the delivery of the feedback was, well, a bit intense. I think that session left us both exhausted and unsure of ourselves. Between that time to the end of day 2, we’ve been mulling about changing the game entirely, but never been able to determine how.

A little too laid back

I think we’ve gotten a little too comfortable before that one play-tester came along to really realize some flaws in the game. Ultimately, I feel like we should have gathered feedback from other people sooner to help identify problems with the gameplay. In context, I realize this would have been difficult: most people who would play our game were stuck working on their own game at the jam site, and our game still required 4 people at least to play. Fortunately, the day 2 feedback did prove to be a good wake-up call, so we did eventually get back into shape.

Programming independently from the game design

One feedback we found early on was that it was hard to come up with 3 secret rules before the game started, making the setup time longer than necessary. It was decided in the middle to eventually program a random rule generator that would be smart enough to provide 3 non-conflicting rules so that the user can easily choose a set of rules as they please. I finally took on this task during day 3’s morning, immediately while the rest of the team decided to change the game focus from the originally gambling objective to sleuthing. I wasn’t able to communicate or update properly at the time, so right when I was done with the framework and UI design, I was surprised to here that the game changed entirely from the former 3 set of rules to any number of rules you’d like (though only one was recommended). A classic moment of terrible communication, especially on my part. Fortunately, most of the framework still worked for the game, and the rest of the team commented it’s very unlikely that anyone would want more than 2 rules to play (let alone 3), so this problem was very quickly resolved, and I was able to proceed on creating more content.

What to do next

I’ve been told numerous times that paper prototypes are the best place to start designing your game, but up to this point, I’ve only been nodding my head in reply to that advice. Now I see the real wisdom behind that advice: paper prototypes provide quicker feedback and ease in modifications that is much hard to do on the digital space. This is perfect for experimenting with different design ideas, and making sure they’re tight enough to start a bigger project. Next time when I’m brainstorming and prototyping on a game, any ideas that doesn’t rely on physics heavily will be prototyped via paper to make sure it is as engaging as I hope.