Talk:Blackjack: Difference between revisions

From TetrisWiki
Jump to navigation Jump to search
No edit summary
*>Tepples
respond to AC
Line 9: Line 9:
* 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)
* 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
* 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 <code>with Z,S,Z,S history</code> look OK?
"Looping through arbitrarily defined strings"? In theory, this pathological case could be expressed in Blackjack as a a 65536-piece deck <code>with 65535 history</code>, 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 <code>I2,I2,L3,I2,I2,O with 5 history</code> and the other set to <code>R,Y,G,C,B</code>.
"Reusability via XML"? XML is often thought of as an overrated serialization. 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?
<pre>
<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>
</pre>
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.--[[User:Tepples|Tepples]] 22:55, 27 December 2006 (EST)

Revision as of 03:55, 28 December 2006

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. 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)