Why Game Design?
Whether on a screen or a board, I’m an avid gamer. Game design has always been enticing to me, but it wasn't until I started this project that I realized how similar the processes are to the ones I use for product design. This project gave me a chance to sharpen my toolkit in a new context.
Testing with users/players is integral at every part of the process for both product and game design. UX writing and writing rules share similar goals: clear, concise writing.
Design
Target Audience
If it is only my fiancée and I playing a game, it is usually towards the end of a night with only time for a short game. She suffers from an ailment common among board game fans — analysis paralysis (AP), or overthinking to the point of stalling games. We often turn to co-operative games, which alleviate the problem as I can help with decision making if she gets stuck. With that in mind, I set out to create a quick two-player competitive game, that minimizes AP without sacrificing strategic choices and interesting decisions.
AP occurs most often when players have the ability to think multiple turns ahead. Players cycle through all options, in an attempt to produce the best possible strategy. This can greatly elongate the game. In order to minimize the need to think multiple moves ahead, choices should have value without requiring planning.
Core Gameplay Loop
The basic idea for the game came from the pop-culture image of hackers and hack-a-thons. It is a race to hack into your opponent's computer and find their location. In the game, this is done by rolling dice and playing them on one of your opponent's slots (cards). Your opponent then gives approximations by stating if your rolls are "higher", "lower", or a "hit" on the slot.
In the initial few playtests, tracking was done by memory. While the basic gameplay loop was enjoyable, memory is not a mechanic that we usually like it and this game followed that pattern. Giving players a paper and pencil helped to solve the memory problem, but made the game feel slow. Designing an interface to keep track of the information became a key part of the design problem.
Tracking Information
One of the first interfaces stood out amongst the group: a two-level number track for each card. After playing a few games with it, I was comfortable that we could focus on and iterate the design to find our end solution.
The first version didn't have a cover. The second version became a little cumbersome to reach the card, so the third version added a card holder. Any slight movement made the card fall, and it was unable to hold a card sturdy enough facing both directions.
The current tracker is sturdy enough to hold the card facing either way in place while the user moves the cubes.
Programs
The early gameplays focused on refining the basic gameplay loop, which held up on repeated plays. However, the game felt basic and needed another element to keep in interesting.
One of my favorite game mechanics is dice mitigation, which gives you the ability to affect the value you roll. It's a great way to balance luck and strategy. Adding this mechanic via programs, or special powers/abilities, seemed like a great avenue to explore.
After testing a few basic programs, the game started to come alive. One power stood above the rest and found its way into the core gameplay loop; the ability to Scramble a card and replace it with a new one added an element of strategy that we couldn't play without.
As more ideas formed around programs, this ever-evolving Post-It wall became a checklist for future playtests. Two primary decision spaces emerged around programs: are they purchased or shared, and how to balance power-levels.
Purchased vs shared market is still being tested. Both have shown advantages and disadvantages.
Having multiple ways to balance programs gives more control that can be used to fine tune power-levels. An initial cost and cooldown on use created easily adjustable ways to equalize programs. You sacrifice dice to buy programs, but cooldowns provided a new challenge: how to track them without adding fiddliness. Utilizing the backs of the programs to track cooldowns worked well without adding any components.
Playtesting
While my fiancée and family are great playtesters, I eventually needed to venture outside of that bubble and let others play the game. During a pandemic, that became very difficult to accomplish.
Tabletop Simulator
Print 'n Play
In order to reach out to those who don't enjoy playing virtual board games, I have started creating a Print 'n Play (PnP) version. Most of the components can be borrowed from other games or substituted with an equivalent found around your house, so it seems like a great candidate. Because I won't be present for PnP games, well-written rules are imperative for success. Current Rules Draft
Status
- Continuing to test individual powers and balacing with my fiancée
- Playtesting over Tabletop Simulator
- Writing rules to put together PnP version