Talk:Blackjack

One issue with the history function: How do you pre-program history, as done in the actual TGM Randomizer?

And also, having a program that can process a randomizer specification string, and then output a list that would be produced by it. I'm guessing that this will happen as part of the development process, though :-) --Lardarse 13:55, 27 December 2006 (EST)

Things that seem impossible with the current specification so far:

• Pre-population of history
• Looping through arbitrarily defined strings (eg. Recreating the Sega Tetris power-on pattern or TGM3's Sakura pattern)
• Checking from multiple histories flushed at independent timings (Panel de Pon/Puzzle League uses multiple histories to avoid pieces clearing immediately upon entry)
• Arbitrary sequence of random choices from multiple predefined groups (Puyo Pop Fever has a fixed sequence of piece shapes in random colors - If the sequence was domino domino tromino domino domino tetromino, for instance, the shapes would always come in that order, but in different colors every time)
• Reusability via XML

--59.87.132.88

"Pre-population of history"? Granted. I'll just hardcode Z,S,... in the first public implementation until we find a better way. Does with Z,S,Z,S history look OK?

"Looping through arbitrarily defined strings"? In theory, this pathological case could be expressed in Blackjack as a a 65536-piece deck with 65535 history, but at least my first implementation of Blackjack won't support decks that big.

"Multiple histories"? PDP != Tetris. Still, as I understand it, PDP actually checks the bottom line of the playfield as it exists, not as it was generated. Still, you could just run six Blackjack objects in parallel.

"Arbitrary sequence of random choices from multiple predefined groups"? Puyo != Tetris. Still, this would be easy. Run two Blackjack objects, one set to I2,I2,L3,I2,I2,O with 5 history and the other set to R,Y,G,C,B.

"Reusability via XML"? XML is often thought of as an overrated serialization. In fact, editors of Ward Cunningham's design pattern wiki have called XML a poor copy of Lisp's S-expressions. A lot of AJAX sites use JSON or other custom notations that are smaller across the wire than XML. If you insist on XML for some odd reason, is it really that hard to do?

<blackjack>
  <piece>I</piece>
  <piece>J</piece>
  <piece>L</piece>
  <piece>O</piece>
  <piece>S</piece>
  <piece>T</piece>
  <piece>Z</piece>
  <history rolls="6">
    <piece>Z</piece>
    <piece>S</piece>
    <piece>Z</piece>
    <piece>S</piece>
  </history>
  <first>
    <piece>I</piece>
    <piece>J</piece>
    <piece>L</piece>
    <piece>T</piece>
  </first>
</blackjack>

What seems difficult to me is that the generality of Blackjack brings in more computational and RAM overhead than fixed-function randomizers. I'll probably include Blackjack as an option in Lockjaw for PC (where even my 6-year-old machine is 866 MHz with 128 MB of RAM) but not in Lockjaw for GBA (where every machine is 16.8 MHz with about 0.3 MB of RAM). The current randomizer has about 20 bytes of state; Blackjack's increased generality needs about 160 bytes.--Tepples 22:55, 27 December 2006 (EST)

As for Panel de Pon and Puyo, I fail to see the reason this needs to be limited to Tetris and not for piece-dealing games in general (Chiral, Pipe Dream, Hexic, ...). The criteria between including a feature in the language specs and excluding it to outside handling seems pretty arbitrary at this point.
As for XML, just looking at the success BulletML has enjoyed in generalizing and reusing shmup barrage patterns. I guess a personal bias toward lower-powered hardware takes that down.