Totem stack rotation
In the prior discussion I defaulted without examination to moving forward in the event of a collision1 Why?
If collisions do not trigger slides then either it must always be possible to avoid a collision (easily proven impossible in 4+ player games) or there must be an ordering function for players resident at the same action slot, perhaps a FIFO(def) or LIFO(def). Both queue forms have their interesting aspects with LIFOs perhaps being the more interesting as later players can get an instant second turn by ending atop a prior player, perhaps to the earlier player’s discomfort (making turn prediction more difficult and yet more valuable).
Stacking seems inevitably less interesting. Collision sliding offers a few clear interest-benefits:
- A slide moves the subject player further around the ring thus making their next dividend closer/sooner
- Situations can be crafted which allow multiple positions to be collision-slid
- Collision sliding encourages players to chose actions which use/absorb the lost action point. Because this value cuts in both directions, Development gets an extra boost encouraging a slightly more Development-centric game than Expansion-centric
- Unpreventable slides (can) force players to waste action points in non-income producing movement
Meanwhile almost the same multiple-turn opportunity remains, just trimmed by one action point to not include the collision point.
More simply collision-sliding offers an additional decision: To slide or not to slide. Each side of that decision has significant effects on turn order — effects which are interesting for the subject player and interesting for other players to predict and arrange afore-hand.
- player ends their turn at the same place on the action track as a prior player, thus colliding and sliding forward to the next available slot. ↩
Definition: FIFO
[1] : The Collaborative International Dictionary of English v.0.48
FIFO \FIFO\ (f[imac]"f[=o]), a. [acronym, First In First Out.]
1. (accounting) an accounting method in which goods in
inventory are valued at the price of the most recent
acquisition of each type of goods, and those used up from
inventory are valued at the cost of those first acquired.
[PJC]
[2] : WordNet (r) 3.0 (2006)
FIFO
n 1: inventory accounting in which the oldest items (those first
acquired) are assumed to be the first sold [syn: first in
first out, FIFO]
See also:
[first in first out] [FIFO]
[3] : The Free On-line Dictionary of Computing (26 July 2010)
first-in first-out FIFO(FIFO, or "queue") A data structure or hardware buffer from which items are taken out in the same order they were put in. Also known as a "shelf" from the analogy with pushing items onto one end of a shelf so that they fall off the other. A FIFO is useful for buffering a stream of data between a sender and receiver which are not synchronised - i.e. not sending and receiving at exactly the same rate. Obviously if the rates differ by too much in one direction for too long then the FIFO will become either full (blocking the sender) or empty (blocking the receiver). A Unix pipe is a common example of a FIFO. A FIFO might be (but isn't ever?) called a LILO - last-in last-out. The opposite of a FIFO is a LIFO (last-in first-out) or "stack". (1999-12-06) See also: [block] [Unix] [pipe] [stack]
[4] : V.E.R.A. -- Virtual Entity of Relevant Acronyms (June 2006)
FIFO
First In First Out (CPU)
Definition: LIFO
[1] : WordNet (r) 3.0 (2006)
LIFO
n 1: inventory accounting in which the most recently acquired
items are assumed to be the first sold [syn: last in first
out, LIFO]
See also:
[last in first out] [LIFO]
[2] : The Free On-line Dictionary of Computing (26 July 2010)
stack FILO last-in first-out LIFO(See below for synonyms) A data structure for storing items which are to be accessed in last-in first-out order. The operations on a stack are to create a new stack, to "push" a new item onto the top of a stack and to "pop" the top item off. Error conditions are raised by attempts to pop an empty stack or to push an item onto a stack which has no room for further items (because of its implementation). Most processors include support for stacks in their instruction set architectures. Perhaps the most common use of stacks is to store subroutine arguments and return addresses. This is usually supported at the machine code level either directly by "jump to subroutine" and "return from subroutine" instructions or by auto-increment and auto-decrement addressing modes, or both. These allow a contiguous area of memory to be set aside for use as a stack and use either a special-purpose register or a general purpose register, chosen by the user, as a stack pointer. The use of a stack allows subroutines to be recursive since each call can have its own calling context, represented by a stack frame or activation record. There are many other uses. The programming language Forth uses a data stack in place of variables when possible. Although a stack may be considered an object by users, implementations of the object and its access details differ. For example, a stack may be either ascending (top of stack is at highest address) or descending. It may also be "full" (the stack pointer points at the top of stack) or "empty" (the stack pointer points just past the top of stack, where the next element would be pushed). The full/empty terminology is used in the Acorn Risc Machine and possibly elsewhere. In a list-based or functional language, a stack might be implemented as a linked list where a new stack is an empty list, push adds a new element to the head of the list and pop splits the list into its head (the popped element) and tail (the stack in its modified form). At MIT, pdl used to be a more common synonym for stack, and this may still be true. Knuth ("The Art of Computer Programming", second edition, vol. 1, p. 236) says: Many people who realised the importance of stacks and queues independently have given other names to these structures: stacks have been called push-down lists, reversion storages, cellars, dumps, nesting stores, piles, last-in first-out ("LIFO") lists, and even yo-yo lists! [Jargon File] (1995-04-10) See also: [instruction set architectures] [subroutine] [machine code] [auto-increment] [addressing modes] [register] [stack pointer] [recursive] [activation record] [Forth] [object] [Acorn Risc Machine] [functional language] [linked list] [MIT] [pdl] [Knuth] [Jargon File]
[3] : V.E.R.A. -- Virtual Entity of Relevant Acronyms (June 2006)
LIFO
Last In First Out
Commentary and processes of 
Write a Comment
You must be logged in to post a comment. Log in