Game Proposals

moonbeam

I knew immediately I wanted some sort of relaxing game that could be single-player. However, I didn't want it to be as rigid and mathematical as Solitaire is, for example. To this end, the design I have in mind for moonbeam is one of a story-building game.

The goal of the player(s) will be to build from the North Pole towards the moon. They will do this via the means of physical materials, such as ice harvested from the Arctic Ocean, as well as fantasy concepts, such as celestial energy from the Aurora Borealis. The game will serve as being an ice-breaker, or writer's block assistant, in that it will encourage the player(s) to recall or invent experiences, characters, or events matching a certain theme, description, or purpose.

The game will end once the player(s) are able to play the Moon card.

Design Challenges

• How do I maximize replayability, without sacrificing rule clarity or story-telling purpose?
• How do I gate the Moon behind a natural progression point?
• How do I design the progression to encourage construction of a cohesive storyline?
• How do I make the story-telling aspect of moonbeam relaxing instead of frustrating, especially for those like me who have difficulties with story-telling?

flowgram

The concept of flowgram was born well after its corresponding mood-board: the mood-board designed early into the week, and the flowgram itself only conceptualized at 5 A.M. on the Thursday it was meant to be presented.

flowgram is intended to be a card game where skill matters much more than the cards you draw. Games played between players of equal skill should come down to the wire, with engaging back-and-forths. However, it's hard to design a skill-based card game without either the game becoming a TCG or having a dynamic ruleset.

So, flowgram takes the dynamic ruleset approach to the extreme. flowgram is intended to be played with 2 equally-sized teams of either 1, 2, or 3 players. Each team has a machine, and each player has units. The machine determines what rules the units follow. The machine starts out in a simple BEGIN → ATTACK → END state, allowing each player's attack unit to do a basic attack once per turn. However, as players draw machine cards, they can augment this flow chart. For example, a second ATTACK card can be played to augment the chart towards BEGIN → ATTACK → ATTACK → END, allowing attack units to attack twice per turn.

The machine cards would be positional: the BEGIN card would have a lower connection, signalling to process next whichever card is placed below it. This position-based system will easily allow for more complex control structures while preventing unabated growth (wire cards must be drawn to extend a connection, for example).

Design Challenges

• How do I prevent flowgram from becoming a TCG?
• Should creation of more units be enabled by drawing unit cards or by machine actions?
• How do I prevent infinite loops while still allowing complexity in a graph-based system?
• Should I make reorganizing already-placed machine parts (for example, for the goal of optimization) have some sort of cost?

Elevator

Elevator is a game concept I came up with before making a mood-board, and I had trouble making a mood-board in turn. It is a cooperative game, where you must keep yourself and your peers from going insane, but helping your peers comes at a cost of your own sanity.

Your elevator just got stuck, and you have to wait 30 (or 60) minutes (turns) for the Fire Department to arrive. Each player has been given a specific subset of the main deck (determining their "personality"). Players are not allowed to communicate out-of-character: no attempts must be made to reveal what cards have been played or are being held, or to reveal the sanity points of a certain player. (This is a co-op game, so there's no reason to cheat unless you hate fun.)

The difficulty of Elevator comes from the need for players to be fully anonymous in many of the cards they might play (starting an argument, but nobody knows who started it, etc). Other cards, such as assisting other players (helping another player will restore 2 sanity points for them, but cost you 1, and the maximum sanity is only 3) will be played in full view.

Each turn, a card is pulled from a size-30 (or size-60) "Event Card" deck, which describes things that may happen during a turn, or things players are required to do during a turn. If a single player drops to 0 sanity during the game, the entire group loses. If the Event Card deck runs out before then, the entire group wins.

Design Challenges

• How do I balance this game, especially without changing the max of 3 sanity points?
• How do I develop a system for playing cards anonymously?
• How do I make it clear that players should be entirely in-character?
• How do I make it fun to be in-character?