Written in February 2017
During the winter of 2015, I participated in a tabletop game jam known as Paper Jam 4. The challenge was to create a print-and-play game over a 10 day period. Participants were given a choice of theme sets, each with a mechanic, theme, goal, and restriction. I chose the following set:
- Mechanics: Action Programming
- Theme: Laser, Zoo
- Victory: Biggest Reputation
- Constraint: Must be easy for the brain
The design process began with a look at the mechanic. Action programming is gameplay that requires a player or players to decide on multiple actions. Those actions are then execute in sequence with further input only required after all actions have completed. This creates a lack of adaptability, which makes action programming a mechanic of prediction and planning.
This mechanic was evocative of the gameplay and theming of Transistor, a video game with a beautiful, computer themed aesthetic, and a fluid, action-based combat system. A part of this system made use of items that had multiple purposes when equipped in different ways. This gave players a wide range of choice while providing only a few resources. This acted as inspiration for modular nature of Module.
I decided to make Module a card game, as drawing is a mechanic that predictable provides resources to each player. From here cards were designed around the idea of having base units that were modified in different ways by equipping supporting cards. The theming incorporated a zoo theme in unit design, by having different program units named after a variety of different animals (ex: Fennec.exe). The victory condition was incorporated by each player having a reputation, and the program units work to either build a player's reputation, or tear down the reputation of their opposition.
To fit the print-and-play requirements, assets were designed by Peter Van and Anh Le. Peter created card borders and card backs, while Anh did card art for many of the cards. The final product is the current print-and-play version of ModuleCG.
Reflecting on the project two years later, I understand two main problems with ModuleCG’s design. The first is the level of complexity. The ruleset consists primarily of terms and phases, and is confusing to unfamiliar eyes. In ways, it reminiscent of many collectible card games in how it focuses on board control and maintaining units. These problems of complexity could be avoided in a couple of ways. The most obvious is further iterating on the design. “Trimming the fat” of the ruleset could do wonders on creating a much more playable game. The original version of ModuleCG was jam project, and for that reason had limited time for iterative design and playtesting. Another solution would be to stray farther from tradition collectible card games. Shifting moduleCG to focus more on a per round result and less on board state could make each round more engaging and reduce the need for complex unit interaction. It would also help avoid some pitfalls common to CCGs (ex: snowballing).
The second problem is the print-and-play nature of the game. Though this was a requirement for the contest, I feel that Module would play better as a video game, strictly because of its action programming mechanics. These mechanics translate better in a virtual/digital environment, as a player only has to worry about making the decisions, and not on executing the actions. This would reduce the overall computation a player has to go through while playing, without taking away from the satisfying aspects of gameplay, the planning and decision making.
Overall, I’m still interested in the potential of this project, and will likely revisit it in the future.