Our game Chipot-play tests if players can open and run a new Chipotle location (without bleeding too much money such that they are forced to shut down / lose). The game is collaborative and players fulfill different roles (manager, crew member, crew member, cashier); players must work together to make decisions that will affect potential cash flow throughout the game (for example, the first decision players have to make is how many tables to purchase for their restaurant, which dictates how many customers they can serve at one time. But, if players purchase too many tables at first, and become low on money, an unpredictable scenario could occur to make them bleed money / lose). The game teaches prioritization, optimization, and coordination and showcases all the different factors restaurant owners have to think about when starting out, and how to best balance between resources.
Objects are the players / individual employees, customers, and orders. Employees must manage the customers’ orders to ultimately satisfy and make each one. Our tap is buying more ingredients. Our converter is turning money into ingredients for different orders. Each person’s inventory holds a different amount of ingredients based on how they buy them.
One loop is when every four players uses an action (1 round). Depending on each player’s role, each player has speciality actions. For example, a manager can either purchase new furniture / ingredients, or help fulfill a customer order. A crew member can fulfill customer orders at a faster pace. Players see after they execute an action whether it was the right choice (fulfilling a customer action faster earned them more money vs prioritizing spending money to purchase a table led to more customers in the future) and receive feedback. Different unpredictable scenario cards are drawn at the end of each loop to determine a new setting (an example scenario is losing money / customers for a certain reason). Over time, players learn how to maximize efficiency / make the most money in the shortest amount of time.
As for arcs, we’re playing around with introducing a new constraint – time. During a certain time period, we would measure how many customers the players could fulfill, and reward accordingly. During this time constraint, the players start with a mental model, apply their specific actions (placing ingredients down for customers), and receive feedback (how many customers they were able to serve). Perhaps we could introduce this rush hour “time constraint” at various points in the game, so players can see whether they can increase the number of customers each time. This could update players’ mental models of how to optimize for outside the time constraint period, too.
