Three Hundred :: Mechanic #209
  Squidi.net Sites:     Webcomics   |   Three Hundred Mechanics   |   Three Hundred Prototypes
 Three Hundred
   - Index Page
   - About...
   - By Year

 Collections
   - Comp-Grid
   - Procedural
   - Tactics
   - Tiny Crawl
   - Misc


 
PreviousMechanic #209Next

  Mechanic #209 - Collectible Tokens
Posted: Jan 12, 2015

A collectible game format where you collect the very rules of the game itself.


  A Stupid Idea

As I mentioned in the previous entry, I was trying to figure out a new twist on the collectible aspect of games. I figured that there were two possibilities that were somewhat untapped. The first, as seen in the entry, was collectible tokens. The other was collectible rules.

I almost immediately dismissed the idea because when you think about it, most collectible card games are already about collecting rules - mostly exceptions, but rules. But then I thought, what if you were trying to design a game like Connect-4, but you didn't have the rules you needed. What if you didn't have the gravity rule which made the pieces fall down, but did have a rule which allow you to shift lines? Or what if you had too many gravity rules in your possession? Maybe you could have the gravity change halfway through the game, or have each colored piece obey a separate set of gravity rules.

It dawned on me that creativity is where knowledge and experience meet limitation... or perhaps, where they meet potential. The idea that you would define a game through rules that you had conditional access to could open up many creative possibilities. A similar concept is behind the creation of this Three Hundred Mechanics project. What happens when you run through all your good ideas? You have to go outside your comfort zone. You have to look at ideas differently. The Three Hundred is about exhausting potentials to create limitations and inspire creativity. So why couldn't I do the same thing with a collectible game?


  Defining a Game

Technically, this is a collectible card game, since the rules and pieces of rules are contained on cards. However, these rules don't apply to the cards themselves, but instead apply to a separate, distinct game as defined by the cards. So, it's not really a game, but a toolkit for creating a game. For the purpose of this entry, I'm assuming the creation of a bead-and-board game, like Go, Othello, Pente, Connect-4, Tic-Tac-Toe, Score Four, and so on. It could, in theory, be applied to other genres of games (board or otherwise) like card games, first person shooters, miniature games, artificial intelligence, or even dating advice. It's more about structure than purpose.

Probably the best way to think about this is that I'm creating a programming language, complete with subroutines, conditionals, and program flow. It is not Turing Complete, as there is no memory storage. So it defines rules, but it has not internal state of its own.

 

[rules1.png]

Fig 209.1 - xxx.

I'm still sort of working through the logistics of everything in my head, but as of the time writing this, there are two basic structures that ultimately define a game: Rulesets, Blocks, and Rules. In programming terms, a Rule is a statement. It is a singular behavior, frequently with a conditional built it (example: you can only drop a Connect-4 token if the column is not already full). A block is a set of rules that have an implicit OR attached to them. A Ruleset is a series of Rules and Blocks that define a specific aspect of the game's design, such as setup, turn behavior, or victory conditions. Rulesets are kind of like subroutines, but they are called from the game design rather than from the Ruleset's Rules.

That's a lot to take in, so I'll explain each of them in detail below.


  Rules

 

[rules2.png]

Fig 209.2 - Various Cards Making Up Rule Parts.

A Rule is a basic statement which represents a game rule. It can be anything from "A player wins if he has 5 pieces in a row" to "Player 1 begins the game with 31 red beads" to "A player can place his colored piece on any open location". If you'll notice, the rules are not on monolithic statement, but instead it is a statement made up of a number of variable pieces that modify each other. Sort of a who, what, where, and when.

 

[rules3.png]

Fig 209.3 - A Composite Rule Statement.

To this end, you can create a complex statement by overlapping cards. In this example, Player 1 can put a piece on the board up to three times, so long as his money is greater than 3. It's an odd example, but it shows how the behavior (placing a piece on the board) can be modified by who (Player 1), how often (x3), and when ($ > 3).

At this point, I want to point out that because only half of the card is used for the modifiers, I've elected to place two values on each other cards. So you have a card that can be used to represent Player 1, but rotate it 180 degrees and it can be Player 2. In this way, permutations become less of an obstacle. Something could represent both ANY PLAYER and EVERY PLAYER on the same card.

 

[rules4.png]

Fig 209.4 - Complex Conditionals.

Some rules have complicated conditionals that state whether or not a rule is active or allowed. For instance, you can place a piece in Connect-4 only if it is your turn and the column isn't full. Other games have considerably more complex conditionals such as being able to put a piece if X and not Y or X AND Y OR Z. To this end, conditional cards (and modifiers) can be placed below rules, indented. There is an implicit AND between conditional cards, but you can override this by using an OR card, stacked between rows.

(Just assume that the structure is the important thing in the illustrations, and that the rules themselves are just random. I can't fact check my made up rules to a made up game while simultaneously trying to describe the structure being used. I could, but it's exhausting enough and I want to finish this entry in a reasonable amount of time).


  Blocks

 

