Talk:Blackjack: Difference between revisions

From TetrisWiki
Jump to navigation Jump to search
*>Lardarse
No edit summary
*>Tepples
My criterion
Line 11: Line 11:


--59.87.132.88
--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?
"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?
Line 46: Line 47:


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


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.<br>
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.<br>
Line 51: Line 53:


--59.87.132.88
--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?'' - Sounds good, as long as we specify that "card" names can't start with a number. That will likely make your job easier.
''"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?'' - Sounds good, as long as we specify that "card" names can't start with a number. That will likely make your job easier.
Line 61: Line 64:


There is one other thing that this doesn't support, but I'm not sure you want to be thinking about it just yet... --[[User:Lardarse|Lardarse]] 08:40, 28 December 2006 (EST)
There is one other thing that this doesn't support, but I'm not sure you want to be thinking about it just yet... --[[User:Lardarse|Lardarse]] 08:40, 28 December 2006 (EST)
"I fail to see the reason this needs to be limited to Tetris" I didn't intend to limit it to Tetris. I just didn't want scope creep to destroy my will to get an 0.1 implementation out. Randomizers in Columns, classic Puyo Pop, and classic Lumines appear to resemble Dr. Mario's <code>R,Y,B</code> repeated once for each block in the piece.
"The criteria between including a feature in the language specs and excluding it to outside handling seems pretty arbitrary" - My criterion is the analogy to a single deck of playing cards. Bag and History style randomizers can be described in terms of physical operations on cards. The whole original proposal (<code>''n'' bag of ''list''</code>) was based on my observation that the randomizers in card games work almost exactly like Random Generator, prompted by Lardarse's suggestion of a cut point.
As for multiple objects vs. one object determining multiple attributes: In Monopoly, Community Chest and Chance would be represented as separate Blackjack objects because they are obviously separate decks. If the color and shape of a piece are determined together, as the suit and number on playing cards (H4, S9, CJ), then the analogy holds. Likewise, the 3D orientation of a snake or gun tetromino is determined with its shape by splitting S and Z into separate elements. But if the color and shape of a piece are determined separately, you need two randomizers. If you're making random fast food meals, you'll want one randomizer involving <code>BigMac,QuarterPounder,BigMac</code>, one involving <code>Fries,OnionRings,OrangeSlices,Applesauce,SideSalad</code>, and one involving <code>Coca-Cola,DietCoke,Sprite,ChocolateShake,Coffee</code>. --[[User:Tepples|Tepples]] 13:31, 28 December 2006 (EST)

Revision as of 18:31, 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. 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.

--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? - Sounds good, as long as we specify that "card" names can't start with a number. That will likely make your job easier.

I also see a use for Blackjack in multiple piece-dealing/block-dropping games, even if it means that we need multiple Blackjack machines running. To that end, it would be nice if we could have the entire state in 1 array/string/struct.

Is there any chance we could document the piece order for each character in Puyo Pop Fever, and have more infomation about the PdP randomization system (including frequency of "shock blocks")?

XML does feel like overkill for this. And keeping it all one one line means that we could store it in lj.ini, for example.

There is one other thing that this doesn't support, but I'm not sure you want to be thinking about it just yet... --Lardarse 08:40, 28 December 2006 (EST)


"I fail to see the reason this needs to be limited to Tetris" I didn't intend to limit it to Tetris. I just didn't want scope creep to destroy my will to get an 0.1 implementation out. Randomizers in Columns, classic Puyo Pop, and classic Lumines appear to resemble Dr. Mario's R,Y,B repeated once for each block in the piece.

"The criteria between including a feature in the language specs and excluding it to outside handling seems pretty arbitrary" - My criterion is the analogy to a single deck of playing cards. Bag and History style randomizers can be described in terms of physical operations on cards. The whole original proposal (n bag of list) was based on my observation that the randomizers in card games work almost exactly like Random Generator, prompted by Lardarse's suggestion of a cut point.

As for multiple objects vs. one object determining multiple attributes: In Monopoly, Community Chest and Chance would be represented as separate Blackjack objects because they are obviously separate decks. If the color and shape of a piece are determined together, as the suit and number on playing cards (H4, S9, CJ), then the analogy holds. Likewise, the 3D orientation of a snake or gun tetromino is determined with its shape by splitting S and Z into separate elements. But if the color and shape of a piece are determined separately, you need two randomizers. If you're making random fast food meals, you'll want one randomizer involving BigMac,QuarterPounder,BigMac, one involving Fries,OnionRings,OrangeSlices,Applesauce,SideSalad, and one involving Coca-Cola,DietCoke,Sprite,ChocolateShake,Coffee. --Tepples 13:31, 28 December 2006 (EST)