User talk:Lardarse/LRS: Difference between revisions

From TetrisWiki
Jump to navigation Jump to search
*>Tepples
m →‎S and Z: correct I
*>NightmareciBot
m Robot: Converting to new playfield syntax...
 
(5 intermediate revisions by one other user not shown)
Line 1: Line 1:
== S and Z ==
== S and Z ==
Why are S and Z handled differently? Treating them like J, L, and T would allow more DAS-then-backtrack moves, similar to those seen in SRS (see [[Movement Finesse]]). Once you get [[Image:ITet.png|I]][[Image:ITet.png|ITet.png]][[Image:ITet.png|ITet.png]][[Image:ITet.png|ITet.png]] done, I'll consider implementing LRS in LJ and sending you some private builds to test variants of LRS against each other. --[[User:Tepples|Tepples]] 21:45, 1 May 2007 (EDT)
Why are S and Z handled differently? Treating them like J, L, and T would allow more DAS-then-backtrack moves, similar to those seen in SRS (see [[Movement Finesse]]). Once you get [[Image:ITet.png|I]][[Image:ITet.png|ITet.png]][[Image:ITet.png|ITet.png]][[Image:ITet.png|ITet.png]] done, I'll consider implementing LRS in LJ and sending you some private builds to test variants of LRS against each other. --[[User:Tepples|Tepples]] 21:45, 1 May 2007 (EDT)
:I'm not sure what you mean. And I have no problem with trying to implement it myself. That's part of the reason why I wanted to be able to compile my own binaries on Windows.
:For this, I'm not trying to implement an SRS variant. This is more meant to be an ARS variant, but with no rotation exceptions. I'm trying to create something that the hardcore players would appreciate, but at the same time doesn't scare the hell about the casual, semi-skilled, and skilled players.
:And I have a lot more pieces to document besides I<sub>4</sub>... --[[User:Lardarse|Lardarse]] 08:22, 2 May 2007 (EDT)
== I Tetromino ==
Having a discussion in IRC with Digital and jujube, I had an idea for the I tetromino, but I would like a reality check for it. The basc idea is that the rotation that you make gives it a preference about which direction to prefer to rotate in.
Take the following example:
<playfield>
----
----
GJZG
----
</playfield>
My idea would be that, regardless of previous rotation, rotating anticlockwise (left) would have the I overlapping the blue block, and rotating clockwise (right) would have it overlapping the red block.
There is also a similar occurance for rotating from verical to horizontal:
<playfield>
--G--
--G--
--S--
--G--
</playfield>
The I will rotate overlapping the green block, but the side that has 2 blocks sticking out of it will depend on which way you rotated. I am undecided if rotating right sould put the double on the left or the right, but I will decide eventually.
And all of this is before wallkick. This is mainly for behaviour in free space.
So... how crazy am I? Is this even implementable? --[[User:Lardarse|Lardarse]] 03:18, 10 September 2007 (EDT)
: I've realised that it is implementable, in certain games, anyway. ''(Translation: I cn make a test version in Lockjaw)''
: But now jujube has suggested that I have a similar thing for S and Z as well. My preference would be that for all 3 pieces, rotationg twice in the same direction in free space will not shift it sideways. --[[User:Lardarse|Lardarse]] 23:07, 17 September 2007 (EDT)
:: After talking with colour_thief about it, I've decided that rotating right will always go right, and rotating left will always go left, for all 3 of the pieces here. Expect me to start tryins to implement it soon... --[[User:Lardarse|Lardarse]] 23:28, 20 September 2007 (EDT)

Latest revision as of 03:52, 5 August 2009

S and Z

Why are S and Z handled differently? Treating them like J, L, and T would allow more DAS-then-backtrack moves, similar to those seen in SRS (see Movement Finesse). Once you get IITet.pngITet.pngITet.png done, I'll consider implementing LRS in LJ and sending you some private builds to test variants of LRS against each other. --Tepples 21:45, 1 May 2007 (EDT)

I'm not sure what you mean. And I have no problem with trying to implement it myself. That's part of the reason why I wanted to be able to compile my own binaries on Windows.
For this, I'm not trying to implement an SRS variant. This is more meant to be an ARS variant, but with no rotation exceptions. I'm trying to create something that the hardcore players would appreciate, but at the same time doesn't scare the hell about the casual, semi-skilled, and skilled players.
And I have a lot more pieces to document besides I4... --Lardarse 08:22, 2 May 2007 (EDT)

I Tetromino

Having a discussion in IRC with Digital and jujube, I had an idea for the I tetromino, but I would like a reality check for it. The basc idea is that the rotation that you make gives it a preference about which direction to prefer to rotate in.

Take the following example:

----
----
GJZG
----


My idea would be that, regardless of previous rotation, rotating anticlockwise (left) would have the I overlapping the blue block, and rotating clockwise (right) would have it overlapping the red block.

There is also a similar occurance for rotating from verical to horizontal:

--G--
--G--
--S--
--G--


The I will rotate overlapping the green block, but the side that has 2 blocks sticking out of it will depend on which way you rotated. I am undecided if rotating right sould put the double on the left or the right, but I will decide eventually.

And all of this is before wallkick. This is mainly for behaviour in free space.

So... how crazy am I? Is this even implementable? --Lardarse 03:18, 10 September 2007 (EDT)

I've realised that it is implementable, in certain games, anyway. (Translation: I cn make a test version in Lockjaw)
But now jujube has suggested that I have a similar thing for S and Z as well. My preference would be that for all 3 pieces, rotationg twice in the same direction in free space will not shift it sideways. --Lardarse 23:07, 17 September 2007 (EDT)
After talking with colour_thief about it, I've decided that rotating right will always go right, and rotating left will always go left, for all 3 of the pieces here. Expect me to start tryins to implement it soon... --Lardarse 23:28, 20 September 2007 (EDT)