[rules5.png]

Fig 209.5 - Blocks.

Similar to the conditionals above, Blocks are a series of Rules that are grouped together by indentation. Generally speaking, Blocks decide the relationship between the Rules within a Block. Some Blocks are a a sequence of Rules, checked in order, while others just collect similar Rules together that are all active simultaneously. Blocks are represented by a card that starts the block and dictates what kind of block it is. There's no end block card, as indentation is used to designate blocks. A block card can appear anywhere a Rule (or a Rule Conditional) would otherwise appear.

In a game like Descent 2E, the player has several possible actions he can perform (move, attack, rest, use item, trade items, etc) from which he can pick two to perform each activation. This would be a Block called SELECT (with the x2 modifier) with each action under it being move, attack, rest, and so on.

Some games, have phases which happen in a specific order. Doomtown Reloaded, for example, begins with a gambling phase, an upkeep phase, noon phase, and sundown phase - each one have its own sequence of actions that need to happen. For instance, the Sundown Phase first checks to see if any players have won, and if not, played refresh their booted characters and draw a number of cards to get their hand back up to 5 cards. This sequence of phases can be modeled using a SEQUENCE block.


  Rulesets

Rulesets are just top-level Blocks that dictate a series of rules that are in play, regardless of sequence. It's kind of a RULE A, RULE B, RULE C, and so on. Sequential structure can be imposed through additional Blocks.

Each Ruleset is associated with a certain phase or event in the game. They are triggered. For instance, a Ruleset could represent a single phase of the game, global rules that affect the game board at all times, or it could represent the conditions required for victory, or even how to set up the board. A Ruleset is either always active or triggered. This is dictated by the game itself.

For instance, a typical game will, at the very least, have a Setup Ruleset, a Player Turn Ruleset, and a Victory Conditions Ruleset. Some games will have Rulesets that happen every turn, every phase, or in response to something that happens in the game. Similar to how Rules are made up of modifiers, you can create a Ruleset that is EVERY Upkeep Phase or AFTER Player Turn Phase, and so on.


  An Example: Pente

I'm going to give you an example of how to build the game Pente from this rule structure. The illustration at the top of this entry should give you a visual representation of it, but I'll explain it in more detail here. For those that don't know how to play Pente, it's very simple. Players alternate placing their colored glass beads on a board. When a player gets 5 in a row, column, or diagonally, they win the game.

  • SETUP
    • Board
    • Player 1 -> HAS A -> Pool of Colored Beads -> Green
    • Player 2 -> HAS A -> Pool of Colored Beads -> Blue
    • Player 3 -> HAS A -> Pool of Colored Beads -> Yellow
    • Player 4 -> HAS A -> Pool of Colored Beads -> Red
    • Player 1 -> Begin Turn

The Setup Ruleset simply shows that each player has a pool of beads of a specific color. It is implied that the pools are infinite, but you can use a x20 modifier to specify the size of the pools if you want. The Board part is simply a card which dictates what the board looks like, its size and shape. Different board cards could yield different playing fields. Finally, it starts the game off with the first player's turn.

  • PLAYER TURN
    • Block: SEQUENCE
      • Current Player -> Place Piece On Board
        • NOT -> Location is Occupied
      • Check Victory Conditions
      • Player on the Left -> Begin Turn
Simple enough. This describes what happens during each player's turn, in a specific sequence. The current player places a piece (implied from the pool of available pieces) on the board where no other piece is currently located. Next, the victory conditions are checked. If victory is not had, the next player clockwise begins his turn.

  • VICTORY CONDITIONS
    • Any Player - Victory
      • Pieces In Sequence -> Row -> x5
      • - or - Pieces In Sequence -> Column -> x5
      • - or - Pieces In Sequence -> Diagonal -> x5
    Finally, the victory conditions are a Ruleset which says whether any player has won the game yet. A player achieves victory is he has 5 pieces in a sequence, be it a row, column, or diagonally. And that's pretty much it.

    Defining Pente using this structure is relatively straight forward. So much so that one wonders why bother with the card aspect. But imagine you didn't have the card for Diagonal, or only had three Pool of Colored Beads cards. What if you wanted to add another condition to the victory conditions? What if players could move the beads like a Rook or Queen instead of placing new pieces? What if the board was shaped like an L?

    This structure doesn't just define a game. It defines what you can change about a game. You can replace pieces outright, add to them, create new pieces and phases, or even remove old ones. The difference between the rules for Pente and Connect-4 might be only three Rules - the board, where you can place your piece, and gravity. The difference between Pente and Tic-Tac-Toe might be even fewer changes. So imagine what you could do when you have a collection of rules and modifiers in a random assortment and just try to make something.

     

     





Copyright 2007-2014 Sean Howard. All rights reserved.