User:Oshisaure: Difference between revisions

From TetrisWiki
Jump to navigation Jump to search
(I've been wanting to do a writeup of my own rotation system concept and the ideas behind it to have a reference of it somewhere. I'll do this here later.)
No edit summary
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
Hello! I'm Oshisaure, a Tetris nerd who likes to do silly things in Tetris games, with a slight specification in [[Rotation system|Rotation Systems]] and unusual [[Twists]]. I have a [http://youtube.com/user/LeSpyroshisaure/ YouTube channel] where I like to share these silly things.
Hello! I'm Oshisaure, a Tetris nerd who likes to do silly things in Tetris games, with a slight specialisation in [[Rotation system|Rotation Systems]] and unusual [[Twists]]. I have a [http://youtube.com/user/LeSpyroshisaure/ YouTube channel] where I like to share these silly things.


I've also made [[A Gnowius' Challenge]] and [https://oshisaure.itch.io/puzzle-juggle-trouble Puzzle Juggle Trouble], and worked on a [[Cambridge]] fork with MillaBasset.
I've also made [[A Gnowius' Challenge]] and [[Puzzle Juggle Trouble]], and worked on a [[Cambridge]] fork with MillaBasset.


== Custom Rotation System concept ==
== Vulptile Rotation System (VRS) ==
(I'll write this when I'm not as tired)
Although I had made a few over-the-top joke rulesets in the past (see [[A Gnowius' Challenge#Biased-On-Nutty-Kick-Enhancement Rotation System|BONKERS]] for a good example), the question of a proper Rotation System came about when I started having projects about a 1-VS-1 game. I wanted to have a game that differed greatly from the [[Tetris Guideline]], partly because it was incompatible with the idea of my game, partly because I wanted to imply that this game was following its own set of rules. One of the points of difference was, of course, the Rotation System.


<small>''(More to be added to this page someday)''</small>
=== Piece colours and entry orientations ===
While I do not consider things like colour scheme, harddrop vs sonic drop or piece entry rotation to be strictly related to the rotation system itself, they still end up being commonly assiciated into a common ruleset that people get used to - you can ask a guideline player and a TGM player what "the right piece colours" are and they will give you different answers.
 
Because of this, I've decided to make my own colour scheme as well. To make it easier to play for colourblind people, I've made S and Z follow complemetary hues, as well as L and J. I then filled in the colours to the best of my ability by putting warm colours on the S and L pieces - as they both fit in a left well - and then picking colours that would probably upset anyone using Sega or guideline colours. I ended up with:
* I: Purple (hue 270°)
* O: Orange (hue 30°)
* T: Green (hue 150°)
* L: Red (hue 0°)
* J: Cyan (hue 180°)
* S: Yellow (hue 60°)
* Z: Dark blue (hue 240°)
 
As for spawning orientations, I make the pieces spawn flat side down, as that gives the most manoeuvrability in high gravity.
 
TL;DR: the pieces look like this on spawn
<playfield>
      ll  s    z  i    oo  jj 
tttt  ll  sss  zzz  iii  oo    jj
</playfield>
 
Now onto the rotation system itself, for real.
 
=== Core ideas and base guideline of VRS ===
A common criticism about [[SRS]] is that it feels unpredictable at high gravity. I think that this is mostly an issue on the wallkicks, but that part of it is induced by the S, Z and I pieces behaving differently on opposite orientations. Here's an example:
 
{| border="0" cellspacing="0" style="text-align:center; border-collapse:collapse"
|- style="vertical-align:top;"
|style="padding:4px; width:108px;"|<playfield>
  gggg 
gggggg   
gggggggzz
ggggggggzz
ggggggggg
gggggggg 
gggggggg 
ggggggggg
</playfield>
Rotate CW from entry orientation
|style="padding:4px; width:108px;"|<playfield>
  gggg 
gggggg   
ggggggg 
gggggggg 
gggggggggz
ggggggggzz
ggggggggz
ggggggggg
</playfield>
Z piece goes down
|- style="vertical-align:top;"
|style="padding:4px; width:108px;"|<playfield>
  gggg 
gggggg   
gggggggzz
ggggggggzz
ggggggggg
gggggggg 
gggggggg 
ggggggggg
</playfield>
Rotate CW from "upside-down"
|style="padding:4px; width:108px;"|<playfield>
  gggg 
gggggg  z
ggggggg zz
ggggggggz
ggggggggg
gggggggg 
gggggggg 
ggggggggg
</playfield>
Z piece stays up
|}
 
While ambiguities like this don't happen in ARS, its right-side bias still leads to the infamous [[ARS#Mihara's conspiracy|Mihara conspiracy]].
The [[ARS#Center column rule|centre column rule]] also prevents moves that would otherwise work the same as their inverse:
{| border="0" cellspacing="0" style="text-align:center; border-collapse:collapse"
|- style="vertical-align:top;"
|style="padding:4px; width:108px;"|<playfield>
gg       
gggllggggg
ggggl  ggg
gggglggggg
</playfield>
Rotate CCW
|style="padding:4px; width:108px;"|<playfield>
gg       
ggg  ggggg
gggglllggg
gggglggggg
</playfield>
Works fine, classic ARS twist
|- style="vertical-align:top;"
|style="padding:4px; width:108px;"|<playfield>
gggg     
ggg     
gggglllggg
gggglggggg
</playfield>
Inverse move, rotate CW
|style="padding:4px; width:108px;"|<playfield>
gggg     
gggxx   
ggggx  ggg
ggggxbgggg
</playfield>
Doesn't work, would kick off [[File:BTet.png]]
|}
 
Based on these observations, VRS was designed with strict compliance to the following rules in mind:
* '''Visual consistency:''' If two situations look identical, they are identical, and the same input will give the same results. The only direct consequence of this is that S, Z and I only have two states (horizontal and vertical) instead of four (North, East, South and West)
* '''Reversability:''' If a rotation works, then the inverse rotation should be accounted for. While a valid setup for some reverse rotations may be impossible, the necessary kick is available anyway. This happens with the T piece in SRS on a couple rotations:
{| border="0" cellspacing="0" style="text-align:left; border-collapse:collapse"
|-
|style="padding:4px;width:68px;"|<playfield>
gt 
gttgg
gt--g
gg-gg
</playfield>
|This kick exists
|-
|style="padding:4px;width:68px;"|<playfield>
-- 
ttt
  t 
</playfield>
|Despite not being possible to make this kick happen in normal gameplay, it is still coded in out of reversability
|}
* '''Horizontal symmetry''': A setup and its mirror conditions give mirrored results. This prevents the rotations and kicks to be biased towards one side only. For example:
{| border="0" cellspacing="0" style="text-align:left; border-collapse:collapse"
|-
|style="padding:4px;width:108px;"|<playfield>
g       
g  i-   
gggiii gg
ggg-g ggg
ggggggggg
</playfield>
|If this is what happens when rotating CW on this state...
|-
|style="padding:4px;width:108px;"|<playfield>
        g
    -z  g
gg zzzggg
ggg g-ggg
ggggggggg
</playfield>
|... then this is what happens when rotating CCW on this state
|}
* '''Kick thoroughness:''' Do not leave gaps in the list of kicks you attempt, and attempt rotations closer to the kickless rotation first. For example, don't attempt a kick 2 cells up without trying 1 cell up first, or a diagonal down-left kick without trying a down kick and a left kick before that. Here's a visual example of a situation where SRS does '''not''' follow this rule, and which is probably the main inspiration for this rule:
{| border="0" cellspacing="0" style="text-align:left; border-collapse:collapse"
|-
|style="padding:4px;width:108px;"|<playfield>
gggg     
g       
glll     
glgggggggg
g-gggggggg
g--ggggggg
</playfield>
|If this is what happens when rotating CCW on this state...
|-
|style="padding:4px;width:108px;"|<playfield>
         
gggg     
g       
glll     
glgggggggg
gxxggggggg
</playfield>
|... then why would this not happen when rotating CCW on this state?
|}
 
=== Base rotations and the I piece drift ===
Defining the base rotation of L, J, T under these rules is not a problem - just make them rotate around their visual centre like SRS does and notice that it works: L and J perfectly mirror eachother, and T perfectly mirrors itself.
{| border="1" cellspacing="0" style="text-align:center; border-collapse:collapse"
|-
|style="padding:4px;"|<playfield>
s
scs
 
</playfield>
|style="padding:4px;"|<playfield>
s
cs
s
</playfield>
|style="padding:4px;"|<playfield>
 
scs
s
</playfield>
|style="padding:4px;"|<playfield>
s
sc
s
</playfield>
|-
|style="padding:4px;"|<playfield>
  z
zcz
 
</playfield>
|style="padding:4px;"|<playfield>
z
c
zz
</playfield>
|style="padding:4px;"|<playfield>
 
zcz
</playfield>
|style="padding:4px;"|<playfield>
zz
c
z
</playfield>
|-
|style="padding:4px;"|<playfield>
ici
 
</playfield>
|style="padding:4px;"|<playfield>
ii
c
i
</playfield>
|style="padding:4px;"|<playfield>
 
ici
  i
</playfield>
|style="padding:4px;"|<playfield>
i
c
ii
</playfield>
|}
 
S and Z have to be two-state however. The two states were chosen so that the vertical state "reaches down", as this allows more spins to be done with kicks. As for the lateral placement, it was inspired by [[Sega rotation]] and [[The New Tetris]], where the space in the middle column occupied by the piece is always at the same place.
{| border="1" cellspacing="0" style="text-align:center; border-collapse:collapse"
|-
|style="padding:4px;"|<playfield>
oo
oo
 
</playfield>
|style="padding:4px;"|<playfield>
o
oo
  o
</playfield>
|-
|style="padding:4px;"|<playfield>
jj
jj
 
</playfield>
|style="padding:4px;"|<playfield>
j
jj
</playfield>
|}
 
The O piece only has a single orientation.
{| border="1" cellspacing="0" style="text-align:center; border-collapse:collapse"
|-
|style="padding:4px;"|<playfield>
ll
ll
</playfield>
|}
 
However, defining a base rotation for the I piece gives some complications.
 
Let's look at the rotation from horizontal to vertical. Because of the horizontal symmetry rule, the result of a clockwise rotation and a counterclowise rotation in free space have to be mirrors of each other. However, because of the visual consistency rule, the I piece has to be 2-state. This means the only possible place for the I piece to be pushed to the same position on both CW and CCW would be between two columns, which can't work. To work around this, a slight right bias is introduced on the CW rotation, and a slight left bias is introdiced on the CCW rotation.
{| border="0" cellspacing="0" style="text-align:left; border-collapse:collapse"
|-
|style="padding:4px;width:48px;"|<playfield>
  -
  -
tttt
  -
</playfield>
|style="padding:4px;width:48px;"|<playfield>
  t
  t
  t
  t
</playfield>
|Clockwise rotation
|-
|style="padding:4px;width:48px;"|<playfield>
tttt
</playfield>
|style="padding:4px;width:48px;"|<playfield>
</playfield>
|Counterclockwise rotation
|}
 
Now if we look at the rotation from vertical to horizontal, the same problem appears. It is resolved in the same way, by giving a slight right bias to CW rotation and a slight left bias to CCW rotations again.
{| border="0" cellspacing="0" style="text-align:left; border-collapse:collapse"
|-
|style="padding:4px;width:58px;"|<playfield>
  t 
  t 
-t--
  t 
</playfield>
|style="padding:4px;width:58px;"|<playfield>
   
   
tttt
   
</playfield>
|Clockwise rotation
|-
|style="padding:4px;width:58px;"|<playfield>
  t 
  t 
--t-
  t 
</playfield>
|style="padding:4px;width:58px;"|<playfield>
   
   
tttt
   
</playfield>
|Counterclockwise rotation
|}
 
This leads to a peculiar behaviour where one can add up the biases of the individual rotations to move I piece to the side without even pushing the shifting buttons, even without taking advantage of  wallkicks, by rotating in the same direction repeatedly. This behaviour is called ''I piece drift''.
 
{| border="0" cellspacing="0" style="text-align:center; border-collapse:collapse"
|- style="vertical-align:top;"
|style="padding:4px; width:108px;"|<playfield>
    -   
    -   
  tttt 
    -   
         
ggggggggg
ggggggggg
ggggggggg
ggggggggg
</playfield>
Rotate CW
|style="padding:4px; width:108px;"|<playfield>
    t   
    t   
    -t-- 
    t   
         
ggggggggg
ggggggggg
ggggggggg
ggggggggg
</playfield>
Rotate CW again
|style="padding:4px; width:108px;"|<playfield>
         
         
  -tttt 
         
         
ggggggggg
ggggggggg
ggggggggg
ggggggggg
</playfield>
I piece moved to the right one cell
|}
 
=== Wallkicks ===
Coming Soon
<small>''(this is still WIP)''</small>

Latest revision as of 03:35, 27 October 2020

Hello! I'm Oshisaure, a Tetris nerd who likes to do silly things in Tetris games, with a slight specialisation in Rotation Systems and unusual Twists. I have a YouTube channel where I like to share these silly things.

I've also made A Gnowius' Challenge and Puzzle Juggle Trouble, and worked on a Cambridge fork with MillaBasset.

Vulptile Rotation System (VRS)

Although I had made a few over-the-top joke rulesets in the past (see BONKERS for a good example), the question of a proper Rotation System came about when I started having projects about a 1-VS-1 game. I wanted to have a game that differed greatly from the Tetris Guideline, partly because it was incompatible with the idea of my game, partly because I wanted to imply that this game was following its own set of rules. One of the points of difference was, of course, the Rotation System.

Piece colours and entry orientations

While I do not consider things like colour scheme, harddrop vs sonic drop or piece entry rotation to be strictly related to the rotation system itself, they still end up being commonly assiciated into a common ruleset that people get used to - you can ask a guideline player and a TGM player what "the right piece colours" are and they will give you different answers.

Because of this, I've decided to make my own colour scheme as well. To make it easier to play for colourblind people, I've made S and Z follow complemetary hues, as well as L and J. I then filled in the colours to the best of my ability by putting warm colours on the S and L pieces - as they both fit in a left well - and then picking colours that would probably upset anyone using Sega or guideline colours. I ended up with:

  • I: Purple (hue 270°)
  • O: Orange (hue 30°)
  • T: Green (hue 150°)
  • L: Red (hue 0°)
  • J: Cyan (hue 180°)
  • S: Yellow (hue 60°)
  • Z: Dark blue (hue 240°)

As for spawning orientations, I make the pieces spawn flat side down, as that gives the most manoeuvrability in high gravity.

TL;DR: the pieces look like this on spawn

       LL   S     Z  I     OO  JJ
 TTTT  LL  SSS  ZZZ  III  OO    JJ


Now onto the rotation system itself, for real.

Core ideas and base guideline of VRS

A common criticism about SRS is that it feels unpredictable at high gravity. I think that this is mostly an issue on the wallkicks, but that part of it is induced by the S, Z and I pieces behaving differently on opposite orientations. Here's an example:

   GGGG
GGGGGG
GGGGGGGZZ
GGGGGGGGZZ
GGGGGGGGG
GGGGGGGG
GGGGGGGG
GGGGGGGGG

Rotate CW from entry orientation

   GGGG
GGGGGG
GGGGGGG
GGGGGGGG
GGGGGGGGGZ
GGGGGGGGZZ
GGGGGGGGZ
GGGGGGGGG

Z piece goes down

   GGGG
GGGGGG
GGGGGGGZZ
GGGGGGGGZZ
GGGGGGGGG
GGGGGGGG
GGGGGGGG
GGGGGGGGG

Rotate CW from "upside-down"

   GGGG
GGGGGG   Z
GGGGGGG ZZ
GGGGGGGGZ
GGGGGGGGG
GGGGGGGG
GGGGGGGG
GGGGGGGGG

Z piece stays up

While ambiguities like this don't happen in ARS, its right-side bias still leads to the infamous Mihara conspiracy. The centre column rule also prevents moves that would otherwise work the same as their inverse:

GG
GGGLLGGGGG
GGGGL  GGG
GGGGLGGGGG

Rotate CCW

GG
GGG  GGGGG
GGGGLLLGGG
GGGGLGGGGG

Works fine, classic ARS twist

GGGG
GGG
GGGGLLLGGG
GGGGLGGGGG

Inverse move, rotate CW

GGGG
GGGXX
GGGGX  GGG
GGGGXBGGGG

Doesn't work, would kick off BTet.png

Based on these observations, VRS was designed with strict compliance to the following rules in mind:

  • Visual consistency: If two situations look identical, they are identical, and the same input will give the same results. The only direct consequence of this is that S, Z and I only have two states (horizontal and vertical) instead of four (North, East, South and West)
  • Reversability: If a rotation works, then the inverse rotation should be accounted for. While a valid setup for some reverse rotations may be impossible, the necessary kick is available anyway. This happens with the T piece in SRS on a couple rotations:
GT
GTTGG
GT--G
GG-GG
This kick exists
 -
 --
 TTT
  T
Despite not being possible to make this kick happen in normal gameplay, it is still coded in out of reversability
  • Horizontal symmetry: A setup and its mirror conditions give mirrored results. This prevents the rotations and kicks to be biased towards one side only. For example:
G
G  I-
GGGIII GG
GGG-G GGG
GGGGGGGGG
If this is what happens when rotating CW on this state...
         G
     -Z  G
 GG ZZZGGG
 GGG G-GGG
 GGGGGGGGG
... then this is what happens when rotating CCW on this state
  • Kick thoroughness: Do not leave gaps in the list of kicks you attempt, and attempt rotations closer to the kickless rotation first. For example, don't attempt a kick 2 cells up without trying 1 cell up first, or a diagonal down-left kick without trying a down kick and a left kick before that. Here's a visual example of a situation where SRS does not follow this rule, and which is probably the main inspiration for this rule:
GGGG
G
GLLL
GLGGGGGGGG
G-GGGGGGGG
G--GGGGGGG
If this is what happens when rotating CCW on this state...
GGGG
G
GLLL
GLGGGGGGGG
GXXGGGGGGG
... then why would this not happen when rotating CCW on this state?

Base rotations and the I piece drift

Defining the base rotation of L, J, T under these rules is not a problem - just make them rotate around their visual centre like SRS does and notice that it works: L and J perfectly mirror eachother, and T perfectly mirrors itself.

 S
SCS
 S
 CS
 S
SCS
 S
 S
SC
 S
  Z
ZCZ
 Z
 C
 ZZ
ZCZ
Z
ZZ
 C
 Z
I
ICI
 II
 C
 I
ICI
  I
 I
 C
II

S and Z have to be two-state however. The two states were chosen so that the vertical state "reaches down", as this allows more spins to be done with kicks. As for the lateral placement, it was inspired by Sega rotation and The New Tetris, where the space in the middle column occupied by the piece is always at the same place.

 OO
OO
 O
 OO
  O
JJ
 JJ
 J
JJ
J

The O piece only has a single orientation.

LL
LL

However, defining a base rotation for the I piece gives some complications.

Let's look at the rotation from horizontal to vertical. Because of the horizontal symmetry rule, the result of a clockwise rotation and a counterclowise rotation in free space have to be mirrors of each other. However, because of the visual consistency rule, the I piece has to be 2-state. This means the only possible place for the I piece to be pushed to the same position on both CW and CCW would be between two columns, which can't work. To work around this, a slight right bias is introduced on the CW rotation, and a slight left bias is introdiced on the CCW rotation.

  -
  -
TTTT
  -
  T
  T
  T
  T
Clockwise rotation
 -
 -
TTTT
 -
 T
 T
 T
 T
Counterclockwise rotation

Now if we look at the rotation from vertical to horizontal, the same problem appears. It is resolved in the same way, by giving a slight right bias to CW rotation and a slight left bias to CCW rotations again.

  T
  T
 -T--
  T
 TTTT
Clockwise rotation
  T
  T
--T-
  T
TTTT
Counterclockwise rotation

This leads to a peculiar behaviour where one can add up the biases of the individual rotations to move I piece to the side without even pushing the shifting buttons, even without taking advantage of wallkicks, by rotating in the same direction repeatedly. This behaviour is called I piece drift.

     -
     -
   TTTT
     -
GGGGGGGGG
GGGGGGGGG
GGGGGGGGG
GGGGGGGGG

Rotate CW

     T
     T
    -T--
     T
GGGGGGGGG
GGGGGGGGG
GGGGGGGGG
GGGGGGGGG

Rotate CW again

   -TTTT
GGGGGGGGG
GGGGGGGGG
GGGGGGGGG
GGGGGGGGG

I piece moved to the right one cell

Wallkicks

Coming Soon (this is still WIP)