Comparison of action systems

From BlogNomic Wiki
Jump to navigation Jump to search

This is a comparison of ways in which a BlogNomic dynasty can restrict the performance of actions, using a hypothetical example where the gameplay centres around the building of bricks. (It's assumed that the goal is to build a lot of bricks, but there are unseen other rules in place that make the exact time and method of this more nuanced.)

This still needs expanding, feel free to add more examples, and more pros and cons for those already listed.

Action timing

System Example rule Pros Cons As seen in
Short cycle actions (eg. daily) "As a daily action, a player may build one brick."
  • Easy to understand how it works
  • Level playing field: at any given point in the game, nobody is better at building than anyone else
  • Game noise: Clear distinction between active and inactive players
  • Use-it-or-lose-it forces a decision
  • Forces players to grind, remembering to take the action very frequently
  • Rewards quick reactions. In some situations, a player who reacts first to the new day can get the advantage.
  • Stalemate: In all other situations, players will want to take the action as late as possible in the cycle, so that others have less time to react to it, and they have more time to react to other players.
Long cycle actions (eg. weekly) "The Emperor may announce a new round if the current round is more than 96 hours old. Once per round, a player may build seven bricks."
  • Easy to understand
  • Level playing field
  • Some game noise: Still some distinction between active and inactive players
  • Use-it-or-lose-it
  • Still some grind
  • In some cases, rewards quick reactions.
  • In others, pushes players to stalemate and take the action as late as possible in the cycle.
  • Some game silence: Hard to tell (early in the cycle) if other players are biding their time, or bored
Ruleset 210#The Gift of the Isle
Cycle topup "At the start of the week, each player gains seven bricks. A player may build a brick at any time."
  • Some distinction between active and inactive players
  • Still some grind
  • Stalemate: Pushes players to take all seven actions as late as possible in the cycle
  • Game silence: Patience and boredom broadly indistinguishable
  • Encourages stockpiling
Currency "At any time, a player may pay a coin to buy and build a brick." (Other game rules output coins in a complex way.)
  • Visible status: Easy to see how prepared each player is to take build actions
  • Stalemate: Players with coins may wait to see what others do, before spending their own
Finite personal resource "Players start with 50 bricks each. At any time, a player may build one of their bricks." (Rules generally do not output additional bricks.)
  • Level playing field: Newer and older players start with the same mechanical budget
  • Game noise: Bursts of game activity can happen at any time during the day or week
  • Newcomer advantage: Later players can make optimum moves based on others' earlier mistakes
  • Stalemate
Ruleset 147#Bankroll (?)
Finite shared resource "The group starts with 250 bricks. At any time, a player may take one of the group's bricks and build it."
  • Game noise
  • Use-it-or-lose-it: Encourages players to act sooner rather than later
  • Tragedy of the Commons: a bad actor can empty the pool in one go
Turn-based "The active player may build a brick at any time. It then becomes the turn of the next player."
  • No race condition; there is no advantage in reacting quickly
  • No stalemate in waiting to see what others do
  • Needs rule machinery to handle the turn sequence
  • Turn order matters: possibilities for first player advantage; later players copying moves; benefitting from being directly after a careless player
  • Lots of downtime, very slow-moving (especially if some players are inactive)
  • Ruleset changes enacting mid-round can create a fairness issue, or require delaying mechanisms
Ruleset 155#Crates,
Ruleset 181#Turns,
Ruleset 172#Battle Actions,
Ruleset 167#Bidding Queue,
Ruleset 203#The Queue
Simultaneous reveal "Players submit build orders secretly to the Emperor. When all players have submitted orders, the Emperor applies them."
  • No race condition
  • No stalemate
  • Encourages all players to be active
  • Needs Emperor moderation: complex resolution systems can become a dead end
  • Secrecy can delay the noticing of mistakes or loophole abuse, if a player submits an illegal or surprising order
  • Inactive players may need to be dealt with
Ruleset 120#Notes,
Ruleset 169#The Watch,
Ruleset 219#Duel
Bursty simultaneous reveal "Players submit build orders secretly to the Emperor. Every so often, the Emperor applies all pending orders."
  • Reduced race condition
  • Reduced stalemate
  • Needs Emperor moderation
  • Delays from illegal or surprising orders
Ruleset 222#Clock Cycle
Synchronised actions "Players announce build plans publicly and can change them. When nobody has changed their mind for 24 hours, all plans are built."
  • No race condition
  • Reduced stalemate
  • Actions don't depend on those of others
  • Requires a complex processing step
  • Can cause a stalemate if a player refuses to commit to a decision
Ruleset 179#Wagers
Date-based income "Players have as many bricks as the numerical difference between the start date and today. They can build a brick by increasing their personal start date."
  • Eliminates grind, as gains are automatic.
  • No advantage to older players, as new players can catch up.
  • Stalemate
  • Encourages stockpiling of time
Ruleset 170#Workdays
Infinite "A player may build a brick at any time."
  • Easy to understand and implement.
  • No advantage to older players: any player can take this action however much they want at any time.
  • Risk of game silence and stalemate while players wait for the ideal moment to perform the actions.
  • Encourages burst activity, where nothing happens for a while and then everything happens.
  • The gained resource can become fool's gold.
  • Can turn into a race if players have been waiting for a rule or gamestate change before building.
Proposals "To build one or more bricks, make a proposal declaring your wish to do so: if it enacts, they are built."
  • Level playing field
  • Game noise
  • Use-it-or-lose-it
  • Can slow the proposal queue down
Ruleset 117#The Chambers,
Ruleset 193#Floors
Auctions "Players make open bids of coins, where only one auction is open at a time. When nobody wants to bid any higher, the highest bidder may build a brick."
  • Game noise
  • Can make the cost of actions self-balancing
  • Each auction results in only a single action occurring
Ruleset 139#Planning,
Ruleset 147#Auctions
Ruleset 176#Auctions

Action modifiers

Modifying how the action is performed can mitigate some of the downsides in the above table.

Modifier Example rule Pros Cons As seen in
Downside "Whenever a player builds a brick, the wolf attacks them."
  • Removes grind, if the downside is enough that players will not always want to take the action.
  • If the downside is currency-like, it may introduce the downsides of currency (stalemate).
First-mover advantage "The first player to build each round build 10 bricks, the next 9, etc."
  • Reduces stalemate.
  • Can be difficult to balance; too much of an advantage and it becomes a race to take the action.
Randomly determined "As an X action, a player rolls a die and builds that many bricks."
  • Reduces the advantage to older players, if newer players with luckier rolls can catch up.
  • Adds luck, which may favor certain players regardless of their skill.
Resource cap "A player has a pool of up to 10 bricks to build with, and gains 7 per week."
  • Prevents stockpiling
  • Use-it-or-lose-it forces a decision
  • Disadvantages less active players, who may (even if they only miss a few days of play) fall behind.
  • The maximum stockpile allowable might be limiting to engaging gameplay.
Cost actions by frequency "A player may build a brick at any time but must pay one additional brick for each brick they've built that day."
  • Lessens burst activity, because bursting is expensive.
  • Adds game noise by encouraging players to do something every day.
  • Hard to keep track of.
  • Can reintroduce the grind and stalemate of daily actions.
Caretaker roles "A player may build a brick by announcing this in a blog post. Any caretaker may apply the gamestate changes."
  • Allows action complexity to be handled by a subset of players (possibly just the Emperor) who are comfortable with it.
  • Reduces the chance of the gamestate becoming illegal.
  • May give some admin advantage to the caretaker players.
  • Game can stall if the caretakers idle or are otherwise unavailable.
Hidden information "Each player has a secret shape they are trying to build." / "Each player has a secret pool of randomly coloured bricks."
  • Reduces stalemate: with some of the game hidden, players aren't just watching each other take verifiably optimal moves as late as possible. An early move can be a successful (or double) bluff.
  • Requires an active Emperor (or complex hash system) to track.
  • Scams can be opaque if they involve hidden gamestate.
Shared playing area "Each player places bricks of their colour on the same shared building site."
  • Reduces stalemate: a good opportunity seen early in the week may be unavailable by the end of it, encouraging players to seize the day.
  • May add a race condition, to be the first to respond to another's move
Ruleset 1#The Game Board,
Ruleset 182#The Mosaic
Hashes "Players record an MD5 hash of their next build action, to be revealed after all have recorded one."
  • Can remove the need for Emperor moderation
  • Players can make mistakes when using hashes, invalidating moves
Ruleset 132#Confessions

Combined examples

Success stories

Not intended as an exhaustive list yet, but it's worth keeping track of systems which worked particularly well:

  • The Wizard Duel dynasty used a simultaneous reveal system where players submitted orders to the Emperor and these were resolved only when every player had done so. Players could also retract orders if they'd changed their mind. The required unanimity worked particularly well with the proposal queue, with players occasionally holding their order back until a proposal had passed or failed, and the game only proceeding to the next round when everybody wanted it to. The dynasty had no issues with inactive players failing to submit orders - this may have been luck, or could have been the obvious social pressure that would be present from other players waiting for an inactive player to respond. (Conversely, the turn system in the Atlantean City dynasty floundered at times because it had a built in time-out for inactive players, which created less social pressure to actually take a turn, the minimum ruleset-acceptable activity being "do nothing ever".) There's an essay about this at The Timeout Paradox.